openSUSE Tumbleweed aarch64 for Raspberry Pi-3B can be installed so that the Pi can be booted from USB-connected storage devices. As a result, you can install TW on a hard drive or SSD drive through a USB adapter and use that as your primary working environment.
However, if you install TW on microSD card using a USB adapter, and then boot through that adapter, the setup process creates configuration files that will subsequently only allow you to boot in that manner – through the USB adapter: you can’t move the microSD card to the microSD (mmc) slot and boot from /dev/mmcblk0.
This How-To shows you how to set up a microSD drive so that you can use it to boot your Raspberry Pi-3B from either the microSD slot (mmc) or through a USB adapter in a USB port.
**
I. One-time preparation of the Raspberry Pi-3 to boot from a USB drive**
Before you can boot your Raspberry Pi-3B (NOT available on earlier models) from a USB port (whether Raspbian, openSUSE, or Fedora), you must follow a one-time procedure to prepare the Pi for USB booting.
The general concepts of Pi-3B Mass Storage Booting are documented here:https://www.raspberrypi.org/blog/pi-3-booting-part-i-usb-mass-storage-boot/
If you have not already done prepared your Pi for USB booting, follow the preparation procedure documented here:https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md
through the step:
$ vcgencmd otp_dump | grep 17:
17:3020000a
which will verify that your RPi-3B is configured to attempt to boot off an attached USB drive. That is, you don’t need to continue into the section “PREPARE THE USB STORAGE DEVICE”. However, if you subsequently are unable to boot SUSE off your USB drive, return to that section to create a bootable Raspbian USB drive in order to verify that your USB drive is compatible with RPi-3B for this purpose.
II. Getting Started and Context
Assume that you’re preparing to do a new install of a standard Tumbleweed or Leap aarch distribution and that you have a version of SLES, Leap, or TW already running on your RPi-3B. Boot your RPi-3 from the microSD drive in your microSD (mmc) slot.
Find the image from which you want at to create a new installation fromhttps://en.opensuse.org/HCL:Raspberry_Pi3
or athttp://download.opensuse.org/ports/aarch64/tumbleweed/images/
Download that image to your computer. Follow directions for imaging to your storage device from thehttps://en.opensuse.org/HCL:Raspberry_Pi3
page.
The following procedure was developed with the 2018.02.02 distribution:openSUSE-Tumbleweed-ARM-XFCE-raspberrypi3.aarch64-2018.02.02-Build1.2.raw
and in my case I booted off a prior install of TW on a microSD drive in the microSD (mmc) slot; the drive was then mounted as /dev/mmcblk0.
To avoid the risk of wiping out your boot device in some of the steps below, this procedure presumes that you’ve booted into an openSUSE distribution in a similar manner, with your microSD in the microSD (mmc) slot. Your USB-attached microSD drive will then be connected as /dev/sda, and in the steps below you’ll reference the drive and partitions as /dev/sda or /dev/sda?, but as a precaution, the directions below reference the drive as /dev/sdX or /dev/sdX? so you’ll have to consciously select the drive you’re using.
For example, assume that you have a microSD that you want to reimage so that it will boot from either the microSD drive (/dev/mmcblk0) or from a USB adapter with that microSD card in it, (/dev/sdX). Then after downloading the image, to a system already running openSUSE, you would insert that USB adapter containing the microSD card into a USB slot on your RPi-3B, wipe any file system previously installed on that microSD card, and use the instructions from that install-guide link to install the TW image on that microSD:
wipefs --all /dev/sdX
xzcat [image].raw.xz | dd bs=4M of=/dev/sdX iflag=fullblock oflag=direct; sync
That copies the downloaded raw disk image onto that microSD so that the microSD will now boot your newly-downloaded Tumbleweed image. There are two partitions on the drive after the imaging, with sizes of approximately 200MB and 3.6GB, so the drive is not fully used. And those two partitions are labeled, as lsblk will show you. In this example, my RPi-3B was booted from /dev/mmcblk0, and the raw image was copied to /dev/sda:
Pi-6:~ # lsblk -o +LABEL
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT LABEL
sda 8:0 1 119.1G 0 disk
├─sda1 8:1 1 200M 0 part EFI
└─sda2 8:2 1 3.6G 0 part ROOT
mmcblk0 179:0 0 29.8G 0 disk
├─mmcblk0p1 179:1 0 200M 0 part /boot/efi EFI
├─mmcblk0p2 179:2 0 28.7G 0 part / ROOT
└─mmcblk0p3 179:3 0 992M 0 part [SWAP] SWAP
Note that my newly-imaged /dev/sda has a ROOT partition (partition 2) and EFI partition (partition 1) but no SWAP partition at this time, in comparison with /dev/mmcblk0.
After removing power from the Pi, you can reboot from that microSD either by leaving it in the USB adapter, removing your original boot drive, and powering up again; or by removing the newly-imaged microSD from that USB adapter, inserting it in place of your original boot drive in the microSD (mmc) slot and powering up. When you boot with that new image, one of the first things the startup process does is to restructure your microSD card so that sets up a SWAP space and expands ROOT to use all remaining space. It then reboots itself into that new disk structure before guiding you through the Linux setup process.
But in the process of restructuring partitions, it embeds in the boot configuration files the id’s of the partitions on the medium. For example, my microSD card is inserted in a Lexar USB adapter, and after I boot from that device the first time, the system identifies the
root partition with something like
/dev/disk/by-id/usb-Lexar_uSD_UHS2_RDR_GLI888888888-0:0-part2
That’s fine if I plan always to use that medium in that storage slot (USB using the Lexar adapter in this case). But it makes it impossible to move that microSD card from the USB adapter to the mmc slot or back again as the boot device: I would be locked into using that card in the device from which I first booted the newly-installed system since the id is embedded in the boot configuration.
However, a few steps can restructure the boot and system configuration files to allow you to boot that medium from either USB or mmc – move it readily from one interface to the other as the boot device.
III. Procedure
Boot from your newly-installed Tumbleweed drive – either in the mmc slot or through a USB adapter. After restructuring the drive (adding swap space and expanding ROOT to fill the remaining space), the system will reboot and eventually bring up a login screen (CLI or GUI). Login (root:linux) just to make sure it’s functioning. If you’re not comfortable using the vi editor, this would be a good time to make a network connection and install the editor or your choice (e.g, zypper in nano in a terminal window). Then shutdown (e.g., poweroff in a terminal window) and remove power from the Pi.
Remove your new drive, insert your original drive, and power up to boot from your original drive (again, we’re assuming that’s a microSD inserted in the mmc slot). Log in as root. Insert your USB adapter with the newly-imaged microSD: it’ll be /dev/sda. If the partitions of /dev/sda automount, unmount them with umount /dev/sda*. As a safety precaution, I’ll use /dev/sdX below so you’ll need to translate to your setup.
We’ll mount that device, isolate our work to that drive, edit just a few files, and then have the system recreate the boot configuration with our new parameters.
Pi-6:/ # cd /mnt
Pi-6:/ # mkdir tgt
Pi-6:/mnt # mount /dev/sdX2 tgt
Pi-6:/mnt # mount /dev/sdX1 tgt/boot/efi
Pi-6:/mnt # cd tgt
Pi-6:/mnt/tgt # mount --bind /dev dev
Pi-6:/mnt/tgt # mount --bind /sys sys
Pi-6:/mnt/tgt # mount --bind /proc proc
Pi-6:/mnt/tgt # chroot /mnt/tgt
Now edit the grub template file to use LABELs rather than id. Change the line for GRUB_CMDLINE_LINUX as follows:
Pi-6:/ # vi /etc/default/grub
...
GRUB_CMDLINE_LINUX=" root=LABEL=ROOT plymouth.enable=0 swiotlb=512 cma=384M console=ttyS1,115200n8 console=tty quiet"
...
Note the change to ‘cma=384M’; as of this writing (March, 2018) that addresses an unrelated problem that caused updates to the 2018.02.02 RPi aarch64 XFCE distribution to fail.
Tell dracut that you want to use labels rather than id’s or UUID’s:
echo 'persistent_policy="by-label"' >> /etc/dracut.conf
Now edit the /etc/fstab file to also use LABEL rather than id:
Pi-6:/ # vi /etc/fstab
LABEL=ROOT / ext4 noatime,nobarrier 1 1
LABEL=EFI /boot/efi vfat defaults 0 0
LABEL=SWAP swap swap defaults 0 0
At this point, you can check your partitions and labels to make sure they’re set up correctly. In my case,
Pi-6:/ # lsblk -o +LABEL
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT LABEL
sda 8:0 1 119.1G 0 disk
├─sda1 8:1 1 200M 0 part /boot/efi EFI
├─sda2 8:2 1 118.4G 0 part / ROOT
└─sda3 8:3 1 485.7M 0 part
mmcblk1 179:0 0 29.8G 0 disk
├─mmcblk1p1 179:1 0 200M 0 part EFI
├─mmcblk1p2 179:2 0 28.7G 0 part ROOT
└─mmcblk1p3 179:3 0 992M 0 part [SWAP] SWAP
Notice that swap (partition 3 in my new drive) is not labeled. Fix that with:
Pi-6:/ # mkswap -L SWAP /dev/sdX3
mkswap: /dev/sdX3: warning: wiping old swap signature.
Setting up swapspace version 1, size = 485.7 MiB (509272064 bytes)
LABEL=SWAP, UUID=60a5723e-a3ce-4c6f-bc2f-acc598c81d87
In my case, the labels now look like this:
Pi-6:/ # lsblk -o +LABEL
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT LABEL
sda 8:0 1 119.1G 0 disk
├─sda1 8:1 1 200M 0 part /boot/efi EFI
├─sda2 8:2 1 118.4G 0 part / ROOT
└─sda3 8:3 1 485.7M 0 part SWAP
mmcblk1 179:0 0 29.8G 0 disk
├─mmcblk1p1 179:1 0 200M 0 part EFI
├─mmcblk1p2 179:2 0 28.7G 0 part ROOT
└─mmcblk1p3 179:3 0 992M 0 part [SWAP] SWAP
So now we’re set to rebuild the configuration and boot files:
Pi-6:/ # grub2-mkconfig -o /boot/grub2/grub.cfg
Pi-6:/ # mkinitrd
Pi-6:/ # sync
and we’re done. Exit out of that chroot environment to get back to our original boot system, unmount the various devices, and poweroff:
Pi-6:/ # exit
Pi-6:/mnt/tgt # cd /mnt/tgt
Pi-6:/mnt/tgt # umount proc
Pi-6:/mnt/tgt # umount sys
Pi-6:/mnt/tgt # umount dev
Pi-6:/mnt/tgt # cd ~
Pi-6:~ # umount /dev/sdX*
Pi-6:~ # poweroff
Remove power to your Pi, remove your original boot medium, and then reapply power to boot off your newly-installed Tumbleweed. If you leave it in its USB adapter (which is easiest for this first pass), your Pi will boot off your USB drive, which will come up as /dev/sda.
Log in.
Now check your drives:
localhost:~ # lsblk -o +LABEL
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT LABEL
sda 8:0 1 119.1G 0 disk
├─sda1 8:1 1 200M 0 part /boot/efi EFI
├─sda2 8:2 1 118.4G 0 part / ROOT
└─sda3 8:3 1 485.7M 0 part SWAP
localhost:~ # mount
...
/dev/sda2 on / type ext4 (rw,noatime,nobarrier,data=ordered)
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
...
localhost:~ # swapon -s
Filename Type Size Used Priority
/dev/sda3 partition 497336 520 -2
You now have a working system that boots off the USB interface.
poweroff, remove the power to the Pi, and move the microSD to mmc slot.
Power up and wait for the boot sequence to complete.
Log in
And check your drive mount points again:
localhost:~ # lsblk -o +LABEL
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT LABEL
mmcblk0 179:0 0 119.1G 0 disk
├─mmcblk0p1 179:1 0 200M 0 part /boot/efi EFI
├─mmcblk0p2 179:2 0 118.4G 0 part / ROOT
└─mmcblk0p3 179:3 0 485.7M 0 part [SWAP] SWAP
localhost:~ # mount
...
/dev/mmcblk0p2 on / type ext4 (rw,noatime,nobarrier,data=ordered)
/dev/mmcblk0p1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
...
localhost:~ # swapon -s
Filename Type Size Used Priority
/dev/mmcblk0p3 partition 497336 0 -2
Your microSD drive also boots from the microSD slot!
That’s it. You now have a microSD drive that you can move between USB and mmc, and you can proceed to update your system and install software components that you need.
**Acknowledgement
**
Key elements of this procedure were worked out to make earlier Leap/TW versions USB bootable, as detailed in this How-To:
https://forums.opensuse.org/showthread.php/523341-Create-a-USB-Bootable-aarch64-openSUSE-Raspberry-Pi-3
Thanks to malcomlewis, agraf, and jsevener for guiding me through the steps needed to accomplish that, and as a result, enable switchable boot media as described here.