Bug 13073

Summary: CU174 Testing - failure when trying to install fresh from iso
Product: IPFire Reporter: Adolf Belka <adolf.belka>
Component: ---Assignee: Adolf Belka <adolf.belka>
Status: CLOSED FIXED QA Contact:
Severity: Crash    
Priority: Will affect most users CC: arne.fitzenreiter, michael.tremer, peter.mueller
Version: 2Keywords: Blocker
Hardware: x86_64   
OS: Unspecified   
Attachments: Screenshot of TTY2 while freshly installing Core Update 174
Screenshot of the output of "grub-install --verbose" run in chroot after installation of Core Update 174
Screenshot of the output of "sh -x /usr/bin/install-bootloader" run in chroot after installation of Core Update 174
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

Description Adolf Belka 2023-03-29 17:40:50 UTC
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.
Comment 1 Adolf Belka 2023-03-29 17:55:25 UTC
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.
Comment 2 Arne.F 2023-03-31 16:14:22 UTC
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.
Comment 3 Peter Müller 2023-04-02 17:15:59 UTC
Thank you for reporting this.

This looks like a show-stopper for the release of Core Update 174, I'll investigate and report back.
Comment 4 Peter Müller 2023-04-02 20:36:48 UTC
I can reproduce this here as well.
Comment 5 Peter Müller 2023-04-02 20:37:14 UTC
CC'ing Michael as this bug will delay the release of Core Update 174.
Comment 6 Peter Müller 2023-04-02 21:23:03 UTC
Created attachment 1144 [details]
Screenshot of TTY2 while freshly installing Core Update 174
Comment 7 Peter Müller 2023-04-02 21:23:47 UTC
Created attachment 1145 [details]
Screenshot of the output of "grub-install --verbose" run in chroot after installation of Core Update 174
Comment 8 Peter Müller 2023-04-02 21:24:18 UTC
Created attachment 1146 [details]
Screenshot of the output of "sh -x /usr/bin/install-bootloader" run in chroot after installation of Core Update 174
Comment 9 Peter Müller 2023-04-02 21:24:56 UTC
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
Comment 10 Peter Müller 2023-04-02 21:28:33 UTC
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.
Comment 11 Arne.F 2023-04-04 06:33:43 UTC
I have reverted the grep update for testing but the error is still present.
Comment 12 Arne.F 2023-04-04 12:54:09 UTC
this looks related...
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030846
Comment 13 Arne.F 2023-04-04 13:49:05 UTC
After revert the e2fsprogs update grub is now installed again.
Comment 14 Peter Müller 2023-04-04 20:06:32 UTC
Thank you very much, reverted the e2fsprogs update: https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=d3a520fa68d2d0198ddca827a96a4e2cbb595d8a
Comment 15 Peter Müller 2023-04-07 13:33:03 UTC
I can confirm that installing GRUB works fine again after the e2fsprogs update has been reverted.
Comment 16 Michael Tremer 2023-04-11 10:31:56 UTC
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.
Comment 17 Adolf Belka 2023-04-15 10:56:23 UTC
Fix has been merged into master build b7c95899
Comment 18 Adolf Belka 2023-04-15 10:59:14 UTC
Tested out a fresh install of CU174 Testing using build b7c95899 and can confirm it boots successfully.
Comment 20 Adolf Belka 2024-05-09 10:47:55 UTC
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.
Comment 21 Adolf Belka 2024-05-10 10:09:25 UTC
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.
Comment 22 Adolf Belka 2024-05-11 10:55:59 UTC
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.
Comment 23 Adolf Belka 2024-06-10 09:05:54 UTC
the patch for e2fsprogs has been merged into next (CU187)

https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=26f53e2c2e70aa5e6adb06f53f7a2414bbe0e518

I have tested this out in a vm and it worked without problems. Once CU187 goes to Testing release then it can be formally tested.
Comment 24 Adolf Belka 2024-07-16 07:48:27 UTC
Core Update 187 Testing has been issued

https://www.ipfire.org/blog/ipfire-2-29-core-update-187-is-available-for-testing
Comment 25 Adolf Belka 2024-07-16 12:10:59 UTC
Verified with a fresh install of CU187 Testing and the updated e2fsprogs, that the fresh install worked without any problems.

This confirms that this bug has been fixed in CU187 Testing.