Created attachment 1890 [details] install log screen capture Tested with: meta-intel a1491bc54b60a1c622a9060756fd9b145bc01378 meta-qt3 3016129d90b7ac8517a5227d819f10ad417b5b45 poky ae938eba92b2c89a9fd91161e57c5dbc594ad4ad Using core-image-lsb-sdk-jasperforest Description: Sometimes when using the "Install" boot option from GRUB on USB Stick the following happens: 0) Usually we live boot the image before anything else but this might not be relevant. After this we install the image from the USB stick. 1) When asked to choose an install disk, usually the option shown by the install script is /dev/sda (on meta-intel and generic BSPs). Sometimes the option shown is /dev/sdb as seen in attached image "install.jpg" 2) The installation finishes successfully 3) When booted, if /dev/sdb was used, the error in "boot.jpg" is shown and the boot fails. ( "VFS: Unable to mount root fs on unknown-block(0,0)" ) NOTE_1: This does not happen when /dev/sda is shown by the install script NOTE_2: If the user chooses not to use /dec/sdb the installation process ends NOTE_3: This issue has been present for a long time but we have not been able to find a 100% reproduction scenario NOTE_4: I am attaching (fdisk.log) the output of 'fdisk -l /dev/sdg' where /dev/sdg is the installable USB image (created using 'sudo dd if=core-image-lsb-sdk-jasperforest-20140326203442.hddimg of=/dev/sdc') NOTE_5: After a few shutdowns and reboots the problem can be solved but there is not sure way of reproducing it once it works. NOTE_6: We are setting the BIOS to see the USB stick as a HDD. We do this for all the intel BIOS boards.
Created attachment 1891 [details] boot log screen capture
Created attachment 1892 [details] fdisk output
I suspect this is related to a race in how the kernel identifies USB vs SATA, which changes the /dev/sd* node assigned to each. If we are installing to SATA on /dev/sdb and then remove USB (/dev/sda), on reboot SATA will be /dev/sda and the root=/dev/sdb1 kernel cmdline parameter will result in a failure as described in the opening comment. The difficulty here is that using UUID or LABEL in the root= parameter requires an initial ramdisk, which we do not have on all images. To fix this properly, we need to first define the scope of the installer. Does it only work with initrd-based images?
Marking as NEEDINFO as we need to define installer scope.
This will require further investigation which will be done in the following weeks.
This bug makes an interesting example of why we likely need to integrate partition UUIDs into the system and is related to some of the other UUID requests we're getting. Note this shouldn't need the initramfs UUID work.
Started to work on this today. The issue is clear and hopefully can be fixed by using GPT partitions and root=PARTUUID==<UUID> option in kernel command line. I've just finished similar implementation for wic, so the knowledge is fresh :)
I managed to reproduce this bug with NUC and two USB sticks. The reason of it is pretty clear - device names could differ on installation time and when device is booting. The obvious solution is to use GPT partition table and partition UUIDs instead of device names.
Implemented for EFI installer images, please review: http://lists.openembedded.org/pipermail/openembedded-core/2015-June/105949.html http://lists.openembedded.org/pipermail/openembedded-core/2015-June/105950.html Cornel, can you verify if above 2 patches fix the issue in your setup? BTW, do you use efi or non-efi live installation image?
Here is hopefully final patchset that fixes both EFI and non-efi installers: http://lists.openembedded.org/pipermail/openembedded-core/2015-June/106117.html
Patchset has been merged to master. Here is the last commit of the series: http://cgit.openembedded.org/openembedded-core/commit/?id=9be59c02901a6c9ecaaa293aea2e938edf9b122c