[opensuse] Fail To Boot After Update to kernel-default-4.12.14-lp150.12.82.1 ??
All, Devs, On a virtualbox install, zypper up to kernel-default-4.12.14-lp150.12.82.1 on 15.0 left the VM unable to boot - it hangs part way though the boot. Downgrade to kernel-default-4.12.14-lp150.12.79.1 works just fine. Attempts to rebuild the init with: # dracut -fM --kver 4.12.14-lp150.12.82-default completes successfully but does not solve the problem. I have removed (zypper rm'ed) kernel-default-4.12.14-lp150.12.82.1 and the system boots fine on the kernel-default-4.12.14-lp150.12.79.1 kernel. What to check as to why update to the new kernel failed? There is no persistent journal to check. -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/11/2019 23.46, David C. Rankin wrote:
All, Devs,
On a virtualbox install, zypper up to kernel-default-4.12.14-lp150.12.82.1 on 15.0 left the VM unable to boot - it hangs part way though the boot. Downgrade to kernel-default-4.12.14-lp150.12.79.1 works just fine.
Attempts to rebuild the init with:
# dracut -fM --kver 4.12.14-lp150.12.82-default
completes successfully but does not solve the problem. I have removed (zypper rm'ed) kernel-default-4.12.14-lp150.12.82.1 and the system boots fine on the kernel-default-4.12.14-lp150.12.79.1 kernel.
What to check as to why update to the new kernel failed? There is no persistent journal to check.
If the kernel boots and starts the system, then crashes, there is either journal or syslog, or both. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXc32CAAKCRC1MxgcbY1H 1XS6AJ95mZALktwqVh47AyrL7CeZtCQfqQCfWwEkQQbXxL53IeGWigqHCHcU7Yo= =SZi1 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/14/2019 06:49 PM, Carlos E. R. wrote:
On 14/11/2019 23.46, David C. Rankin wrote:
All, Devs,
On a virtualbox install, zypper up to kernel-default-4.12.14-lp150.12.82.1 on 15.0 left the VM unable to boot - it hangs part way though the boot. Downgrade to kernel-default-4.12.14-lp150.12.79.1 works just fine.
Attempts to rebuild the init with:
# dracut -fM --kver 4.12.14-lp150.12.82-default
completes successfully but does not solve the problem. I have removed (zypper rm'ed) kernel-default-4.12.14-lp150.12.82.1 and the system boots fine on the kernel-default-4.12.14-lp150.12.79.1 kernel.
What to check as to why update to the new kernel failed? There is no persistent journal to check.
If the kernel boots and starts the system, then crashes, there is either journal or syslog, or both.
I wish that were true. The only thing captured in /var/log/messages is the install of the kernel and associated kernel-source, kernel-syms, etc.., and then the removal of the kernel. It is before early boot is started because there is noting related to the actual operation of 4.12.14-lp150.12.82.1 in /var/log/messages. YaST2/mkinitrd.log shows that the initrd was created and setup correctly, but literally hangs immediately after reboot to it. I'm not sure what to check. The update on the 15.1 VM to 4.12.14-lp151.28.32-default went fine, so this is limited to the 15.0 VM and 4.12.14-lp150.12.82.1 -- David C. Rankin, J.D.,P.E.
David C. Rankin composed on 2019-11-14 16:46 (UTC-0600):
What to check as to why update to the new kernel failed? There is no persistent journal to check.
If you want a persistent journal, simply create /var/log/journal. -- Evolution as taught in public schools is religion, not science. 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 11/14/2019 07:44 PM, Felix Miata wrote:
David C. Rankin composed on 2019-11-14 16:46 (UTC-0600):
What to check as to why update to the new kernel failed? There is no persistent journal to check.
If you want a persistent journal, simply create /var/log/journal.
That's what I'll end up having to do. As it is, I have to start the VM on the server, hist Alt+F2 and start rdesktop quick enough to catch the grub screen to go to the Advanced options and boot the .79 kernel after then boot of the .82 kernel hangs resulting in having to use VBoxManange controlvm "leap150" poweroff To kill the hung process. We shall see if the journal can catch anything. -- 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 11/14/2019 08:00 PM, David C. Rankin wrote:
On 11/14/2019 07:44 PM, Felix Miata wrote:
David C. Rankin composed on 2019-11-14 16:46 (UTC-0600):
What to check as to why update to the new kernel failed? There is no persistent journal to check.
If you want a persistent journal, simply create /var/log/journal.
That's what I'll end up having to do. As it is, I have to start the VM on the server, hist Alt+F2 and start rdesktop quick enough to catch the grub screen to go to the Advanced options and boot the .79 kernel after then boot of the .82 kernel hangs resulting in having to use
VBoxManange controlvm "leap150" poweroff
To kill the hung process. We shall see if the journal can catch anything.
Nope, hangs before the journal starts. Here is a screenshot of where to boot hangs and what is dumped to the screen. https://paste.opensuse.org/69998024 Frustrating... -- 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
15.11.2019 5:29, David C. Rankin пишет:
On 11/14/2019 08:00 PM, David C. Rankin wrote:
On 11/14/2019 07:44 PM, Felix Miata wrote:
David C. Rankin composed on 2019-11-14 16:46 (UTC-0600):
What to check as to why update to the new kernel failed? There is no persistent journal to check.
If you want a persistent journal, simply create /var/log/journal.
That's what I'll end up having to do. As it is, I have to start the VM on the server, hist Alt+F2 and start rdesktop quick enough to catch the grub screen to go to the Advanced options and boot the .79 kernel after then boot of the .82 kernel hangs resulting in having to use
VBoxManange controlvm "leap150" poweroff
To kill the hung process. We shall see if the journal can catch anything.
Nope, hangs before the journal starts. Here is a screenshot of where to boot hangs and what is dumped to the screen.
Booting without "quiet" may give more information. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/14/2019 10:01 PM, Andrei Borzenkov wrote:
Nope, hangs before the journal starts. Here is a screenshot of where to boot hangs and what is dumped to the screen.
Booting without "quiet" may give more information.
That's so obvious, it's almost embarrassing -- almost... Thanks. -- 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 11/14/2019 11:31 PM, David C. Rankin wrote:
On 11/14/2019 10:01 PM, Andrei Borzenkov wrote:
Nope, hangs before the journal starts. Here is a screenshot of where to boot hangs and what is dumped to the screen.
Booting without "quiet" may give more information.
That's so obvious, it's almost embarrassing -- almost... Thanks.
Reinstalled the new .82 kernel from update. Disabled "quite" option and rebooted: https://paste.opensuse.org/97682437 Basically it gets to Starting Show Plymouth Boot Screen.. vboxguest: loading out-of-tree modules taints kernel ACPI: bus type USB registered ... ehci-pci: EHCI PCI platform driver <BOOM!> Coredumps. (I tried to paste the coredump screenshot by paste.opensuse.org is on the fritz (404 after I click to paste) But suffice it to say it is your normal coredump with processor register states spewed all over the boot screen. On thing that is strange is that while all prior kernels have shown the Plymouth boot image fine, even though above says "Starting Show Plymouth Boot Screen..", it never appears. The boot just hangs after the "ehci-pci: EHCI PCI platform driver" and nothing else is shown until I refresh that window when the coredump appears. For the time being I've just removed the new kernel and blacklisted "kernel-default" -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/11/2019 07.32, David C. Rankin wrote:
On 11/14/2019 11:31 PM, David C. Rankin wrote:
On 11/14/2019 10:01 PM, Andrei Borzenkov wrote:
Nope, hangs before the journal starts. Here is a screenshot of where to boot hangs and what is dumped to the screen.
Booting without "quiet" may give more information.
That's so obvious, it's almost embarrassing -- almost... Thanks.
Reinstalled the new .82 kernel from update. Disabled "quite" option and rebooted:
https://paste.opensuse.org/97682437
Basically it gets to
Starting Show Plymouth Boot Screen..
I always uninstall it. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXc5NvQAKCRC1MxgcbY1H 1X5BAKCKUUqnVB/t6Vn9shf2DwTjbbrY1gCcC9O+pkIB6yb5T+V0TNKl7ldpNOM= =6D0g -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/15/2019 01:03 AM, Carlos E. R. wrote:
Starting Show Plymouth Boot Screen.. I always uninstall it.
I did of 42.3, but I've left it on 15.0 and 15.0 because it had caused no problems -- until now... If something change in the way Plymouth was handled in this latest kernel update, that may very well be the problem. It may also be something that change in the way USB is setup that cause it to crash. The last screen messages before the coredump seem to show the USB set up and happy -- so it's either what comes next or that's when Plymouth got around to trying to change the display. The key is how do I narrow that down :( -- David C. Rankin, J.D.,P.E.
David C. Rankin composed on 2019-11-15 01:40 (UTC-0600):
Carlos E. R. wrote: [...]
Starting Show Plymouth Boot Screen..
I always uninstall it.
I did of 42.3, but I've left it on 15.0 and 15.0 because it had caused no problems -- until now...
If something change in the way Plymouth was handled in this latest kernel update, that may very well be the problem. It may also be something that change in the way USB is setup that cause it to crash. The last screen messages before the coredump seem to show the USB set up and happy -- so it's either what comes next or that's when Plymouth got around to trying to change the display.
The key is how do I narrow that down :(
If it is actually the combination of to+from, changing the to and/or from might solve it. Adding vga=791 to cmdline will cause the kernel to use VESA 1024x768, the "from" mode, until such time as KMS kicks in. Or add video= to cmdline, e.g. video=1440x900, to change the "to" mode for KMS to kick into instead of native 1920x1080 or whatever your display's native is. Much like Carlos, I never have Plymouth on any installation that doesn't force its presence (e.g. Mageia). On openSUSE I normally install minimal, so Plymouth doesn't get installed in the first place. I like seeing the kernel messages indicate something is actually happening, unlike Windows, using the kernel's comfortably legible normal white/gray on black framebuffer text. -- Evolution as taught in public schools is religion, not science. 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 Fri, 15 Nov 2019 01:40:25 -0600 "David C. Rankin" <drankinatty@suddenlinkmail.com> wrote:
On 11/15/2019 01:03 AM, Carlos E. R. wrote:
Starting Show Plymouth Boot Screen.. I always uninstall it.
I did of 42.3, but I've left it on 15.0 and 15.0 because it had caused no problems -- until now...
If something change in the way Plymouth was handled in this latest kernel update, that may very well be the problem. It may also be something that change in the way USB is setup that cause it to crash. The last screen messages before the coredump seem to show the USB set up and happy -- so it's either what comes next or that's when Plymouth got around to trying to change the display.
The key is how do I narrow that down :(
Maybe one of these will provide some hints: https://freedesktop.org/wiki/Software/systemd/Debugging/ https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-vi... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/11/2019 16.57, Dave Howorth wrote: > On Fri, 15 Nov 2019 01:40:25 -0600 "David C. Rankin" > <drankinatty@suddenlinkmail.com> wrote: > >> On 11/15/2019 01:03 AM, Carlos E. R. wrote: >>>> Starting Show Plymouth Boot Screen.. >>> I always uninstall it. >> >> I did of 42.3, but I've left it on 15.0 and 15.0 because it had >> caused no problems -- until now... >> >> If something change in the way Plymouth was handled in this >> latest kernel update, that may very well be the problem. It may >> also be something that change in the way USB is setup that cause >> it to crash. The last screen messages before the coredump seem to >> show the USB set up and happy -- so it's either what comes next >> or that's when Plymouth got around to trying to change the >> display. >> >> The key is how do I narrow that down :( > > Maybe one of these will provide some hints: > > https://freedesktop.org/wiki/Software/systemd/Debugging/ > > https://www.digitalocean.com/community/tutorials/how-to-use-journalctl - -to-view-and-manipulate-systemd-logs > > As the system doesn't boot, it is possible that the journal service does not start. In that case, the kernel log can be written to the serial port as it tries to boot; and in vmware at least the serial port can be captured on a file on the host. The kernel boot line needs a modification for this, which right now I don't remember, I would have to investigate, if it is of interest. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXc7/MgAKCRC1MxgcbY1H 1aHAAJ45HjQsVpVUHK6Iloby55/cuafZ7ACcDj4UtcmDaTNwGfmtBMEUVct8+C4= =bd3I -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/15/2019 09:57 AM, Dave Howorth wrote:
Maybe one of these will provide some hints:
https://freedesktop.org/wiki/Software/systemd/Debugging/
https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-vi...
Thanks dnh, This is happening early before the journal is started. I created a persistent journal and nothing other than the fact the kernel is started makes it into the journal. The screenshot shown the last thing that happens is USB EHCI controller initialization, then boom... Which in the screen output with "quite" removed as a kernel parameter occurs 4-lines after the Plymouth start (so it may just be getting to the point the display flips to Plymouth when it craters) I'll try uninstalling Plymouth first and see what that does. -- 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 11/15/2019 11:33 PM, David C. Rankin wrote:
On 11/15/2019 09:57 AM, Dave Howorth wrote:
Maybe one of these will provide some hints:
https://freedesktop.org/wiki/Software/systemd/Debugging/
https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-vi...
Thanks dnh,
This is happening early before the journal is started. I created a persistent journal and nothing other than the fact the kernel is started makes it into the journal.
The screenshot shown the last thing that happens is USB EHCI controller initialization, then boom... Which in the screen output with "quite" removed as a kernel parameter occurs 4-lines after the Plymouth start (so it may just be getting to the point the display flips to Plymouth when it craters)
I'll try uninstalling Plymouth first and see what that does.
Note, This is not a 1-off problem. Second vbox 15.0 guest install on separate server updated to kernel-default-4.12.14-lp150.12.82.1 fails to boot at exact same point. Something changed between: kernel-default-4.12.14-lp150.12.79.1 and kernel-default-4.12.14-lp150.12.82.1 That break booting for 15.0 on virtualbox. I'll remove Plymouth and re-test this weekend. For now, zypper rm of kernel-default-4.12.14-lp150.12.82.1 and zypper al kernel-default will work for now. -- 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
Disclaimer | Use of IBA e-communication<https://iba-worldwide.com/disclaimer> The contents of this e-mail message and any attachments are intended solely for the recipient (s) named above. This communication is intended to be and to remain confidential and may be protected by intellectual property rights. Any use of the information contained herein (including but not limited to, total or partial reproduction, communication or distribution of any form) by persons other than the designated recipient(s) is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free. Ion Beam Applications does not accept liability for any such errors. Thank you for your cooperation.
participants (6)
-
Andrei Borzenkov -
Carlos E. R. -
Dave Howorth -
David C. Rankin -
Felix Miata -
Philippe Andersson