duetpi will not run on usb ssd - raspbian will

jhalewood

I've been running duet for years off an SD card on my raspberry pi connected to my 6HC

For fun i thought I'd try running from an SSD (in an enclosure to usb)

I cannot get duetpi to work (image 2024 04 19 full 32bit) - this is a fresh flash with NIL changes (not even adding wpa supplicant/sh)
it seems to pause substantially with message "systemd-rfkill.service" while the blue duetpi logo is displayed

then it goes into emergency mode with: (i have to type this from a photo, so not exact, but you get the gist)

nm1: controller never released inhibit bit (we can ignore this - this is because no SD card in slot)
You are in emergency mode. After logging in type jounalctl -xb to view system logs, systemctl reboot to reboot, systemctl default or exit to boot into default mode

cannot open access to console, the root account is locked.
see sulog man page for more details

press enter to continue

pressing enter it'll say

reloading system manager configuration
starting default.target

it'll then boot to desktop
duet doesn't work properly, the web page loads, but it cant connect to the board, and in journalctl logs there's errors for duet starting

the desktop works, and I can SSH in, but it'll enter emergency mode as above on every reboot

Please note that if I use raspberry pi os (in rpi imager) it boots fine, there's no pause on systemd-rfkill.service, it boots quickly and without issue (though also of course without duet)

Googling the problems some people have suggested is a problem with UAS (my ssd adapter is jmicron), however adding quicks to cmdline.txt doesn't fix it (and rasp pi OS boots fine without this change)

Another suggestion was that fsck was timing out as the drive is large, i edited fstab to disable fsck on my boot drive, no difference (and rasp pi OS boots fine, fsck doesn't time out)

I've tried raspberrypi imager, balena, and 2 usb enclosures, and using a USB 2 port instead of USB 3, nothing helps

output of journalctl : https://pastebin.com/UDZtvrzC

any ideas?

EDIT: i updated bootloader to run from USB of course

chrishamm

@jhalewood The main difference between the standard RasPi OS and DuetPi is AppArmor. You could try to disable that (remove lsm=apparmor from the cmdline and disable the apparmor service) and check if it boots up correctly then.

I can't see any obvious reason why it starts the emergency shell but perhaps a more verbose boot screen shows more (remove quiet and splash from the cmdline).

jhalewood

@chrishamm i forgot to mention i tried disabling apparmor, didn't help

but i have reflashed the ssd and edited cmdline to remove apparmor, quiet, and splash, and re-did first boot, reboot, enter to pass energency mode, and exported journal

this file contains the entire 25000 lines of journalctl

have a look at line 608

all_logs.txt

jhalewood

also tried setting fsck.mode=skip, nil effect

chrishamm

@jhalewood Thanks, that log shows more. It may be a conflict with the USB auto-mount setup that is exclusive to DuetPi:

Apr 19 19:37:01 duet3 (udev-worker)[299]: sda2: Process '/bin/systemctl start usb-mount@sda2.service' failed with exit code 1.
Apr 19 19:37:01 duet3 (udev-worker)[311]: sda1: Process '/bin/systemctl start usb-mount@sda1.service' failed with exit code 1.

I suggest you disable that feature or edit the udev rule (rm /etc/udev/rules.d/99-usb-automount.rules) and check if that fixes it.

jhalewood

@chrishamm I ran rm /etc/udev/rules.d/99-usb-automount.rules and that seems to have done the trick! Thanks @chrishamm

you mentioned I could "disable that feature" or edit the udev rule (rm ..)

how would i disable that feature? and which method would you recommend?

Is it possible to do this on the boot partition prior to first boot?

chrishamm

@jhalewood You already did that by running the rm command. i suppose you could edit the file you removed again and exclude your boot device, but you'd have to look up how exactly (search for udev rules, I believe there's a statement to ignore certain UUIDs/names [sda1/sda2 in your case]). If you can live without auto USB mount support, just leave that file deleted.

It's possible to rebuild DuetPi without that particular feature (see here and delete stage-dsf/04-usb-automount before you build it).

jhalewood

@chrishamm would it be possible to add to the next duetpi build something that disables the udev automount in favour of just using duetpi exclusive version?

I've been trying to find a (ideally simple) way to disable udev automount from the boot partition, i.e. using firstrun.sh or cmdline.txt, I've been unable to (which doesn't mean it doesn't exist, I'm no expert). But since this seems to be a duetpi conflict, perhaps a change in the build is warranted?

Though I understand this is not a big problem, considering I seem to be the first person to report it... Just a suggestion.

Zseven

@chrishamm Hello, have you solved the problem? That you can boot from ssd despite automount ?

chrishamm

@Zseven See the workaround above. I will check if I can change the automount script to detect if the Pi is booted from USB.

chrishamm

@jhalewood I'm happy to report that I've got a bug fix ready. It will be included in the next image which will be available when 3.5.2 stable is out.

jhalewood

@chrishamm Chris you are a fricken legend!