When I use --verify=no to get past #366, the problem then is, nspawn doesn't know how to find the root.
--verify=no
$ sudo systemd-nspawn -M FCB35-20220127 Multiple suitable root partitions found in image '/var/lib/machines/FCB35-20220127.raw'.
Metadata Update from @davdunc: - Issue tagged with: meeting
I have the same issue with the F37 Cloud Base image, trying to run with machinectl start f37.
machinectl start f37
systemd-nspawn[1216707]: /var/lib/machines/f37.raw: Multiple suitable root partitions found in image.
I found https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html#-i which mentions the partitions can be marked according to https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ so I tried to make this work with parted /var/lib/machines/f37.raw type 5 4f68bce3-e8cd-4db1-96e7-fbcaf984b709.
parted /var/lib/machines/f37.raw type 5 4f68bce3-e8cd-4db1-96e7-fbcaf984b709
The partition is now of this type:
# sfdisk -d f37.raw label: gpt label-id: CE202B35-1671-4520-BFBB-0CA31828411D device: f37.raw unit: sectors first-lba: 34 last-lba: 10485726 sector-size: 512 f37.raw1 : start= 2048, size= 2048, type=21686148-6449-6E6F-744E-656564454649, uuid=1E11B9EF-8CC4-4531-A8FB-BE5036A546CF f37.raw2 : start= 4096, size= 2048000, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=C207C083-72FE-4770-A9C6-39B43747C021 f37.raw3 : start= 2052096, size= 204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=5D5B4A6E-8244-4947-A4C2-006233137753 f37.raw4 : start= 2256896, size= 8192, type=9E1A2D38-C612-4316-AA26-8B49521E5A8B, uuid=4FE7612A-CDBE-4E6F-B3AC-B25C73B3E07F f37.raw5 : start= 2265088, size= 8218624, type=4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709, uuid=63719156-D0B4-46FF-90B6-CEA87E64B19E
This has changed the systemd-nspawn message to:
systemd-nspawn[1221085]: Failed to mount image: No medium found systemd-nspawn[1221081]: Short read while reading UID shift.
I'm unsure if this means progress. :)
Trying with systemd-nspawn:
systemd-nspawn
# systemd-nspawn -M f37 Spawning container f37 on /var/lib/machines/f37.raw. Press ^] three times within 1s to kill container. execv(/bin/bash, /bin/bash, /bin/sh) failed: No such file or directory Container f37 failed with error code 1.
It seems it doesn't know to mount the btrfs subvolume root.
root
I'm unsure how this is supposed to work, or if it is supposed to work?
Discoverable Partitions Spec won't work with Fedora Cloud images currently. We'd either need to inhibit Btrfs subvolume support in whatever creates the cloud image, or we need to establish an equivalent "discoverable subvolumes spec" and roll that into systemd as a generator unit, similar to discoverable partitions.
https://www.spinics.net/lists/systemd-devel/msg06574.html
The summary is that there'd be a new GPT partition type GUID for "discoverable pools" to identify e.g. Btrfs, ZFS, LVM as containing discoverable "subvolumes" (I'm using it as a generic term, the Btrfs term is subvolume, LVM term is logical volume, ZFS term is dataset) and then we need either a path and naming convention or an xattr to define the various things we'd want discovered: root, usr, var, home, whatever.
Unfortunately the manpage of systemd-nspawn(1) still has this example, suggesting that this should work:
systemd-nspawn(1)
Example 1. Download a Fedora image and start a shell in it # machinectl pull-raw --verify=no \ https://download.fedoraproject.org/pub/fedora/linux/releases/37/Cloud/x86_64/images/Fedora-Cloud-Base-37-1.7.x86_64.raw.xz \ Fedora-Cloud-Base-37-1.7.x86-64 # systemd-nspawn -M Fedora-Cloud-Base-37-1.7.x86-64
...but that doesn't work for the current rawhide image:
rawhide
# machinectl pull-raw --verify=no \ https://download.fedoraproject.org/pub/fedora/linux/development/rawhide/Cloud/x86_64/images/Fedora-Cloud-Base-Rawhide-20240108.n.0.x86_64.raw.xz \ Fedora-Cloud-Base-Rawhide.x86-64 # systemd-nspawn -M Fedora-Cloud-Base-Rawhide.x86-64 Multiple suitable root partitions found in image '/var/lib/machines/Fedora-Cloud-Base-Rawhide.x86-64.raw'. # kpartx -l /var/lib/machines/Fedora-Cloud-Base-Rawhide.x86-64.raw loop4p1 : 0 2048 /dev/loop4 2048 loop4p2 : 0 2048000 /dev/loop4 4096 loop4p3 : 0 204800 /dev/loop4 2052096 loop4p4 : 0 8192 /dev/loop4 2256896 loop4p5 : 0 8218624 /dev/loop4 2265088
Log in to comment on this ticket.