[QUOTE=hdtodd;36212]
Is there a way to direct the boot process to go to a USB-attached drive, or to redirect the boot to a hard drive with a modified bootstrap program on a microSD? [/QUOTE]
I feel a bit like Scott trying to get back from the South Pole: the expedition was unsuccessful, but I feel I should leave notes in case others follow this so they might learn from my failures. Thanks to Malcolm Lewis for his help: I wouldn’t have made it this far without his suggestions.
And for a related thread, on a problem that arose when trying to set up WiFi in Tumbleweed but ended up in a similar place, see https://forums.opensuse.org/showthread.php/522941-How-to-resolve-quot-A-start-job-is-running-for-dev-disk-by-quot-problems-Raspberry-Pi-openSUSE
Key references were:
[LIST=1]
[]Installing Raspbian on a bootable USB drive: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md
[]Conversation between Freigeist and Alex Graf indicating that, ultimately, it was possible to get Tumbleweed to boot from USB (but providing insufficient details about how to actually do it): https://lists.opensuse.org/opensuse-arm/2017-01/msg00060.html
[]Installing WAN on RPi under openSUSE: https://lists.opensuse.org/opensuse-arm/2016-11/msg00018.html
[]Installing grub: https://forums.opensuse.org/content.php/128-Re-install-Grub2-from-DVD-Rescue
[/LIST]
I worked on a Raspberry Pi-3 that I had prepared to boot off USB (first reference above). I had developed a Raspbian USB drive and confirmed that that Pi-3 would boot Raspbian off the USB drive (the preparation part is a one-time process). Subsequently, I did my work in SLES or openSUSE on that Pi-3, booting off a microSD card and working on either a USB thumb drive (Verbatim, Lexar) or on another microSD inserted into a USB adapter (so that I could confirm that that drive would boot when inserted into the microSD slot of the Pi-3).
Briefly, I was initially working in SLES-12.2 and hoped to get it booting off USB. When that was unsuccessful, I also tried LEAP 42.2 and various stable releases and snapshots of Tumbleweed, : 2017-01-13, 2017-01-28, 2017-01-31, 2017-0203. I used two techniques to create and edit my USB boot drive:
[LIST=1]
[]boot up some version of SUSE/openSUSE from the microSD in the microSD slot, and either install onto a USB drive (or microSD inserted into a USB adapter) from the .raw.xz file with the usual xzcat/dd process and then edit the files in the installed partitions on that USB drive; or
[]boot from the microSD slot, then create the USB boot drive and partitions with parted, then populate the EFI and ROOT partitions with rsync from the microSD partitions, then edit the USB partitions to configure for USB booting.
[/LIST]
In both cases, subsequent work with grub2-mkconfig, grub2-install, mkinitrd, and dracut were done after isolating the USB drive from the microSD drive (as best possible). The USB root drive was mounted as /mnt/tgt, for example, and the USB efi drive (first partition, FAT32) was mounted as /mnt/tgt/boot/efi, mimicing the microSD mount structure. Except for the /dev, /sys, and /proc mountpoints (which may be a critical issue!), the two environments were separated for editing and grub/initrd creation by:
cd /mnt/tgt
mount --bind /dev dev
mount --bind /sys sys
mount --bind /proc proc
chroot /mnt/tgt
<work on USB>
exit
The configuration-generating programs wouldn’t work without /proc (or /dev, as I recall). But I think that is the step in the process that caused the ultimate boot loop failure.
Over the many attempts to get this to work, I worked at various times with the grub configuration files (/boot/grub2/, /etc/default/, /usr/share/grub2/*), with /etc/fstab, and with the mkinitrd and dracut shell scripts.
I routinely worked the USB drive configuration to the point where, when booting off the USB drive (no microSD installed), the Pi-3 would bring up the SLES/openSUSE splash screen (default or recover boot option), then initiate the boot, then hang (systemd, I believe) in a wait loop with the message:
A start job is running for dev-disk-by\\x2did-mmc\\x2dSL32G_0x28b56c90\\x2dpart2.device
where the part after x2did varied over the many attempts I made to get this to work. The hang was caused by some component that insisted upon referencing the root and swap partitions “by-id”, with references in grub to UUID; I was unable to coerce it into using “/dev/sda3” or “LABEL=ROOT”, for example.
I think the problem is that grub2-mkconfig (and mkinitrd/dracut) reference the /proc/cmdline from the running OS and use it to see the configuration for grub for the USB drive. I could find no way to avoid that. BUT, I could also find no way to get the hanging component (systemd?) to use “/dev/sda3” (for example) or “LABEL=ROOT” to identify the root device, for which it was stuck in a “no limit” loop.
I believe there is some development work going on in this area within the openSUSE group. It seems increasingly that the Raspberry Pi folks are preparing to use systems that boot off the network or off USB drives, and the RPi-3 is a pretty capable little computer when you put an SSD drive onto the USB port. But the characteristics of the boot problems (and particularly the related WAN-install problem, which once worked but failed on newer Tumbleweed releases) changed over the last three weeks, suggesting that there have been changes in the code in this area (grub/mkinitrd configuration).
So I’m guessing that this will get fixed in some future release, but for now it’s a non-functioning moving target.
If anyone sees mistakes I’ve made in my approach, please let me know and I’ll give it another try. But for now, I’ll just wait for it to work in a future release.
David Todd
] I’ve never seen that before and haven’t figured out how to remount mmcblk0p3 as the / partition. I’ll post again if I make any progress.