http://bugzilla.opensuse.org/show_bug.cgi?id=1076779 Oliver Kurz <okurz@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |okurz@suse.com Severity|Normal |Major -- 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#c8 Michael Chang <mchang@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lnussel@suse.com --- Comment #8 from Michael Chang <mchang@suse.com> --- *** Bug 1076917 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1076779 Max Lin <mlin@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mlin@suse.com -- 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#c22 --- Comment #22 from Tomáš Chvátal <tchvatal@suse.com> --- Created attachment 759729 --> http://bugzilla.opensuse.org/attachment.cgi?id=759729&action=edit udevadminfo-sed.txt -- 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#c24 --- Comment #24 from Michael Chang <mchang@suse.com> --- Indeed, the output was cluttered the by locale settings, at least my browser interprets those translated string as junks .. EVLINKS=/dev/disk/by-partlabel/ԁŁ\xed\xb0\xa4﴾༁đā䄏츉姯ăℇ龜ĉ䄈䰊規Ǽ䄆肯Āᄆਁ࠱朎ǽᄇࠋԁԑċᄋԄఁ ID_VENDOR_ENC=ATA\x20\x20\x20\x20\x20 PARTNAME=!A$>!!!!!�!!!!!!!�!!� @Frank, What do you think about the cluttered output, is it something wrong ? -- 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#c26 Tomáš Chvátal <tchvatal@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(tchvatal@suse.com | |) | --- Comment #26 from Tomáš Chvátal <tchvatal@suse.com> --- arcarius:~ # LC_ALL=C udevadm info -q property -n /dev/sdb2 | sed -n -e 's/\(.*\)=\(.*\)/\1="\2"/p' | grep -E '^(MD_CONTAINER|ID_PART_ENTRY_(TYPE|SCHEME)|PARTNAME)=' ID_PART_ENTRY_SCHEME="gpt" ID_PART_ENTRY_TYPE="c12a7328-f81f-11d2-ba4b-00a0c93ec93b" Binary file (standard input) matches arcarius:~ # LANG=C udevadm info -q property -n /dev/sdb2 | sed -n -e 's/\(.*\)=\(.*\)/\1="\2"/p' | grep -E '^(MD_CONTAINER|ID_PART_ENTRY_(TYPE|SCHEME)|PARTNAME)=' ID_PART_ENTRY_SCHEME="gpt" ID_PART_ENTRY_TYPE="c12a7328-f81f-11d2-ba4b-00a0c93ec93b" Binary file (standard input) matches Still sadly looks the same. Trying the rpm it fails the same too: arcarius:/home/scarabeus/tmp # os-prober /usr/lib/os-probes/mounted/05efi: eval: line 33: syntax error near unexpected token `(' /usr/lib/os-probes/mounted/05efi: eval: line 33: `Binary file (standard input) matches' 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. -- 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 <fbui@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(fbui@suse.com) | --- Comment #28 from Franck Bui <fbui@suse.com> --- Hi Michael, (In reply to Michael Chang from comment #27)

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#c30 --- Comment #30 from Franck Bui <fbui@suse.com> --- Yes either you use blkid or as suggested in comment #16, the udev db needs to be exported. -- 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#c32 Franck Bui <fbui@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(fbui@suse.com) | --- Comment #32 from Franck Bui <fbui@suse.com> --- 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). 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. -- 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#c34 --- Comment #34 from Michael Chang <mchang@suse.com> --- (In reply to Michael Chang from comment #29)

(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#c36 --- Comment #36 from Michael Chang <mchang@suse.com> --- (In reply to Tomáš Chvátal from comment #26)

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#c38 --- Comment #38 from Michael Chang <mchang@suse.com> ---

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#c40 --- Comment #40 from Franck Bui <fbui@suse.com> --- (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 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#c42 --- Comment #42 from Michael Chang <mchang@suse.com> --- (In reply to Franck Bui from comment #40)

(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.