From vmoutoussamy at suse.com Thu Aug 5 07:48:43 2021 From: vmoutoussamy at suse.com (Vincent Moutoussamy) Date: Thu, 5 Aug 2021 07:48:43 +0000 Subject: [TEST] This is a test email Message-ID: Hi there, Please ignore this email as it?s just a test for the archive feature of our mailing list. Have a nice day, Regards, -- Vincent Moutoussamy SUSE Beta Program Manager JeOS Technical Project Manager Paris, France -------------- next part -------------- An HTML attachment was scrubbed... URL: From beta-programs at suse.com Thu Aug 5 09:34:15 2021 From: beta-programs at suse.com (SUSE Beta Program) Date: Thu, 05 Aug 2021 11:34:15 +0200 Subject: Welcome to the SUSE Linux Enterprise Micro Beta Public Mailing List Message-ID: <610bb097e6a93_272f2bc-2cc@MacBouille.local.mail> Welcome! You are now subscribed to the public micro-beta[1] mailing list, which is the forum for the Public Beta Testers of SUSE Linux Enterprise Micro. It is our official channel to reach out SUSE Engineering and other external Beta Participants for support, help and technical discussions around SUSE Linux Enterprise Micro Beta. By subscribing to this list you will receive: - Announcement emails for new beta release and official release of the final product version, - General or technical information emails about the beta product, - Emails sent by other beta testers (feedback, question, report), - Survey at the end of the beta program to retrieve your feedback on the beta product and the beta program itself. We will not use your email address for anything not related to the SUSE Beta Program and SUSE Beta products. It is required to subscribe to this mailing list to be able to post, however, the mailing list archive can be read by anyone without being subscribed. To see the collection of prior postings to the list, visit the micro-beta Archives[2]. Last but not least, please read and acknowledge our SUSE Beta Code of Conduct[3]. SLE Micro 5.1 Public Beta (beta 2) is out! As you might be aware, we have release SLE Micro 5.1 Public Beta (beta 2), please refer to our dedicated micro-beta[4] pages for more information. Questions? If you have any questions, please contact us at beta-programs at suse.com. Your SUSE Linux Enterprise team Click here to unsubscribe[5] [1]:http://lists.suse.com/mailman/listinfo/micro-beta [2]:http://lists.suse.com/pipermail/micro-beta/ [3]:https://www.suse.com/betaprogram/codeofconduct/ [4]:https://suse.com/betaprogram/micro-beta [5]:mailto:beta-programs at suse.com?subject=Unsubscribe%20from% 20SLE%20Public%20Beta%20Program&body=Unsubscribe%20from%20SLE %20Public%20Beta%20Program -------------- next part -------------- An HTML attachment was scrubbed... URL: From beta-programs at suse.com Fri Aug 6 13:57:37 2021 From: beta-programs at suse.com (SUSE Beta Program) Date: Fri, 06 Aug 2021 15:57:37 +0200 Subject: [ANNOUNCE] SUSE Linux Enterprise Micro 5.1 Public Beta (Beta 2) is out! Message-ID: <610d3fd18e007_75fe2bc-266@MacBouille.local.mail> We are thrilled to announce the Public Beta (Beta 2) of SUSE Linux Enterprise Micro 5.1! SLE Micro is an ultra-reliable, lightweight operating system purpose built for edge computing. Please check out our Product page[1] to learn more, but for the beta program, please refer to our dedicated beta page[2]. Download[3] Major Theme for SLE Micro 5.1 - Web based System Management with Cockpit As an immutable operating system designed for Edge use cases, SLE Micro does not support YaST for local system administration. We provide basic administration tools via the included web-based system management based on the Cockpit project. - New deliverable: Real-Time Real-Time ? On Intel and AMD64 SLE Micro provides a real-time kernel as an option. - Security Framework SLE Micro standardises on SELinux as the security and confinement framework and extents it with a fully supported SELinux policy. Notable Changes since SLE Micro 5.0? - Based on SLE 15 SP3 SLE Micro 5.1 is based on SLE 15 SP3 where SLE Micro 5.0 was based on SLE 15 SP2. - SUSEConnect re-write As we strive to make SLE Micro as minimal as possible we decided to re-write SUSEConnect in a compiled language that does not come with a dependency on a scripting language stack. We have decided to re-write SUSEConnect in Go. - Full 5G support (Planned, not yet included in Beta) Initial testing with partners and customers has shown the support for 5G devices with the currently used networking stack based on wicked is limited. With SLE Micro 5.1 the support for 5G client devices shall be improved and expand to cover common devices. - Secure Device Onboarding (SDO) Secure Device Onboarding (SDO) will play a major role in upcoming edge deployments. We therefore will provide an SDO client on SLE Micro 5.1. The client will not be provided on the SLE Micro 5.1 images itself but outside of the images. - LivePatching With SLE Micro being introduced in datacenter as a container host OS, there is a need for specific datacenter feature, thus the availability of live patching. We are going to provide LivePatching with the final product SLE Micro 5.1. It is not yet available with this beta2. Call for feedback We are eager and excited to retrieve your feedback on this new version of our beloved SLE Micro product! As with any SUSE Public Beta Program[4], we have a public mailing list[5] in place for technical and product discussion as well as a bugzilla setup[6] to be used for bug report. Please refer to SLE Micro Beta web page[7] for more information. More information FAQ[8] Feedback[9] Known issues[10] Questions? If you have any questions, please contact us at beta-programs at suse.com. Your SUSE Linux Enterprise Micro team Click here to unsubscribe[11] [1]:https://www.suse.com/products/micro/ [2]:https://suse.com/betaprogram/micro-beta [3]:https://suse.com/betaprogram/micro-beta/#download [4]:https://www.suse.com/betaprogram/beta/ [5]:https://suse.com/betaprogram/micro-beta/#mailinglist [6]:https://suse.com/betaprogram/micro-beta/#bugzilla [7]:https://suse.com/betaprogram/micro-beta/ [8]:https://suse.com/betaprogram/micro-beta/#faq [9]:https://suse.com/betaprogram/micro-beta/#feedback [10]:https://suse.com/betaprogram/micro-beta/#knownissues [11]:mailto:beta-programs at suse.com?subject=Unsubscribe%20from %20SLE%20Micro%20Public%20Beta%20Program&body=Unsubscribe%20f rom%20SLE%20Micro%20Public%20Beta%20Program -------------- next part -------------- An HTML attachment was scrubbed... URL: From brice.dekany at suse.com Fri Aug 13 10:00:33 2021 From: brice.dekany at suse.com (Brice Dekany) Date: Fri, 13 Aug 2021 10:00:33 +0000 Subject: Fail to boot SLE-Micro 5.1 Beta2 on qemu-arm Message-ID: 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 [cid:69c4480b-353f-4a36-866d-3fad180c6792] 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: Outlook-fidfsjjm.png Type: image/png Size: 2013 bytes Desc: Outlook-fidfsjjm.png URL: From jsrain at suse.com Fri Aug 13 14:06:34 2021 From: jsrain at suse.com (Jiri Srain) Date: Fri, 13 Aug 2021 14:06:34 +0000 Subject: Fail to boot SLE-Micro 5.1 Beta2 on qemu-arm In-Reply-To: References: Message-ID: <6EDF747C-A352-412C-B7B4-AA11207F919E@suse.com> Hello Brice, The log to me seems like dracut fails to find the device with the root filesystem. 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. [ 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 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 > > > Brice DEKANY > SE for France > +33.6.37.12.53.24 > brice.dekany at suse.com > LinkedIn | Twitter | YouTube From iforster at suse.de Fri Aug 13 14:21:48 2021 From: iforster at suse.de (Ignaz Forster) Date: Fri, 13 Aug 2021 16:21:48 +0200 Subject: Fail to boot SLE-Micro 5.1 Beta2 on qemu-arm In-Reply-To: References: Message-ID: <435e0763-1576-7e09-e600-39057c1417e1@suse.de> Am 13.08.21 um 12:00 Uhr schrieb Brice Dekany: > 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. It seems that no Ignition configuration was found: [ 77.149196] localhost ignition[449]: Ignition 2.11.0 [ 77.195059] localhost ignition[449]: Stage: fetch-offline [ 77.240441] localhost ignition[449]: no config dir at "/usr/lib/ignition/base.d" [ 77.242479] localhost ignition[449]: no config dir at "/usr/lib/ignition/base.platform.d/metal" [ 77.269157] localhost ignition[449]: parsed url from cmdline: "" [ 77.283457] localhost ignition[449]: no config URL provided [ 77.307189] localhost ignition[449]: reading system config file "/usr/lib/ignition/user.ign" [ 77.323124] localhost ignition[449]: no config at "/usr/lib/ignition/user.ign" [ 77.329128] localhost ignition[449]: noop provider fetching empty config [ 77.338430] localhost ignition[449]: not a config (empty): provider config was empty, continuing with empty cache config [ 77.540842] localhost ignition[449]: fetched base config from "system" [ 77.615612] localhost ignition[449]: fetch-offline: fetch-offline passed [ 77.617638] localhost ignition[449]: Ignition finished successfully This is probably caused by the fact that the RPi images have `ignition.platform.id=metal` set in the KIWI configuration, so it doesn't try to search for the QEMU specific configuration file. This could be removed, an auto-detection will be attempted then. > And then it crash > cat /run/initramfs/rdsosreport.txt >>>?https://pastebin.com/1RV9zagr > These are the relevant lines: [ 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. [ 87.312537] localhost systemd[1]: Dependency failed for /sysroot. The root file system cannot be found, maybe because the the necessary kernel modules are missing from the initrd. (I've just seen that Jiri came to the same conclusion.) Ignaz -- Ignaz Forster Research Engineer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 N?rnberg, Germany (HRB 36809, AG N?rnberg) Gesch?ftsf?hrer: Felix Imend?rffer From brice.dekany at suse.com Fri Aug 13 14:25:27 2021 From: brice.dekany at suse.com (Brice Dekany) Date: Fri, 13 Aug 2021 14:25:27 +0000 Subject: Fail to boot SLE-Micro 5.1 Beta2 on qemu-arm In-Reply-To: <435e0763-1576-7e09-e600-39057c1417e1@suse.de> References: <435e0763-1576-7e09-e600-39057c1417e1@suse.de> Message-ID: Hi, I understand that raw image is meant to be flashed in card only for RPi. So the idea of "flashing"-convert it in qcow2 is impossible? Making a specific qcow2 could help qemu user but will not serve my use-case. We need to test our application and the new ignition process in a CI-way before flash our hardware. The idea behing using the same raw image was to minimize the difference. I really don't want to create a CI based on the ISO and then discover that the whole ignation process is wrong. Thanks for your help. My new question now is: how do I/we test the ignition process and app deployement without spending ages on flashing sdcard? Regards [cid:f6fd7142-d6a2-4f00-883e-880b621b76da] Brice DEKANY SE for France +33.6.37.12.53.24 brice.dekany at suse.com LinkedIn | Twitter | YouTube ________________________________ De : micro-beta de la part de Ignaz Forster Envoy? : vendredi 13 ao?t 2021 16:21 ? : micro-beta at lists.suse.com Objet : Re: Fail to boot SLE-Micro 5.1 Beta2 on qemu-arm Am 13.08.21 um 12:00 Uhr schrieb Brice Dekany: > 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. It seems that no Ignition configuration was found: [ 77.149196] localhost ignition[449]: Ignition 2.11.0 [ 77.195059] localhost ignition[449]: Stage: fetch-offline [ 77.240441] localhost ignition[449]: no config dir at "/usr/lib/ignition/base.d" [ 77.242479] localhost ignition[449]: no config dir at "/usr/lib/ignition/base.platform.d/metal" [ 77.269157] localhost ignition[449]: parsed url from cmdline: "" [ 77.283457] localhost ignition[449]: no config URL provided [ 77.307189] localhost ignition[449]: reading system config file "/usr/lib/ignition/user.ign" [ 77.323124] localhost ignition[449]: no config at "/usr/lib/ignition/user.ign" [ 77.329128] localhost ignition[449]: noop provider fetching empty config [ 77.338430] localhost ignition[449]: not a config (empty): provider config was empty, continuing with empty cache config [ 77.540842] localhost ignition[449]: fetched base config from "system" [ 77.615612] localhost ignition[449]: fetch-offline: fetch-offline passed [ 77.617638] localhost ignition[449]: Ignition finished successfully This is probably caused by the fact that the RPi images have `ignition.platform.id=metal` set in the KIWI configuration, so it doesn't try to search for the QEMU specific configuration file. This could be removed, an auto-detection will be attempted then. > And then it crash > cat /run/initramfs/rdsosreport.txt >>> https://pastebin.com/1RV9zagr > These are the relevant lines: [ 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. [ 87.312537] localhost systemd[1]: Dependency failed for /sysroot. The root file system cannot be found, maybe because the the necessary kernel modules are missing from the initrd. (I've just seen that Jiri came to the same conclusion.) Ignaz -- Ignaz Forster Research Engineer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 N?rnberg, Germany (HRB 36809, AG N?rnberg) Gesch?ftsf?hrer: Felix Imend?rffer -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Outlook-g2lijtnd.png Type: image/png Size: 2013 bytes Desc: Outlook-g2lijtnd.png URL: From iforster at suse.de Fri Aug 13 14:40:59 2021 From: iforster at suse.de (Ignaz Forster) Date: Fri, 13 Aug 2021 16:40:59 +0200 Subject: Fail to boot SLE-Micro 5.1 Beta2 on qemu-arm In-Reply-To: References: <435e0763-1576-7e09-e600-39057c1417e1@suse.de> Message-ID: <8f1f5e06-713d-739c-684e-4084da73d10b@suse.de> Am 13.08.21 um 16:25 Uhr schrieb Brice Dekany: > My new question now is: how do I/we test the ignition process and app > deployement without spending ages on flashing sdcard? You can just append the kernel parameter `ignition.firstboot` in GRUB - Ignition will run again then - no need to reflash. If you have write access to the system already you can also delete the file /boot/writable/firstboot_happened (/boot writable is a separate subvolume) to retrigger an Ignition run. I'd recommend to also append `rd.break` as an additional kernel parameter to prevent health-checker from just restarting the system in case of an error. As written in the last mail the aarch64 image only seems to work on a real Raspberry Pi for now. Ignaz -- Ignaz Forster Research Engineer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 N?rnberg, Germany (HRB 36809, AG N?rnberg) Gesch?ftsf?hrer: Felix Imend?rffer From kukuk at suse.de Fri Aug 13 14:48:54 2021 From: kukuk at suse.de (Thorsten Kukuk) Date: Fri, 13 Aug 2021 16:48:54 +0200 Subject: Fail to boot SLE-Micro 5.1 Beta2 on qemu-arm In-Reply-To: <0e6aaff608b4426fb54c8ce549c311d4@AM0PR0402MB3507.eurprd04.prod.outlook.com> References: <435e0763-1576-7e09-e600-39057c1417e1@suse.de> <0e6aaff608b4426fb54c8ce549c311d4@AM0PR0402MB3507.eurprd04.prod.outlook.com> Message-ID: <20210813144854.GA11699@suse.de> On Fri, Aug 13, Brice Dekany wrote: > Hi, > > I understand that raw image is meant to be flashed in card only for RPi. > So the idea of "flashing"-convert it in qcow2 is impossible? It could work, but you have to emulate e.g. a real Raspberry Pi, so no virtio drivers or something similar which does not exist on real hardware. > Making a specific qcow2 could help qemu user but will not serve my use-case. > > We need to test our application and the new ignition process in a CI-way before > flash our hardware. But if you use qemu, you don't test the ignition process used on your hardware... > The idea behing using the same raw image was to minimize the difference. > I really don't want to create a CI based on the ISO and then discover that the > whole ignation process is wrong. If you really want to test the process on real hardware, you have to use real hardware. Or emulate real hardware in qemu, so that the system does not notice it's running virtual. Else ignition will use the qemu-workflow and not the bare metal workflow... Thorsten > Thanks for your help. > > My new question now is: how do I/we test the ignition process and app > deployement without spending ages on flashing sdcard? > > Regards > > [cid] > Brice DEKANY > SE for France > +33.6.37.12.53.24 > brice.dekany at suse.com > LinkedIn | Twitter | YouTube > ??????????????????????????????????????????????????????????????????????????????? > De : micro-beta de la > part de Ignaz Forster > Envoy? : vendredi 13 ao?t 2021 16:21 > ? : micro-beta at lists.suse.com > Objet : Re: Fail to boot SLE-Micro 5.1 Beta2 on qemu-arm > > Am 13.08.21 um 12:00 Uhr schrieb Brice Dekany: > > 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. > > It seems that no Ignition configuration was found: > > [ 77.149196] localhost ignition[449]: Ignition 2.11.0 > [ 77.195059] localhost ignition[449]: Stage: fetch-offline > [ 77.240441] localhost ignition[449]: no config dir at > "/usr/lib/ignition/base.d" > [ 77.242479] localhost ignition[449]: no config dir at > "/usr/lib/ignition/base.platform.d/metal" > [ 77.269157] localhost ignition[449]: parsed url from cmdline: "" > [ 77.283457] localhost ignition[449]: no config URL provided > [ 77.307189] localhost ignition[449]: reading system config file > "/usr/lib/ignition/user.ign" > [ 77.323124] localhost ignition[449]: no config at > "/usr/lib/ignition/user.ign" > [ 77.329128] localhost ignition[449]: noop provider fetching empty config > [ 77.338430] localhost ignition[449]: not a config (empty): provider > config was empty, continuing with empty cache config > [ 77.540842] localhost ignition[449]: fetched base config from "system" > [ 77.615612] localhost ignition[449]: fetch-offline: fetch-offline passed > [ 77.617638] localhost ignition[449]: Ignition finished successfully > > This is probably caused by the fact that the RPi images have > `ignition.platform.id=metal` set in the KIWI configuration, so it > doesn't try to search for the QEMU specific configuration file. This > could be removed, an auto-detection will be attempted then. > > > And then it crash > > cat /run/initramfs/rdsosreport.txt >>> https://pastebin.com/1RV9zagr > > > > These are the relevant lines: > > [ 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. > [ 87.312537] localhost systemd[1]: Dependency failed for /sysroot. > > The root file system cannot be found, maybe because the the necessary > kernel modules are missing from the initrd. (I've just seen that Jiri > came to the same conclusion.) > > Ignaz > -- > Ignaz Forster > Research Engineer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 N?rnberg, Germany > > (HRB 36809, AG N?rnberg) > Gesch?ftsf?hrer: Felix Imend?rffer > -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG N?rnberg) From fvogt at suse.de Tue Aug 17 14:09:32 2021 From: fvogt at suse.de (Fabian Vogt) Date: Tue, 17 Aug 2021 16:09:32 +0200 Subject: Fail to boot SLE-Micro 5.1 Beta2 on qemu-arm In-Reply-To: <6EDF747C-A352-412C-B7B4-AA11207F919E@suse.com> References: <6EDF747C-A352-412C-B7B4-AA11207F919E@suse.com> Message-ID: <2930281.T8shpCOLCW@linux-e202.suse.de> 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 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 > > > > > > Brice DEKANY > > SE for France > > +33.6.37.12.53.24 > > brice.dekany at suse.com > > LinkedIn | Twitter | YouTube > > > From brice.dekany at suse.com Tue Aug 17 17:25:38 2021 From: brice.dekany at suse.com (Brice Dekany) Date: Tue, 17 Aug 2021 17:25:38 +0000 Subject: Fail to boot SLE-Micro 5.1 Beta2 on qemu-arm In-Reply-To: <2930281.T8shpCOLCW@linux-e202.suse.de> References: <6EDF747C-A352-412C-B7B4-AA11207F919E@suse.com> <2930281.T8shpCOLCW@linux-e202.suse.de> Message-ID: 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 Envoy? : Tuesday, August 17, 2021 4:09:32 PM ? : micro-beta at lists.suse.com Cc : Brice Dekany 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 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 > > > > > > 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: