Support booting from a multipath-backed device#893
Conversation
gibmat
force-pushed
the
multipath
branch
6 times, most recently
from
93f3743 to
480be21
Compare
Signed-off-by: Mathias Gibbens <mathias.gibbens@futurfusion.io>
Manually measuring PCRs depends on /run/systemd/tpm2-pcr-public-key.pem being available, but we can't just depend on systemd-tmpfiles-setup.service since that creates a dependency loop with the new initrd-multipath-partition service. So, add our own call to systemd-tmpfiles to ensure /run/ is populated. Signed-off-by: Mathias Gibbens <mathias.gibbens@futurfusion.io>
Signed-off-by: Mathias Gibbens <mathias.gibbens@futurfusion.io>
gibmat
force-pushed
the
multipath
branch
2 times, most recently
from
c107559 to
7fdc4bc
Compare
| @@ -0,0 +1,14 @@ | |||
| [Unit] | |||
| Description=Configure basic multipath | |||
| After=modprobe@dm_multipath.service modprobe@dm_service_time.service systemd-udev-settle.service | |||
There was a problem hiding this comment.
Relying on systemd-udev-settle.service isn't great, since it causes a single choke point on the critical path during boot. But lsblk relies on udev to get WWNs, so we can't really avoid it.
| multipath -i | ||
|
|
||
| # Need to sleep a few seconds to allow multipath devices to become available. | ||
| sleep 5 |
There was a problem hiding this comment.
This sleep delay will only affect systems where a multipath configuration is detected. In my testing I needed at least a 1-2 second delay between the multipath -i command finishing and actual mapped devices to properly show up. I hope 5 seconds will be sufficient time for real hardware; if not we may need to extend this or switch to some sort of a polling approach.
| @@ -0,0 +1,16 @@ | |||
| [Unit] | |||
There was a problem hiding this comment.
I split the early boot message into its own service that doesn't depend on anything so we can get something on the screen as quickly as possible during boot.
Signed-off-by: Mathias Gibbens <mathias.gibbens@futurfusion.io>
This is needed when booting from a multipath-backed device, since the systemd gpt-auto generator won't auto-create these files for us. Signed-off-by: Mathias Gibbens <mathias.gibbens@futurfusion.io>
…multipath device Signed-off-by: Mathias Gibbens <mathias.gibbens@futurfusion.io>
Signed-off-by: Mathias Gibbens <mathias.gibbens@futurfusion.io>
Signed-off-by: Mathias Gibbens <mathias.gibbens@futurfusion.io>
Signed-off-by: Mathias Gibbens <mathias.gibbens@futurfusion.io>
…th-backed devices Signed-off-by: Mathias Gibbens <mathias.gibbens@futurfusion.io>
Signed-off-by: Mathias Gibbens <mathias.gibbens@futurfusion.io>
|
OK @stgraber I think this is finally ready for a review! :) |
|
@gibmat I may be missing something, but from my reading of the scripts it seems to assume that any multipath disk found from the initrd will be the root disk. What happens in an environment where on top of the root disk being available over multipath you have another few other disks that are also exposed over FC with multipath? |
| TOTAL_UNIQUE_WWNS=$(lsblk -o WWN -dn | grep -v "^$" | sort | uniq | wc -l) | ||
|
|
||
| if [ "$TOTAL_WWNS" -ne "$TOTAL_UNIQUE_WWNS" ]; then | ||
| multipath -i |
There was a problem hiding this comment.
This will activate all multipath disks, not just the root disk.
| #!/bin/sh | ||
|
|
||
| # Manually setup any detected multipath devices. | ||
| for MP in $(dmsetup ls --target multipath | cut -f1); do |
There was a problem hiding this comment.
This iterates over all multipath devices and will blindly run systemd-repart on any disk that has exactly 8 partitions.
| swapon /dev/mapper/swap | ||
|
|
||
| # Unlock root partition, which will be automatically detected and then mounted. | ||
| systemd-cryptsetup attach root "/dev/mapper/${MP}-part10" |
There was a problem hiding this comment.
Given we're iterating over multipath devices. If we managed to locate and unlock the swap and root partition, we should probably break, no?
Also do these calls properly answer the recovery key input?
2 participants
Closes #807