Fail to boot SLE-Micro 5.1 Beta2 on qemu-arm

Tue Aug 17 17:25:38 UTC 2021

I managed to boot on a real RPi 4

I’ll spend more time later to understand why my qemu (leap 15.3) is not working

Regards

—
Brice DEKANY
SE for France
06.37.12.53.24
________________________________
De : Fabian Vogt <fvogt at suse.de>
Envoyé : Tuesday, August 17, 2021 4:09:32 PM
À : micro-beta at lists.suse.com <micro-beta at lists.suse.com>
Cc : Brice Dekany <brice.dekany at suse.com>
Objet : Re: Fail to boot SLE-Micro 5.1 Beta2 on qemu-arm

Hi,

I gave the image a try and it works here on x86_64 TW using qemu-system-aarch64
directly and using the virt-install call as well. What do you use as host?

512MiB RAM seems low though, especially with the initial initrd that doesn't
leave a lot of space for the actual programs. I suggest to use at least 1GiB.

Am Freitag, 13. August 2021, 16:06:34 CEST schrieb :
> Hello Brice,
>
> The log to me seems like dracut fails to find the device with the root filesystem.

Which is a bit weird, because it is there:

[   75.155459] localhost kernel:  vda: vda1 vda2
lrwxrwxrwx 1 root root 10 Aug 13 09:43 6dd18fe1-192e-4627-affc-9bba001859aa -> ../../vda2

Maybe it's temporarily missing because of something ignition did, but
ignition didn't do much, the platform=metal means it had no config.

What's the result if you try without libvirt, like this?

cp /usr/share/qemu/aavmf-aarch64-vars.bin vars
qemu-system-aarch64 -M virt -cpu cortex-a72 -m 512 -bios /usr/share/qemu/aavmf-aarch64-code.bin -drive if=pflash,file=vars,unit=1 -hda /tmp/SUSE-MicroOS.aarch64-5.1.0-Default-Beta2.raw -net none -fw_cfg name=opt/com.coreos/config,file=config.ign

> I don?t know whether this is the real cause, but keep in mind that this image (raw of aarch64) is intended and only was tested on RaspberryPi, therefore I can imagine the virtualisation drivers not being loaded from initrd.

It shouldn't actually make a difference in this case. The only changes an image
targeted at QEMU would have is a different image format (qcow2 instead of raw,
no RPi specific "ESP" content) and packages like qemu-guest-agent, but not any
kernel or initrd differences.

In the raw image there might not be any free space on the root partition after
boot, but that sholudn't make a difference during this phase of booting either.

At least for JeOS, the image for RPi is tested by openQA with QEMU and UEFI the
same way (just natively on ARM hosts).

BTW: Please don't use pastebin.com for potentially internal content. The pasted
text is publicly listed.

Cheers,
Fabian

> [   87.230528] localhost systemd[1]: dev-disk-by\x2duuid-6dd18fe1\x2d192e\x2d4627\x2daffc\x2d9bba001859aa.device: Job dev-disk-by\x2duuid-6dd18fe1\x2d192e\x2d4627\x2daffc\x2d9bba001859aa.device/start timed out.
> [   87.231660] localhost systemd[1]: Timed out waiting for device /dev/disk/by-uuid/6dd18fe1-192e-4627-affc-9bba001859aa.
> [   87.253797] localhost systemd[1]: Dependency failed for Initrd Root Device.
> [   87.259636] localhost systemd[1]: initrd-root-device.target: Job initrd-root-device.target/start failed with result 'dependency'.
> [   87.263634] localhost systemd[1]: initrd-root-device.target: Triggering OnFailure= dependencies.
> [   87.283626] localhost systemd[1]: Dependency failed for File System Check on /dev/disk/by-uuid/6dd18fe1-192e-4627-affc-9bba001859aa.
>
> We are open to adding new pre-built images (which would even include qcow image for aarcht64 when needed; is there any real business case for that or is it only testing environment?
>
> Jiri
>
> > On 13. 8. 2021, at 12:00, Brice Dekany <brice.dekany at suse.com> wrote:
> >
> > Hi there,
> >
> > I tried to boot the aarch64 raw image of SLE-Micro 5.1 Beta2 on qemu-arm
> > The process goes well to grub. It looks like the ignation file is read. And then it crash.
> >
> > Image used: SUSE-MicroOS.aarch64-5.1.0-Default-Beta2.raw
> > CommandLine:
> > sudo  virt-install      --connect qemu:///system   \
> >    --name demo2      --ram 512      --disk path=SUSE-MicroOS.aarch64-5.1.0-Default-Beta2.raw \
> >         --network network=default      --virt-type qemu --import --os-variant sle15sp3 \
> >         --arch=aarch64 --qemu-commandline="-fw_cfg name=opt/com.coreos/config,file=config.ign"
> >
> > Log:
> > Loading Linux 5.3.18-59.16-default ...
> > Loading initial ramdisk ...
> > SetUefiImageMemoryAttributes - 0x000000005BD60000 - 0x0000000000040000 (0x0000000000000008)
> > SetUefiImageMemoryAttributes - 0x000000005BD10000 - 0x0000000000040000 (0x0000000000000008)
> > SetUefiImageMemoryAttributes - 0x000000005BCC0000 - 0x0000000000040000 (0x0000000000000008)
> > SetUefiImageMemoryAttributes - 0x000000005BC80000 - 0x0000000000030000 (0x0000000000000008)
> > SetUefiImageMemoryAttributes - 0x000000005BC30000 - 0x0000000000040000 (0x0000000000000008)
> > SetUefiImageMemoryAttributes - 0x0000000058690000 - 0x00000000000B0000 (0x0000000000000008)
> > SetUefiImageMemoryAttributes - 0x0000000058490000 - 0x0000000000030000 (0x0000000000000008)
> > SetUefiImageMemoryAttributes - 0x0000000058450000 - 0x0000000000030000 (0x0000000000000008)
> > [   23.103874] pcieport 0000:00:01.6: pciehp: Failed to check link status
> >
> > Generating "/run/initramfs/rdsosreport.txt"
> >
> >
> > Entering emergency mode. Exit the shell to continue.
> > Type "journalctl" to view system logs.
> > You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot
> > after mounting them and attach it to a bug report.
> >
> >
> > Press Enter for maintenance
> > (or press Control-D to continue):
> >
> >
> > cat /run/initramfs/rdsosreport.txt >>> https://pastebin.com/1RV9zagr
> >
> >
> > Regards
> >
> > <Outlook-fidfsjjm.png>
> > Brice DEKANY
> > SE for France
> > +33.6.37.12.53.24
> > brice.dekany at suse.com
> > LinkedIn | Twitter | YouTube
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.suse.com/pipermail/micro-beta/attachments/20210817/778dbe30/attachment.htm>