Unable to install on 4k drive #385
Comments
|
same behavior on coreos-installer 0.1.3-alpha.0 |
|
You can try booting with Wonder if somehow we didn't wait long enough for the partitions to show up. Is this reproducible? We might just need to bump the timeout. Or maybe we should change the strategy so we keep looping/waiting in |
|
thanks @jlebon, re-running manually has the same result. here is some inspection post failure: |
|
Right yeah, inspecting in post won't work because the installer clears the partition table. If you're in a position to compile Rust code, you could give this PR a try: coreos/coreos-installer#155. |
|
Grabbed an strace as well. https://gist.github.com/bcg62/91f0339a3b925b17c609d945afcd0bc2 I'll see if I can build and test the patch. thanks. |
|
more info but still failed. |
|
I increased the retry during the loop took some more inspections |
|
Hmm, what kind of setup are you installing on? |
|
bare-metal, attempting an install via pxe boot. EFI, megaraid-sas-9270-8i, HGST HUC101812CS4200 4k drives Looking for anything in specific? |
Ahh I think that might be the issue. My understanding is that 4k disks will require separate metal images which we do not yet produce. Our current metal images assume traditional 512b sector-sized drives. |
jlebon
changed the title
|
Ahh yup, this was discussed here: #18 (comment). Transferring this ticket to the main tracker. |
|
reading though #18 is seems like there isn't currently a work around? Is there a way or documentation on how someone might be able to build their own 4k compat images? |
I almost wonder if we could handle this case as part of the "complex root devices" work. i.e. rather than make a separate metal image we act like we would if someone requested a different filesystem on ignition during boot. There's probably a million reasons why this wouldn't work, but I'd really like to not have to ship a separate set of metal images :( |
|
I started on this in coreos/coreos-assembler#1130. If you're feeling adventurous and want to test that patch, you can build cosa with it, and then build FCOS as described in the cosa README. :)
For 4k native setups, I don't think this is doable on first boot, because the system wouldn't even be able to boot in the first place. But it might be doable to do at install time via coreos-installer. E.g. it could detect that the target disk is 4k and translate the metal image on the fly? Not sure how feasible that is though. My understanding is that it's not just a bit-level transformation, but would require changing the filesystem level itself since it assumes 512b sectors (see #18 (comment)). Worth exploring the idea though with some storage folks. |
I agree with @jlebon here. The installer will splat the disk down and then the complicated disk setup work won't even come to play and worse, prepping /boot is out of scope for complicated disks. For the time being, we'll need a new disk target. |
|
coreos/coreos-installer#167 teaches coreos-installer to detect this case and fail with a clearer error message. |
|
Just did a quick experiment with FAT32 likewise fails: ext4 works fine, and all three are fine if created on a 4k-sector disk but mounted from a 512-byte sector disk. That's not an argument that we should just use 4k sectors for everything, though. XFS, at least, is presumably relying on atomic sector writes. |
First, add a new `buildextend-metal4k` command to create 4k disk images.
Then, teach `kola` and `cosa run` to read these images.
To test:
cosa run -I metal4k
One potentially controversial bit here is that this requires a newer
libguestfs which isn't in f31 yet, so we pull it from f32 for now.
Closes: coreos/fedora-coreos-tracker#385
First, add a new `buildextend-metal4k` command to create 4k disk images.
Then, teach `kola` and `cosa run` to read these images.
To test:
cosa run -I metal4k
One potentially controversial bit here is that this requires a newer
libguestfs which isn't in f31 yet, so we pull it from f32 for now.
Closes: coreos/fedora-coreos-tracker#385
First, add a new `buildextend-metal4k` command to create 4k disk images.
Then, teach `kola` and `cosa run` to read these images.
To test:
host$ cosa run -I metal4k
...
vm$ sudo fdisk -l /dev/vda
...
Sector size (logical/physical): 4096 bytes / 4096 bytes
...
One potentially controversial bit here is that this requires a newer
libguestfs which isn't in f31 yet, so we pull it from f32 for now.
Closes: coreos/fedora-coreos-tracker#385
First, add a new `buildextend-metal4k` command to create 4k disk images.
Then, teach `kola` and `cosa run` to read these images.
To test:
host$ cosa run -I metal4k
...
vm$ sudo fdisk -l /dev/vda
...
Sector size (logical/physical): 4096 bytes / 4096 bytes
...
One potentially controversial bit here is that this requires a newer
libguestfs which isn't in f31 yet, so we pull it from f32 for now.
Closes: coreos/fedora-coreos-tracker#385
|
Hmm, or maybe a cleaner alternative is having a |
|
@jlebon from the point of |
|
@lucab In coreos/fedora-coreos-releng-automation#87, I went back to just using |
Some work has happened since then. Is the above still the current status? |
|
Yes, this is done. The download page already lists 4k images but I've submitted a patch to give it a better label and have it listed near the regular raw image: https://pagure.io/fedora-web/websites/pull-request/104 |
|
Let's leave this open until coreos-installer can automatically select 4k images and/or we've documented how to install them. |
|
Oh right, I totally forgot about that part. (I actually did start on that, which is probably why I got mixed up and thought it was done already!) |
|
coreos-installer feature request: coreos/coreos-installer#201 |
|
Let's also add CI coverage to the list of things missing before closing this out completely. |
|
Kola support for testing metal4k added in coreos/coreos-assembler#1312 and part of coreos-assembler CI. coreos-installer support and CI testing added in coreos/coreos-installer#203 and pipeline testing in coreos/fedora-coreos-pipeline#218. So we just need a new coreos-installer release now. @dustymabe Is the new procedure here to leave this open until that happens or do we close it and tag it with something? |
|
The fix for this landed upstream. It is now pending a testing stream release. |
dustymabe
added
the
status/pending-testing-release
|
we're still waiting on that |
Yes, correct. |
|
The fix for this went into testing stream release |
dustymabe
added
status/pending-stable-release
|
The fix for this went into stable stream release |
dustymabe
removed
the
status/pending-stable-release
|
is this fixed, i still encounter this issue, install os from pxe env. the pxelinux.cfg file is: the report error still be: coreos-installer install /dev/sda --ignition /tmp/coreos-installer-hmtgYF --firstboot-args rd.neednet=1 ip=dhcp BOOTIF=01-3c-2a-1d-da-44 --image-url http://10.30.0.109/fedora-coreos-31.20200505.3.0-metal.x86_64.raw.xz --insecure Error: parsing arguments |
|
Assuming I see you are using the wrong metal image for a 4k sector drive. Could you try with the 4k metal image? |
|
how did you build the image with 4K sector size? |
|
|
Bug
Host Operating System Version
31.20200127.3.0
Target Operating System Version
31.20200127.3.0
coreos-installer Version
coreos-installer 0.1.2
Expected Behavior
boot drive part partitioned
Actual Behavior
Reproduction Steps
Is there a way to get better debug information to find out why or how this is failing?
The text was updated successfully, but these errors were encountered: