On Thu, Nov 17, 2011 at 3:24 AM, Thomas Bächler <thomas@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@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@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