Ubuntu from SSD - easy method

[JaySom]

Flash ubuntu to sd and the ssd. Use dd or official imager etc.

Delete partition 2 from sd (fdisk, diskpart, gparted, Windows disk management)

Delete partition1 from ssd.

Plug both in and turn on.

[smoore]

Hmmm ... this doesn't seem to work. I used Raspberry Pi Imager to write Ubuntu 18.04.4 (Pi 3/4) 64 Server OS onto both an SD card and USB 3.0 flash drive. Using gparted (on a different workstation), I removed partition 2 from the SD card and partition 1 from the USB drive. Then both devices were inserted into the Pi4 and booted. It executes some boot sequences, clears the screen and displays 4 raspberries, then goes into a kernel panic. Game over.

Could you provide a few more clues about your method?

[procount]

This only works if the boot partition identifies the location of the rootfs partition using some consistent method, such as by partition label.
(I know Ubuntu Mate uses this approach, which makes it impossible to have more than one instance of the OS on your storage devices.)

Normally the location of the rootfs is stored in /boot/cmdline.txt if it uses the RPi bootloader.
However, some later versions of Ubuntu use U-Boot for the boot loader, and U-Boot has several different methods to boot the OS, including using some boot.scr script files that are often compressed using gzip and cpio. Such OSes are more difficult to relocate to different partitions. Sometimes it is necessary to remove UBoot altogether and use the RPi bootloader instead.

[smoore]

Working.

Mount the boot partition of the SD card using a different computer. Edit /boot/cmdline.txt and change the path to /sda2

Code: Select all

console=ttyAMA0,115200 console=tty1 root=/dev/sda2 rootfstype=ext4 

[procount]

Good work. An easy fix, unlike some of the OSes I come across.
You may want to look at /etc/fstab on sda2 as well and check those references still refer to the correct drives. They may, or may not, need updating.

[smoore]

The fstab looks as follows:

Code: Select all

LABEL=writable     /               ext4  defaults  0  0
LABEL=system-boot  /boot/firmware  vfat  defaults  0  1

This doesn't appear like it needs changing. I did alter the code with UUID=xxxx of the USB drive on the first line but it didn't (apparently) change anything. I'm going for a fresh re-install to make sure I have a disciplined approach.

[procount]

Fstab is ok. It's using partition label names to determine where the partitions are so no mods needed.

[waveform80]

We're working slowly towards support for USB boot, but the situation is complicated by our use of u-boot. In Eoan I changed the kernel command line and fstab (as procount and smoore have noticed) to use FS labels to identity the boot and root partitions, so those no longer need changing. I also updated the u-boot script so that in theory it can now boot from USB as well as SD/MMC.

Unfortunately there's still one missing bit: u-boot itself, despite having USB support compiled in (and despite apparently having USB mass-storage compiled in) ... doesn't see any mass storage devices whenever I've tested it! I've not yet had time to dig into this (beyond examining the compile time flags), but if anyone fancies a delve I'd love to hear any ideas!

In the meantime, if you want to try USB boot your best bet is to do so on a Pi3+ (where USB mass storage boot is supported "out of the box"), and to skip u-boot on startup (it isn't strictly required on classic - however it is on core for the A/B booting capability and the classic & core boot sequences derive from the same source). To do this:

• burn the image to your chosen USB device
• un-plug and re-plug the device in to mount it cleanly
• open config.txt on the boot partition and comment out/delete all the [pi*] sections
• add kernel=vmlinuz in the [all] section
• add initramfs initrd.img followkernel in the [all] section

You should wind up with something looking like this:

Code: Select all

# Please DO NOT modify this file; if you need to modify the boot config, the
# "usercfg.txt" file is the place to include user changes. Please refer to
# the README file for a description of the various configuration files on
# the boot partition.

# The unusual ordering below is deliberate; older firmwares (in particular the
# version initially shipped with bionic) don't understand the conditional
# [sections] below and simply ignore them. The Pi4 doesn't boot at all with
# firmwares this old so it's safe to place at the top. Of the Pi2 and Pi3, the
# Pi3 uboot happens to work happily on the Pi2, so it needs to go at the bottom
# to support old firmwares.

#[pi4]
#kernel=uboot_rpi_4_32b.bin
#max_framebuffers=2
#
#[pi2]
#kernel=uboot_rpi_2.bin
#
#[pi3]
#kernel=uboot_rpi_3_32b.bin

[all]
device_tree_address=0x03000000
kernel=vmlinuz
initramfs initrd.img followkernel

# The following settings are "defaults" expected to be overridden by the
# included configuration. The only reason they are included is, again, to
# support old firmwares which don't understand the "include" command.

enable_uart=1
cmdline=nobtcmd.txt

include syscfg.txt
include usercfg.txt

At this point you can simply plug your USB device into your Pi3+, remove any SD card, and it should boot happily (the rainbow screen takes a bit longer to go away as it takes time for the firmware to notice there's no SD, to fire up USB, enumerate devices, etc. but it does get there - I've tried this with an SSD and a flash drive).

A warning: right now this will work on both armhf and arm64. However, in future this will break on arm64. The reason is to do with kernel compression: the armhf image is currently a self-extracting gzipped image; that's fine as both u-boot and the pi's firmware bootloader can handle that. However, the arm64 image is currently uncompressed. The reason is simply that self-extracting kernels aren't supported on arm64 (upstream's view is roughly "bootloaders should handle that, and we never should have added self-extractors on all those other archs in the first place").

While it's uncompressed, things will work okay (both u-boot and the pi's firmware bootloader can read that), but we're planning to ship it compressed (not self-extracting, just compressed) in future because the uncompressed kernel is pretty large and that's causing issues on some of the images with minimal boot partitions. Once it's shipped compressed, u-boot will be required to uncompress it before launching it (the pi's firmware bootloader doesn't currently know how to deal with a compressed kernel), and obviously that's going to break the instructions above which skip u-boot. You could work around this by un-compressing the kernel image after an upgrade, but it's an annoying hoop to jump through (I'd rather just fix u-boot to read USB devices properly).

For those wanting to try this on a Pi4:

I would caution against trying this on a Pi4 at the moment. Booting from USB mass storage isn't (currently) supported on that model (although it is planned), so you wind up having to use an SD card to load the kernel and initrd, then continue the boot on the USB device.

It is possible to get this working (though because things are now relying on FS label you have to be careful not to duplicate those!), but you will wind up with issues every time the kernel gets upgraded or the initrd rebuilt because flash-kernel gets confused about where the boot partition "really" is (FWIW I wound up with similar problems when I tried this in Raspian even without flash-kernel - basically having two boot partitions, or a boot partition on a separate device to the root partition winds up painful whichever way you go). Yes, it's possible to work around these issues if you remember to jump through some more hoops, but while it was an interesting experiment I'd rather just wait for official USB boot support on the 4 which will make everything much simpler and should mean you can follow a similar path to the 3+ above.

Dave.

[lingon]

I did try this on a Raspberry Pi 4. It gets as far as to the rainbow screen where it hangs with only a SSD attached. Before that the USB-SSD enclosure status LED clearly blinks for a brief moment, so it is accessing the USB bus.

I'll try to see if the serial console has some hints about what is failing.

Has anyone else tried to boot Ubuntu using the new USB MSD boot capability?

[lingon]

The vmlinuz Aarch64 kernel is gzip compressed. Uncompressing it and booting the uncompressed kernel did not improve this.
My serial-USB cable has not yet given any output, but if the problem is before the kernel boots then it is expected.

[lingon]

In the end I managed to get Ubuntu 20.04 booting from my SSD. My 500 GB Crucial BX 100 SSD is already quite old, but so far it has never given any I/O errors. It run without problems with Raspbian when I tested it shortly, but now I get some nasty timeouts and errors which slow down the boot of the Ubuntu 20-04 LTS kernel. But that is already a bit off the topic and something I need to look into.

Thanks waveform80 for the detailed description on how to hack around the Uboot problem to get the USB MSD boot working on a Raspberry Pi 4! Do you have any new insight on what could be the reason that Uboot does not see the USB devices? I did try to run once more with only 3072 MB of RAM enabled, but I could not make Uboot work in that way.

[lingon]

Has anyone running from a SSD encountered this error message?

blk_update_request I/O err dev sda

I tested the SSD several times and found no errors on it. By booting Ubuntu 20.04 into single user mode I was able to work around the errors that put the filesystem into a read only mode and install all upgraded packages. It USB boots nicely and at least for the moment it seems to work as it should. Currently the kernel is:

Linux ubuntu 5.4.0-1011-raspi #11-Ubuntu SMP Fri May 8 07:43:33 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux

ubuntu@ubuntu:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 48.4M 1 loop /snap/core18/1708
loop1 7:1 0 48.4M 1 loop /snap/core18/1753
loop2 7:2 0 23.5M 1 loop /snap/snapd/7267
loop3 7:3 0 61.3M 1 loop /snap/lxd/14808
sda 8:0 0 465.8G 0 disk
ââsda1 8:1 0 256M 0 part /boot/firmware
ââsda2 8:2 0 465.5G 0 part /

[alkersan]

Unfortunately there's still one missing bit: u-boot itself, despite having USB support compiled in (and despite apparently having USB mass-storage compiled in) ... doesn't see any mass storage devices whenever I've tested it! I've not yet had time to dig into this (beyond examining the compile time flags), but if anyone fancies a delve I'd love to hear any ideas!

I've tried to make u-boot recognize the usb controller on rpi4, and even current master version, with compiled xhci support it fails to do so. Then looked at patchwork, and there seems to be an ongoing effort to bring the usb firmware initialization to u-boot here. With this patch applied and with replacement of uboot_rpi_4.bin on the boot partition I've managed to boot the 20.04 distro.

[ejolson]

Unfortunately there's still one missing bit: u-boot itself, despite having USB support compiled in (and despite apparently having USB mass-storage compiled in) ... doesn't see any mass storage devices whenever I've tested it! I've not yet had time to dig into this (beyond examining the compile time flags), but if anyone fancies a delve I'd love to hear any ideas!

I've tried to make u-boot recognize the usb controller on rpi4, and even current master version, with compiled xhci support it fails to do so. Then looked at patchwork, and there seems to be an ongoing effort to bring the usb firmware initialization to u-boot here. With this patch applied and with replacement of uboot_rpi_4.bin on the boot partition I've managed to boot the 20.04 distro.

In my opinion this is significant news and may open the door for many distributions to run on the Pi. I'd like to try the same with the 64-bit version of Void Linux, but that belongs in another thread. I find it disappointing as ARM has rapidly entered the server market that the way a Pi boots is very different than the bigger ARM-based servers. In contrast, the same x86 installation media and boot system used to install Ubuntu on a cheap laptop can be used for an expensive 128-core server.

Pooling resources at this point, at least so the Pi can boot all the common ARM Linux distributions, could only help the ecosystem as a whole.

[jens.maus]

Unfortunately there's still one missing bit: u-boot itself, despite having USB support compiled in (and despite apparently having USB mass-storage compiled in) ... doesn't see any mass storage devices whenever I've tested it! I've not yet had time to dig into this (beyond examining the compile time flags), but if anyone fancies a delve I'd love to hear any ideas!

I've tried to make u-boot recognize the usb controller on rpi4, and even current master version, with compiled xhci support it fails to do so. Then looked at patchwork, and there seems to be an ongoing effort to bring the usb firmware initialization to u-boot here. With this patch applied and with replacement of uboot_rpi_4.bin on the boot partition I've managed to boot the 20.04 distro.

Thanks for this note. In fact, I am also currently working on getting u-boot 2020.04 with the XHCI patch applied in one of my projects because I would like to get USB boot implemented for the rpi4 (see https://github.com/jens-maus/RaspberryM ... -640118741). However, even with the XHCI patches applied (see https://github.com/jens-maus/RaspberryM ... ot-patches) my own compiled U-boot version stops right after DRAM initialization (see github ticket above) when booting just with a USB thumb drive attached.

I could, however, verify that when booting from SD card U-boot is perfectly able to use/initialize the USB ports of the rpi4 (because the XHCI init shows up perfectly fine), so thge applied XHCI patches seem to work. Only when I remove the SD card and try to boot from a USB thumb drive with the same uboot.bin / boot partition like on the SD card the rpi4 stops immediately after the DRAM init and on the HDMI I only can see the standard color splash screen of the pi. So do you have any idea or reference where to continue my investigations to get the usb-boot with u-boot and the latest bootloader rpi4 working?

Any help is of course highly appreciated.

[ftarz]

Just wondering if there's any news about Ubuntu and USB booting on the RPI4?

Regards.
Frank

[alkersan]

Just wondering if there's any news about Ubuntu and USB booting on the RPI4?

Regards.
Frank

Checked the daily build and noticed that u-boot was updated to2020.04 from upstream, and there are mentions of a few rpi related tweaks. Unfortunately those aren't related to USB. Also it seems that upstream u-boot didn't land any raspberry related usb or xhci updates neither.