Re: [dm-devel] [PATCH v12] dm: add support to directly boot to a mapped device

From: Zdenek Kabelac
Date: Wed Jun 05 2019 - 04:40:02 EST

Dne 04. 06. 19 v 21:35 Stephen Boyd napsal(a):
Quoting Helen Koike (2019-06-04 10:38:59)
On 6/3/19 8:02 PM, Stephen Boyd wrote:

I'm trying to boot a mainline linux kernel on a chromeos device with dm
verity and a USB stick but it's not working for me even with this patch.
I've had to hack around two problems:

1) rootwait isn't considered

2) verity doesn't seem to accept UUID for <hash_dev> or <dev>

For the first problem, it happens every boot for me because I'm trying
to boot off of a USB stick and it's behind a hub that takes a few
seconds to enumerate. If I hack up the code to call dm_init_init() after
the 'rootdelay' cmdline parameter is used then I can make this work. It
would be much nicer if the whole mechanism didn't use a late initcall
though. If it used a hook from prepare_namespace() and then looped
waiting for devices to create when rootwait was specified it would work.

The patch was implemented with late initcall partially to be contained
in drivers/md/*, but to support rootwait, adding a hook from
prepare_namespace seems the way to go indeed.

Alright, great.

The second problem is that in chromeos we have the bootloader fill out
the UUID of the kernel partition (%U) and then we have another parameter
that indicates the offset from that kernel partition to add to the
kernel partition (typically 1, i.e. PARTNROFF=1) to find the root
filesystem partition. The way verity seems to work here is that we need
to specify a path like /dev/sda3 or the major:minor number of the device


As not a direct dm developer - isn't this going a bit too far ? -
This way you will need to soon move halve of the userspace functionality into kernel space.

IMHO would be way more progressive to start using initramdisk and let userspace resolve all the issue.

Clearly once you start to wait for some 'devices' to appear - then you will need to way for CORRECT device as well - since sda,sdb... goes in random order, so you would need to parse disk headers and so on.

What you are effectively doing at this moment is you are shifting/ballooning 'ramdisk' code into kernel image - just to be named a kernel.

So why it is so big deal to start to use ramdisk on ChromeOS?
That would have solved most of problems you have or you will have instantly.