[opensuse] total system failure
This is a first for me. I am running a dual boot machine. Leap 42.2 and Windows 10 Pro, each on their own SSD. I have been using Leap 42.2 for a few months now and have had no issues with anything. Today I did an update and after the update everything seemed normal. I came back to the computer several hours later and everything had a serious time lag (30 seconds or more), such as opening apps, input from the keyboard, changing desktops, closing apps, etc. There were 14 updates but I did not pay much attention to what they were. I know one was Google Chrome but I cannot remember the rest. I decided to do a reboot to make sure there were no conflicts with the updates and libraries that might still be in ram. That is the last time I have been able to see my linux desktop. I can get to grub but every time I try to boot into Leap 42.2 I end up in emergency mode. The screen is totally blank prior to the emergency screen and my keyboard does not work in the emergency mode screen. I end up having to use the reset button to reboot out of the emergency mode screen. I have used both kernels both in default and recovery and every time end up in emergency mode. With the recovery kernels I do see output to the screen prior to emergency mode but I am not seeing anything that would suggest this failure. This is a basic install, I have done nothing fancy and update regularly when prompted. The only thing that is a bit different is my drive configuration. Besides a separate 500G SSD for Windows and Leap. There is a shared 4T drive that is formatted in NTFS. There is also a NAS Server. Users can access files on the NAS and shared drive from either Windows or Leap. I am typing this from Windows. In Windows I can access files on the NAS server and the shared drive so they are both up and working properly. I am totally stumped what could be wrong. Anyone with ideas on how to get my system back online? Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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? jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
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 <antlists@youngman.org.uk> 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
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.
On Friday, 21 April 2017 19:35:01 CEST Dave Smith wrote: probably an obvious point, but on the power options be sure to check the fast boot option INSIDE windows is still set to off. -- 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)
On 04/20/2017 05:43 PM, Dave Smith wrote:
This is a first for me. I am running a dual boot machine. Leap 42.2 and Windows 10 Pro, each on their own SSD.
BE CAREFUL!!! I have the exact same setup (except I have Leap 42.2 on a 1T WD Black drive). Keep windows on windows alone and Leap on it's own disk alone. If you boot via MBR, there is a very real risk, every kernel and grub update will overwrite the MBR on your Win10 drive installing grub and a menu-entry to chain-load windows instead of only updating the MBR on your Leap disk. This drives me crazy. Even explicitly configuring grub install in /etc/default/grub and specifying the disk/by-UUID for the drive, e.g.: GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-uuid/3cadab5b-13b4-4dce-84d3-05e2070f741c splash=silent quiet showopts" is not enough to prevent grub on openSuSE for trouncing the MBR on your windows drive due to the way openSuSE uses OS_PROBER to locate all drives and write a boot record there as it attempts to determine how to load the OS on whatever disk it finds. You can set the option in the same file: GRUB_DISABLE_OS_PROBER="true" Even with the uuid for the boot drive specified and OS_Prober diabled, openSuSE still overwites the Win10 MBR. So the word is "caution"... To prevent this unwanted behavior which forces me to have to recovery the windows boot record, etc.., I now add a 'lock' to grub to prevent any reinstall or update, and as an extra precaution, I though an Arch drive in the normal windows drive bay for `grub` updates. This may be overkill, but Linux now never touches my Win10 drive and Win10 never touches my Leap drive -- and that is the way it should be to begin with. There is a lot more info on this in my 2 prior threads on the subject within the last 4-5 months. Good luck with your dual-boot setup. I have the dual-boot there, but I also virtualize Win7 on Leap via Virtualbox. It is far easier to simply start windows as a Linux guest OS eliminating all boots required. I'll still start the Win10 install every couple of weeks and let it update, primarily so it is ready for use when I need it without having to wait though a 50 min. update when booting into it for the first time in a couple of weeks... -- 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
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
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. -- 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 <arvidjaar@gmail.com> 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
John Andersen composed on 2017-04-23 09:13 (UTC-0700):
Andrei Borzenkov wrote:
David C. Rankin composed:
openSuSE uses OS_PROBER to locate all drives and write a boot record there
Note what David wrote includes a conjunction.
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.
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. -- "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 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)
23.04.2017 19:13, John Andersen пишет:
On April 23, 2017 1:48:02 AM PDT, Andrei Borzenkov <arvidjaar@gmail.com> 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.
os-prober does not write boot record. ever. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
David C. Rankin composed on 2017-04-24 03:23 (UTC-0500):
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?
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. -- "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 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
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) jdd -- 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)
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 :-) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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)
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) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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)
Le 27/04/2017 à 14:06, Carlos E. R. a écrit :
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.
same for me, I have to switch in the bios to uefi or bios. It may differ depending on the firmware jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
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. -- 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 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
participants (10)
-
Andrei Borzenkov -
Carlos E. R. -
Dave Smith -
David C. Rankin -
Felix Miata -
jdd＠dodin.org -
jdd＠dodin.xyz
-
John Andersen -
nicholas -
Wols Lists