shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2024-12-22 17:35:35 +03:00
Code
ccaa76ac48
systemd/units/storage-target-mode.target

17 lines
943 B
SYSTEMD
Raw Normal View History

storagetm: add new systemd-storagetm component This implements a "storage target mode", similar to what MacOS provides since a long time as "Target Disk Mode": https://en.wikipedia.org/wiki/Target_Disk_Mode This implementation is relatively simple: 1. a new generic target "storage-target-mode.target" is added, which when booted into defines the target mode. 2. a small tool and service "systemd-storagetm.service" is added which exposes a specific device or all devices as NVMe-TCP devices over the network. NVMe-TCP appears to be hot shit right now how to expose block devices over the network. And it's really simple to set up via configs, hence our code is relatively short and neat. The idea is that systemd-storagetm.target can be extended sooner or later, for example to expose block devices also as USB mass storage devices and similar, in case the system has "dual mode" USB controller that can also work as device, not just as host. (And people could also plug in sharing as NBD, iSCSI, whatever they want.) How to use this? Boot into your system with a kernel cmdline of "rd.systemd.unit=storage-target-mode.target ip=link-local", and you'll see on screen the precise "nvme connect" command line to make the relevant block devices available locally on some other machine. This all requires that the target mode stuff is included in the initrd of course. And the system will the stay in the initrd forever. Why bother? Primarily three use-cases: 1. Debug a broken system: with very few dependencies during boot get access to the raw block device of a broken machine. 2. Migrate from system to another system, by dd'ing the old to the new directly. 3. Installing an OS remotely on some device (for example via Thunderbolt networking) (And there might be more, for example the ability to boot from a laptop's disk on another system) Limitations: 1. There's no authentication/encryption. Hence: use this on local links only. 2. NVMe target mode on Linux supports r/w operation only. Ideally, we'd have a read-only mode, for security reasons, and default to it. Future love: 1. We should have another mode, where we simply expose the homed LUKS home dirs like that. 2. Some lightweight hookup with plymouth, to display a (shortened) version of the info we write to the console. To test all this, just run: mkosi --kernel-command-line-extra="rd.systemd.unit=storage-target-mode.target" qemu
2023-10-27 15:25:49 +03:00
# SPDX-License-Identifier: LGPL-2.1-or-later
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=Storage Target Mode
Documentation=man:systemd.special(7)
units: pull in plymouth when booting into storagetm mode
2023-11-10 19:00:38 +03:00
Wants=systemd-storagetm.service systemd-udevd.service systemd-udev-trigger.service systemd-networkd.service systemd-network-generator.service systemd-journald.socket systemd-journald-dev-log.socket plymouth-start.service
storagetm: add new systemd-storagetm component This implements a "storage target mode", similar to what MacOS provides since a long time as "Target Disk Mode": https://en.wikipedia.org/wiki/Target_Disk_Mode This implementation is relatively simple: 1. a new generic target "storage-target-mode.target" is added, which when booted into defines the target mode. 2. a small tool and service "systemd-storagetm.service" is added which exposes a specific device or all devices as NVMe-TCP devices over the network. NVMe-TCP appears to be hot shit right now how to expose block devices over the network. And it's really simple to set up via configs, hence our code is relatively short and neat. The idea is that systemd-storagetm.target can be extended sooner or later, for example to expose block devices also as USB mass storage devices and similar, in case the system has "dual mode" USB controller that can also work as device, not just as host. (And people could also plug in sharing as NBD, iSCSI, whatever they want.) How to use this? Boot into your system with a kernel cmdline of "rd.systemd.unit=storage-target-mode.target ip=link-local", and you'll see on screen the precise "nvme connect" command line to make the relevant block devices available locally on some other machine. This all requires that the target mode stuff is included in the initrd of course. And the system will the stay in the initrd forever. Why bother? Primarily three use-cases: 1. Debug a broken system: with very few dependencies during boot get access to the raw block device of a broken machine. 2. Migrate from system to another system, by dd'ing the old to the new directly. 3. Installing an OS remotely on some device (for example via Thunderbolt networking) (And there might be more, for example the ability to boot from a laptop's disk on another system) Limitations: 1. There's no authentication/encryption. Hence: use this on local links only. 2. NVMe target mode on Linux supports r/w operation only. Ideally, we'd have a read-only mode, for security reasons, and default to it. Future love: 1. We should have another mode, where we simply expose the homed LUKS home dirs like that. 2. Some lightweight hookup with plymouth, to display a (shortened) version of the info we write to the console. To test all this, just run: mkosi --kernel-command-line-extra="rd.systemd.unit=storage-target-mode.target" qemu
2023-10-27 15:25:49 +03:00
Conflicts=rescue.service rescue.target
units: pull in plymouth when booting into storagetm mode
2023-11-10 19:00:38 +03:00
After=systemd-storagetm.service systemd-udevd.service systemd-udev-trigger.service systemd-networkd.service systemd-network-generator.service systemd-journald.socket systemd-journald-dev-log.socket plymouth-start.service rescue.service rescue.target
storagetm: add new systemd-storagetm component This implements a "storage target mode", similar to what MacOS provides since a long time as "Target Disk Mode": https://en.wikipedia.org/wiki/Target_Disk_Mode This implementation is relatively simple: 1. a new generic target "storage-target-mode.target" is added, which when booted into defines the target mode. 2. a small tool and service "systemd-storagetm.service" is added which exposes a specific device or all devices as NVMe-TCP devices over the network. NVMe-TCP appears to be hot shit right now how to expose block devices over the network. And it's really simple to set up via configs, hence our code is relatively short and neat. The idea is that systemd-storagetm.target can be extended sooner or later, for example to expose block devices also as USB mass storage devices and similar, in case the system has "dual mode" USB controller that can also work as device, not just as host. (And people could also plug in sharing as NBD, iSCSI, whatever they want.) How to use this? Boot into your system with a kernel cmdline of "rd.systemd.unit=storage-target-mode.target ip=link-local", and you'll see on screen the precise "nvme connect" command line to make the relevant block devices available locally on some other machine. This all requires that the target mode stuff is included in the initrd of course. And the system will the stay in the initrd forever. Why bother? Primarily three use-cases: 1. Debug a broken system: with very few dependencies during boot get access to the raw block device of a broken machine. 2. Migrate from system to another system, by dd'ing the old to the new directly. 3. Installing an OS remotely on some device (for example via Thunderbolt networking) (And there might be more, for example the ability to boot from a laptop's disk on another system) Limitations: 1. There's no authentication/encryption. Hence: use this on local links only. 2. NVMe target mode on Linux supports r/w operation only. Ideally, we'd have a read-only mode, for security reasons, and default to it. Future love: 1. We should have another mode, where we simply expose the homed LUKS home dirs like that. 2. Some lightweight hookup with plymouth, to display a (shortened) version of the info we write to the console. To test all this, just run: mkosi --kernel-command-line-extra="rd.systemd.unit=storage-target-mode.target" qemu
2023-10-27 15:25:49 +03:00
AllowIsolate=yes
Copy Permalink