booting into recovery mode hangs under 20.04

Bug #1873965 reported by Jack Howarth
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

On a 2008 MacPro with GTX680 under Ubuntu 20.04, selecting the recovery mode from grub hangs on loading of the ramdisk with the Recovery Menu dialog never appearing. This problem doesn't exist for a fresh install of Ubuntu 18.04 updated to the current package updates. In that case, the Recovery Menu appears as expected. This bug in Ubuntu 20.04 was reproduced for both an existing Ubuntu 19.10 installation dist-upgraded to Ubuntu 20.04 as well as for a fresh install of Ubuntu 20.04.

Revision history for this message
Jack Howarth (jwhowarth) wrote :
Revision history for this message
Jack Howarth (jwhowarth) wrote :

If I remove 'nomodeset' from the grub kernel options for the recovery kernel under 20.04, the hang in booting at loading the ramdisk is eliminated. The recovery dialog appears as expected.

Revision history for this message
Jack Howarth (jwhowarth) wrote :

Interestingly, installing the mainline Ubuntu 5.4.25 generic kernel packages on Ubuntu 18.04 produces the same bug of nomodeset preventing the recovery dialog from appearing.

Revision history for this message
Jack Howarth (jwhowarth) wrote :

Oddly, so far I have not found a Ubuntu mainline kernel build that doesn't show the problem.

5.3.18-050318-generic
5.4.0-050400-generic
5.4.25-050425-generic
5.4.28-050428-generic
5.6.6-050606-generic

all produce the hang at loading the ramdisk when booting the recovery kernel with the default use of nomodesetunder Ubuntu 18.04. The stock 5.3.0-46-generic kernel installed by bionics updates doesn't have this problem.

So I am guessing this problem must be either a dropped patch in the kernels used by Ubuntu 20.04 or a change in configuration options in the kernels between 18.04 and 20.04.

Revision history for this message
Jack Howarth (jwhowarth) wrote :

This problem doesn't exist for current Ubuntu 19.10 under its 5.3.0-46-generic kernel. The recovery mode boots fine on the same hardware.

Revision history for this message
Jack Howarth (jwhowarth) wrote :

I have been able to eliminate the focal 5.4.0-26-generic kernel packages as the origin of this bug. Manually installing those onto an installation of Ubuntu 19.10, produced a fully functional boot. More importantly the recovery mode boot from grub worked fine. So the problem under 20.04 would appear to be something outside of the kernel itself.

Revision history for this message
Jack Howarth (jwhowarth) wrote :

This issue extends to the daily desktop cd image for focal. When booted from a usb memory stick and the safe graphics (which uses nomodeset) is selected from grub, the screen remains black and never completes booting. This issue doesn't exist with the current 19.10 cd images which boot without issue on a GTX680.

Revision history for this message
Jack Howarth (jwhowarth) wrote :

This offending package for bug is proving very difficult to pin down. I have tried to sequentially regress all the packages that the recovery kernel boot are likely to use back to their eoan versions on a 20.04 installation. In each case, I reinstalled the kernels afterwards to insure that the initrd.img files were full regenerated and reinstalled. The installed packages from the following have been regression tested...

plymouth
busybox
udev
kmod
grub
initramfs
libklibc

and none of these eliminate the breakage in nomodeset under 20.04 on a Mac ROMed GTX680.

The only 'workaround' that I have found is to append 'nouveau.modeset=1' after 'nomodeset' in grub's recovery kernel entry.

affects: linux-meta (Ubuntu) → linux (Ubuntu)
Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1873965

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

Changed in linux (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.