<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body>
<div>
<div>
<div style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" dir="ltr">
I managed to boot on a real RPi 4 </div>
<div style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" dir="ltr">
<br>
</div>
<div style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" dir="ltr">
I’ll spend more time later to understand why my qemu (leap 15.3) is not working </div>
<div style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" dir="ltr">
<br>
</div>
<div style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" dir="ltr">
Regards</div>
</div>
<div id="ms-outlook-mobile-signature">
<div><br>
</div>
<div style="direction: ltr;">—</div>
<div style="direction: ltr;">Brice DEKANY </div>
<div style="direction: ltr;">SE for France</div>
<div style="direction: ltr;">06.37.12.53.24</div>
</div>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>De :</b> Fabian Vogt <fvogt@suse.de><br>
<b>Envoyé :</b> Tuesday, August 17, 2021 4:09:32 PM<br>
<b>À :</b> micro-beta@lists.suse.com <micro-beta@lists.suse.com><br>
<b>Cc :</b> Brice Dekany <brice.dekany@suse.com><br>
<b>Objet :</b> Re: Fail to boot SLE-Micro 5.1 Beta2 on qemu-arm</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Hi,<br>
<br>
I gave the image a try and it works here on x86_64 TW using qemu-system-aarch64<br>
directly and using the virt-install call as well. What do you use as host?<br>
<br>
512MiB RAM seems low though, especially with the initial initrd that doesn't<br>
leave a lot of space for the actual programs. I suggest to use at least 1GiB.<br>
<br>
Am Freitag, 13. August 2021, 16:06:34 CEST schrieb :<br>
> Hello Brice,<br>
> <br>
> The log to me seems like dracut fails to find the device with the root filesystem.<br>
<br>
Which is a bit weird, because it is there:<br>
<br>
[ 75.155459] localhost kernel: vda: vda1 vda2<br>
lrwxrwxrwx 1 root root 10 Aug 13 09:43 6dd18fe1-192e-4627-affc-9bba001859aa -> ../../vda2<br>
<br>
Maybe it's temporarily missing because of something ignition did, but<br>
ignition didn't do much, the platform=metal means it had no config.<br>
<br>
What's the result if you try without libvirt, like this?<br>
<br>
cp /usr/share/qemu/aavmf-aarch64-vars.bin vars<br>
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<br>
<br>
> 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.<br>
<br>
It shouldn't actually make a difference in this case. The only changes an image<br>
targeted at QEMU would have is a different image format (qcow2 instead of raw,<br>
no RPi specific "ESP" content) and packages like qemu-guest-agent, but not any<br>
kernel or initrd differences.<br>
<br>
In the raw image there might not be any free space on the root partition after<br>
boot, but that sholudn't make a difference during this phase of booting either.<br>
<br>
At least for JeOS, the image for RPi is tested by openQA with QEMU and UEFI the<br>
same way (just natively on ARM hosts).<br>
<br>
BTW: Please don't use pastebin.com for potentially internal content. The pasted<br>
text is publicly listed.<br>
<br>
Cheers,<br>
Fabian<br>
<br>
> [ 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.<br>
> [ 87.231660] localhost systemd[1]: Timed out waiting for device /dev/disk/by-uuid/6dd18fe1-192e-4627-affc-9bba001859aa.<br>
> [ 87.253797] localhost systemd[1]: Dependency failed for Initrd Root Device.<br>
> [ 87.259636] localhost systemd[1]: initrd-root-device.target: Job initrd-root-device.target/start failed with result 'dependency'.<br>
> [ 87.263634] localhost systemd[1]: initrd-root-device.target: Triggering OnFailure= dependencies.<br>
> [ 87.283626] localhost systemd[1]: Dependency failed for File System Check on /dev/disk/by-uuid/6dd18fe1-192e-4627-affc-9bba001859aa.<br>
> <br>
> 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?<br>
> <br>
> Jiri<br>
> <br>
> > On 13. 8. 2021, at 12:00, Brice Dekany <brice.dekany at suse.com> wrote:<br>
> > <br>
> > Hi there,<br>
> > <br>
> > I tried to boot the aarch64 raw image of SLE-Micro 5.1 Beta2 on qemu-arm<br>
> > The process goes well to grub. It looks like the ignation file is read. And then it crash.<br>
> > <br>
> > Image used: SUSE-MicroOS.aarch64-5.1.0-Default-Beta2.raw<br>
> > CommandLine: <br>
> > sudo virt-install --connect qemu:///system \<br>
> > --name demo2 --ram 512 --disk path=SUSE-MicroOS.aarch64-5.1.0-Default-Beta2.raw \<br>
> > --network network=default --virt-type qemu --import --os-variant sle15sp3 \<br>
> > --arch=aarch64 --qemu-commandline="-fw_cfg name=opt/com.coreos/config,file=config.ign"<br>
> > <br>
> > Log:<br>
> > Loading Linux 5.3.18-59.16-default ...<br>
> > Loading initial ramdisk ...<br>
> > SetUefiImageMemoryAttributes - 0x000000005BD60000 - 0x0000000000040000 (0x0000000000000008)<br>
> > SetUefiImageMemoryAttributes - 0x000000005BD10000 - 0x0000000000040000 (0x0000000000000008)<br>
> > SetUefiImageMemoryAttributes - 0x000000005BCC0000 - 0x0000000000040000 (0x0000000000000008)<br>
> > SetUefiImageMemoryAttributes - 0x000000005BC80000 - 0x0000000000030000 (0x0000000000000008)<br>
> > SetUefiImageMemoryAttributes - 0x000000005BC30000 - 0x0000000000040000 (0x0000000000000008)<br>
> > SetUefiImageMemoryAttributes - 0x0000000058690000 - 0x00000000000B0000 (0x0000000000000008)<br>
> > SetUefiImageMemoryAttributes - 0x0000000058490000 - 0x0000000000030000 (0x0000000000000008)<br>
> > SetUefiImageMemoryAttributes - 0x0000000058450000 - 0x0000000000030000 (0x0000000000000008)<br>
> > [ 23.103874] pcieport 0000:00:01.6: pciehp: Failed to check link status<br>
> > <br>
> > Generating "/run/initramfs/rdsosreport.txt"<br>
> > <br>
> > <br>
> > Entering emergency mode. Exit the shell to continue.<br>
> > Type "journalctl" to view system logs.<br>
> > You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot<br>
> > after mounting them and attach it to a bug report.<br>
> > <br>
> > <br>
> > Press Enter for maintenance<br>
> > (or press Control-D to continue):<br>
> > <br>
> > <br>
> > cat /run/initramfs/rdsosreport.txt >>> <a href="https://pastebin.com/1RV9zagr">
https://pastebin.com/1RV9zagr</a><br>
> > <br>
> > <br>
> > Regards<br>
> > <br>
> > <Outlook-fidfsjjm.png><br>
> > Brice DEKANY<br>
> > SE for France<br>
> > +33.6.37.12.53.24<br>
> > brice.dekany at suse.com<br>
> > LinkedIn | Twitter | YouTube<br>
> <br>
> <br>
> <br>
<br>
<br>
<br>
<br>
</div>
</span></font></div>
</body>
</html>