Installed system does not boot on EFI only systems #82
Comments
|
@HTPC-Schrauber Thanks for the report.
Was the USB key booted in EFI mode? Our installer basically senses to install in EFI or otherwise depending on how it was booted. Many systems will a non EFI boot of USB and then 'flag' our installer to install a non EFI install. Definitely worth a try as I've seen this behaviour myself. |
|
As I said, the System has CSM disabled. So it can only boot in EFI mode. |
|
@HTPC-Schrauber I'm assuming here you are referencing our v4 "Built on openSUSE" DIY installer: https://github.com/rockstor/rockstor-installer Our old 2017 CentOS based installer from SourceForge is now pretty dated and we last release an update for that around a year and a half ago.
|
Not necessarily but possibly. Some systems still allow for external/usb boot by older methods. You could check. See my last comment for a question about the installer as our old one was known to be a bit duff on EFI !! |
|
I am on V4 DIY installer. OK, I will check if I bootet in EFI mode for sure. |
OK, that's good then. Yes, some bios firmware allows for you to pick the boot mode for 'external' media of which a USB key is often singled out dur to it's common place use in os installs. On a system I remember seeing this anomaly on I had two choices with which to boot the installer. Choosing the wrong one caused a boot error about not being able to find a efi file of some sort. In your case this may be different due to boot differences. Also some systems are pretty picky with regard to add in sata cards/adapters etc. Definitely worth playing around a tad. But yes the installer, build by kiwi-ng is dual capable but we may have had a recent bug of sorts of course. |
|
OK, this was strange. I checked and the system booted from USB in EFI mode. Then I tried to run: This worked without an error. And after this the system was bootable in EFI mode without CSM. Thanks for your support. |
|
@HTPC-Schrauber Hello again, and glad you've found a work around but this should not be necessary and definitely represents a bug or anomaly in the installer build. Do you still have the kiwi-ng log from when you build the installer? Re:
this size is intentional and should be just fine. We are not accomodating any other OS's here and our upstream of kiwi-ng did have an issue with this partition being too small but that was resolved when they moved from 15 MB to 20 MB here: And we specify 64MB across all our profiles to be safe and consistent. I'm going to re-open this issue as although you found a work around for the failure this failure may still be caused by a bug somewhere along the line. |
|
@HTPC-Schrauber If you still have your kiwi-ng build log then we can more easily/usefully submit this to upstream as a new issue as our own config has not changed in this regard for a long time. So it may be relevant / observable by them. I'm unfortunately unable to re-produce myself as I'm in the process of moving and have non of my prior test hardware available so have no UEFI/EFI hardware to test install/reboot an install on. I've had a look over their recent issues and pull requests in kiwi-ng and although they have made some changes in this area (grub), they are a super active project, there is nothing that looks just like your own report. But it may be a new thing that they have yet to have reported. https://github.com/OSInside/kiwi Let us know if you still have the kiwi-ng build log or if you are able to reproduce this again with a fresh build, grabbing it's log, as then we can report upstream with some more information that may help them work our what may have caused this. Also having this issue open should help with other users of our own finding and filling in more info. Thanks again for the report and hopefully we can get to why this happened as it certainly is not intended that you have to re-install grub by-hand at the end of the install. The log you are looking for would be called image-root.log /home/kiwi-images/build From example my last build I have the following grub mentions lines: As you can be seen there are a lot of entries. I'm noting mine down here for reference but I think I'm due to update my kiwi-ng as it goes. But I'm not able to do this until we are past our beta testing of the images I've created with this version. Which to date have not had this reported issue. So in short if your can attache a build log of a failing installer then that would be fantastic as we can them more legitimately bother the good folks at kiwi-ng with something for them to look over as our expertise basically ends with kiwi-ng config file in this repo and our testing of the resulting images. Our Readme in this repo encourages the use of the latest version but I have to take care with my own version use reliant on the timing of our pending Stable release and it's associated installers which are currently being closed beta tested by folks on the forum. Once we have known good installers our I and then update and further investigate myself assuming I have test hardware available again soon. |
|
I will look into this futher. |
|
Hi, |
|
@HTPC-Schrauber Cheers. |
|
Noting elements as I read through the log. At the stage when the grub is being installed on the target image /dev/loop0 i.e. the line just before: we have: so we have And A btrfs subvol. Which is unchanged from prior working efi boots. |
|
From you own earlier build log, whose resulting image is untested in efi boot (moving so hardware access issues currently) is identical configured: So looking earlier in the log of my build here for /dev/loop0p2 we have: I.e. second partition, equivalent of say sda2, for the fat16 part of the boot image. and the fstab of this install: And @HTPC-Schrauber earlier image partitions also look to be identically arrangted: So all looks to be OK assuming the 'efi_device': '/dev/mapper/loop0p2', bit is being enacted as expected. Very sorry folks I'm a little hampered by my current circumstance re no 'real' EFI hardware to test on as we need confirmation that this is not a single machine, i.e. custom efi path in bios type thing. But as indicated the resulting EFI fat16 partition is in fstab at /boot/efi as @HTPC-Schrauber ended up passing to grub in order to achieve a successful boot via a grub re-install:
I'll have another look upstream for some potential changes as we definitely used to be able to boot in EFI if our installer was similarly booted in EFI mode. In anyone can ship in with some more analysis then great. I'm reluctant to take this upstream to the kiwi-ng until we have a more concrete understanding of what may have gone wrong. I'm thinking myself that we have a failure to write the fat16 contents to the target 64MB /dev/mapper/loop0p2 which is our eventual sda2 EFI partition. And that maybe the required files are instead ending up in the btrfs subvol of "@/boot/grub2/x86_64-efi". But we clearly see the 'efi_device': '/dev/mapper/loop0p2', passed to grub at least apparently from the log. |
|
An install I have here has: With /boot/efi containing only the "EFI" directory and in turn this contains only the directory "BOOT". |
|
Thanks a lot for the dissection, @phillxnet! Command.run(
[
'chroot', self.root_mount.mountpoint,
self._get_grub2_install_tool_name(
self.root_mount.mountpoint
)
] + self.install_arguments + [
'--directory', module_directory,
'--boot-directory', boot_directory,
'--target', self.target,
'--modules', self.modules,
self.install_device
]
)From there the target seems defined below for the x86_64 arch: if Defaults.is_x86_arch(self.arch):
self.target = 'i386-pc'
self.install_device = self.device
Hopefully this helps. |
|
I could build a new ISO using the Leap15.3_x86 profile but I have not had time to test it yet. For reference, here's the info: The "simple" kiwi log (stdout, helpful to locate timestamps of interest) is: The full build log: I'll try to find some time later today to test this ISO on real hardware. |
Hello guys, I'm having the same situation. What's also strange in my situation is, that the root label is missing Thanks a lot. Edit: CSM is turned off |
|
@slowhand93 Thanks for the confirmation. Much appreciated.
I believe @HTPC-Schrauber ran the grub re-install command at the very end of the installation process; that is before the first reboot. At that point the system is pretty much fully functional, it just doesn't appear to have had it's efi grub configured correctly. Hence the first reboot (from the new install) failing and dropping you to the dracut-emergency shell. Your other issues re labels size etc may all be resolve once this first successful boot is accomplished. Let us know how it goes. And thanks again for confirming this bug. |
I disabled CSM (I believe) on my motherboard, forced UEFI only as boot mode, and booted the USB containing that ISO in UEFI mode. Very first boot, we have: and and
Finally: and |
|
@FroggyFlox Thanks for the additional test:
So we have a successful uefi boot of an install resulting from one of our 4.0.9-0 iso's. Can you confirm that this boot was actually from the resulting install as the USB key (the installer) has the ability to boot an installed system. I don't think it would work in this case however but given the USB key (installer) is still in play here it would be good to completely rule this out. Also upon an assumed drive only efi/uefi boot do you have contents in: Which I'm assuming is proof of an effective efi boot? Thanks for this. Initially reassuring but we now have a some do and some don't type arrangement!! Assuming no anomalies in your system drive only boot of the resulting install. |
|
@FroggyFlox Thanks for a back-channel conversation it seems I have again got the wrong end of the stick. So @FroggyFlox's info above represents the boot of the installer, i.e. end of install state post reboot. Not a resulting reboot state of the resulting install. I'll try and emulate a uefi/efi boot here soon so I can keep up :). Sorry for the noise folks. |
@phillxnet Thanks for your answer. I wasn't able to get it booting up. Then I saw that the rockstor download page links to a 15.3 iso which did work for me. I noticed, that for whatever reason in my previous attempts the installer didn't went through completely. It just stopped after the copying process and led me to dracut shell. Please allow me an OT question: Why is the btrfsprogs version still very old? There have been many changes in the last few years |
@phillxnet, I just another quick look at the build log I uploaded above and looking at the |
|
I did a fresh Install with the new ISO from rockstor website. Directly after the installer I looked at the output from the commands from @FroggyFlox. After my grub2-install command there is only one change: So now there is a /boot/efi/EFI/rockstor directory. |
|
I've now added an installer-uefi test instance to our test setup. setup via: Our kvm-pool setupOur target system diskMachine definition fileMachine createFirst boot (defaults to secure boot)
Post secure boot disableDevice Manager -> Secure Boot Configuration (post the required un-tick change and reset)
We have a successful installer UEFI boot with the following pre-initial reboot state: But most noteworthy re this issue is we can also boot, in UEFI, the resulting install. Details to follow. |
|
Continuing on from above UEFI proof of boot on Tiano ovmf. Select HDD from boot manager:Pressing escape at Grub first screen and then "exit" at the grub command line and we are in the EUFI interface.
We are presented with our installed grub setup:
This proceeds as expected and we have not had to re-install grub on a UEFI only system. and: @FroggyFlox has reproduced @HTPC-Schrauber 's experience and proved the work around but due to the above proof of concept on a uefi only system I think we are seeing something else here other than a non uefi bootable install as the result of at least a 4.0.9-0 image. I don't know quite what yet, unless this is some interplay on some motherboard firmware. We are not currently secure boot compatible so maybe there is some firmware setting that is causing some issues here on some hardware setups. As seen my test system has secure boot disabled but is not capable of booting anything non UEFI by design, from the given referenced anyway. More input on this issue is welcome as always but I'm currently putting this down to a hardware/firmware anomaly which would be great to find but I don't think we can do much about it given we have a proven uefi boot here. At least on the reference ovmf firmware and the given machine definition. I will endeavour to now test on this machine also before releasing x86_64 installers as I had previously only test installed on a bios KVM. However we predominantly rely on the expertise of our upstream kiwi-ng for the details of our installer boot capabilities. And with this Tiano firmware proof of boot in UEFI I'm not sure we have much to take upstream currently. |
|
A potentially important caveat with my prior proof of concept posts: Using the installers grub boot hdd option ends up sending us to the UEFI (i.e. it fails to boot hdd from installer). Noting in case this rings-a-bell for our observations here. |
|
Linking to a potentially interesting upstream report. Although in the linked report issue the base os is debian not a JeOS Leap such as in our case. Given we now have at least 2 reports of failed uefi boot of the resulting install but proven uefi boot within a kvm/libvirt Tiano ovmf based system (detailed earlier) the linked issue may be contextually interesting as it expresses a uefi boot failure (with grub-install work-around) expressed in a virtual box uefi instantiation. Apologies if this is just noise. But we are still struggling with this one. |
|
Linking to another upstream issue, this time for CentOS Stream 9 (as apposed to our openSUSE Leap 15.3 base), where UEFI fails to boot. This time it shares our expandable OEM install profile: "efibootmgr is not called on the OEM expandable image" OSInside/kiwi#2140 Apologies again if this is just noise. But we are still struggling with this one. As we have set/known partitions we may well be able to hard-code a config for a call to efibootmgr via a oneshot post-install run. Or incorporate something a little more fancy such as is referenced in the sited issue. We do the like (and need-not any longer I suspect) for our "Rebuild dracut initrd for this host" service. Or we could incorporate something a little more fancy such as is referenced in the sited issue, but ideally this does look to be an upstream issue. But the discrepancy between 'some' real hardware uefi boot failures and the above ".. UEFI proof of boot on Tiano ovmf" remains, and is likely a pointer to fussiness or work-around capability differences in UEFI implementations. |
|
We have, since these reports, updated our kiwi-ng to the latest twice. Most recently to 10.1.18: current as of this comment. Once we have installers released using this far newer variant we need to confirm what, if anything, is required at our end re config etc to ensure this is fixed: or wont be fixed in view of what may be required. I.e. we do not need the additional load of providing non-uefi and uefi installers if it comes to that. We should provide the minimum number of installer that are able to instantiate an install. uefi is a preferred capability but not a show-stopper. |
|
Having recently rebuild and uploaded a new set of installers, this time built using kiwi-ng v10.1.10, and |
I tried to install the build image on a system, which is set to EFI. So CSM is disabled on this system.
The USB strick bootet without any problem. Installation went fine.
But after reboot the installed system does not boot.
The UEFI firmware does not even find any bootable disk.
So I think there is a problem with the grub installation on this system.
The text was updated successfully, but these errors were encountered: