[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
`mount`.
<excess>
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 :-)
</excess>
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