Lennart Poettering has been working on a new systemd feature called systemd-storagetm that is inspired by the Apple macOS “Target Disk Mode” feature.
[…]This is similar to Apple’s Target Disk Mode as a boot option on Macs that allows other systems to then easily access it as an external device. The systemd intent with this Storage Target Mode is to make it easier to debug a broken system with very few dependencies while being able to access the raw block device of the broken system via the network. This may also make it easier to migrate from one system to the next. By having access to the raw block device via NVMe-TCP, it can be easy to use the “dd” command or similar for copying the drive.
Target Disk Mode has long been one of those amazing Mac features that should’ve come to PCs decades ago, so I’m incredibly glad Poettering is working on it. This will make it so much easier to troubleshoot, get files off a broken system, and so on, without having to move hard drives around or boot into live CDs.
I’d rather just have iscsi TBH. If that’s too heavy, linux already has network block devices, which are extremely light weight.
https://github.com/NetworkBlockDevice/nbd
As usual, Poettering is pursuing his “not invented here” agenda and make sure everything gets tightly coupled to systemd because that’s his baby. IMHO the displacement of more portable, flexible, specialized tools in favor of more monolithic ones hard coded for systemd is bad for unix operating systems. At some point we’ll have to stop calling the operating system “Linux” and start calling it “Lennix”.
Since Lennart moved to MS recently, I think this might be for Azure or AWS. Infamously, AWS doesn’t provide a console for VMs, and recovering a borked system requires attaching the disk to another VM.
Azure might be the same way, and this is the result.
> make sure everything gets tightly coupled to systemd
Honestly… If systemd would become a single binary like BusyBox, I would be okay with that. Rolling all the userland tools into one binary would simplify deployments, or strip everything down and have one single service which responds like a terminal would be fine.
Flatland_Spider,
I know for a fact they could do it using existing tools, I’ve already done this exact thing, but the guy likes to reinvent the wheel.
Anyway, I’m surprised AWS doesn’t provide a remote console. I use QEMU/KVM built in remote desktop capabilities to setup VMs before networking is setup. I guess they wanted to gut the VMs as much as possible to minimize resources.
I was almost certain I’d used a remote console on azure, but now I think it was only the guest VM’s remote desktop service rather than an azure feature. It looks like azure enables remote serial access but otherwise no support for a local console.
https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/remote-tools-troubleshoot-azure-vm-issues
Yep, I can see how this could be a problem if the system fails to boot cleanly or has a networking issue. You’d need to migrate the disk to a new VM to fix it, just like you said.
> Anyway, I’m surprised AWS doesn’t provide a remote console.
> I use QEMU/KVM built in remote desktop capabilities to setup
> VMs before networking is setup.
So was I. Smaller shops then AWS have figured that out. They don’t even need a graphical console. A serial console works fine, and I’d rather they put the effort into the virtio console.
That Azure feature is basically what I want.
This should probably be built into the firmware, but since Linux distros don’t control the hardware they run on, this.
It’s interesting, but ultimately, I’m not sure how useful this will be. I’ve used Target Disk Mode before with a G5 Mac, but it was just a very expensive external drive at that point. There needed to be another computer directly attached, which limited it’s usefulness. Booting into a secondary rescue image or live disk is probably better.
Flatland_Spider,
As a technology, DRAC/iLO used in server grade equipment is awesome! They’ve gotten worse with time though, not only do you need to buy the hardware, but now they want to charge regular subscriptions to connect to your hardware. Intel AMT built into workstations doesn’t require any special hardware at all, just the right firmware.
The problem is manufacturers only support these for a limited lifespan and the software/firmware are proprietary (and notoriously vulnerable). This technology would be absolutely amazing if an open source project were allowed to take over. It would revolutionize remote administration the same way that dd-wrt has helped revolutionize NAS.
It’s too bad computers don’t come with this as a standard feature, although it’s probably possible to replicate this yourself.
If you plug in an internal usb DOM (these used to be so much cheaper, like $10, what happened??) then the system could boot your HDD/SDD by default but allow you to manually boot the USB DOM. You could install whatever OS you want on it.
https://www.newegg.com/p/1W7-00T2-014J4
This might work for you assuming you are ok with booting the DOM manually. This is very similar to the configuration I use for my server systems although in my case the DOM boots by default. It provides a remotely accessible boot environment for administration and is intended for headless displays. This admin boot environment can proceed to kexec into alternate kernels located on raid disks. This is as close as I can get to an ideal boot environment on nearly any x86 hardware. It would be nice if this could be a standard feature on all computers out of the box. It would not be that difficult to do using standard FOSS software (as I have done) though it seems unlikely for manufacturers to get on board.
> As a technology, DRAC/iLO used in server grade equipment is awesome!
> They’ve gotten worse with time though, not only do you need to buy the
> hardware, but now they want to charge regular subscriptions to connect
> to your hardware.
They are really awesome!
They’re hard to add to a system after the fact though, and OEMs are milking them. 🙁
I’d like to see OpenBMC and the Raptor CS Arctic Tern gain more traction in the BMC world, or the OEMs standardize and allow the BMC to be swapped.
https://github.com/openbmc/openbmc
https://raptorcs.com/content/AT1PC2/intro.html
> It would not be that difficult to do using standard FOSS software
> (as I have done) though it seems unlikely for manufacturers to get on board.
I agree. A little rescue environment would be nice, and a UEFI could probably do this with some eMMC on the MB.