df shows my root partition at 59%. All other partitions are well below that. I have the power settings in Windows set so that my hard drives should not hibernate. I will check the setting again and see if Windows reset this during an update. The system was also not mounting /home which is an XFS filesystem. After 3 boot attempts since my last boot into Windows, Leap 42.2 fully booted. I did not change anything to the system, only used journalctl. No idea why it would not boot and now no idea why it suddenly will. Any ideas where to look for clues? On Fri, Apr 21, 2017 at 1:17 PM, Wols Lists wrote:

On 21/04/17 13:02, jdd@dodin.xyz wrote:

...

Le 21/04/2017 à 00:43, Dave Smith a écrit :

...

I am totally stumped what could be wrong. Anyone with ideas on how to get my system back online?

Dave

btrfs full?

Is Windows suspending, and linux (as a result of the update) trying to mount the windows drive?

Ime if you have the C: drive in fstab, and Windows suspends, it's a nightmare trying to boot linux.

As for your delays, can you see what your load level is? Since an update a while back, on my 2-core processor, the load at boot is typically 4 or 5 for a good five minutes. Of course, that absolutely knackers response ... and it seems to be plasma/kde that is the problem. Or it could be NetworkManager, it seems to be worse when our router is playing up.

(I have xosview start at login, and so I can see the load ... :-)

Cheers, Wol

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2017-04-21 19:35, Dave Smith wrote:

df shows my root partition at 59%. All other partitions are well below that. I have the power settings in Windows set so that my hard drives should not hibernate. I will check the setting again and see if Windows reset this during an update. The system was also not mounting /home which is an XFS filesystem. After 3 boot attempts since my last boot into Windows, Leap 42.2 fully booted. I did not change anything to the system, only used journalctl. No idea why it would not boot and now no idea why it suddenly will. Any ideas where to look for clues?

You say that /home failed to mount? In that case, the boot would fail, probably dumped you into emergency mode. Probably the log should say why /home failed to mount. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

Plus one for Virtualbox or VMware workstation instead of dual boot. My rule these days is never let Windows touch real hardware. I don't use it enough to take the of dual booting. (Although I have Windows Server running 24/7 in virtualbox and just about every version of Windows in VMware VMs. Dual booting was always risky, never a satisfactory solution. And it hasn't improved with age. If you insist, a pure UEFI / secure boot solution is said to be easier and safer. But I haven't tried that yet. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On April 23, 2017 1:48:02 AM PDT, Andrei Borzenkov wrote:

23.04.2017 10:43, David C. Rankin пишет:

...

openSuSE uses OS_PROBER to locate all drives and write a boot record there

This is complete nonsense. Show code that does it.

Nope, not nonsense, that is os_prober's job, and it does it rather well. Since I moved to an SSD when I installed 42.2, I kept the 13.2 HDD intact and mounted it in a USB caddy. I had plugged into a Manjaro machine when a new kernel update came along and in the process up updating grub, osprober found the opensuse 13.2 on the external USB drive, and dutifully added into the grub list of bootable systems. I had to disconnect the USB and run update grub again to get rid of the extra entries. No harm done. I didn't have this issue on 42.2 simply because I didn't leave the USB caddy plugged in over a kernel update, but I have no reason to think it would act differently on Opensuse than on Manjaro. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2017-04-23 18:41, Felix Miata wrote:

Andrei referred to the entirety of what David wrote. John apparently glossed over the second clause, and wrote only about the first clause, discovery of all drives so as to be able to find installations to include in Grub's menu. Grub is not supposed to be writing boot records to all drives, absent specific instruction to do so.

I understand you say that it happens when the grub rpm is updated. Side note: Thunderbird removed the (was: ...) section, not me. I confirmed this clicking reply list a second time. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

On 04/23/2017 11:48 AM, Andrei Borzenkov wrote:

os-prober does not write boot record. ever.

Now we quibble of phonetics. os-prober identifies the OS's installed, then what ever it is on Leap takes over and plants an MBR on the first drive (/dev/sda even though the only Linux install and existing grub bootloader is on /dev/sdb) That's wrong. If the only existing bootloader and linux install is on /dev/sdb, then why is grub update overwriting the MBR of /dev/sda -- that it shouldn't touch? -- 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 04/24/2017 05:28 AM, Felix Miata wrote:

Is there such a BIOS as can or will look to device HD1 aka sdb instead of HD0 aka sda when exists bootable (generic/legacy/Windows) code on HD0? If not, then the BIOS will never use it. Grub on sdb will only be used in such a case by chainloading from from elsewhere.

Most modern BIOS can swap physical devices HD0 and HD1 via function key at POST or via setup menu, but that's not the same thing, as the second physical device in such case is presented as if the first. The installer or updater won't know the BIOS has done any such thing.

This is on my HP8760w laptop. It has 2 hard drive bays (actually 3, the dvd drive can be removed and it will server as a 3rd bay). All are directly bootable via the bios. The problem is I have the original Win10 SSD in bay 1, and SuSE in bay 2. I boot direct to SuSE. With this setup, grub updated, via their fried os_prober, always overwrites the MBR on the Win10 drive instead of writing the bootloader to drive 2. This is frustrating as hell (and probably a large part of the reason that Arch only provides os_prober on the install media and does not install it in the OS) With the SuSE install on the 2nd drive, grub should only install as: grub-install --target=i386-pc /dev/sdb but instead in the install everywhere leap setup, it installs as grub-install --target=i386-pc /dev/sda (the win 10 drive) even specifying in /etc/default/grub_installdevice /dev/sdb1 /dev/sdb activate generic_mbr and explicitly specifying the UUID for the install filesystem in /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-uuid/3cadab5b-13b4-4dce-84d3-05e2070f741c splash=silent quiet showopts" GRUB_DISABLE_OS_PROBER="true" I give up... -- 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 2017-04-27 12:32, jdd@dodin.org wrote:

Le 27/04/2017 à 11:17, David C. Rankin a écrit :

...

I give up...

isn't your computer uefi capable? this should solve the problem (no more MBR...)

It's not that simple but possible to have a BIOS windows and an UEFI openSUSE (I have one)

It is simple. YaST does it up automatically. :-) -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

On 2017-04-27 12:53, jdd@dodin.org wrote:

Le 27/04/2017 à 12:44, Carlos E. R. a écrit :

...

On 2017-04-27 12:32, jdd@dodin.org wrote:

...

Le 27/04/2017 à 11:17, David C. Rankin a écrit :

...

I give up...

isn't your computer uefi capable? this should solve the problem (no more MBR...)

It's not that simple but possible to have a BIOS windows and an UEFI openSUSE (I have one)

It is simple. YaST does it up automatically. :-)

no

In my computer at least it's not possible to have both windows BIOS and openSUSE uefi/GPT in the same bootable menu, I boot openSUSE as default and have to hit F12 and choose the windows disk to be able to boot windows. But it's rare enough not to be important. Last time I had difficulty to remember how to boot windows, because I didn't do it for month :-)

Oh, I got confused in my response. What I meant was that it is easy to have a BIOS computer booting a GPT partitioned hard disk. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

On 2017-04-27 13:56, jdd@dodin.org wrote:

Le 27/04/2017 à 13:48, Carlos E. R. a écrit :

...

What I meant was that it is easy to have a BIOS computer booting a GPT partitioned hard disk.

only from openSUSE, windows don't like it (at least windows 10)

It is on another disk. On a caddy. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

David C. Rankin composed on 2017-04-27 04:17 (UTC-0500):

This is on my HP8760w laptop. It has 2 hard drive bays (actually 3, the dvd drive can be removed and it will server as a 3rd bay). All are directly bootable via the bios. The problem is I have the original Win10 SSD in bay 1, and SuSE in bay 2. I boot direct to SuSE. How exactly? Are you using EFI, or a BIOS boot device selection menu?

With this setup, grub updated, via their fried os_prober, always overwrites the MBR on the Win10 drive instead of writing the bootloader to drive 2. This is frustrating as hell (and probably a large part of the reason that Arch only provides os_prober on the install media and does not install it in the OS) Are both SSD and HD running off the same controller and kernel module?

With the SuSE install on the 2nd drive, grub should only install as:

grub-install --target=i386-pc /dev/sdb

Only thing I can suggest is put Grub same place I always say to put it, on the / or /boot partition's PBR, not on the MBR. Put Generic MBR code on the MBR and leave it there untouched. Set boot flag on primary partition containing Grub. Set up Windows SSD the same way. Add the Grub partition to the bcd Windows boot menu for chainloading to. If not EFI and you are really ambitious, remove Grub2 and install Grub. I find Grub2 useful only to make life much more complicated.

but instead in the install everywhere leap setup, it installs as

grub-install --target=i386-pc /dev/sda (the win 10 drive)

even specifying in /etc/default/grub_installdevice /dev/sdb1 /dev/sdb activate generic_mbr

and explicitly specifying the UUID for the install filesystem in /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-uuid/3cadab5b-13b4-4dce-84d3-05e2070f741c splash=silent quiet showopts" GRUB_DISABLE_OS_PROBER="true"

I give up...

Do you actually want a quiet boot hiding boot messages that might explain trouble? If not, strip the splash and quiet parameters from the Grub configuration. They're there for the benefit mostly of dweebs who want to see nothing before the greeter, like in windoz. -- "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 24/04/17 09:18, David C. Rankin wrote:

23.04.2017 10:43, David C. Rankin пишет:

...

openSuSE uses OS_PROBER to locate all drives and write a boot record there

This is complete nonsense. Show code that does it.

Nonsense -- nothing, see the complete thread

"[opensuse] Leap 42.2 overwrote Win10 mbr on /dev/sda on grub update for SuSE on /dev/sdb"

If a windows drive is found on grub update, Leap takes it upon itself to overwrite the win mbr and set grub option to chainload win10. It has happened twice. Nonsense my foot.

Even when the original install was told to write grub to the PBR? If that's the case, then it IS a bug - indeed, if it was told to write it to /dev/sdb and then writes it to /dev/sda instead, that's also a bug. My trouble is understanding the message about where it intends to write grub ... :-) Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org