[opensuse] Am I doing this custom grub config correctly?
Hi, I'm preparing a new 2 GB disk with GPT partitioning as boot disk on a BIOS only machine, and installed Leap 42.1 on it, for testing. I need grub2 on this system to be able to boot other systems. I could let os-prober do its job, but I do not want to. For starters, it takes long minutes thinking about it (there are six disks with up to 20 partitions), and I don't like the resulting menu, because it tries to boot specific kernels. Instead I want grub2 to chainload the grub instances on the other partitions. So I edit /boot/grub2/custom.cfg like this: menuentry '2:1 - 11.4' { insmod part_msdos insmod ext2 set root='hd2,msdos1' chainloader +1 } However, this means that as I insert or remove hard disks, the locations of those disks may change (hd2 may become hd0, for instance). Instead, I could refer to those other disks using the uuid. So I copied partly the config initially generated by YaST2 and os-prober: menuentry '2:1 - 11.4 uuid' { insmod part_msdos insmod ext2 set root='hd2,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd2,msdos1 --hint-efi=hd2,msdos1 --hint-baremetal=ahci2,msdos1 93f0311e-2a93-49ca-b836-d362ffc84486 else search --no-floppy --fs-uuid --set=root 93f0311e-2a93-49ca-b836-d362ffc84486 fi chainloader +1 } Both methods appear to work. I wonder if I should skip completely the second line, «set root='hd2,msdos1'». But grub2 uses that syntax. What would happen if the disk happens to change instead to, say, 'hd3,msdos1', would grub2 find the new location correctly using the uuid just below? Am I doing it correctly, or should I do it some other way? -- Cheers / Saludos, Carlos E. R. (from openSUSE Leap 42.1 x86_64 (test)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 19/02/2016 20:19, Carlos E. R. a écrit :
Both methods appear to work.
this seems really clever
I wonder if I should skip completely the second line, «set root='hd2,msdos1'». But grub2 uses that syntax. What would happen if the disk happens to change instead to, say, 'hd3,msdos1', would grub2 find the new location correctly using the uuid just below?
Am I doing it correctly, or should I do it some other way?
try removing the offending line completely and see :-) good luck jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/19/2016 08:25 PM, jdd wrote:
Le 19/02/2016 20:19, Carlos E. R. a écrit :
Both methods appear to work.
this seems really clever
Thanks :-)
Am I doing it correctly, or should I do it some other way?
try removing the offending line completely and see :-)
Right. Didn't think of that. -- Cheers / Saludos, Carlos E. R. (from openSUSE Leap 42.1 x86_64 (test)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
19.02.2016 22:19, Carlos E. R. пишет:
Hi,
I'm preparing a new 2 GB disk with GPT partitioning as boot disk on a BIOS only machine, and installed Leap 42.1 on it, for testing.
I need grub2 on this system to be able to boot other systems. I could let os-prober do its job, but I do not want to. For starters, it takes long minutes thinking about it (there are six disks with up to 20 partitions), and I don't like the resulting menu, because it tries to boot specific kernels.
Instead I want grub2 to chainload the grub instances on the other partitions. So I edit /boot/grub2/custom.cfg like this:
menuentry '2:1 - 11.4' { insmod part_msdos insmod ext2 set root='hd2,msdos1' chainloader +1 }
However, this means that as I insert or remove hard disks, the locations of those disks may change (hd2 may become hd0, for instance). Instead, I could refer to those other disks using the uuid. So I copied partly the config initially generated by YaST2 and os-prober:
menuentry '2:1 - 11.4 uuid' { insmod part_msdos insmod ext2 set root='hd2,msdos1'
if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd2,msdos1 --hint-efi=hd2,msdos1 --hint-baremetal=ahci2,msdos1 93f0311e-2a93-49ca-b836-d362ffc84486 else search --no-floppy --fs-uuid --set=root 93f0311e-2a93-49ca-b836-d362ffc84486 fi
chainloader +1 }
grub-mkconfig generates code that looks so complicated because of backward compatibility consideration and to cover different platforms. You know that your grub version supports hints, so you do not need feature check. Also you do not need hints for platforms you won't be booting on anyway. Which reduces it to search --no-floppy --fs-uuid --set=root --hint-bios=hd2,msdos1 93f0311e-2a93-49ca-b836-d362ffc84486 And if you want hints to be useful - go into grub CLI and verify name for each disk. grub-mkconfig lists them in order Linux enumerates them which is not necessary the same as BIOS.
Both methods appear to work.
I wonder if I should skip completely the second line, «set root='hd2,msdos1'». But grub2 uses that syntax.
Syntax?
What would happen if the disk happens to change instead to, say, 'hd3,msdos1', would grub2 find the new location correctly using the uuid just below?
Yes. This is just default. search won't modify variable it it fails (cannot find search target), so this assignment simply defaults root to the value guessed when grub-mkconfig was run. This is probably wrong anyway (see above).
Am I doing it correctly, or should I do it some other way?
Well, it would be useful to check that search was successful and if not, just echo this to inform user, instead of attempting to boot that will likely hang anyway. Like if search ... ; then chainloader else echo Could not find this OS instance, will not boot sleep 10 fi You can even do search in toplevel grub.cfg and generate menu entries only for those OS that are actually present. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-02-20 06:43, Andrei Borzenkov wrote:
19.02.2016 22:19, Carlos E. R. пишет:
menuentry '2:1 - 11.4 uuid' { insmod part_msdos insmod ext2 set root='hd2,msdos1'
if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd2,msdos1 --hint-efi=hd2,msdos1 --hint-baremetal=ahci2,msdos1 93f0311e-2a93-49ca-b836-d362ffc84486 else search --no-floppy --fs-uuid --set=root 93f0311e-2a93-49ca-b836-d362ffc84486 fi
chainloader +1 }
grub-mkconfig generates code that looks so complicated because of backward compatibility consideration and to cover different platforms. You know that your grub version supports hints, so you do not need feature check. Also you do not need hints for platforms you won't be booting on anyway. Which reduces it to
search --no-floppy --fs-uuid --set=root --hint-bios=hd2,msdos1 93f0311e-2a93-49ca-b836-d362ffc84486
Ah, good. Makes sense.
And if you want hints to be useful - go into grub CLI and verify name for each disk. grub-mkconfig lists them in order Linux enumerates them which is not necessary the same as BIOS.
Both methods appear to work.
I wonder if I should skip completely the second line, «set root='hd2,msdos1'». But grub2 uses that syntax.
Syntax?
Well, dunno, do you call it something else? phraseology? I meant that "/boot/grub2/grub.cfg" is written that way.
What would happen if the disk happens to change instead to, say, 'hd3,msdos1', would grub2 find the new location correctly using the uuid just below?
Yes. This is just default. search won't modify variable it it fails (cannot find search target), so this assignment simply defaults root to the value guessed when grub-mkconfig was run. This is probably wrong anyway (see above).
Am I doing it correctly, or should I do it some other way?
Well, it would be useful to check that search was successful and if not, just echo this to inform user, instead of attempting to boot that will likely hang anyway. Like
if search ... ; then chainloader else echo Could not find this OS instance, will not boot sleep 10 fi
I like this. I will use this method.
You can even do search in toplevel grub.cfg and generate menu entries only for those OS that are actually present.
I think I prefer to list them all, then know that someone doesn't work. I could write the menu entry with a "not found" text at top level. But it seems quite some work, I would have to do a lot of reading, and worse, understanding ;-) I'll think about it. Thanks. -- Cheers / Saludos, Carlos E. R. (from openSUSE Leap 42.1 x86_64 (test)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Op 21-02-16 20:02, Carlos E. R. schreef:
On 2016-02-20 06:43, Andrei Borzenkov wrote:
19.02.2016 22:19, Carlos E. R. пишет:
menuentry '2:1 - 11.4 uuid' { insmod part_msdos insmod ext2 set root='hd2,msdos1'
if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd2,msdos1 --hint-efi=hd2,msdos1 --hint-baremetal=ahci2,msdos1 93f0311e-2a93-49ca-b836-d362ffc84486 else search --no-floppy --fs-uuid --set=root 93f0311e-2a93-49ca-b836-d362ffc84486 fi
chainloader +1 }
grub-mkconfig generates code that looks so complicated because of backward compatibility consideration and to cover different platforms. You know that your grub version supports hints, so you do not need feature check. Also you do not need hints for platforms you won't be booting on anyway. Which reduces it to
search --no-floppy --fs-uuid --set=root --hint-bios=hd2,msdos1 93f0311e-2a93-49ca-b836-d362ffc84486 Ah, good. Makes sense.
And if you want hints to be useful - go into grub CLI and verify name for each disk. grub-mkconfig lists them in order Linux enumerates them which is not necessary the same as BIOS.
Both methods appear to work.
I wonder if I should skip completely the second line, «set root='hd2,msdos1'». But grub2 uses that syntax. Syntax? Well, dunno, do you call it something else? phraseology? I meant that "/boot/grub2/grub.cfg" is written that way.
What would happen if the disk happens to change instead to, say, 'hd3,msdos1', would grub2 find the new location correctly using the uuid just below?
Yes. This is just default. search won't modify variable it it fails (cannot find search target), so this assignment simply defaults root to the value guessed when grub-mkconfig was run. This is probably wrong anyway (see above).
Am I doing it correctly, or should I do it some other way?
Well, it would be useful to check that search was successful and if not, just echo this to inform user, instead of attempting to boot that will likely hang anyway. Like
if search ... ; then chainloader else echo Could not find this OS instance, will not boot sleep 10 fi I like this. I will use this method.
You can even do search in toplevel grub.cfg and generate menu entries only for those OS that are actually present. I think I prefer to list them all, then know that someone doesn't work. I could write the menu entry with a "not found" text at top level. But it seems quite some work, I would have to do a lot of reading, and worse, understanding ;-)
I'll think about it.
Thanks.
Another way to do the job is using for every partition a relevant label and then boot and mount by partition-label. like this example: you never haver to search for deviceid or uuid menuentry 'openSUSE 13.2, Linux on fm2 ' --class 'opensuse' --class os{ set label_os='lx-1320' #the partition of / ,if different set label_boot='lx-1320' #the bootpartition where vmliniz and initrd resides # set gfxpayload=1920x1080x32 search --label $label_boot --set root echo '' date echo '' echo 'Boot from..........' $root echo 'OS from..........' $label_os echo '' echo 'Loading Linux 3.16.....-desktop ...' linuxefi /boot/vmlinuz root=/dev/disk/by-label/$label_os resume=/dev/disk/by-label/swap video=1680x1050 splash=verbose quiet showopts initrdefi /boot/initrd } # # menuentry 'Windows 10 (on /dev/sdc1)' --class windows --class os { insmod part_gpt insmod fat search --label --set root EFI0 chainloader /EFI/Microsoft/BOOT/bootmgfw.efi } # # search --filesystem efipartition # search --fs-u # Succes, Hans -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-02-22 09:00, Hans de Faber wrote:
Op 21-02-16 20:02, Carlos E. R. schreef:
On 2016-02-20 06:43, Andrei Borzenkov wrote:
Well, it would be useful to check that search was successful and if not, just echo this to inform user, instead of attempting to boot that will likely hang anyway. Like
if search ... ; then chainloader else echo Could not find this OS instance, will not boot sleep 10 fi I like this. I will use this method.
Well, this syntax is causing me problems. First, prior to getting the menu printed on the screen, I get a few lines about something not found (I'm writing from yesterday memories), and finally, the message "Could not find this OS instance", a delay, then it prints the menu. On some of the menu entries that I know should fail (I intentionally wrote the wrong uuid, for testing), I get the message, then the wait, and then a prompt to press any key. Thus the delay is not needed, I think. I also notice that it searches the floppy drive (yes, I do have a floppy drive in this machine), despite having "--no-floppy". This causes long delays. I just noticed an error on the "custom.cfg" file, as I was going to post the file: menuentry '2:1 - Main (uuid)' { insmod part_msdos insmod ext2 set root='hd2,msdos2' if search search --no-floppy --fs-uuid --set=root 5135ab82-1374-4c30-b9d0-4b56d6d6d6c6 ; then chainloader +1 else echo Could not find this OS instance, will not boot sleep 10 fi } The word "search" is repeated. That maybe the cause of the error(s). I will try to reboot later and see what happens.
Another way to do the job is using for every partition a relevant label and then boot and mount by partition-label. like this example: you never haver to search for deviceid or uuid
Label in grub? Indeed, I use labels on fstab, so using them here would be very nice. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
22.02.2016 15:46, Carlos E. R. пишет:
On 2016-02-22 09:00, Hans de Faber wrote:
Op 21-02-16 20:02, Carlos E. R. schreef:
On 2016-02-20 06:43, Andrei Borzenkov wrote:
Well, it would be useful to check that search was successful and if not, just echo this to inform user, instead of attempting to boot that will likely hang anyway. Like
if search ... ; then chainloader else echo Could not find this OS instance, will not boot sleep 10 fi I like this. I will use this method.
Well, this syntax is causing me problems.
First, prior to getting the menu printed on the screen, I get a few lines about something not found (I'm writing from yesterday memories), and finally, the message "Could not find this OS instance", a delay, then it prints the menu.
On some of the menu entries that I know should fail (I intentionally wrote the wrong uuid, for testing), I get the message, then the wait, and then a prompt to press any key. Thus the delay is not needed, I think.
I also notice that it searches the floppy drive (yes, I do have a floppy drive in this machine), despite having "--no-floppy". This causes long delays.
--no-floppy skips devices with name fd0, fd1, etc. What devices are listed in GRUB CLI (command ls)
I just noticed an error on the "custom.cfg" file, as I was going to post the file:
menuentry '2:1 - Main (uuid)' { insmod part_msdos insmod ext2 set root='hd2,msdos2' if search search --no-floppy --fs-uuid --set=root 5135ab82-1374-4c30-b9d0-4b56d6d6d6c6 ; then
Why second "search"? Syntax is compatible with UNIX shell, "if" is followed by command; second "search" here is interpreted by command "search" and results in error.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-02-22 14:20, Andrei Borzenkov wrote:
22.02.2016 15:46, Carlos E. R. пишет:
--no-floppy skips devices with name fd0, fd1, etc. What devices are listed in GRUB CLI (command ls)
I can't try just now, but I will, thanks. :-)
I just noticed an error on the "custom.cfg" file, as I was going to post the file:
menuentry '2:1 - Main (uuid)' { insmod part_msdos insmod ext2 set root='hd2,msdos2' if search search --no-floppy --fs-uuid --set=root 5135ab82-1374-4c30-b9d0-4b56d6d6d6c6 ; then
Why second "search"? Syntax is compatible with UNIX shell, "if" is followed by command; second "search" here is interpreted by command "search" and results in error.
Because my fingers copy-pasted badly (not in the email, but on the grub config file) O:-) I think that this is what caused the errors, but I have been unable to test it yet. Busy... :-( I actually noticed the error while I was writing the other post. It happens to me often: while I write the post I have to examine the facts and clarify them in my mind, and then I discover the cause of the problem that had eluded me for long time. So I still post the email, as a log of problem tracing, that may help me and others in case of a similar problem. I guess I write too confusedly. Sorry. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlbLh/cACgkQja8UbcUWM1xtWAD9HuatB0CfJ1HfAnqBF9nF5mAX V9fpFj2w863nbviiC8kA/i+d3OwyxnTw+NmhvrZ4KCpHL/j+/2RbLhLrEnMKbf+R =JNWz -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-02-22 23:13, Carlos E. R. wrote:
On 2016-02-22 14:20, Andrei Borzenkov wrote:
22.02.2016 15:46, Carlos E. R. пишет:
--no-floppy skips devices with name fd0, fd1, etc. What devices are listed in GRUB CLI (command ls)
I can't try just now, but I will, thanks. :-)
Toot a photo. Now I copy text by hand. (hd0) (hdo,gpt3) (hdo,gpt2) (hdo,gpt1) (hd1) (hd2) (hd3) (hd4) (hd4,gpt1) (hd5) (hd6) (fd0) Current /boot/grub2/custom.cfg is: +++----------------- # Segun device map de éste. #(hd1) /dev/sdb #(hd5) /dev/sdf #(hd4) /dev/sde #(hd0) /dev/sda #(hd2) /dev/sdc #(hd3) /dev/sdd #el main (grub 1) device map: #(hd0) /dev/disk/by-id/ata-ST3500418AS_5VM2RSY4 #el main es "root (hd0,1)" # Aquí es: #/dev/sdc7 on /other/main type ext4 (rw,relatime,data=ordered) #/dev/sdc2 on /other/main/boot type ext2 (rw,relatime) menuentry '0:1 - ' { insmod part_msdos insmod ext2 set root='hd0,msdos1' chainloader +1 } menuentry '0:2 - ' { insmod part_msdos insmod ext2 set root='hd0,msdos2' chainloader +1 } menuentry '0:3 - ' { insmod part_msdos insmod ext2 set root='hd0,msdos3' chainloader +1 } menuentry '0:4 - ' { insmod part_msdos insmod ext2 set root='hd0,msdos4' chainloader +1 } menuentry '1:1 - hd0:? not found, 12.1' { insmod part_msdos insmod ext2 set root='hd1,msdos1' chainloader +1 } menuentry '1:2 - hd0:? not found, kernel 3.11' { insmod part_msdos insmod ext2 set root='hd1,msdos2' chainloader +1 } menuentry '1:3 - Elessar (13.1)' { insmod part_msdos insmod ext2 set root='hd1,msdos3' chainloader +1 } menuentry '2:1 - 11.4' { insmod part_msdos insmod ext2 set root='hd2,msdos1' search --no-floppy --fs-uuid --set=root 93f0311e-2a93-49ca-b836-d362ffc84486 chainloader +1 } menuentry '2:1 - Main (must fail)' { insmod part_msdos insmod ext2 set root='hd2,msdos4' if search --no-floppy --fs-uuid --set=root 5135ab82-1374-4c30-b9d0 ; then chainloader +1 else echo Could not find this OS instance, will not boot sleep 10 fi } menuentry '2:1 - Main (uuid)' { insmod part_msdos insmod ext2 set root='hd2,msdos2' if search --no-floppy --fs-uuid --set=root 5135ab82-1374-4c30-b9d0-4b56d6d6d6c6 ; then chainloader +1 else echo Could not find this OS instance, will not boot sleep 10 fi } menuentry 'Gestor' { insmod part_gpt insmod ext2 set root='hd1,gpt2 <============ missing "'" if search --no-floppy --fs-uuid --set=root 943d650b-ea9c-4fbd-9d2c-993abae7655b' ; then <============ extra "'" chainloader +1 else echo Could not find this OS instance, will not boot sleep 10 fi } -----------------++- When I boot, first I see a message about loading grub, then some error messages. I took a photo, I'll copy the text here: +++----------------- error: syntax error. error: Incorrect command. error: syntax error. error: syntax error. error: Incorrect command. error: syntax error. Could not find this OS instance, will not boot -----------------++- This error I solved. It is the last menu, it has a missing "'" in "set root", now corrected. The next problem remains, see below. It takes a longish time to do that, then it prints the menu. If I select the menu entry '2:1 - Main (must fail)' (which contains wrong uuid to make it fail), I distinctly see it search the floppy, its light goes on and makes noises. It waits some seconds, then tries again. Then it prints the message "Could not find this OS instance, will not boot" (which is correct, the uuid is intentionally wrong). It waits 10 seconds, then it prompts to press any key to continue. I now see another error in the "'Gestor'" entry, an extra "'" in the uuid line. I correct that and reboot. Entry '2:1 - Main (uuid)' works correctly. Does not search the floppy. Entry '2:1 - Main (must fail)' fails, and searches the floppy twice, thus taking a long time to do it. Entry 'Gestor' works (loads this same Grub2 instance). I don't see more syntax errors :-? -- Cheers / Saludos, Carlos E. R. (from openSUSE Leap 42.1 x86_64 (test)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
23.02.2016 15:11, Carlos E. R. пишет:
On 2016-02-22 23:13, Carlos E. R. wrote:
On 2016-02-22 14:20, Andrei Borzenkov wrote:
22.02.2016 15:46, Carlos E. R. пишет:
--no-floppy skips devices with name fd0, fd1, etc. What devices are listed in GRUB CLI (command ls)
I can't try just now, but I will, thanks. :-)
Toot a photo. Now I copy text by hand.
(hd0) (hdo,gpt3) (hdo,gpt2) (hdo,gpt1) (hd1) (hd2) (hd3) (hd4) (hd4,gpt1) (hd5) (hd6) (fd0)
Yes, that was GRUB bug, should be fixed now upstream. Thanks! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-02-23 21:19, Andrei Borzenkov wrote:
23.02.2016 15:11, Carlos E. R. пишет:
I can't try just now, but I will, thanks. :-)
Toot a photo. Now I copy text by hand.
(hd0) (hdo,gpt3) (hdo,gpt2) (hdo,gpt1) (hd1) (hd2) (hd3) (hd4) (hd4,gpt1) (hd5) (hd6) (fd0)
Yes, that was GRUB bug, should be fixed now upstream. Thanks!
Ah. You mean that the search of floppy, even when told not to do so, is a known bug, solved upstream? Ok, good to know. Was driving me nuts. -- Cheers / Saludos, Carlos E. R. (from openSUSE Leap 42.1 x86_64 (test)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
24.02.2016 01:32, Carlos E. R. пишет:
On 2016-02-23 21:19, Andrei Borzenkov wrote:
23.02.2016 15:11, Carlos E. R. пишет:
I can't try just now, but I will, thanks. :-)
Toot a photo. Now I copy text by hand.
(hd0) (hdo,gpt3) (hdo,gpt2) (hdo,gpt1) (hd1) (hd2) (hd3) (hd4) (hd4,gpt1) (hd5) (hd6) (fd0)
Yes, that was GRUB bug, should be fixed now upstream. Thanks!
Ah. You mean that the search of floppy, even when told not to do so, is a known bug, solved upstream? Ok, good to know. Was driving me nuts.
It was not known until you mentioned it :) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-02-24 04:23, Andrei Borzenkov wrote:
24.02.2016 01:32, Carlos E. R. пишет:
On 2016-02-23 21:19, Andrei Borzenkov wrote:
23.02.2016 15:11, Carlos E. R. пишет:
Yes, that was GRUB bug, should be fixed now upstream. Thanks!
Ah. You mean that the search of floppy, even when told not to do so, is a known bug, solved upstream? Ok, good to know. Was driving me nuts.
It was not known until you mentioned it :)
Oh!! :-) -- Cheers / Saludos, Carlos E. R. (from openSUSE Leap 42.1 x86_64 (test)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (4)
-
Andrei Borzenkov -
Carlos E. R. -
Hans de Faber -
jdd