Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DNM: experiment with unit requirements for multipath over iscsi work #2984

Closed

Conversation

dustymabe
Copy link
Member

@dustymabe dustymabe commented Apr 24, 2024

We are experimenting with iscsi and also multipath+iscsi.

In the multipath+iscsi case we end up with dependency issues in our initramfs because of coreos-multipath-wait.target:

  • It blocks cryptsetup-pre.target and thus basic.target:
basic.target -> sysinit.target -> cryptsetup.target -> cryptsetup-pre.target -> coreos-multipath-wait.target -> /boot disk
  • It blocks dracut-initqueue.service and that is what sets up the iscsi disks:
dracut-initqueue.service -> coreos-multipath-wait.target

I was testing this with a disk that was installed using:

sudo coreos-installer install /path/to/disk \
    --append-karg rd.multipath=default      \
    --append-karg root=/dev/disk/by-label/dm-mpath-root \
    --append-karg rw --append-karg rd.iscsi.firmware=1  \
    --console ttyS0,115200n8 -i config.ign --insecure   \
    --image-file fedora-coreos-40.20240424.dev.1-metal.x86_64.raw.xz

an a PXE config that looked like:

[dustymabe@media images]$ cat boot.ipxe 
#!ipxe
# set some random uuid as the initiator iqn, otherwise
# this will fail pointing to https://ipxe.org/1c0d6502
set initiator-iqn iqn.68cc69b9-1b54-4ff1-9d61-eedb570da8fd
sanboot iscsi:192.168.122.137::::iqn.2024-04.com.coreos:0 \
        iscsi:192.168.122.137::::iqn.2024-04.com.coreos:1

@dustymabe
Copy link
Member Author

After talking with @jlebon I was able to investigate a bit more:

basic.target -> sysinit.target -> cryptsetup.target -> cryptsetup-pre.target -> coreos-multipath-wait.target -> /boot disk

This chain isn't important or rather it's not what is blocking things. It's that coreos-enable-network was blocking on basic.target, which was holding up networking and dracut-initqueue.

dracut-initqueue.service -> coreos-multipath-wait.target

This one was important. We were able to remove it.

After dropping the After=basic.target from coreos-enable-network.service and Before=dracut-initqueue.service from coreos-multipath-wait.target things seem to work.

@dustymabe dustymabe closed this Apr 26, 2024
dustymabe added a commit to dustymabe/fedora-coreos-config that referenced this pull request Apr 26, 2024
This isn't strictly required and is causing a dependency
timeout in early boot when iscsi+multipath is used. See
coreos#2984
for some more context.
@dustymabe
Copy link
Member Author

took the output of this investigation and opened #2987

jlebon pushed a commit that referenced this pull request Apr 26, 2024
This isn't strictly required and is causing a dependency
timeout in early boot when iscsi+multipath is used. See
#2984
for some more context.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant