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

Dave Reisner d at falconindy.com
Thu Nov 17 09:11:14 EST 2011


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.

> 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).

> 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.

> 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.

> +        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).

> +        if launch_interactive_shell; then
> +            echo "Attempting to mount '$root' ..."
> +            if ! mount ${opts} "$root" "$1"; then
> +                echo $'\n'"Unable to mount root device '$root'! (2 of 2)"$'\n'
> +                echo "mount ${opts} '$root' '$1'"$'\n'
> +                echo "You are being dropped to an emergency shell, typing ..."
> +                echo "    'exit 0' abruptly ends our adventure and reboots the machine."
> +                echo "    'exit 1' attempts to boot immediately -- '$1' MUST be mounted."

same here re: $1 v $root.

> +                if launch_interactive_shell; then
> +                    echo $'\n'":: Boot aborted, reboot in progress"

same here re: echo v printf.

> +                    sleep 2
> +                    reboot -f
> +                fi
> +            fi
> +        fi
> +        echo "Trying to continue (will fail unless '$root' is mounted) ..."
>      fi
>  }
>  
> -- 
> 1.7.7.3
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-projects/attachments/20111117/ad995cea/attachment.asc>


More information about the arch-projects mailing list