aboutsummaryrefslogtreecommitdiffstats
path: root/meta/conf
diff options
context:
space:
mode:
authorPatrick Ohly <patrick.ohly@intel.com>2015-09-03 20:42:32 +0200
committerRichard Purdie <richard.purdie@linuxfoundation.org>2015-09-06 15:24:26 +0100
commit1e29d77d0d33ee216b43022439876863f0db39bb (patch)
tree7ea393243cee6ac458135024ae913050c848f9b9 /meta/conf
parent7fa76bd923fd643cf0984077321d6064d8ec3a2b (diff)
downloadopenembedded-core-contrib-1e29d77d0d33ee216b43022439876863f0db39bb.tar.gz
boot loader: support root=UUID
As mentioned when introducing the VM images (https://bugzilla.yoctoproject.org/show_bug.cgi?id=7374), the resulting images only work when the image is mounted as a disk that results in the hard-coded path (/dev/sda in the current default). Using the file system UUID to find the rootfs is more flexible. To enable this for boot-direct.bbclass and thus image-vm.bbclass (aka FSTYPEs vdi/vmdk/qcow2), set SYSLINUX_ROOT = "root=UUID=<<uuid-of-rootfs>>". The rootfs image must use an ext file system. The special string will get replaced in the APPEND line with the actual UUID when the boot loader (grub-efi, syslinux or gummiboot) writes the boot loader configuration files. At that time, the rootfs image has already been created and its UUID can be extracted using "tune2fs -l", which also should be available because the e2fsprogs-native tools were needed to create the image in the first place. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta/conf')
0 files changed, 0 insertions, 0 deletions