Created attachment 1800 [details] screen photo poky dylan:7ab82abcad9ede847c42c01d2a4f4c2c18877e6f Steps to reproduce: 1) use 'dd' to copy minnowboard core-image-sato-sdk.hddimg on USB stick 2) live boot the image 3) use fdisk to format the mmc to 1 new partition 4) reboot 5) install image to MMC 6) run installed image on board Notice trace call(attached image)
SDK images should not be booted as live images. They are too large and send the system into OOM, killing random things like init. To test these images, especially on EFI systems, something like mkefidisk or wic should be used to prepare a properly partitioned image on the boot media. I will open a new book to deal with the problem with large images as live images.
The issue here is not with the live image but with the installed image. That one fails to boot.
Ah, thanks. Will have a closer look.
The reason I addes steps 1, 2, 3 and 4 is because installing the minnow image over an already-partitioned MMC will sometimes cause errors. I have yet to reproduce this 100% though.
Scott, is there any chance you can see if you can replicate this issue?
(In reply to comment #4) > The reason I addes steps 1, 2, 3 and 4 is because installing the minnow > image over an already-partitioned MMC will sometimes cause errors. I have > yet to reproduce this 100% though. Please provide some more contextual information, such as this, when opening new bugs. The fact that it isn't 100% reproducible is critical information. The observation about it being on already-partitioned MMC is also very important.
(In reply to comment #5) > Scott, is there any chance you can see if you can replicate this issue? I will try to replicate it, but I can't commit further than that at this time.
Stoicescu, when you say "use fdisk to format the mmc to 1 new partition" - that's not the way we generate mmc disk images for Minnow. The mkefidisk.sh script will create an mmc with two partitions - one that is properly prepared for UEFI (vfat fs, bootloader installed in the required directory structure) and then a second partition for the rootfs. Also, I don't believe fdisk will create GPT partition tables, which is a requirement for UEFI systems. We use parted within the mkefidisk.sh script. Either that step is incorrect on your side, or I'm misunderstanding something. Please explain. Thanks -Scott
I will explain steps 3 and 5: 3) Under normal circumstances, the MMC will contain the previously installed Minnow image from the previous Full Pass. If I attempt to install the new Minnow image from USB using UEFI boot and choosing the "install" option from Grub, usually(but not always) an error will stop the installation. That is why I boot the live image from USB, use fdisk to erase the partitions and then install the new image from USB. This install process creates the appropriate partitions you mentioned for the image to work. This process succeeds 100% in master but with the mentioned dylan commit it fails with the attached error. 5) By "install image to MMC" I mean we should install the image to MMC using the USB stick and the "install" option from Grub. Please tell me if you need any further information.
I was able to reproduce this issue tonight, but need to look into it further tomorrow.
Ok I lied; I had one idea I wanted to investigate tonight. I saved the EFI partition contents and /boot from the rootfs from two images: 1. The microSD card that was created from the GRUB install menu of the USB stick. 2. The microSD card that was created by running mkefidisk.sh from the same .hddimg that was used to create the USB stick. I ran md5sum on all the files saved from the two environments, and the kernels were indeed exactly the same. However, the failing system's grub.cfg file is missing the root=/dev/mmcblk0p2 declaration. Which reminds me that some time ago the mkefidisk.sh script used to have an *intermittent* problem including the root= setting in grub.cfg. I suspect the version of mkefidisk.sh from dylan has this bug, but newer releases of Poky have the fixed version of the script. I'm 99% certain this is the cause of this failure, but I really do not have the time to verify a fix. I'm handing this bug back to Darren - what do you think?
I suspect the dylan install script, init-install-efi.sh, has some bugs since Stoicescu wasn't using mkefidisk.sh to create the image. Both likely need updating. $ git l dylan.. -- ./meta/recipes-core/initrdscripts/files/init-install-efi.sh 5f05bdd classes: Add gummiboot class 1917544 init-install-efi.sh: Remove unnecessary udev rules file to avoid errors e42fefe init-install-efi.sh: Fix root= specification f371626 Revert "initramfs-live-install*: fix the "install" boot option" 1695345 initramfs-live-install*: fix the "install" boot option These two look like they could be readily applied to dylan: 1917544 init-install-efi.sh: Remove unnecessary udev rules file to avoid errors e42fefe init-install-efi.sh: Fix root= specification Stoicescu, could you cherrypick those two patches to your build environment and try this again? Scott, I don't see anything the following mkefidisk.sh that obviously applies to this bug: $ git l dylan.. -- scripts/contrib/mkefidisk.sh cf2ebed mkefidisk.sh: Allow using a loopback mounted file d55d458 scripts/contrib/mkefidisk.sh: fix bashism 7156f30 scripts/contrib/*: fix arithmetic bashism c09866b mkefidisk: Unmount after partitioning d853d5b mkefidisk: Attempt to automatically unmount target device
Corneliu / Alex G: Marking this as NEEDINFO per Comment 12, can you verify?
I tested with latest meta-intelm meta-minnow and poky dylan master (that has 1917544 already applied under 5152260a32bd297d6ec91ea37474e44dd3c2f3da) and the issue happens as described. I then cherry picked e42fefe and rebuild the core-image-sato-sdk image and still, the issue happens as described.
MinnowBoard v1 has reached new feature EOL, FW development is done as are new hardware features. If you feel EXCEEDINGLY strongly about an issue please re-open it for discussion but be aware that we are recommending individuals migrate to the MAX platform.