run_qemu
run_qemu copied to clipboard
pmem
chmod: cannot access 'root.img': No such file or directory
Hello
Pls help check this error, during build process, thanks
DISTRO: Fedora release 40 (Rawhide) with 6.5.0-0.rc6.20230818git0e8860d2125f.47.fc40.x86_64
Linux: latest linux tree: https://github.com/torvalds/linux.git
mkosi: mkosi 15.1
running: mkosi -i -f build
‣ Removing output files…
‣ Building default image
Create subvolume '/root/git/linux/qbuild/.mkosi-tmp7dgrxv9y/root'
‣ Mounting image…
‣ Copying cached trees
Create a snapshot of '/root/git/linux/qbuild/mkosi.cache/fedora~40/image.cache' in '/root/git/linux/qbuild/.mkosi-tmp7dgrxv9y/root'
‣ Copying in extra file trees…
‣ Running postinstall script…
+ [[ ! -d /root/ndctl ]]
+ exit 0
‣ Generating system users
‣ Applying presets…
‣ Generating hardware database
No hwdb files found, skipping.
‣ Recording packages in manifest…
‣ Unmounting image…
‣ Generating disk image
No machine ID set, using randomized partition UUIDs.
Pre-populating btrfs filesystem of partition 10-root.conf twice to calculate minimal partition size
Populating btrfs filesystem.
Successfully populated btrfs filesystem.
btrfs-progs v6.3.2
See https://btrfs.readthedocs.io for more information.
NOTE: several default settings have changed in version 5.15, please make sure
this does not affect your deployments:
- DUP for metadata (-m dup)
- enabled no-holes (-O no-holes)
- enabled free-space-tree (-R free-space-tree)
Rootdir from: /var/tmp/.#repart8f24a5ac7fa55719
Shrink: no
Label: root-x86-64
UUID: bcebc2c4-d003-4c52-bbd6-d5644151fd81
Node size: 16384
Sector size: 4096
Filesystem size: 1.00TiB
Block group profiles:
Data: single 8.02GiB
Metadata: DUP 1.00GiB
System: DUP 8.00MiB
SSD detected: no
Zoned device: no
Incompat features: extref, skinny-metadata, no-holes, free-space-tree
Runtime features: free-space-tree
Checksum: crc32c
Number of devices: 1
Devices:
ID SIZE PATH
1 1.00TiB /var/tmp/.#repartd9afafd37efe36ac
/var/tmp/.#repartd9afafd37efe36ac successfully formatted as btrfs (label "root-x86-64", uuid bcebc2c4-d003-4c52-bbd6-d5644151fd81)
Minimal partition size of btrfs filesystem of partition 10-root.conf is 8.4G
btrfs-progs v6.3.2
See https://btrfs.readthedocs.io for more information.
NOTE: several default settings have changed in version 5.15, please make sure
this does not affect your deployments:
- DUP for metadata (-m dup)
- enabled no-holes (-O no-holes)
- enabled free-space-tree (-R free-space-tree)
Rootdir from: /var/tmp/.#repart8f24a5ac7fa55719
Shrink: no
Label: root-x86-64
UUID: 4f743d66-1aee-492a-ad0c-73d7587d7fa7
Node size: 16384
Sector size: 4096
Filesystem size: 8.48GiB
Block group profiles:
Data: single 7.95GiB
Metadata: DUP 256.00MiB
System: DUP 8.00MiB
SSD detected: no
Zoned device: no
Incompat features: extref, skinny-metadata, no-holes, free-space-tree
Runtime features: free-space-tree
Checksum: crc32c
Number of devices: 1
Devices:
ID SIZE PATH
1 8.48GiB /var/tmp/.#repartd9afafd37efe36ac
/var/tmp/.#repartd9afafd37efe36ac successfully formatted as btrfs (label "root-x86-64", uuid 4f743d66-1aee-492a-ad0c-73d7587d7fa7)
Automatically determined minimal disk image size as 8.4G.
Sized '/root/git/linux/qbuild/.mkosi-tmp7dgrxv9y/staging/image.raw' to 8.4G.
Applying changes.
Wiped block device.
Discarded entire block device.
Successfully wiped file system signatures from future partition 0.
Copying in '/var/tmp/.#repartd9afafd37efe36ac' (8.4G) on block level into future partition 0.
Copying in of '/var/tmp/.#repartd9afafd37efe36ac' on block level completed.
Adding new partition 0 to partition table.
Writing new partition table.
All done.
‣ Generating disk image
No machine ID set, using randomized partition UUIDs.
Automatically determined minimal disk image size as 8.4G, current image size is 8.4G.
File '/root/git/linux/qbuild/.mkosi-tmp7dgrxv9y/staging/image.raw' already is of requested size or larger, not growing. (8.4G >= 8.4G)
No changes.
‣ Saving manifest image.manifest
‣ /root/git/linux/qbuild/image size is 8.5G, consumes 5.7G.
chmod: cannot access 'root.img': No such file or directory
From [1], seem it was due to the changes in latest mkosi
[1] https://github.com/systemd/mkosi/issues/1852
This is probably not a mkosi problem - might be another mkosi change that we need to comprehend. I've not updated to mkosi 15.x yet, Fedora 38 is only on mkosi-14. Will need to look into it a more when I do get the update.
