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.

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

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.

https://paste.opensuse.org/69998024

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 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.

https://paste.opensuse.org/69998024

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 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

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.

On Fri, 15 Nov 2019 01:40:25 -0600 "David C. Rankin" 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

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

Disclaimer | Use of IBA e-communicationhttps://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.