Were you affected by this bug affecting Ubuntu 4.18 kernel: https://news.softpedia.com/news/canonical-apologizes-for-another-ubuntu-linu... On Tue, Feb 19, 2019 at 11:07 D. Hugh Redelmeier via talk <talk@gtalug.org> wrote:

| From: Clive DaSilva via talk <talk@gtalug.org>

Note: I barely touch Ubuntu so I may be wrong in important details.

| I had a problem with my recent Ubuntu 18.10 install which I thought that I | should share. I was running Ubuntu 18.04 on an older Pentium (R)Dual Core | CPU E5200 with 4 gigs of ram and things went well. About 2 months ago, I | noticed that there was an Ubuntu 18.10 so I thought that I would give it a | try. So I downloaded Ubuntu 18.10 with kernel 4.18.0.10 and it worked well | with all my machine learning stuff (Anaconda3, etc.).

So far, so good.

| About 2 weeks ago, | Ubuntu informed me that I had a kernel update so I downloaded the update | (kernel 4.18.0.14) and tried to install it. Couldn't get past the boot | screen, so I reinstalled 4.18.0.10 but right away I was informed of the | waiting update.

I'm not 100% sure what you mean by "the boot screen".

(1) trying a previous kernel

My systems always have the most recent three installed kernels available for booting. All you have to do is talk to grub at boot time to select one of the two older kernels. Did you try that?

If that works, you have something more concrete to report.

(2) getting more information out of the boot process

GRUB invokes the kernel with parameters. Ted pointed you at a page one some parameters that you could try tweaking.

Before you do that,

- boot your system

- early on, get grub's attention

- choose the boot entry you wish to use

- edit that entry (there's a key for that). (The edit is only for this boot.). Remove "quiet splash" from the kernel parameters. This will cause the boot process to be logged to the console. That way you can often find out where it goes wrong.

You should be able to tell if it is a kernel problem or an X problem or something else.

I admit that the result looks like gobbledygook to the unfamiliar.

(3) lock the system to a kernel that works.

I'm pretty sure that there are magic things to do with apt-get or whatever you use to update to say

(a) don't update the kernel (if, in fact, that turns out the be the problem), or

(b) keep this working kernel even if you install new ones. Also: you need to tell grub to keep using the kernel you like.

| I googled the issue and the only comment that made sense was | to block Wayland being loaded and instead default to Xorg by adjust | custom.conf \etc\gdm3. That made no difference to my situation as described

Xorg and Wayland both talk to the kernel. But there is usually a difference between a bug in them and a bug in the kernel.

You need to narrow down the problem: identify the component that is the most likely culprit. Or give up (which might save you time).

I imagine that there is a way to boot to text console mode (its been years since I've done that). From there you can start X by hand. That might give you insight. --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk

-- Eric Brown MD HBSc FRCPC For encryption, OpenPGP public key available on request.

Thank you Hugh and Eric. I think the softpedia link highlighted the issue that my computer was affected by. I am back running 18.04LTS kernel 4.15.0.45 for now. When I mentioned “boot screen” I meant the point in time after the machine starts and the red Ubuntu screen shows up. My boot process stopped there , no small windows showing the process of the boot into Ubuntu to show the username(s) and ask for password. I tried to access an earlier kernel, but the machine just kept crashing. I am very happy with 18.04LTS as in the last three weeks, its worked really well for me. Thanks for your response, guys, I’ll lay off 18.10 for a while as 18.04 suits my needs Clive From: talk <talk-bounces@gtalug.org> On Behalf Of Eric Brown via talk Sent: February 19, 2019 11:32 AM To: D. Hugh Redelmeier <hugh@mimosa.com>; GTALUG Talk <talk@gtalug.org> Cc: Eric Brown <eb@ericebrown.com> Subject: Re: [GTALUG] FW: Problems with Ubuntu 18.10 Were you affected by this bug affecting Ubuntu 4.18 kernel: https://news.softpedia.com/news/canonical-apologizes-for-another-ubuntu-linu... On Tue, Feb 19, 2019 at 11:07 D. Hugh Redelmeier via talk <talk@gtalug.org <mailto:talk@gtalug.org> > wrote: | From: Clive DaSilva via talk <talk@gtalug.org <mailto:talk@gtalug.org> > Note: I barely touch Ubuntu so I may be wrong in important details. | I had a problem with my recent Ubuntu 18.10 install which I thought that I | should share. I was running Ubuntu 18.04 on an older Pentium (R)Dual Core | CPU E5200 with 4 gigs of ram and things went well. About 2 months ago, I | noticed that there was an Ubuntu 18.10 so I thought that I would give it a | try. So I downloaded Ubuntu 18.10 with kernel 4.18.0.10 and it worked well | with all my machine learning stuff (Anaconda3, etc.). So far, so good. | About 2 weeks ago, | Ubuntu informed me that I had a kernel update so I downloaded the update | (kernel 4.18.0.14) and tried to install it. Couldn't get past the boot | screen, so I reinstalled 4.18.0.10 but right away I was informed of the | waiting update. I'm not 100% sure what you mean by "the boot screen". (1) trying a previous kernel My systems always have the most recent three installed kernels available for booting. All you have to do is talk to grub at boot time to select one of the two older kernels. Did you try that? If that works, you have something more concrete to report. (2) getting more information out of the boot process GRUB invokes the kernel with parameters. Ted pointed you at a page one some parameters that you could try tweaking. Before you do that, - boot your system - early on, get grub's attention - choose the boot entry you wish to use - edit that entry (there's a key for that). (The edit is only for this boot.). Remove "quiet splash" from the kernel parameters. This will cause the boot process to be logged to the console. That way you can often find out where it goes wrong. You should be able to tell if it is a kernel problem or an X problem or something else. I admit that the result looks like gobbledygook to the unfamiliar. (3) lock the system to a kernel that works. I'm pretty sure that there are magic things to do with apt-get or whatever you use to update to say (a) don't update the kernel (if, in fact, that turns out the be the problem), or (b) keep this working kernel even if you install new ones. Also: you need to tell grub to keep using the kernel you like. | I googled the issue and the only comment that made sense was | to block Wayland being loaded and instead default to Xorg by adjust | custom.conf \etc\gdm3. That made no difference to my situation as described Xorg and Wayland both talk to the kernel. But there is usually a difference between a bug in them and a bug in the kernel. You need to narrow down the problem: identify the component that is the most likely culprit. Or give up (which might save you time). I imagine that there is a way to boot to text console mode (its been years since I've done that). From there you can start X by hand. That might give you insight. --- Talk Mailing List talk@gtalug.org <mailto:talk@gtalug.org> https://gtalug.org/mailman/listinfo/talk -- Eric Brown MD HBSc FRCPC For encryption, OpenPGP public key available on request.