I was doing a build of CU174 to do some fault finding on some other problem. To test it I had to install IPFire fresh from the CU174 Iso that was produced. This was done on my vm testbed system. After doing the installation and pressing Reboot I got the following message on the console screen. No bootable medium found! Please insert a bootable medium and reboot. I repeated and got the same result. I suspected that I must have done something wrong in my build so I tested it by downloading the latest CU174 version from the nightly directory /master/latest/x86_64/ipfire-2.27-core174-x86_64.iso I also downloaded the b2 hash and confirmed that the download was good. I then did a fresh install with that iso and after pressing Reboot I got the same message as above. So there seems to be a problem with a fresh install of CU174 Testing that is built into the build process and the iso that is created from it.
Forgot to mention. As a check that there was no general problem with installing on my vm testbed I did an install of a CU173 iso into the same vm clone and it rebooted with no problems.
I can reproduce this. In the installer runs /usr/bin/install-bootloader which fails to install grub without detailed messages. I have already tried to revert my riscv patch for grub and it not fix the issue.
Thank you for reporting this. This looks like a show-stopper for the release of Core Update 174, I'll investigate and report back.
I can reproduce this here as well.
CC'ing Michael as this bug will delay the release of Core Update 174.
Created attachment 1144 [details] Screenshot of TTY2 while freshly installing Core Update 174
Created attachment 1145 [details] Screenshot of the output of "grub-install --verbose" run in chroot after installation of Core Update 174
Created attachment 1146 [details] Screenshot of the output of "sh -x /usr/bin/install-bootloader" run in chroot after installation of Core Update 174
Created attachment 1147 [details] Screenshot of the output of "sh -x /usr/bin/install-bootloader" run in chroot after installation of Core Update 174, with target "i386-pc" removed manually
Looks like this issue boils down to GRUB not detecting filesystems properly in Core Update 174, for reasons unknown to me at the moment. Attached several screenshots of how this looks like, both during execution of the installer for Core Update 174, as well as during manual attempts in a chroot environment of the installed system. Removing the "i386-pc" target does not make a difference. There has been a rootfile change regarding GRUB by Matthias (https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=6d3e6cfc16cb734d1923c5bb2c41e70433113a33), but it was subsequently reverted after Arne told me on the phone to do so, since this clashes with RISC-V. So, this is unlikely to be the root cause. Comments/further insights welcome. Will continue working on this tomorrow.
I have reverted the grep update for testing but the error is still present.
this looks related... https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030846
After revert the e2fsprogs update grub is now installed again.
Thank you very much, reverted the e2fsprogs update: https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=d3a520fa68d2d0198ddca827a96a4e2cbb595d8a
I can confirm that installing GRUB works fine again after the e2fsprogs update has been reverted.
In the next release, could we fix this the following way: * Re-apply the e2fsprogs update (I don't want us to get behind on this as GRUB does not release very often but e2fsprogs does). * Import this patch https://git.ipfire.org/?p=thirdparty/grub.git;a=patch;h=7fd5feff97c4b1f446f8fcf6d37aca0c64e7c763 * And maybe this one that was mentioned in the bug report, too: https://git.ipfire.org/?p=thirdparty/grub.git;a=patch;h=2e9fa73a040462b81bfbfe56c0bc7ad2d30b446b This is not urgent, but I think it is a cleaner way and with the next GRUB update we should be able to drop both patches again.
Fix has been merged into master build b7c95899
Tested out a fresh install of CU174 Testing using build b7c95899 and can confirm it boots successfully.
https://blog.ipfire.org/post/ipfire-2-27-core-update-174-released
I have noticed that the patches mentioned in comment 16 never ended up in a patch update submission, which also means that the e2fsprogs package was not updated. I will create a new patch for this that includes the two patches found by @Michael.
I have found that the two patches to fix the problem with ext2 related to Ignore checksum seed incompat feature and Ignore the large_dir incompat feature Are built into grub-2.12 I will therefore do a build with the e2fsprogs version 1.47.0 and see if the problem is now fixed.
I have just done an install of a CU186 build with the updated e2fsprogs source and it installed without having a problem at the Reboot command. So it looks like the patches that were built into grub-2.12 have fixed the problem. I am putting together a patch for the e2fsprogs update.