[opensuse] system freeze during boot of new kernel v. 4.4.180-102.1.x86_64
The day before yesterday I did a system update, including downloading and installing a new kernel (v. 4.4.180-102.1.x86_64). I didn't reboot however; rather I continued to run the previous kernel (4.4.179-99-default). This may be worth mentioning only because towards the end of the day yesterday my system froze up. That is, I could move the mouse pointer around, but clicking on any window did nothing. This meant that I couldn't switch to any other window, so no way to try to diagnose anything. From gkrellm, however, I did see that both RAM and swap usage were normal, not maxed out, so no runaway processses. But the only way to get out of that frozen system was to power down via the power switch. Turning the laptop back on, I booted into the new kernel. However, it wouldn't boot. It hung even before I was able to log in, when the text messages about the boot processes were still rolling up the screen. Here's what I saw: ... [ OK ] Reached target System Iniitialization. Starting Show Plymouth Boot Screen... Starting dracut Initqueue hook... [ 1.761617] wmi: Mapper loaded [ 8.862476] nouveau 0000:01:00.0: DRM: evicting buffers... [ 8.862400] nouveau 0000:01:00.0: DRM: waiting for kernel channels to go idle... [ 8.862497] nouveau 0000:01:00.0: DRM: suspending client object trees... [ 8.865333] nouveau 0000:01:00.0: DRM: suspending kernel object trees.. And that's where it hung... for at least fifteen minutes (that's about how long it took me to note by hand all of what I saw onscreen). I had to hard-reboot (again), where I selected the previous (bootable) kernel (4.4.179-99-default). There was no problem booting it and haven't had any problems running it for more than a day-and-a-half. Any explanations and/or recommendations? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/21/2019 02:36 PM, ken wrote:
Turning the laptop back on, I booted into the new kernel. However, it wouldn't boot. It hung even before I was able to log in, when the text messages about the boot processes were still rolling up the screen. Here's what I saw:
... [ OK ] Reached target System Iniitialization. Starting Show Plymouth Boot Screen... Starting dracut Initqueue hook... [ 1.761617] wmi: Mapper loaded [ 8.862476] nouveau 0000:01:00.0: DRM: evicting buffers... [ 8.862400] nouveau 0000:01:00.0: DRM: waiting for kernel channels to go idle... [ 8.862497] nouveau 0000:01:00.0: DRM: suspending client object trees... [ 8.865333] nouveau 0000:01:00.0: DRM: suspending kernel object trees..
And that's where it hung... for at least fifteen minutes (that's about how long it took me to note by hand all of what I saw onscreen). I had to hard-reboot (again), where I selected the previous (bootable) kernel (4.4.179-99-default). There was no problem booting it and haven't had any problems running it for more than a day-and-a-half.
Any explanations and/or recommendations?
I saw a similar hang the first time I booted into 4.4.180-102 on 42.3 (in my case I just chocked it up to flaky hardware). Regardless, I just pulled power, and booted a second time and all worked fine. If the problem persists, boot the install CD/DVD to recovery mode and then chroot your system under /mnt and re-run mkinitrd. Then try a reboot. Chroot cliff's-notes (non-btrfs): 1. Boot into recovery mode, login as root (no password) 2. Check partitions with cat /proc/partitions, and identify your / and /home (and /boot if separate) 3. mount root on /mnt and then mount /home (and if needed /boot) below /mnt. Example: mount /dev/sda3 /mnt ## mount root mount /dev/sda2 /mnt/home ## mount home 4. bind mount /dev /proc and /sys below /mnt. Example: mount -o bind /dev /mnt/dev mount -o bind /proc /mnt/proc mount -o bind /sys /mnt/sys 5. change to the /mnt directory and chroot system, e.g. cd /mnt chroot /mnt /bin/bash 6. now you have your installed system available. You can update or do whatever is needed. In your case just: mkinitrd 7. exit chroot (exit) and now umount bind mounts and home and / in reverse order, e.g. cd / ## change directory out of where you chrooted umount /mnt/sys umount /mnt/proc umount /mnt/dev umount /mnt/home umount /mnt ## may fail saying files still open, check with fuser /mnt if there are no open files, just reboot at this point Others will have to chime in if anything special is needed for btrfs. (note: you can also 'mount -t proc /proc /mnt/proc` and use `--rbind` for /dev and /sys, but -o bind is fine for all and easier to remember) -- 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 21/06/2019 22.21, David C. Rankin wrote:
(note: you can also 'mount -t proc /proc /mnt/proc` and use `--rbind` for /dev and /sys, but -o bind is fine for all and easier to remember)
Oh. I did not notice that. (man 8 mount) Bind mounts Remount part of the file hierarchy somewhere else. The call is: mount --bind olddir newdir or by using this fstab entry: /olddir /newdir none bind After this call the same contents are accessible in two places. One can also remount a single file (on a single file). It's also possible to use the bind mount to create a mountpoint from a regular directory, for example: mount --bind foo foo The bind mount call attaches only (part of) a single filesystem, not possible submounts. The entire file hierarchy including submounts is attached a second place by using: mount --rbind olddir newdir Note that the filesystem mount options will remain the same as those on the original mount point. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
participants (3)
-
Carlos E. R. -
David C. Rankin -
ken