Bug 4059

Summary: init-install.sh assumes boot device is the same as the one selected when it is run
Product: [Build System, Metadata & Runtime] OE-Core Reporter: Opensource <opensource>
Component: deploymentAssignee: California Sullivan <california.l.sullivan>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: Medium CC: dvhart, irina.patru, meta.mr.watcher, meta.watcher, richard.purdie
Version: unspecified   
Target Milestone: Future   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: No (bug/feature does not impact docs)

Description Opensource 2013-03-19 16:50:21 UTC
This is probably best described by means of an example:

1) A meta-cedartrail image is put on a external USB drive and is used to boot an Intel DM2800-MT system using the 'Install' grub menu item;

2) This system has an internal USB device installed on the motherboard which is to be used as the boot device;

3) init-install.sh runs and reports that the system has booted from 'sda' and that the on-board USB device is 'sdb'. It installs the image to 'sdb' and shuts down.

4) The system fails to boot when the USB drive is removed and the system restarted as the on-board USB drive is now 'sda', but grub was configured to boot using 'sdb'.

Note: This issue has been entered in response to a request by Darren Hart to the mailing list on 2013-01-11 "That is definitely a weakness in the installer ... An improved installer is something we are working on and this would be good input to track".

It may also be worth noting that init-install.sh also fails to detect the internal USB drive on most runs. It looks as if it's not waiting long enough for the bus enumeration to complete, possibly because the device I'm using (an ATP AF512SSGH) takes a while to initialize internally.

Happy to help if I can ;-)
Comment 1 Darren Hart 2013-09-23 18:57:46 UTC
The trouble with switching to using something like device labels is that relies on an initrd as far as I know and we don't always have those. Without them, I'm not sure how to go about uniquely identifying the root device. Any ideas out there?

Moving this to 1.6 as this can be resolved by editing the bootloader config post install (undertandably much less than ideal).

As for the bit about not seeing the USB key.... that is interesting. I suppose we could have a "Restart" option which would cause the installer to rescan the available devices.
Comment 2 Darren Hart 2014-07-15 21:57:12 UTC
Assigning to Mark to manage as part of the deployment effort.
Comment 3 Richard Purdie 2015-02-11 16:02:05 UTC
This is a known issue with the installer, moving this to a Future Enhancement unassigned as its unlikely Mark will not have time for this any time soon. The hope is if its unassigned, someone will pick this up.
Comment 4 California Sullivan 2017-08-17 18:24:57 UTC
Closing. The installer script now uses UUIDs to set the root device.