Bug 6101

Summary: Install script sometimes produces faulty installation
Product: [Runtime] Installation Reporter: Stoicescu Cornel <corneliux.stoicescu>
Component: InstallationAssignee: Ed Bartosh <eduard.bartosh>
Status: RESOLVED FIXED QA Contact: Cristina Agurida <cristina-danielax.agurida>
Severity: normal    
Priority: Medium CC: alexandru.c.georgescu, bogdanx.a.voiculescu, kevin.tian, sgw
Version: 1.6   
Target Milestone: 1.9   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: Unknown (Hard to categorize)
Verified: Documentation change: Don't know
Attachments:
Description Flags
install log screen capture
none
boot log screen capture
none
fdisk output none

Description Stoicescu Cornel 2014-04-02 13:05:19 UTC
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.
Comment 1 Stoicescu Cornel 2014-04-02 13:05:49 UTC
Created attachment 1891 [details]
boot log screen capture
Comment 2 Stoicescu Cornel 2014-04-02 13:06:15 UTC
Created attachment 1892 [details]
fdisk output
Comment 3 Darren Hart 2014-04-03 14:57:19 UTC
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?
Comment 4 Darren Hart 2014-11-14 18:47:38 UTC
Marking as NEEDINFO as we need to define installer scope.
Comment 5 Alexandru Georgescu 2014-12-18 12:13:58 UTC
This will require further investigation which will be done in the following weeks.
Comment 6 Richard Purdie 2015-05-14 15:15:32 UTC
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.
Comment 7 Ed Bartosh 2015-06-05 13:58:19 UTC
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 :)
Comment 8 Ed Bartosh 2015-06-09 12:07:22 UTC
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.
Comment 9 Ed Bartosh 2015-06-10 17:06:45 UTC
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?
Comment 10 Ed Bartosh 2015-06-16 08:43:26 UTC
Here is hopefully final patchset that fixes both EFI and non-efi installers: http://lists.openembedded.org/pipermail/openembedded-core/2015-June/106117.html
Comment 11 Ed Bartosh 2015-06-24 11:09:18 UTC
Patchset has been merged to master. Here is the last commit of the series: http://cgit.openembedded.org/openembedded-core/commit/?id=9be59c02901a6c9ecaaa293aea2e938edf9b122c