On Mon, 15 May 2017 10:25:49 -0700 John Andersen wrote:

On 05/15/2017 10:06 AM, Stephen Berman wrote:

...

I have a computer with two hard disks, on one of which both openSUSE 42.2 and 13.2 are installed and on the other a different GNU/Linux system (Linux From Scratch); on booting, the grub2 boot screen (which comes from os42.2) showed all three systems -- till yesterday, after I updated os42.2 for the first time in around a week; after rebooting only os42.2 and os13.2 were listed on the boot screen. I also manually ran `grub2-mkconfig -o /boot/grub2/grub.cfg' from os42.2 and the output also showed just the two openSUSE systems. I noticed that among yesterday's updates were grub2 and os-prober, presumably grub2-2.02~beta2-94.3.1.x86_64.rpm from 08-May-2017 and os-prober-1.61-20.3.1.x86_64.rpm from 06-May-2017. Has anyone else run into this problem? Could either of those updates have caused it?

Steve Berman

Yes, Osprober's job is to find all the OSes installed and add them to the bootable systems. Usually this only happens when you are building the initrd after an update or something, but sometimes it creeps in at other times. Opensuse isn't the only distro in turmoil due to osprober.

(Osprober would be great if it worked reliably, or at least asked if something it found should be included in boot options, but it doesn't. I had an opensuse 13.2 drive mounted in a USB caddy plugged into a Manjaro machine (but not mounted) when the Manjaro was updated with an update that included a kernel. During the process Osprober decided add the Opensuse to the bootable options.

Dual Boot has become a minefield of late. Dueling Distros. Battling boot loaders. Any one system can put your entire multiboot installation at risk. And that's before Windows 10 shenanigans kick in.

After getting burned on this, I refuse to dual boot anymore. If I want to try out a distro I use VirtualBox or VMWare. I run it in a VM for a few months to decide if I want to spend any time on it. Its easier, safer, and you can run two or more OSes at once. Buy Memory. Preserve your Sanity.

So you're implying that it was more likely due to good luck that all three systems were shown before the update, rather than due to bad luck that only two are shown after the update? (I did manually added the missing system to grub.cfg, so the boot screen now shows them all again; I just have to make sure to keep a backup of that in case the next update overwrites it.) Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2017-05-15 19:25, John Andersen wrote:

Dual Boot has become a minefield of late. Dueling Distros. Battling boot loaders. Any one system can put your entire multiboot installation at risk. And that's before Windows 10 shenanigans kick in.

It is in fact doable and simple. You need to have all distributions boot from its own partitions. Do not allow any operating system, except one, to write to the MBR. Choose one system to write and control the MBR, only one. The rest must boot from their respective partitions only, under control of the main operating system. Ie, one grub controls it all. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))

On 2017-05-15 23:08, Stephen Berman wrote:

I made the apparent mistake of installing grub2 in the MBR of both hard drives on my machine (I don't think this is related to the problem of my OP you followed up on, so I've changed the subject). Is it possible to uninstall it from one of them, and if so, how (without making the system on that drive unbootable)? (There's no command grub-uninstall, and the word "uninstall" does not occur in the Grub Info file.)

You got the correct response on that from Dennis Gallien on your other thread. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))

On 2017-05-15 23:53, Stephen Berman wrote:

On Mon, 15 May 2017 23:43:09 +0200 "Carlos E. R." wrote:

...

On 2017-05-15 23:08, Stephen Berman wrote:

...

I made the apparent mistake of installing grub2 in the MBR of both hard drives on my machine (I don't think this is related to the problem of my OP you followed up on, so I've changed the subject). Is it possible to uninstall it from one of them, and if so, how (without making the system on that drive unbootable)? (There's no command grub-uninstall, and the word "uninstall" does not occur in the Grub Info file.)

You got the correct response on that from Dennis Gallien on your other thread.

Yeah, I just saw it. (That wasn't a thread from my OP; there seems to be a serendipitous grub-synchronicity on this list ;-)

Oh, I see. Two people having the same problem at the same time! How curious :-) I think there were uninstall instructions on "LILO" time ago. Or it was on the SuSE books, I don't remember. Basically, no such thing: just install something else on top ;-) -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))

On 05/15/2017 04:53 PM, Stephen Berman wrote:

Yeah, I just saw it. (That wasn't a thread from my OP; there seems to be a serendipitous grub-synchronicity on this list ;-)

Stephen has the 'sync' buzz words down, he's ready for management.. Promote him ;-) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/15/2017 01:44 PM, Carlos E. R. wrote:

It is in fact doable and simple.

You need to have all distributions boot from its own partitions. Do not allow any operating system, except one, to write to the MBR. Choose one system to write and control the MBR, only one. The rest must boot from their respective partitions only, under control of the main operating system.

Ie, one grub controls it all.

It is doable, and simple, then it with some glibly stated list of non straight forward, clear as mud directives you dismiss the entire issue and hand waive it away. Dualbooting, or worse multibooting, is the number one problem child of linux to new users. Add in a Windows installation and it is a disaster just waiting to happen. For those people who practice it every day, and have thirty distros packed onto the same 5 terabyte drive, sure, it becomes easy. But from now on, anyone with a dual boot issue just Email Carlos direct. Because its doable and simple. He'll fix you right up. -- After all is said and done, more is said than done.

On 2017-05-16 04:20, Felix Miata wrote:

Carlos E. R. composed on 2017-05-15 22:44 (UTC+0200):

...

John Andersen wrote:

...

...

Dual Boot has become a minefield of late. Dueling Distros. Battling boot loaders. Any one system can put your entire multiboot installation at risk. And that's before Windows 10 shenanigans kick in.

The only notable thing Win10 changed here is it refuses to assign anything other than C: to its system partition. Its system partitions are still on logical volumes, but it assigns D: to the primary partition containing its boot paraphernalia, which like Vista, 7 and XP before them, can chainload a Grub or Lilo installed to a primary partition for booting Linux. I've not had reason to try, but I suspect the Win10 boot manager might even be able to launch a FOSS bootloader installed to a logical partition.

No, I understand it is broken. EasyBCD, which was the tool used mostly in the past, now fails. And Windows service packs (7 to 10, for instance) and other W10 updates fail unless the windows partition is marked bootable.

...

It is in fact doable and simple.

...

You need to have all distributions boot from its own partitions. Do not allow any operating system, except one, to write to the MBR. Choose one system to write and control the MBR, only one. Or none, doing the controlling yourself, as has been done here for in excess of two decades. They're my machines, so I get to decide what goes in the MBR, which excludes Grub, Lilo and every other bootloader that wasn't originally designed to boot DOS on a 16 bit IBM PC.

That's more difficult. And will not work on GPT disks. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))

On 2017-05-16 15:52, Felix Miata wrote:

Carlos E. R. composed on 2017-05-16 14:31 (UTC+0200):

...

Felix Miata wrote:

...

...

The only notable thing Win10 changed here is it refuses to assign anything other than C: to its system partition. Its system partitions are still on logical volumes, but it assigns D: to the primary partition containing its boot paraphernalia, which like Vista, 7 and XP before them, can chainload a Grub or Lilo installed to a primary partition for booting Linux. I've not had reason to try, but I suspect the Win10 boot manager might even be able to launch a FOSS bootloader installed to a logical partition.

...

No, I understand it is broken. EasyBCD, which was the tool used mostly in the past, now fails. No WRT what exactly? Fails in what manner?

I don't know. I was told not to try, it doesn't work with W10.

...

And Windows service packs (7 to 10, for instance) and other W10 updates fail unless the windows partition is marked bootable.

Boo hoo. How many seconds does it take to move the boot flag elsewhere and back? When necessary, I move it last thing before applying those updates, then move it back when those updates are finished.

Minutes. Hours, if the update fails because I did not change the boot flag. With W10 you do not know when you will get updates, no control over it. Your method means not been able to select the boot system in Grub each time I boot. The method I use is far simpler, once applied: https://nwrickert2.wordpress.com/2015/06/15/generic-boot-code/

...

...

...

It is in fact doable and simple.

...

...

...

You need to have all distributions boot from its own partitions. Do not allow any operating system, except one, to write to the MBR. Choose one system to write and control the MBR, only one.

...

...

Or none, doing the controlling yourself, as has been done here for in excess of two decades. They're my machines, so I get to decide what goes in the MBR, which excludes Grub, Lilo and every other bootloader that wasn't originally designed to boot DOS on a 16 bit IBM PC.

...

That's more difficult. More difficult than what, rescuing non-bootable systems following updates or new installs allowed to usurp control?

More difficult than just selecting what to boot in a working grub menu.

...

And will not work on GPT disks.

Again boo hoo. Just because manufacturers are cranking out monster HDs doesn't mean everybody needs them.

I do. About everybody buying computers now do. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))

On 2017-05-17 10:09, David C. Rankin wrote:

On 05/15/2017 03:44 PM, Carlos E. R. wrote:

I'd rather have to tell osprober where to look, rather than having to sort out dual boot issue when it thinks for itself and gets it wrong. This is positive news. (I have added the lock back to grub2) However, if I see another clean upgrade, w/o overwriting /dev/sda, I'm might have the confidence to try with the w10 drive in place :p

I disable os-prober. It takes a lot to run, and the menu it produces is too complicated. I prefer to write my own menu entries. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))

On 2017-05-18 11:21, Stephen Berman wrote:

On Wed, 17 May 2017 14:09:12 +0200 "Carlos E. R." <> wrote:

...

On 2017-05-17 10:09, David C. Rankin wrote:

...

On 05/15/2017 03:44 PM, Carlos E. R. wrote:

...

I'd rather have to tell osprober where to look, rather than having to sort out dual boot issue when it thinks for itself and gets it wrong. This is positive news. (I have added the lock back to grub2) However, if I see another clean upgrade, w/o overwriting /dev/sda, I'm might have the confidence to try with the w10 drive in place :p

I disable os-prober. It takes a lot to run, and the menu it produces is too complicated. I prefer to write my own menu entries.

How do you disable os-prober?

In YaST boot module. One of the options is something like "probe for other operating systems". I suppose it also translates to a sysconfig setting, but I don't know which. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))

Stephen Berman composed on 2017-05-18 11:21 (UTC+0200):

How do you disable os-prober?

GRUB_DISABLE_OS_PROBER=true in /etc/default/grub https://www.gnu.org/software/grub/manual/grub.html#Multi_002dboot-manual-con... -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Mon, 15 May 2017 21:43:19 +0300 Andrei Borzenkov wrote:

15.05.2017 20:06, Stephen Berman пишет:

...

I have a computer with two hard disks, on one of which both openSUSE 42.2 and 13.2 are installed and on the other a different GNU/Linux system (Linux From Scratch); on booting, the grub2 boot screen (which comes from os42.2) showed all three systems -- till yesterday, after I updated os42.2 for the first time in around a week; after rebooting only os42.2 and os13.2 were listed on the boot screen. I also manually ran `grub2-mkconfig -o /boot/grub2/grub.cfg' from os42.2 and the output also showed just the two openSUSE systems. I noticed that among yesterday's updates were grub2 and os-prober, presumably grub2-2.02~beta2-94.3.1.x86_64.rpm from 08-May-2017 and os-prober-1.61-20.3.1.x86_64.rpm from 06-May-2017. Has anyone else run into this problem? Could either of those updates have caused it?

Well, this is likely os-prober then. Run

START=$(date +%s) os-prober journalctl --since=@$START

and post output.

FTR attached, though it's now clear what went wrong. The output shows that /usr/lib/os-probes/mounted/90linux-distro does not recognize /dev/sda5, which is the root of my LFS system, as a linux system, unlike /dev/sdb6, which it correctly recognizes as openSUSE 13.2. And the reason is that 90linux-distro runs this check: elif [ -e "$dir/etc/lfs-release" ]; then short="LFS" long="$(printf "Linux From Scratch (%s)\n" "$(cat "$dir/etc/lfs-release")")" My LFS system does not have this file (the LFS build instructions recommend but do not require it; however, I did try to follow not just the LFS requirements but also the recommendations, and don't remember deciding not to install that file, so I don't know if this was an oversight or it got deleted by mistake at some point). But prior to the os-prober update it seems a different check was run, because the LFS system was recognized but listed as "unknown Linux distribution"; this fallback now seems to be missing. That seems problematic, since 90linux-distro cannot list all possible Linux-based installations (someone could e.g. just invent a name, or choose not to use any). Steve Berman

On Thu, 18 May 2017 13:14:39 +0300 Andrei Borzenkov wrote:

On Thu, May 18, 2017 at 12:21 PM, Stephen Berman wrote:

...

FTR attached, though it's now clear what went wrong. The output shows that /usr/lib/os-probes/mounted/90linux-distro does not recognize /dev/sda5, which is the root of my LFS system, as a linux system, unlike /dev/sdb6, which it correctly recognizes as openSUSE 13.2. And the reason is that 90linux-distro runs this check:

elif [ -e "$dir/etc/lfs-release" ]; then short="LFS" long="$(printf "Linux From Scratch (%s)\n" "$(cat "$dir/etc/lfs-release")")"

My LFS system does not have this file (the LFS build instructions recommend but do not require it; however, I did try to follow not just the LFS requirements but also the recommendations, and don't remember deciding not to install that file, so I don't know if this was an oversight or it got deleted by mistake at some point). But prior to the os-prober update it seems a different check was run, because the LFS system was recognized but listed as "unknown Linux distribution"; this fallback now seems to be missing. That seems problematic, since 90linux-distro cannot list all possible Linux-based installations (someone could e.g. just invent a name, or choose not to use any).

Yes, I suspected as much. Generic check was removed because it was the source of slowdown. We need to think about how to test for Linux in different way.

Please open bug report and tell its number. Attach this os-prober log.

Done as Bug 1039705. Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org