Email or username:

Password:

Forgot your password?
Lennart Poettering

I recently implemented a fun little feature for systemd: inspired by MacOS' "target disk mode", a tiny tool called systemd-storagetm, that exposes all local block devices as NVMe-TCP devices, as they pop up. The idea is that if available in your initrd you can just boot into that (instead of into your full OS), and can access your disks via NVMe-TCP (in case you wonder what that is: it's the new hot shit for exposing block devices over the network, kinda like iSCSI, NBD, …, but cool).

7 comments
Lennart Poettering

And the idea is that we eventually will expose devices not just via NVMe-TCP but also as USB mass storage for systems that have a dual-mode USB controller (i.e. one that can act as a mass storage *device* rather than just a host), implementation would be trivial I guess, the configfs API is simple enough. Only reason I didn't implement this right-away is that I simply have no device that supports this (Raspberry Pis supposed do support it, but too lazy too bother with UEFI-less machines, tbh)

Lennart Poettering

happy to take patches that add the missing glue

BenBen

@pid_eins Do you have any example of a "dual-mode USB controller"? Seems cool and I never heard of that…

Linus

@pid_eins @BenBen the steam deck too, and it's a delightfully normal x86 UEFI machine besides the form factor! I've used it in device mode before successfully.

Eric Curtin

@pid_eins super cool. NVMe-oF ftw! I'm actually looking for a way of trimming down some of the dependencies in systemd-udevd and udevadm to make it even smaller for an super small inirtd. I only want systemd-udevd to initialize local storage devices for my used case. The Fedora systemd-udevd is dynamically linked to a large systemd .so is there a way of building it against smaller systemd libs like libudev etc.?

Go Up