For example, when calling arch-chroot on a dir without a /proc:
# arch-chroot badroot
mount: badroot/proc: mount point does not exist.
==> ERROR: failed to setup chroot badroot
umount: bad usage
Try 'umount --help' for more information.
I'm too lazy to maintain an uninstall target for something that should
be distributed as a package, and the dist target can just be replaced
by git clones. No more tarballs!
Similar to 232784ec, this logic has been around forever with no
discernible value. Retire the flag from the code and documentation, but
leave it behind as a vestige in order to not break scripts found in the
wild.
This essentially reverts 2ace610c. I'm forgetting the historical context
of what lead to that commit (but note that it predates the first tag).
The only thing I can think of is that genfstab doesn't produce the
correct output when root isn't a mountpoint, but that's a crap reason --
you won't need an fstab when you're calling pacstrap on a directory and
genfstab already complains when the provided root isn't a mountpoint.
This is probably going to lead to somewhere in /run, but we may as well
support a symlink to anywhere, as long as it isn't a nested symlink.
ref: https://bugs.archlinux.org/task/43540
function execution halts entirely on a invalid base, so we never
actually get to our 'return 1'. I'm not sure how our expected failures
ever actually worked, but it's quite plain to see that:
$ a=$(( 2#3 )); echo hi
Never echos "hi". Use a subshell in valid_number_of_base so that we can
properly "trap" execution, and return a meaningful result.
This prevents some odd interactions with the EXIT trap, and our last
command's status is seemingly not preserved for the script's real exit.
Add a BASH override to the Makefile as well, as it might be useful for
debugging or testing against other versions of bash.
Unless I'm mistaken, newroot is assigned later, and never referenced in between:
```
(( $# )) || die "No root directory specified"
newroot=$1; shift
```
The existence of /sys/firmware/efi/efivars only indicates that we've
booted the kernel in EFI mode. It does not guarantee that the same
kernel has support for efivarfs. Since this isn't critical, don't fail
the whole api mount.
