summaryrefslogtreecommitdiffstats
path: root/meta/recipes-extended
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:26:25 +0100
commit6d7bcd4df5722f3ccebbbf73361838cb0a5dc0ee (patch)
tree71567c46291b06559731d451466d7d6cfb59a279 /meta/recipes-extended
parent5d79814b0b9d4d0348dc36c0d9e003e4ba0bd367 (diff)
downloadpoky-6d7bcd4df5722f3ccebbbf73361838cb0a5dc0ee.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. (From OE-Core rev: 1e29d77d0d33ee216b43022439876863f0db39bb) Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta/recipes-extended')
0 files changed, 0 insertions, 0 deletions