[arch-projects] [PATCH] init_functions: rework `default_mount_handler` -- assume less/succeed more

C Anthony Risinger anthony at xtfx.me
Thu Nov 17 13:01:52 EST 2011

On Thu, Nov 17, 2011 at 3:24 AM, Thomas Bächler <thomas at archlinux.org> wrote:
> Am 17.11.2011 07:20, schrieb C Anthony Risinger:
>> +    if ! mount ${opts} "$root" "$1"; then
>> +        if [ ! -b "$root" ]; then
>> +            err "Unable to determine major/minor number of root device '$root'."
>> +        fi
> This error message no longer makes sense. Replace it by something
> understandable.

sure, how about (as a msg instead of err):

"Is root device a /dev/<blockdev>? Unable to determine it's major/minor number."

... or...

"Root device does not exist -- not a block device, or unable to
locate/determine it's major/minor number."

... something like that?

On Thu, Nov 17, 2011 at 8:11 AM, Dave Reisner <d at falconindy.com> wrote:
> On Thu, Nov 17, 2011 at 12:20:54AM -0600, C Anthony Risinger wrote:
>> mostly shuffling, save:
>> 1) immediate mount attempt: assume hooks have allowed for this
>> $root is opaque, attempts to dechiper it's meaning are out of scope.
> I have no idea what this means.

i meant that to the handler, $root is an arbitrary string (ie, "black
box" of sorts) -- it has no way to really understand what it could
mean.  IMO, the `handler` should only be concerned with the high-level
flow, not attempt to make concrete decisions.

in fact, i would take this one step further by introducing a
`mount_exec` variable/identifier pointing to the concrete function
responsible for "mounting the root" ... this would allow the
`default_mount_handler` to be used in *any* concrete `mount_handler`
... one would only change `mount_handler` if they wanted to change the
questions asked, or the options presented on failure -- i'll save that
for another day :-)

>> 2) first mount fail: print details, offer to mount(0) or boot(1)
>> 3) second mount fail: print details, offer to reboot(0) or boot(1)
> Why twice? Seems arbitrary. Why not just run a while loop?
> while ! mount $opts; do
>  if ! launch_interactive_shell; then
>    break
>  fi
> done
> Let the user figure out when to quit (reboot).

ok, i did consider (and prefer) that as well -- i chose twice to
maintain the "now in recover/emergency" of the original.  its not
currently possible for the interactive shell to change anything though
(the $root variable/etc), so i don't know how useful it will be (maybe
introduce an fd the user can echo variables into??).

i'll explore this a bit for v2.

>> this work allows the default handler to be used in nearly all cases mount
>> itself could handle -- work prompted by needless failing of a virtio/9p2000.L
>> based passthru "device" as $root.
> Why not just write a mount hook that covers this one use case? plan 9
> isn't exactly common.

true, but its not even failing -- if i just type `exit` the VM boots
fine.  there isn't much need for a hook -- it's a bug to me that the
`default_mount_handler` is failing because it tries to know more than

9p2000.L passthru ("VirtFS") is a pretty hot topic in the
virtualization world, and most of what i do with Arch is related to
that -- im trying to make it more virt friendly.  this method can
achieve better perf than raw-block by taking advantage of the host
page cache (my systemd VMs boot cold-to-100% in less than 2-3
seconds), it's significantly less management overhead than raw-block,
and allows dead simple guest sharing via bind-mounts and several other
advantages -- i fully expect it to be wildly popular :-)

also see: http://mailman.archlinux.org/pipermail/arch-general/2011-July/021195.html

... i'm basically just fixing that permanently

>> Signed-off-by: C Anthony Risinger <anthony at xtfx.me>
>> ---
>>  init_functions |   37 ++++++++++++++++++++++++++-----------
>>  1 files changed, 26 insertions(+), 11 deletions(-)
>> diff --git a/init_functions b/init_functions
>> index 42e6249..d0bd042 100644
>> --- a/init_functions
>> +++ b/init_functions
>> @@ -197,18 +197,33 @@ resolve_device() {
>>  }
>>  default_mount_handler() {
>> -    if [ ! -b "$root" ]; then
>> -        err "Unable to determine major/minor number of root device '$root'."
>> -        echo "You are being dropped to a recovery shell"
>> -        echo "    Type 'exit' to try and continue booting"
>> -        launch_interactive_shell
>> -        msg "Trying to continue (this will most likely fail) ..."
>> -    fi
>> +    local opts="${rootfstype:+-t $rootfstype} -o ${rwopt:-ro}${rootflags:+,$rootflags}"
>> -    if ! mount ${fstype:+-t $fstype} -o ${rwopt:-ro}${rootflags:+,$rootflags} "$root" "$1"; then
>> -        echo "You are now being dropped into an emergency shell."
>> -        launch_interactive_shell
>> -        msg "Trying to continue (this will most likely fail) ..."
>> +    if ! mount ${opts} "$root" "$1"; then
>> +        if [ ! -b "$root" ]; then
>> +            err "Unable to determine major/minor number of root device '$root'."
>> +        fi
>> +        echo $'\n'"Unable to mount root device '$root'! (1 of 2)"$'\n'
> I'd rather use printf than embed shell expanded newlines.

hmm, i agree, and had used printf first, but for some reason i thought
i *had* to use minimum of 2 args to `printf`, not the case ...

will update this.

>> +        echo "mount ${opts} '$root' '$1'"$'\n'
>> +        echo "You are being dropped to an recovery shell, typing ..."
>> +        echo "    'exit 0' attempts to boot after first retrying the failed mount."
>> +        echo "    'exit 1' attempts to boot immediately -- '$1' MUST be mounted."
> Why $1 and not $root? The latter has a lot more meaning to the user. You
> mount block devices, not directories (ignoring bind mounts).

i chose $1 because $root is already shown in the mount command (well,
so is $1) ... but $1 is less known to user.  everybody knows *what*
they use as root, but far less people know *where* it needs to be
mounted during initramfs (impl detail) ...

... is there value in that?  $root can get huge too ... i'd prefer to
write both but i didn't want to be too verbose.  maybe reword to "$1
must be a mountpoint", or similar?


C Anthony

More information about the arch-projects mailing list