-
Notifications
You must be signed in to change notification settings - Fork 10
Add hacky iSCSI implementation #21
base: main
Are you sure you want to change the base?
Conversation
c8513aa
to
9eb7b6a
Compare
Hmm, this worked before. |
9eb7b6a
to
e0bbe4c
Compare
[ 120.100615] iscsi-generator.sh[203]: iscsiadm: cannot make connection to 10.10.10.1: Network is unreachable |
Yeah, that's a race - I worked around it locally by adding |
So… NetworkManager-wait-online.service finishes successfully, and then tgtadm says: I don't think I want to deal with that. It seems that the tools for this are just so bad it doesn't make sense to try to make this work. |
I'll take a look, maybe I f-up the network setup somewhere along the way. |
Interesting. I tried this locally and it seems to working fine (meaning that the iSCSI device gets correctly discovered and the block device pops up). However, that was without KVM (only plain TCG), so maybe it's a timing issue. I'll try it with KVM next. |
So, this is definitely a timing issue, but I'm not sure on which end, because:
It looks like the network is fully configured after the |
Yeah, if I add
or even:
i.e. NM doesn't even know about the |
And if I explicitly call
I think this happens due to the mode in which
which means NM doesn't actually wait for the devices to come up during boot, it just probes them? 🤷 |
Ah, it looks like NM in dracut does a bit more magic, like calling Looks like networking in initrd without dracut is going to be a lot of fun. |
With networkd the situations seems to be slightly better: diff --git a/.github/workflows/build-fedora.sh b/.github/workflows/build-fedora.sh
index 2584e43..2e25d32 100755
--- a/.github/workflows/build-fedora.sh
+++ b/.github/workflows/build-fedora.sh
@@ -294,7 +294,7 @@ for phase in "${PHASES[@]}"; do
INITRD="initrd_$KVER.cpio.zstd"
mkosi --cache "$MKOSI_CACHE" \
--default fedora.mkosi \
- --package="NetworkManager,iscsi-initiator-utils" \
+ --package="iscsi-initiator-utils,systemd-networkd" \
--extra-tree=mkosi.extra-iscsi \
--image-version="$KVER" \
--environment=KERNEL_VERSION="$KVER" \
@@ -334,7 +334,7 @@ for phase in "${PHASES[@]}"; do
dnsmasq --interface=initrd0 --bind-interfaces --dhcp-range=10.10.10.10,10.10.10.100
grep -q initrd0 /etc/qemu/bridge.conf || echo "allow initrd0" >>/etc/qemu/bridge.conf
- iscsi_cmdline="ip=dhcp netroot=iscsi:10.10.10.1::::$target_name"
+ iscsi_cmdline="ip=dhcp netroot=iscsi:10.10.10.1::::$target_name rd.systemd.wants=systemd-networkd.service"
timeout --foreground -k 10 5m \
qemu-kvm -m 1024 -smp "$(nproc)" -nographic -nic bridge,br=initrd0 \
-initrd "$INITRD" \
but it still seems to start the Note: I use the term
|
Thanks for looking into this. It is indeed a mess.
Hmm, so this tries to kill the iscsi connection. We could mask this, but |
This reverts commit a5618aa.
e0bbe4c
to
d9c3956
Compare
c9e0aa0
to
a0f695e
Compare
I tried to figure out where the error about presets comes from. But it doesn't reproduce when I can the rootfs.img via nspawn. It's annoying because unit_file_preset_all calls quite a lot of things without any logging. |
7a7206a
to
0edb254
Compare
This is not indended as a real solution. The generator should be moved to the open-iscsi project. It is added here to show how things should be done using a systemd generator and an initrd unit. The generator does not handle all the initricasies of iscsi.
It seems that NM doesn't actually wait for the devices to come up during boot, it just probes them. NM in dracut does a bit more magic, like calling nm-initrd-generator among other things: https://github.com/dracutdevs/dracut/blob/master/modules.d/35network-manager/nm-lib.sh.
We were failing like this: 2022-12-05T14:03:20.0045333Z Syncing filesystems and block devices. 2022-12-05T14:03:20.0521424Z Sending SIGTERM to remaining processes... 2022-12-05T14:03:20.1942427Z Sending SIGKILL to remaining processes... 2022-12-05T14:03:20.3466668Z Unmounting file systems. 2022-12-05T14:03:20.3688161Z All filesystems unmounted. 2022-12-05T14:03:20.3700551Z Deactivating swaps. 2022-12-05T14:03:20.3722192Z All swaps deactivated. 2022-12-05T14:03:20.3729382Z Detaching loop devices. 2022-12-05T14:03:20.3863371Z All loop devices detached. 2022-12-05T14:03:20.3880513Z Stopping MD devices. 2022-12-05T14:03:20.3945671Z All MD devices stopped. 2022-12-05T14:03:20.3968579Z Detaching DM devices. 2022-12-05T14:03:20.4043233Z All DM devices detached. 2022-12-05T14:03:20.4103781Z All filesystems, swaps, loop devices, MD devices and DM devices detached. 2022-12-05T14:03:20.5347085Z Syncing filesystems and block devices. 2022-12-05T14:03:20.5761222Z Powering off. 2022-12-05T14:03:20.5828227Z [ 158.519517] kvm: exiting hardware virtualization 2022-12-05T14:03:20.5901373Z [ 158.527392] sd 2:0:0:1: [sda] Synchronizing SCSI cache 2022-12-05T14:03:25.1142225Z [ 163.054446] ACPI: PM: Preparing to enter system sleep state S5 2022-12-05T14:03:25.1183925Z [ 163.058916] reboot: Power down 2022-12-05T14:03:25.1607472Z + tgtadm --lld iscsi --op delete --mode target --tid=1 2022-12-05T14:03:25.1614934Z tgtadm: this target is still active 2022-12-05T14:03:25.1666245Z ##[error]Process completed with exit code 22. We want iscsi-shutdown.service to disable the device for us.
0edb254
to
f5463aa
Compare
This reverts commit a5618aa.