Quantcast

total system failure

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

total system failure

Dave Smith
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: total system failure

jdd-gmane
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: total system failure

Wols Lists
On 21/04/17 13:02, [hidden email] 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: total system failure

Dave Smith
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 <[hidden email]> wrote:

> On 21/04/17 13:02, [hidden email] 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: [hidden email]
> To contact the owner, e-mail: [hidden email]
>

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: total system failure

nicholas cunliffe
On Friday, 21 April 2017 19:35:01 CEST Dave Smith wrote:
> 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.  
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: total system failure

Carlos E. R.-2
In reply to this post by Dave Smith
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)


signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: total system failure

David C. Rankin
In reply to this post by Dave Smith
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: total system failure

John Andersen-2
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: total system failure

Andrei Borzenkov
In reply to this post by David C. Rankin
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: total system failure

John Andersen-2
On April 23, 2017 1:48:02 AM PDT, Andrei Borzenkov <[hidden email]> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: os-prober boot record writing (was: total system failure)

Felix Miata-3
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: total system failure

Andrei Borzenkov
In reply to this post by John Andersen-2
23.04.2017 19:13, John Andersen пишет:
> On April 23, 2017 1:48:02 AM PDT, Andrei Borzenkov <[hidden email]> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: os-prober boot record writing

Carlos E. R.-2
In reply to this post by Felix Miata-3
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)


signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: total system failure

David C. Rankin
In reply to this post by David C. Rankin
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: [hidden email]
To contact the owner, e-mail: [hidden email]


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: total system failure

David C. Rankin
In reply to this post by Andrei Borzenkov
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: total system failure

Felix Miata-3
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: total system failure

Wols Lists
In reply to this post by David C. Rankin
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: total system failure

David C. Rankin
In reply to this post by Felix Miata-3
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: total system failure

jdd-gmane
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: total system failure

Carlos E. R.-2
On 2017-04-27 12:32, [hidden email] 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)


signature.asc (188 bytes) Download Attachment
12
Loading...