Bug 902982

Michael, could you, please, have a look at the live media and suggest what the reason of the described behavior could be?

Since noticing this bug report, I have tried booting the live KDE (for RC1), with the live image written to USB.

It booted without problem on a Lenovo TS 140 (secure-boot disabled), and on a Dell Inspiron 660 (secure-boot enabled).

I don't have a USB-based CD/DVD reader, so I could not test that.

From your description, my best guess would be that your problem has to do with how you prepared the USB.  For example, it is well known that using "UNetbootin" to prepare a boot USB does not work well with opensuse.

I prepared my USB with a raw copy of the image over the USB device:

dd_rescue openSUSE-13.2-KDE-Live-Build0019-x86_64.iso /dev/sdd

The tricky part of UEFI is getting the boot process started.  If you got as far as the grub2 command prompt, then you already got past that stage.  This suggests to me that grub2-efi is running, but is failing on its search for the install media, which it searches for using UUID.

(Just my two cents).

Hi Aidan,

Can you please run set and attach the screen shot here ? 

grub rescue> set

Most notably I'm interested in the value of $prefix and $root variables. You can also provide that piece of information for a quick check instead of making a screen shot in case it is inconvenient for you. 

Thanks.

Sure! I'll be be sure to attach the screenshot.

But I just would like to let you know that the USB based DVD drive (the LG slim portable DVD writer) did interface as a USB device, but it seems to interface very well with the UEFI bootloader, and even printed out the DVD device name alongside its own device name in the boot options. Given that, wouldn't think any drivers would be the issue, because when I used the LG drive with both Fedora 20 and Ubuntu Live Media the drive worked as it should, properly booting up with the live distro and so on.

Created attachment 612574 [details]
The output from the 'set' command in GRUB shell.

Can you please try running the commands to bring up boot menu ?

grub rescue> set prefix=(cd0)/EFI/BOOT
grub rescue> normal

Thanks.

This is likely a firmware problem, as it's reported path for efi loader image is in /EFI/Boot, while the correct one should be /EFI/BOOT. It could be harmless for looking up files in ESP, as it's formatted vfat and is case-insensitive. But for the installer which looks up most of it's files and contents  in iso9660 fs that become a problem as it's case sensitive.

Until a sane fix can be found and provide. we use a workaround patch and I will include it.

(In reply to Michael Chang from comment #7)
> But for the installer which looks up most of it's files
> and contents  in iso9660 fs that become a problem as it's case sensitive.
>
 
As far as I know ISO9660 is case insensitive?

Depending on how you master it, with Joilet/Rock Ridge extension it could be case sensitive.

Created attachment 636944 [details]
Attempt to boot USB from tumbleweed-DVD-i586-Snapshot20150603

Just struggled with this problem (and other problems with regular 13.2 KDE Live image) the last days:
Hardware:
Asus UX501 with Win 8.1 on internal Micron SSD.

BOOT settings:
CSM disabled, secure boot enabled.

Booting USB stick with current Tumbleweed DVD image (created with imagewriter) 
stops at the "grub>" command prompt.

The "set" command reveals
  prefix=(hd0,msdos1)EFI/BOOT
  root=hd0,msdos1
(for details see screenshot attached).

Issuing the commands
  prefix=(hd0,msdos1)EFI/Boot
  normal
makes the system boot into linux.
I.e. no problem with case sensitivity here.
Please note just the slash i inserted in the prefix path before 'EFI'.

Could you please tell the impact of this bug?
I.e. in which situations booting SUSE live images is compromised (and since when)?

(In reply to Stefan Quandt from comment #12)
> Created attachment 636944 [details]
> Attempt to boot USB from tumbleweed-DVD-i586-Snapshot20150603

Are you sure you attached the right picture? It does not have anything related to booting at all.

> Please note just the slash i inserted in the prefix path before 'EFI'.
>

Both strings you show are exactly the same. Both do not have leading slash.
 
> I.e. in which situations booting SUSE live images is compromised (and since
> when)?

What do you mean "compromised"? Apparently information returned by firmware lacks leading slash. To debug it we would need output from test version of grub; you will need to either enroll additional key or disable secure boot to run it. If you are OK, I'll prepare version with additional debug output.

(In reply to Stefan Quandt from comment #12)
> Please note just the slash i inserted in the prefix path before 'EFI'.
> 

Likely fixed by

commit 7e7293d745ef7c0a13d8cbf12f474843edfdd0ab
Author: Vladimir Serbinenko <phcoder@gmail.com>
Date:   Sat Jan 18 16:41:47 2014 +0100

        * grub-core/kern/efi/efi.c: Ensure that the result starts with /
        and has no //.

Still it would be helpful to verify that it does fix your problem.

Created attachment 636945 [details]
Attempt to boot USB from tumbleweed-DVD-i586-Snapshot20150603

(In reply to Andrei Borzenkov from comment #13)
> Are you sure you attached the right picture? 
Oops, attachment 636944 [details] was a completely wrong file :)

> Both strings you show are exactly the same.
Pardon, what I observe from the "set" command is 
  prefix=(hd0,msdos1)EFI/BOOT
It lacks the'/' before EFI as in original attachment 612574 [details].

And of course for booting properly i use
  prefix=(hd0,msdos1)/EFI/Boot
  normal

> Apparently information returned by firmware lacks leading slash.
Ah, did not know that "EFI/BOOT" comes from the firmware.

I don't know if the Dell XPS 13 9333 has the same UEFI firmware as my Asus UX501, but its the same bug.
The BIOS/UEFI utility of my UX501 is Aptio Setup Utility 2.15.1236 from American Megatrends.

Created attachment 636946 [details]
Attempt to boot USB from tumbleweed-DVD-i586-Snapshot20150603

(In reply to Andrei Borzenkov from comment #13)
> Are you sure you attached the right picture? 
Oops, attachment 636944 [details] was a completely wrong file :)

> Both strings you show are exactly the same.
Pardon, just a typo. What I observe from the "set" command is 
  prefix=(hd0,msdos1)EFI/BOOT
It lacks the'/' before EFI as in original attachment 612574 [details].

And of course for booting properly i use
  prefix=(hd0,msdos1)/EFI/Boot
  normal

> Apparently information returned by firmware lacks leading slash.
Ah, did not know that "EFI/BOOT" comes from the firmware.

I don't know if the Dell XPS 13 9333 has the same UEFI firmware as my Asus UX501, but its the same bug.
The BIOS/UEFI utility of my UX501 is Aptio Setup Utility 2.15.1236 from American Megatrends.

>Attempt to boot USB from tumbleweed-DVD-i586-Snapshot20150603
(responding to c12)

I am not able to make sense of this.

Firstly, you are using the 32-bit installer ("i586").  As far as I know, there is no support for UEFI with that.  You will need the x86_64 installer.

Secondly, as far as I know, the 32-bit installer boots with "syslinux".  So the grub prompt that you are getting is probably coming from somewhere else and not from the DVD installer.

Thirdly, your attachment has some nice scenery, but does not appear to be related to the problem.

(In reply to Stefan Quandt from comment #16)
> Created attachment 636946 [details]
> Attempt to boot USB from tumbleweed-DVD-i586-Snapshot20150603
> 

OK so it confirms 64 bit EFI boot. Would you test grub version with proposed fix?

(In reply to Andrei Borzenkov from comment #18)
> (In reply to Stefan Quandt from comment #16)
> > Created attachment 636946 [details]
> > Attempt to boot USB from tumbleweed-DVD-i586-Snapshot20150603
Hmm, obviously it was not that USB stick which I installed from.

> OK so it confirms 64 bit EFI boot. Would you test grub version with proposed
> fix?

I guess this requires an updated live image.
Of course i could test this, if you provide one.

Created attachment 637068 [details]
Fixed GRUB2 EFI x86_64 unsigned

(In reply to Stefan Quandt from comment #19)
> 
> I guess this requires an updated live image.
> Of course i could test this, if you provide one.

If you are using USB, it does not require full image (I actually do not know how to build one :)

Attached is grub.efi built with patch. Please do the following

1. Disable secure boot. Verify that you still see the problem with secure boot disable.
2. Download attached grub.efi
3. Mount first partition of your USB media; it contains ESP
4. Copy modified grub.efi to /EFI/BOOT on first partition.

Step 1 is critical as image is not signed.

(In reply to Andrei Borzenkov from comment #20)

> If you are using USB, it does not require full image (I actually do not know
> how to build one :)

For what it's worth, you can see how openSUSE image was created from open build service log of livcd project. Here's an example.

  osc rbl openSUSE:13.2:Live/kiwi-image-livecd-gnome.x86_64 standard x86_64 | grep /usr/bin/genisoimage

HTH.

Why do you still use the broken genisoimage instead of the maintained
mkisofs original software?

(In reply to Jörg Schiling from comment #22)
> Why do you still use the broken genisoimage instead of the maintained
> mkisofs original software?

I can't answer it as I'm not the author. I just provide the information might be interested by Andrei.

Thanks.

Maybe I should add an important note regarding EFI:

The program genisoimage is in a state where mkisofs has been in May 2004,
mkisofs since then has evolved a lot.

Genisoimage does not support EFI boots, but mkisofs added support for EFI
via the -eltorito-platform option. Check the man page and use
-eltorito-platform efi

Also check the new option -modification-date that has been added on request
of Oracle in order to allow to have UUIDs in the image.

Regarding the bugs in genisoimage: there are many.... genisoimage typically
creates images with structural problems that do not follow the standard.
These problems have been fixed in mkisofs in Autumn 2006, allowing to 
make backup copies of whole directories trees of bootable disks using 
all correct meta data in Rock Ridge.

(In reply to Andrei Borzenkov from comment #20)
> Created attachment 637068 [details]
> Fixed GRUB2 EFI x86_64 unsigned
> 
> (In reply to Stefan Quandt from comment #19)
> Attached is grub.efi built with patch. Please do the following
> 
> 1. Disable secure boot. Verify that you still see the problem with secure
> boot disable.
With secure boot disabled 
1) the problem occurs using an image of the openSUSE-13.2 KDE live CD (current release) and
2) the problem does not occur with a recent KDE live CD image from 
http://download.opensuse.org/tumbleweed/iso/

I.e. the latter boots fine into KDE, but in KDE i could not run the yast live installer because it always crashes immediately after start (and for that reason i could only succeed with installation by using the released 13.2 CD image (with the workaround of setting prefix as described in comment #12 (and comment #6))).

> 2. Download attached grub.efi
> 3. Mount first partition of your USB media; it contains ESP
> 4. Copy modified grub.efi to /EFI/BOOT on first partition.

After modifying the USB stick as described it properly boots into KDE (problem resolved).

(In reply to Stefan Quandt from comment #25)
> 1) the problem occurs using an image of the openSUSE-13.2 KDE live CD
> (current release) and


Could you please attach screenshot of failed boot?

> 2) the problem does not occur with a recent KDE live CD image from 
> http://download.opensuse.org/tumbleweed/iso/
> 

As far as I know Live images do not even support EFI boot and your original report was for full DVD, not for Live.

> I.e. the latter boots fine into KDE, but in KDE i could not run the yast

How is it related to GRUB inability to find its configuration?

> After modifying the USB stick as described it properly boots into KDE
> (problem resolved).

Sorry, I am not convinced these tests actually tested the problem. You should have used the same image as in comment 16 to be sure we test the same problem.

(In reply to Jörg Schiling from comment #24)
> Maybe I should add an important note regarding EFI:
> 
> The program genisoimage is in a state where mkisofs has been in May 2004,
> mkisofs since then has evolved a lot.
> 
> Genisoimage does not support EFI boots, but mkisofs added support for EFI
> via the -eltorito-platform option. Check the man page and use
> -eltorito-platform efi
> 
> Also check the new option -modification-date that has been added on request
> of Oracle in order to allow to have UUIDs in the image.

Thanks for providing info, I added Steffen and Marcus who could be interested on the information here. 

> 
> Regarding the bugs in genisoimage: there are many.... genisoimage typically
> creates images with structural problems that do not follow the standard.
> These problems have been fixed in mkisofs in Autumn 2006, allowing to 
> make backup copies of whole directories trees of bootable disks using 
> all correct meta data in Rock Ridge.

I don't follow any cdrkit changes and don't know what happened to it, but googling it did reveal they are not as actively maintained as cdrtools and are more problematic. We should take it into account.

Thanks.

(In reply to Andrei Borzenkov from comment #26)
> As far as I know Live images do not even support EFI boot and your original
> report was for full DVD, not for Live.

FYI. The live image supports EFI, at least Tumbleweed image for which I've just tested.
Thanks.

(In reply to Andrei Borzenkov from comment #26)
> (In reply to Stefan Quandt from comment #25)
> > 1) the problem occurs using an image of the openSUSE-13.2 KDE live CD
> > (current release) and
 
> Could you please attach screenshot of failed boot?
I did not state this clear enough in comment 19, but the screenshot attachment 636945 [details] is in fact from booting the openSUSE KDE live CD (from USB).
 
> > 2) the problem does not occur with a recent KDE live CD image from 
> > http://download.opensuse.org/tumbleweed/iso/
 
> As far as I know Live images do not even support EFI boot and your original
> report was for full DVD, not for Live.
The tumbleweed-DVD-i586-Snapshot20150603 was one of the images i downloaded, but of coure it is not for x86-64 and therefor did not boot at all.

> > After modifying the USB stick as described it properly boots into KDE
> > (problem resolved).
> 
> Sorry, I am not convinced these tests actually tested the problem. You
> should have used the same image as in comment 16 to be sure we test the same
> problem.
In fact i did use the same image.
As said it fails to boot without adjusting the '/' in the prefix path. And after applying the patch attachment 637068 [details] to /EFI/BOOT/grub.efi (see instructions in comment 20) it boots into KDE without intervention.

(In reply to Stefan Quandt from comment #29)

> As said it fails to boot without adjusting the '/' in the prefix path. And
> after applying the patch attachment 637068 [details] to /EFI/BOOT/grub.efi
> (see instructions in comment 20) it boots into KDE without intervention.

OK, SR#311701. Thank you for testing!

Thanks Andrei, close as resolved fixed.