Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
coreos-install creates ESP with FAT16 instead of the recommended FAT32 #2246
Container Linux Version
coreos-install directly from the master branch, don't know which version that would be
Bare-metal. ASUS laptop (yes, I know this is not the typical target system, but there should be no reason it shouldn't work).
The install-script creates an ESP, using FAT32, that will be recognized by the UEFI firmware and used for booting.
The FAT16 partition is not recognized as a ESP, and hence the system won't boot.
This is probably the ASUS UEFI implementation that is being more strict in what it accepts than others, but as far as I can tell, the UEFI spec does explicitly say that the ESP should use a variant of FAT32.
Nice catch! If you copy the files out of the ESP, reformat the filesystem, and copy the files back, does your system boot? Be sure to label the filesystem
coreos-install is really just downloading and writing a disk image, so the problem is in the formatting tool that runs during image creation. It seems we've always had this bug.
I tried copying the files out and reformatting, but for some reason I get an error about invalid GPT signature when I try booting afterwards. I had to manually add the boot entry, for reasons unknown, so I might have done something wrong there.
I booted using
Would it just be a matter of adding
Container Linux never installs a boot entry; it always boots on EFI via Default Boot Behavior. Installing a boot entry by hand should work, or else deleting all boot entries.
Did the switch to FAT32 at least allow you to make progress, or is it possible that the missing boot entry was the original problem as well?
What was the exact text of the invalid signature message?
On a freshly-installed image, USR-B won't work, and USR-A and default are equivalent except for some detection steps.
I have a two-line patch that adds
Yeah, switching to FAT32 made the partition detected by the firmware, so it was definitive progress. There were no boot entries defined, so it should have used the default boot behavior, but for some reason that didn't happen. Adding the equivalent boot entry worked.
I will try to get time for another attempt this evening, and grab a picture of it so I can get the exact text.
Ok, I suspected as much. This is to be expected then, so the remaining issue is the invalid GPT signature problem. I will get back to you with details about that when I get a chance to look at it.
I pressed enter.
I pressed a key...
Pressing any key here, returns to the GRUB menu, where default, usr-a and usr-b are the options to select from.
I don't know if this is a consequence of the reformatting of the partition, or a separate issue.
wget 'https://users.developer.core-os.net/bgilbert/boards/amd64-usr/1590.0.0%2B2017-11-13-1552/coreos_production_image.bin.bz2' sudo coreos-install -f coreos_production_image.bin.bz2 [...]