You are not logged in.
I created a standard qemu raw image:
qemu-img create virtual-disk 4Gset it up as a loopback device:
losetup /dev/loop0 virtual-diskcreated a partition and file system:
# fdisk creates a single partition across the whole disk
mkfs.ext4 /dev/loop0p1
mount /dev/loop0p1 /mntand then installed arch (base, linux-hardened, grub, and openssh) as usual, with a BIOS MBR grub installation. The machine boots, says "Welcome to Grub", and then:
ERROR: Device "UUID=..." not found. Skipping fsck.I checked fstab and blkid to confirm it was configured correctly, and from the host's perspective this is the correct uuid for the virtual disk's only partition. Further, the guest does not seem to recognize that any drives are connected. Using the emergency shell
cat /proc/partitionsyields nothing.
Has anyone had success creating a qemu guest using arch-install-scripts on a virtual disk configured as a loopback device? Why does the guest not recognize the partition?
Offline
No clue, but why are you using a loopback device ?I
The typical approach to installing archlinux on qemu is to pass the installation iso as a cdrom to qemu.
(Doing it this way allows to follow the installation guide.)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Yes that is the usual process, but I want to automate the creation of virtual machines on demand, and it is easier to automate an installation script on a the hypervisor than the installation medium.
Using a loopback device just makes the hypervisor the installation medium - the installation process is exactly the same (except for this grub stuff apparently).
Last edited by eom.dev (2022-09-09 11:55:24)
Offline
Offline
What's the output of...
fdisk -l /dev/loop0
Disk /dev/loop0: 4GiB, 4294967296 bytes, 8388608 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 09x28b824a5
Device Boot Start End Sectors Size Id Type
/dev/loop0p1 2048 8388607 8386560 4G 83 LinuxI'm noticing the dos disk label type and lack of boot flag on the partition.
Offline
BIOS MBR grub installation.The dos label is common for such an installation .
Did you create the virtual disk with a bios boot gap and install grub on the drive, not on the partiton ?
see https://wiki.archlinux.org/title/GRUB#M … structions
Last edited by Lone_Wolf (2022-09-10 15:18:54)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Did you create the virtual disk with a bios boot gap
That's only required if using GRUB to boot a GPT drive in BIOS mode. If booting a DOS drive in BIOS mode there is already sufficient space for the bootloader in the reserved first 2048 sectors (as can be seen in the fdisk output.
Offline
Lone_Wolf wrote:Did you create the virtual disk with a bios boot gap
That's only required if using GRUB to boot a GPT drive in BIOS mode. If booting a DOS drive in BIOS mode there is already sufficient space for the bootloader in the reserved first 2048 sectors (as can be seen in the fdisk output.
Eventually I tried doing a GPT boot with an intentional gap, after which I consistently had to use
grub-install --target=i386-pc --forceto go back to MBR. I eventually got it to work by booting my admin node as a VM with the drive in question attached. The device UUIDs checked out from the guest's perspective as well, which is strange. None the less, I was able to get the desired VM to boot by running the same install script from the VM admin node. Not really an answer, so I'll have to revisit the problem or consider alternative solutions for future installations.
Offline