Installer crashes when booting from USB on Raspberry Pi
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ubiquity (Ubuntu) |
Triaged
|
High
|
Unassigned |
Bug Description
After writing the Ubuntu 24.04 Desktop for Raspberry Pi image to an SSD drive with a USB3 interface (specifically; this issue does not occur when booting from an SD card), booting the drive on a Pi 4 or Pi 5, and running through the installer to the point where the (corrupted) slide deck starts to display during setup, the installer crashes.
[ Workaround ]
A test image is now available; please see comment 1 below for details.
At the time of writing, some workarounds have been found, but none that consistently work on all boards with all drives. One workaround that has worked on a Pi with a Samsung EVO SSD, and a Crucial SSD is as follows:
Before booting the image, find config.txt on the boot partition, and the "dtoverlay=
dtoverlay=
disable_
Should become:
dtoverlay=
disable_
Unmount the drive cleanly, boot it, and run through the installer. You may revert the change (if you wish) after successful installation.
Another workaround, reported as working on a Pi 5 with an NVMe drive attached over PCIe:
Before booting the image, find config.txt on the boot partition. Under the first "[all]" section append the following line:
dtparam=pciex1
Unmount the drive cleanly, boot it, and run through the installer.
Please note both workarounds have also been reported as failing with certain drive combinations.
[ Background ]
Given this crash occurs immediately upon the (corrupted) slide deck starting, that it only occurs when booting from USB (but the exact same image works from an SD card), and that merely changing the pre-allocation of the contiguous memory area affects it, I suspect this at least related to (if not a duplicate of) LP: #2037015, particularly since a crash bug is now associated with it too, LP: #2062146.
Still, I'll leave this open as a non-duplicate for now as I'm not positive of root-cause yet.
Related branches
- Erich Eickmeyer: Approve
-
Diff: 3179 lines (+2984/-16)15 files modifieddefinitions/pi_desktop_cases.xml (+162/-16)
testcases/image/1745_RaspberryPi 4 4GB Desktop SD (+201/-0)
testcases/image/1746_RaspberryPi 4 8GB Desktop SD (+201/-0)
testcases/image/1747_RaspberryPi 400 Desktop SD (+201/-0)
testcases/image/1749_RaspberryPi CM4 4GB Desktop eMMC (+205/-0)
testcases/image/1750_RaspberryPi CM4 8GB Desktop eMMC (+205/-0)
testcases/image/1791_RaspberryPi 5 4GB Desktop SD (+201/-0)
testcases/image/1792_RaspberryPi 5 8GB Desktop SD (+201/-0)
testcases/image/1812_RaspberryPi 4 4GB Desktop USB (+201/-0)
testcases/image/1813_RaspberryPi 4 8GB Desktop USB (+201/-0)
testcases/image/1814_RaspberryPi 400 Desktop USB (+201/-0)
testcases/image/1815_RaspberryPi 5 4GB Desktop USB3 (+201/-0)
testcases/image/1816_RaspberryPi 5 4GB Desktop NVMe (+201/-0)
testcases/image/1817_RaspberryPi 5 8GB Desktop USB (+201/-0)
testcases/image/1818_RaspberryPi 5 8GB Desktop USB (+201/-0)
description: | updated |
Changed in ubiquity (Ubuntu): | |
status: | New → Triaged |
importance: | Undecided → High |
I now have a test image that, using the patch from LP: #2037015, appears to fix the installer issue when booting from USB. If volunteers are interested in testing the image, I've made it available at:
https:/ /zoidberg. waveform. org.uk/ images/ ubuntu- 24.04-preinstal led-desktop- arm64+raspi. img.xz
The SHA256 of the image, for verification purposes, is b2718d9005a5ea6 486b8512b6cf397 4ce48ef879d1232 a6dc88b2ccaa1dc 3390
I've tested booting from two SD cards on both models and both appear fine; I've also tested USB boot on the Pi 4 (which worked happily) and tomorrow I should be able to test NVMe on a Pi 5. However, given the variability displayed by this bug already, the wider the variety of hardware tested, the better.
Naturally, no workarounds should be in place when testing (leave the config.txt "as is"). If things work, please report the model and memory size of your Pi (e.g. Pi 4 4GB) and what you're booting from (SD card, SSD, NVMe). make+model of the boot media would be useful too, but largely to judge if we're covering a reasonable range of hardware.
If things don't work, please report the above information, plus where in the procedure the crash occurred. If possible, re-flash and try to confirm if the crash occurs in the same place each time (we've already seen cases in this bug where "sometimes it does and sometimes it doesn't").