Boot Problems after Kernel 5.4.0.90 Upgrade...

[asciiman]

Hello everyone!

Code: Select all

System:    Kernel: 5.4.0-90-generic x86_64 bits: 64 compiler: gcc v: 9.3.0
Desktop:  Cinnamon 5.0.7
Linux Mint 20.2 Uma base: Ubuntu 20.04 focal 
Machine:   Type: Desktop Mobo: ASUSTeK model: A68HM-PLUS v: Rev X.0x serial: <filter> 
UEFI:   American Megatrends v: 2011 date: 10/17/2018

Yesterday, immediately after upgrading to kernel 5.4.0.90 and rebooting, my system stalled and locked up at the UEFI/Bios splash screen.
I could not access the bios by the usual methods (F1, F2, or DEL key).
I pushed reset and the machine did reboot and get past the splash screen, booting normally and I was able to get to my desktop. I then verified that 5.4.0.90 was the active kernel.

The same behaviour occurred today at power up, but hitting reset would only get me as far as the bios splash screen. I could not get into the bios or beyond the UEFI/BIOS splash screen.
I went through this process a half-dozen times to the same result.

First time this has every happened to me with a kernel upgrade.

I unplugged the power supply, opened up the desktop and unplugged the boot drive.
Then plugged the power back in and cold booted.
I got the 'bios error' screen and hit F1 to access the bios and it came up.
The Bios had fallen back to the "Optimal Settings" preset which is tailored for Windows machines and included enabling Fast Boot and Windows UEFI mode.

I made various corrections to the UEFI Bios, and saved my settings.
Shut down the machine and plugged in my boot drive.
Cold booted and up came my desktop!
Not really sure how a kernel upgrade would cause this, but it definitely occurred at my reboot immediately after the kernel download and install.
(Yes, the 3V mobo battery is brand new)
Everything seems to be running perfectly now, but I wanted to bring this up as there may be others who are experiencing this issue.


Thanks,
Allen

[RIH]

Not had an issue with either of my machines with that kernel.
I would have suspected a lack of space on your / partition as being the likely culprit.
Can you enter

Code: Select all

inxi -Fxxxrz

into a terminal & post back the output in your next post between the code (</>) tags for easy reading??

[asciiman]

Code: Select all

System:
  Kernel: 5.4.0-90-generic x86_64 bits: 64 compiler: gcc v: 9.3.0 
  Desktop: Cinnamon 5.0.7 wm: muffin 5.0.2 dm: LightDM 1.30.0 
  Distro: Linux Mint 20.2 Uma base: Ubuntu 20.04 focal 
Machine:
  Type: Desktop Mobo: ASUSTeK model: A68HM-PLUS v: Rev X.0x serial: <filter> 
  UEFI: American Megatrends v: 2011 date: 10/17/2018 
Battery:
  Device-1: hidpp_battery_0 model: Logitech M310 serial: <filter> 
  charge: 55% (should be ignored) rechargeable: yes status: Discharging 
  Device-2: hidpp_battery_1 model: Logitech K520 serial: <filter> 
  charge: 70% (should be ignored) rechargeable: yes status: Discharging 
CPU:
  Topology: Quad Core model: AMD A10-7860K Radeon R7 12 Compute Cores 4C+8G 
  bits: 64 type: MCP arch: Steamroller rev: 1 L2 cache: 2048 KiB 
  flags: avx lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm 
  bogomips: 28726 
  Speed: 1866 MHz min/max: 1400/3600 MHz boost: enabled Core speeds (MHz): 
  1: 1541 2: 1415 3: 1541 4: 1463 
Graphics:
  Device-1: AMD Kaveri [Radeon R7 Graphics] vendor: ASUSTeK driver: radeon 
  v: kernel bus ID: 00:01.0 chip ID: 1002:130f 
  Display: x11 server: X.Org 1.20.11 driver: ati,radeon 
  unloaded: fbdev,modesetting,vesa resolution: 1920x1080~60Hz 
  OpenGL: renderer: AMD KAVERI (DRM 2.50.0 5.4.0-90-generic LLVM 12.0.0) 
  v: 4.5 Mesa 21.0.3 direct render: Yes 
Audio:
  Device-1: AMD Kaveri HDMI/DP Audio vendor: ASUSTeK driver: snd_hda_intel 
  v: kernel bus ID: 00:01.1 chip ID: 1002:1308 
  Device-2: AMD FCH Azalia vendor: ASUSTeK driver: snd_hda_intel v: kernel 
  bus ID: 00:14.2 chip ID: 1022:780d 
  Sound Server: ALSA v: k5.4.0-90-generic 
Network:
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet 
  vendor: ASUSTeK driver: r8169 v: kernel port: e000 bus ID: 04:00.0 
  chip ID: 10ec:8168 
  IF: enp4s0 state: up speed: 100 Mbps duplex: full mac: <filter> 
Drives:
  Local Storage: total: 465.76 GiB used: 46.08 GiB (9.9%) 
  ID-1: /dev/sda vendor: Western Digital model: WDS500G1B0A-00H9H0 
  size: 465.76 GiB speed: 6.0 Gb/s serial: <filter> rev: 00WD scheme: GPT 
Partition:
  ID-1: / size: 447.12 GiB used: 46.07 GiB (10.3%) fs: ext4 dev: /dev/sda2 
  ID-2: swap-1 size: 8.00 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sda3 
Sensors:
  System Temperatures: cpu: 2.1 C mobo: N/A gpu: radeon temp: 4 C 
  Fan Speeds (RPM): N/A 
Repos:
  No active apt repos in: /etc/apt/sources.list 
  Active apt repos in: /etc/apt/sources.list.d/official-package-repositories.list 
  1: deb http://packages.linuxmint.com uma main upstream import backport #id:linuxmint_main
  2: deb http://archive.ubuntu.com/ubuntu focal main restricted universe multiverse
  3: deb http://archive.ubuntu.com/ubuntu focal-updates main restricted universe multiverse
  4: deb http://archive.ubuntu.com/ubuntu focal-backports main restricted universe multiverse
  5: deb http://security.ubuntu.com/ubuntu/ focal-security main restricted universe multiverse
  6: deb http://archive.canonical.com/ubuntu/ focal partner
  Active apt repos in: /etc/apt/sources.list.d/pkgcrosswire-ppa-focal.list 
  1: deb http://ppa.launchpad.net/pkgcrosswire/ppa/ubuntu focal main
Info:
  Processes: 218 Uptime: 5h 44m Memory: 6.73 GiB used: 2.48 GiB (36.9%) 
  Init: systemd v: 245 runlevel: 5 Compilers: gcc: 9.3.0 alt: 9 Shell: bash 
  v: 5.0.17 running in: gnome-terminal inxi: 3.0.38

[RIH]

Sorry nothing obvious springs out from your inxi report - except that space would certainly not seem to be an issue..
I do notice that another poster has had issues (wifi) just with that kernel, so maybe it is not the best release ever..
viewtopic.php?f=46&t=360942

[Jo-con-Ël]

my system stalled and locked up at the UEFI/Bios splash screen.

IMHO it is not a problem with kernel or any other update even it is not a problem with SO (look here).

You can discard kernel easily booting with an old kernel in GRUB menu>Advanced Options> and remove that 5.4.0-90 kernel from Update Manager>View>Linux kernel...

[asciiman]

Thank you for your response.
However, I find it strange that my system was having no such problems up until the download and install of the new kernel.
I am using the 5.4.0.90 currently and will report back if the issue returns.
So far, it seems OK.

[Jo-con-Ël]

Notice what you have done (disconnect disk, load optimized default,...) is a sort of UEFI/BIOS reset that may have solve the problem in the same way as proposed by support page.

Link on my last post was wrong (laptops) and changed by this one. Sure you can find other cases in support pages or ASUS community treating this problem.

[asciiman]

Kind of strange that it happened IMMEDIATELY after the kernel upgrade.
I had no issues with boot since the 5.4.0.86 kernel regression where the DVD tray would open and close at a cold boot.
I hope you are correct... that it is just my system that had the issue.
But I wanted to make it known in case it is something larger.

[asciiman]

Update:
Today, the same problem occurred (as OP) when upgrading to latest 5.4.0.91 generic.

System rebooted and loaded the new kernel. Ran fine initially.

Overnight, after a full shutdown, a cold boot brought a stuck bios splash screen.
System would not advance to load Linux.
I could not access my bios either, as before.
Had to switch off the desktop power supply.

After disconnecting my SSD drive, I could then boot into bios/UEFI.

I examined my UEFI/Bios settings and nothing had changed.

Re-attached my boot drive and everything booted as normal.

None of these issues has ever come up before I upgraded to 5.4.0.90.
What changed in these recent kernels that might effect the boot in this manner?
Were there changes made that would require the UEFI/bios to run Windows/UEFI mode in Secure Boot?
I have always used the "Other OS" setting in the bios, and left CSM in "Auto" mode.
That always worked fine until 5.4.0.90 generic.

But I think it is curious (and telling) that trouble has now come with each recent kernel upgrade.
Something now seems incompatible (or corrupted) with either the ASUS Bios, my UEFI/Bios settings, or these recent kernels.

Anyone with experience in kernel development here on the forum that might be able to speak to this?

Thanks in advance,
Allen

[SMG]

Update:
Today, the same problem occurred (as OP) when upgrading to latest 5.4.0.91 generic.

System rebooted and loaded the new kernel. Ran fine initially.

This indicates the kernel is not the issue. If the kernel was the problem it would happen every time. It does not.

It sounds like your system has a hardware related issue and it is more likely to occur from a cold boot than a warm boot.

One thing to keep in mind is booting into BIOS is separate and happens before booting into the operating system. You indicated earlier in this topic that you pulled the drive and the system would still not boot. That is indicative of a hardware issue. If your BIOS changed (and you said it did), then it sounds like your system has an issue outside of the operating system.

In this thread BIOS settings resetting after reboot. the person had some type of BIOS software installed that was causing the settings to revert.

Considering disconnecting and then reconnecting the SSD seems to "fix" things, I'd be suspect of the cabling/connections for it.

[asciiman]

You indicated earlier in this topic that you pulled the drive and the system would still not boot.

Actually, no. Apologies if I was unclear.
The first time, after I pulled the drive, it DID get beyond the bios splash screen.
It booted to the bios but fell back to 'Optimized Settings' which are tailored for Windows OS's.

It is just odd to me that this only occurs after a kernel upgrade.
In each instance, after upgrading, the first cold boot (and every successive attempt to boot) causes a lock up at the bios splash and I cannot access the bios. Also in each instance, after I have disconnected the boot drive, I can then access and reset my bios. After doing that, the machine boots as normal and it continues to boot as normal until a kernel upgrade comes around. That's a clue!

I will follow up on that link you provided, triple check the SATA cable to the boot drive, and I will also get in touch with ASUS on this to see if there might be something in that BIOS version that is causing this.

When I get to the bottom of the issue, I will post my findings here.

Appreciate your response,
Allen

[asciiman]

With regard to that link you shared, the software in question is a Windows-based GUI that ASUS provides for making OC and feature changes while in the host (Windows) OS.

I am running a 100% single-boot Linux system on my boot drive and have installed nothing like what is being discussed in that linked topic.
The only OS on my boot drive is Mint 20.2

[SMG]

You indicated earlier in this topic that you pulled the drive and the system would still not boot.

Actually, no. Apologies if I was unclear.
The first time, after I pulled the drive, it DID get beyond the bios splash screen.
It booted to the bios but fell back to 'Optimized Settings' which are tailored for Windows OS's.

I just re-read your first post and I see that was my error. It was stuck with the drive in, but not when you pulled it.

The fact that it sometimes does it and sometimes does not (which I think I read that part correctly ) seems to more likely be a hardware issue unless there is filesystem corruption. That is the only aspect from an operating system which comes to mind for me. You could run fsck on the partitions to see if anything is amiss. (We recommend booting to a live session of Mint to run fsck because if you want to run the fix option the partition must be unmounted.)

With regard to that link you shared, the software in question is a Windows-based GUI that ASUS provides for making OC and feature changes while in the host (Windows) OS.

I didn't realize there was BIOS software that was only available if one had a specific operating system. I learn something new all the time.

I am running a 100% single-boot Linux system on my boot drive and have installed nothing like what is being discussed in that linked topic.
The only OS on my boot drive is Mint 20.2

In your inxi output I do not see mention of an efi partition. Did you create one for your install?

[asciiman]

Here is Gparted...

[SMG]

Here is Gparted...

It's there. Sometimes I see that partition listed in inxi output and other times there are cases like yours where it exists, but it is not listed. I thought inxi was getting the information from /etc/fstab, but I'm not completely sure.

That is where the boot partition resides and where the operating system knows which kernel to use to boot. However, errors usually end up on the screen if there is a problem there.

Just trying to think of other possibilities.

[asciiman]

The fact that it sometimes does it and sometimes does not (which I think I read that part correctly ) seems to more likely be a hardware issue unless there is filesystem corruption. That is the only aspect from an operating system which comes to mind for me.

To be clear, it is not an 'intermittent' kind of issue.
It has only occurred immediately after a kernel upgrade.
I am in agreement with your thoughts on hardware or file corruption in the bios itself or on the boot partition. But why does it act up only after a kernel upgrade? In each instance, after I have reset the bios, the system boots perfectly without issue until the next kernel upgrade.

I am considering re-installing the bios just to say I did.
But the system is running and booting perfectly now.

[SMG]

To be clear, it is not an 'intermittent' kind of issue.
It has only occurred immediately after a kernel upgrade.
I am in agreement with your thoughts on hardware or file corruption in the bios itself or on the boot partition. But why does it act up only after a kernel upgrade? In each instance, after I have reset the bios, the system boots perfectly without issue until the next kernel upgrade.

The boot partition would have to be updated whenever a new kernel is installed, so there is that "one-time" change happening.

However, I am not aware that change would have any impact on what the BIOS sees in regards to that boot partition, but maybe it does?

I am considering re-installing the bios just to say I did.
But the system is running and booting perfectly now.

I'd personally leave the BIOS as is if it is working. Maybe someone else will have some ideas of something to check before the next kernel is installed.

[asciiman]

The boot partition would have to be updated whenever a new kernel is installed, so there is that "one-time" change happening.

However, I am not aware that change would have any impact on what the BIOS sees in regards to that boot partition, but maybe it does?

Yes, that's my understanding. I wonder if 'Secure Boot' is causing it somehow?
In the previous ASUS bios on this machine, the Secure Boot feature could be toggled on/off.
In this, the latest bios for this MB, the feature is not available. Secure Boot is always 'Enabled.'

Before I did the Mint 20.2 install (from 19.3), I replaced the MB battery and upgraded the ASUS bios to ver 2011. The bios holds its settings fine.

Thanks for your assistance. I might try to email someone over at ASUS to see if this has ever come up before.

[SMG]

One can definitely install and run Mint with Secure Boot on. The keys are there for that.

I did not think it is necessary to re-install if one one installed with it disabled and later enabled it, but I've not looked into the specifics with regards to that type of situation.

[asciiman]

That was the thing... in previous bios versions, I could toggle Secure Boot on/off.
But in this version Secure Boot is always in the 'Enabled' state.
The bios has a dedicated section for Secure Boot, but provides no means of changing it.
Never seen that before.