After Installing Updates, system fails to boot on first try

[Aere Greenway]

I installed Lubuntu 18.04 LTS on an i386 machine (Dell GX-270). After installation, it rebooted with no problems.

I installed all updates, and on rebooting it failed to boot. The screen had unreadable graphics in the top third of it.

On rebooting again, it booted okay, saying it recovered the journal.

Sometimes, it takes 3 tries to get it to boot. Often, it gets most of the way into the boot process, then suddenly goes into the GRUB menu.

I installed this system because my primary partition on the same machine started failing to boot much of the time. This failure started happening after applying updates. I was thinking something in the system files might be corrupted. But the newly-installed system has the same symptoms.

After applying updates, I expected the system to boot successfully every time.

Instead, it always crashes during the boot, or hangs, on the first try to boot. On the 2nd or 3rd try, it will boot.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-4.15.0-51-generic 4.15.0-51.55
ProcVersionSignature: Ubuntu 4.15.0-51.55-generic 4.15.18
Uname: Linux 4.15.0-51-generic i686
AlsaVersion: Advanced Linux Sound Architecture Driver Version k4.15.0-51-generic.
ApportVersion: 2.20.9-0ubuntu7.6
Architecture: i386
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC3: aere 805 F.... pulseaudio
 /dev/snd/controlC0: aere 805 F.... pulseaudio
Card0.Amixer.info:
 Card hw:0 'Live'/'SB Live! 5.1 (rev.7, serial:0x80641102) at 0xdf20, irq 18'
   Mixer name : 'SigmaTel STAC9708,11'
   Components : 'AC97a:83847608'
   Controls : 225
   Simple ctrls : 45
Card1.Amixer.info:
 Card hw:1 'MPD218'/'Akai MPD218 at usb-0000:00:1d.0-2, full speed'
   Mixer name : 'USB Mixer'
   Components : 'USB09e8:0034'
   Controls : 0
   Simple ctrls : 0
Card1.Amixer.values:

Card2.Amixer.info:
 Card hw:2 'Interface'/'M-Audio USB Uno MIDI Interface at usb-0000:00:1d.2-2, full speed'
   Mixer name : 'USB Mixer'
   Components : 'USB0763:0150'
   Controls : 0
   Simple ctrls : 0
Card2.Amixer.values:

Card3.Amixer.info:
 Card hw:3 'ICH5'/'Intel ICH5 with AD1981B at irq 17'
   Mixer name : 'Analog Devices AD1981B'
   Components : 'AC97a:41445374'
   Controls : 27
   Simple ctrls : 19
CurrentDesktop: LXDE
Date: Sun Jun 16 18:09:10 2019
HibernationDevice: RESUME=UUID=254efefa-b824-4c7b-ae5c-dcf19ed85430
InstallationDate: Installed on 2019-06-16 (0 days ago)
InstallationMedia: Lubuntu 18.04 LTS "Bionic Beaver" - Release i386 (20180426)
MachineType: Dell Computer Corporation OptiPlex GX270
ProcFB: 0 nouveaufb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-51-generic root=UUID=01278e7e-143f-479d-8842-aa15ad6ff5a8 ro quiet splash
RelatedPackageVersions:
 linux-restricted-modules-4.15.0-51-generic N/A
 linux-backports-modules-4.15.0-51-generic N/A
 linux-firmware 1.173.6
RfKill:
 0: phy0: Wireless LAN
  Soft blocked: no
  Hard blocked: no
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 06/26/2006
dmi.bios.vendor: Dell Computer Corporation
dmi.bios.version: A07
dmi.board.name: 0U1325
dmi.board.vendor: Dell Computer Corp.
dmi.chassis.type: 6
dmi.chassis.vendor: Dell Computer Corporation
dmi.modalias: dmi:bvnDellComputerCorporation:bvrA07:bd06/26/2006:svnDellComputerCorporation:pnOptiPlexGX270:pvr:rvnDellComputerCorp.:rn0U1325:rvr:cvnDellComputerCorporation:ct6:cvr:
dmi.product.name: OptiPlex GX270
dmi.sys.vendor: Dell Computer Corporation

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This change was made by a bot.

[Aere Greenway (aere)]

When I boot, but specify the other partition (also Lubuntu 18.04.2) - the one that originally started having the boot problems - it boots successfully.

When I boot, but specify the originally-installed kernel (linux-image-4.15.0-20-generic), it also boots successfully.

Sometimes, on the boots that fail, it just hangs, and I have to hold down the power button to turn it off.

It appears, that after initially powering on, and just booting from the first GRUB menu entry, it always fails in some manner the first time.

[Eduardo Alcober (ealcober)]

Hi,

Have you tried reinstalling grub? It's recommended after a big upgrade. The sequence of commands is as follows:

su -
sudo grub-install
sudo update-grub

After this the machine should boot normally. Keep in touch.

Greetings,
EAC.

[Eduardo Alcober (ealcober)]

Just eliminate the first command. just

sudo grub-install
sudo update-grub

from your normal user.

Sorry, Thanks.

[Aere Greenway (aere)]

On 6/16/19 6:51 PM, Eduardo Alcober wrote:
> Just eliminate the first command. just
>
> sudo grub-install
> sudo update-grub
>
> from your normal user.
>
> Sorry, Thanks.
>
The grub-install required a device name.  I specified:

sudo grub-install /dev/sda

It said it was successful, and the "sudo update-grub" completed
normally, as well.

When I powered on the machine after shutting down, I got the GRUB menu,
as expected.

However, the error again occurred, so that appears to have had no
effect.  The particular error this time, was that it hung (with screen
garbage visible), and I had to hold down the power button to turn it off.

--
Sincerely,
Aere

[Kai-Heng Feng (kaihengfeng)]

Does kernel parameter "nopti" help?

[Aere Greenway (aere)]

On 6/16/19 10:08 PM, Kai-Heng Feng wrote:
> Does kernel parameter "nopti" help?
>
If, in the GRUB menu, instead of selecting "Ubuntu" (the default at the
top of the list), I instead select "advanced options for Ubuntu", and
then specify the prior kernel, it works fine, in several tries, without
specifying any kernel options.  It worked once for the most current
kernel that way too, but on trying it again, it failed the same way as
before.

I tried to figure out how to specify kernel options, and I think I
specified it right (nopti at the end of the GRUB menu kernel entry,
preceded by a space), but I have no experience doing that, so I can't
say for sure I did it right.

But in the one attempt to specify the nopti option I did, it crashed
during boot.

--
Sincerely,
Aere

[Kai-Heng Feng (kaihengfeng)]

This is a quite good reference on how you do it:
https://askubuntu.com/questions/19486/how-do-i-add-a-kernel-boot-parameter

[Aere Greenway (aere)]

On 6/17/19 8:50 PM, Kai-Heng Feng wrote:
> This is a quite good reference on how you do it:
> https://askubuntu.com/questions/19486/how-do-i-add-a-kernel-boot-parameter
>
Okay, that information was helpful.

I'm quite sure I did it right this time.  I assume the text I add (after
a space at the end of the command) is:

nopti

I hit F10 to boot with the command applied (an alternative to cntrl-x). I needed that alternative because GRUB dumps you in qwerty layout, and I DO NOT use qwerty.

With the parameter applied, it crashed (on the initial try).

So I don't think the nopti parameter makes any difference.

Again, after that, and specifying the old kernel (with no boot parameter), it worked.

--
Sincerely,
Aere

[Kai-Heng Feng (kaihengfeng)]

Ok, then a kernel bisection is required. What's the latest kernel that works and the first kernel that has this issue?

[Aere Greenway (aere)]

On 6/17/19 10:48 PM, Kai-Heng Feng wrote:
> Ok, then a kernel bisection is required. What's the latest kernel that
> works and the first kernel that has this issue?
>
On the system I just installed, it's the '-20' version.  On the old
system, it was a more recent version, and I think updates removed the
last working version, so that specifying an older kernel didn't work.

However, keep in mind that now I installed a new Lubuntu 18.04.2
partition, if I specify to load the old system (which always used to
crash during boot), it has booted without any problems, several times.

The problem seems to be related some way with booting the default
partition.

I know in applying updates, it asked whether or not to replace the GRUB
configuration with the package-maintainer's version, and I agreed to do
that.  After those updates, the problem started happening.

--
Sincerely,
Aere

[Aere Greenway (aere)]

On 6/18/19 10:19 AM, Aere Greenway wrote:
> On 6/17/19 10:48 PM, Kai-Heng Feng wrote:
>> Ok, then a kernel bisection is required. What's the latest kernel that
>> works and the first kernel that has this issue?
>>
> On the system I just installed, it's the '-20' version.  On the old
> system, it was a more recent version, and I think updates removed the
> last working version, so that specifying an older kernel didn't work.
>
> However, keep in mind that now I installed a new Lubuntu 18.04.2
> partition, if I specify to load the old system (which always used to
> crash during boot), it has booted without any problems, several times.
>
> The problem seems to be related some way with booting the default
> partition.
>
> I know in applying updates, it asked whether or not to replace the GRUB
> configuration with the package-maintainer's version, and I agreed to do
> that.  After those updates, the problem started happening.
>
I encountered the same problem on my 32-bit MacBook, which I updated today.

On that one, there were two earlier kernels.  Both the '-45' kernel
(4.15.0-45, I think) and the '-47' kernel work.  The '-52' kernel
(recently updated-to) fails.

I recently updated a Dell GX-260 (the one I had problems with was a Dell
GX-270), and it has not yet encountered the problem.

- Aere

--
Sincerely,
Aere

[Aere Greenway (aere)]

On 6/18/19 10:19 AM, Aere Greenway wrote:
> On 6/17/19 10:48 PM, Kai-Heng Feng wrote:
>> Ok, then a kernel bisection is required. What's the latest kernel that
>> works and the first kernel that has this issue?
>>
> On the system I just installed, it's the '-20' version.  On the old
> system, it was a more recent version, and I think updates removed the
> last working version, so that specifying an older kernel didn't work.
>
> However, keep in mind that now I installed a new Lubuntu 18.04.2
> partition, if I specify to load the old system (which always used to
> crash during boot), it has booted without any problems, several times.
>
> The problem seems to be related some way with booting the default
> partition.
>
> I know in applying updates, it asked whether or not to replace the GRUB
> configuration with the package-maintainer's version, and I agreed to do
> that.  After those updates, the problem started happening.
>
I did some more testing, and found that the problem does occur on my
Dell GX-260.  I just didn't happen on the reboot after applying
updates.  It is possible that the problem is less likely to happen on a
reboot, than after an initial power-on.  But it does happen on a reboot.

I also updated a Dell GX-240, and the same problem happened there, as well.

If I boot (even after power-on) an earlier kernel ('-45' or '-47'), the
problem does not occur.

When I boot a kernel having the problem ('-51' or '-52'), selected as
the default for a different partition (of the same drive), the problem
does not occur (even after power-up).  It appears I can reliably boot
that way.

- Aere

--
Sincerely,
Aere

[Kai-Heng Feng (kaihengfeng)]

Ah, please try kernel parameter "nopti".

[Aere Greenway (aere)]

On 6/27/19 10:46 PM, Kai-Heng Feng wrote:
> Ah, please try kernel parameter "nopti".
>
As I indicated in my earlier feedback, I tried that, and it didn't
affect the problem.

--
Sincerely,
Aere

[Kai-Heng Feng (kaihengfeng)]

Alright, nothing more I can guess. Let's do a kernel bisection.

[Kai-Heng Feng (kaihengfeng)]

Before doing a kernel bisection, can you please test 4.15.0-48-generic and 4.15.0-50-generic?

[Aere Greenway (aere)]

On 7/2/19 10:34 AM, Kai-Heng Feng wrote:
> Alright, nothing more I can guess. Let's do a kernel bisection.
>
It works on the '-47' kernel (and the '-45' kernel), but on nothing
beyond that (I didn't have a '-50') kernel to try it on).

It seems it fails on the '-51' kernel, as well as the '-52' kernel.

--
Sincerely,
Aere

[Aere Greenway (aere)]

On 7/2/19 8:39 AM, Aere Greenway wrote:
> On 6/27/19 10:46 PM, Kai-Heng Feng wrote:
>> Ah, please try kernel parameter "nopti".
>>
> As I indicated in my earlier feedback, I tried that, and it didn't
> affect the problem.
>
I tried adding the nopti kernel parameter today, in particular, to the
default entry, and it seemed to work, though at least once, it didn't
work, but perhaps I did something wrong.

In an attempt to remove that variability, I made changes to permanently
apply the nopti parameter, and that has been working consistently, on
all 5 machines it was failing on.

Those 5 machines experiencing the problem (all of them i386), were:

Dell GX240

Dell GX260

Dell GX270

MacBook (1,1) 32-bit

HP-Mini

Anyway, applying the 'nopti' kernel parameter in a persistent way,
appears to have solved the problem.

--
Sincerely,
Aere