[Bug 1076779] New: [Build 20180117][storage-ng?] Windows 10 is not listed in the grub menu
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779 Bug ID: 1076779 Summary: [Build 20180117][storage-ng?] Windows 10 is not listed in the grub menu Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/585823/modules/boot_ windows/steps/1 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers@suse.de Reporter: dimstar@opensuse.org QA Contact: jsrain@suse.com Found By: --- Blocker: --- ## Observation openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-kde_dual_windows10@uefi_win fails in [boot_windows](https://openqa.opensuse.org/tests/585823/modules/boot_windows/steps/1) ## Reproducible Fails since (at least) Build [20180117](https://openqa.opensuse.org/tests/585584) ## Expected result Last good: [20180116](https://openqa.opensuse.org/tests/584036) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&test=kde_dual_windows10&version=Tumbleweed&flavor=DVD&machine=uefi_win) The test was shrinking the windows 10 parition (at least that's what the installer claims) - but upon reboot, grub does not have a boot entry for Windows 10. Eother the bootloader did not get a correct config or the win partition disappeared -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779
Oliver Kurz
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779#c3
Dominique Leuenberger
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779#c8
Michael Chang
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779#c15
Michael Chang
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779
Max Lin
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779#c21
--- Comment #21 from Tomáš Chvátal
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779#c22
--- Comment #22 from Tomáš Chvátal
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779#c23
Tomáš Chvátal
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779#c24
--- Comment #24 from Michael Chang
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779#c25
Michael Chang
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779#c26
Tomáš Chvátal
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779#c27
Michael Chang
I guess this has nothing to do with locale in the end but with mess that windows stored as a name of the /dev/sdb2 partition and that will stay same regardless of the locale of the checking system.
Hi Frank, I'm running out of idea, as to how those junk characters would come and how to deal with them, also what's necessary in order to correctly query EFI System Partition in udev database environment ? Could you please help ? Thanks. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779#c28
Franck Bui
I'm running out of idea, as to how those junk characters would come and how to deal with them,
The "junk" characters are probably the one the user entered when giving a label to the partition. I don't think its value is supposed to be "EFI system partition". The partition label is retrieved by udev via libblkid, in fact you can probably see the same chars with blkid(8). And it's not related to the locale settings at all.
also what's necessary in order to correctly query EFI System Partition in udev database environment ?
I would use the partition type GUID which is C12A7328-F81F-11D2-BA4B-00A0C93EC93B for ESP. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779#c29
--- Comment #29 from Michael Chang
I would use the partition type GUID which is C12A7328-F81F-11D2-BA4B-00A0C93EC93B for ESP.
The problem is partition type GUID not always available in udev info (And that's what leading to the bug report). Are you saying to use blkid to retrieve instead ? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779#c30
--- Comment #30 from Franck Bui
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779#c31
Michael Chang
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779#c32
Franck Bui
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779#c33
--- Comment #33 from Ludwig Nussel
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779#c34
--- Comment #34 from Michael Chang
(In reply to Franck Bui from comment #28)
I would use the partition type GUID which is C12A7328-F81F-11D2-BA4B-00A0C93EC93B for ESP.
The problem is partition type GUID not always available in udev info (And that's what leading to the bug report). Are you saying to use blkid to retrieve instead ?
Worse. :( blkid doesn't provide info about PART "TYPE" GUID, it has only PART "ENTRY" GUID, which is unique to every partition, not useful at all here. lsblk seems to provide PARTTYPE, but the man page looks a bit scary as it also depend on udev to function properly ... In opposite to what we wanted to avoid here. "The lsblk command reads the sysfs filesystem and udev db to gather information." "Note that lsblk might be executed in time when udev does not have all information about recently added or modified devices yet. In this case it is recommended to use udevadm settle before lsblk to synchronize with udev." And even more worse .. Both utility seems not providing PARTTYPE for "msdos" partition scheme, as least it shows empty on my test. I have problem to detect EFI System Partition Table on MSDOS scheme using both tools. I felt literally done with it. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779#c35
Michael Chang
I'm not sure it's the right thing to do though. I don't think udev is supposed to fully work in a chroot (or even in a container).
I'm just curious about why it did work for us in the past. Is it an accident/delusion ?
To answer your question the database is located in /run/udev so this directory can be bind mounted from the host to the chroot. But again it seems a hack and even if it works in your case, relying on udev in a chroot seems fragile.
I tested bind mount /run/udev to the chroot environment and it works. Does that justify an installer bug (in the bootstrap process) ? @Jiri, Would you have any comment? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779#c36
--- Comment #36 from Michael Chang
I guess this has nothing to do with locale in the end but with mess that windows stored as a name of the /dev/sdb2 partition and that will stay same regardless of the locale of the checking system.
I an going to revert the patch, apparently it doesn't work. Sorry for the trouble. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779#c37
--- Comment #37 from Franck Bui
And even more worse .. Both utility seems not providing PARTTYPE for "msdos" partition scheme, as least it shows empty on my test. I have problem to detect EFI System
hmm isn't ESP specific to the GPT partition scheme ? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779#c38
--- Comment #38 from Michael Chang
Anyways, another option would be to run the os-prober outside the chroot, ie within the installation environment and only inject it's findings into the target. Since /etc/grub.d/30_os-prober is quite expensive anyways, I'd favor removing that and converting it into some standalone script that can be called by e.g. YaST when needed rather than each bootloader update. Not sure if that is doable short term though :-)
I agree with you. The only drawback could have is that it changes the behavior as user intervention is needed to run that standalone script after installation (in lieu of YaST). Probably as FATE candidate ? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779#c39
--- Comment #39 from Michael Chang
(In reply to Michael Chang from comment #34)
And even more worse .. Both utility seems not providing PARTTYPE for "msdos" partition scheme, as least it shows empty on my test. I have problem to detect EFI System
hmm isn't ESP specific to the GPT partition scheme ?
No. MSDOS also provides ESP (as PARTTYPE 0xEF). AFAIR our ISO image been use it so that a single image could boot from legacy and uefi firmware. That is saying among all the production firmware really recognize it, not just something only documented in Spec but noone use (or care about). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779#c40
--- Comment #40 from Franck Bui
Worse. :( blkid doesn't provide info about PART "TYPE" GUID, it has only PART "ENTRY" GUID, which is unique to every partition, not useful at all here.
Hmm it does here: $ blkid -p /dev/vda2 -o udev -s PART_ENTRY_TYPE ID_PART_ENTRY_TYPE=c12a7328-f81f-11d2-ba4b-00a0c93ec93b However doing the probing in the host environment as suggested by Ludwig sounds better IMHO. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779#c41
--- Comment #41 from Jiri Srain
(In reply to Franck Bui from comment #32)
To answer your question the database is located in /run/udev so this directory can be bind mounted from the host to the chroot. But again it seems a hack and even if it works in your case, relying on udev in a chroot seems fragile.
I tested bind mount /run/udev to the chroot environment and it works. Does that justify an installer bug (in the bootstrap process) ?
Well, as GRUB installation is running in chroot environment, any path, which is not bind-mounted (or mounted any other way) can have an impact on the boot loader installation, which includes generating the initrd. OTOH: sysfs is mounted during installation, I would expect this to be sufficient, or? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779
http://bugzilla.opensuse.org/show_bug.cgi?id=1076779#c42
--- Comment #42 from Michael Chang
(In reply to Michael Chang from comment #34)
Worse. :( blkid doesn't provide info about PART "TYPE" GUID, it has only PART "ENTRY" GUID, which is unique to every partition, not useful at all here.
Hmm it does here:
$ blkid -p /dev/vda2 -o udev -s PART_ENTRY_TYPE ID_PART_ENTRY_TYPE=c12a7328-f81f-11d2-ba4b-00a0c93ec93b
That "-p" does the trick .. Obviously I was overlooking it, because the short description looks not interested ..
-p Switch to low-level superblock probing mode (bypassing the cache) ...
Anyway, with that option I submitted another fix to use blkid as fallback. https://build.opensuse.org/request/show/580144
However doing the probing in the host environment as suggested by Ludwig sounds better IMHO.
That's to be discussed, and also I'm confused why only "udevadm info" did not communicate with host daemon (or it does, but somehow host daemon looks for chroot instead, which is buggy). The child process forked by yast should inherit the same environment ... -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@novell.com