fddbd11baa made it so the command executed
read `sh -c -- '"script" args*'`, the -- in this command is redundant as
the script name never starts with a dash and can never be interpreted as
an option or a flag.
The actually meaningful placement for -- here is after `$SUDO`, to make
sure `$SUDO` does not incorrectly treat `-c` as an option to itself, and
`$SHELL` cannot be interpreted as an option/flag in the extremely
unlikely event that it starts with a dash.
We depend on GNU-specific du switch `--apparent-size`. Busybox has this
implemented, but as `-b` instead.
Another part of the build system uses `cp --preserve=timestamps`. This
can be replaced by `rsync -t`, and rsync is already used through the
file.
Thanks to those changes, Serenity can be built on a Busybox system,
without GNU coreutils.
* `chmod -x` as it's for sourcing, not for executing
* Remove run line, for the same reason
* Rename it from .shell_include.sh to shell_include.sh, since e.g.
`rg` doesn't search in hidden files by default
No behavior change.
This patch adds the `find_executable()` function that will hopefully
find executables in a distro-agnostic way and that is (hopefully as
well) easily upgradable.
The function uses some bash functionalities. So, we now require bash
for each script that includes `.shell_include.sh`.
We previously depended on sudo's specific -E flag to keep all the
environment variables when performing a privilege escalation. We now
incorporate the -E flag into the $SUDO variable, allowing for other
privilege escalation binaries (such as doas) to be used (as long as
they preserve the current environment variables).
Back when adding support for `pls` as a `sudo` replacement,
`build-image-qemu` dynamically set the `SUDO` variable depending on what
system it was running on and used the contents of that variable to call
the correct elevation utility.
During recent changes to the elevation error message, that usage of the
variable was replicated across all of our scripts, but without also
replicating the logic to set that variable in the first place.
Add back the variable setting logic to all the other scripts to keep
them from running into unset variables.
Before, and that was the cause of many confusion in #build-problems
on Discord, the Meta/build-image-*.sh scripts would error out with
the message "this script needs to run as root" while the actual error
was unrelated.
As of ~April 2021 the Meta/build-image-grub.sh script no longer works
for me (on Fedora 34) and fails with the following error:
/usr/sbin/grub2-install: warning: ../grub-core/partmap/msdos.c:403:
your core.img is unusually large. It won't fit in the embedding
area.
/usr/sbin/grub2-install: warning: Embedding is not possible. GRUB
can only be installed in this setup by using blocklists. However,
blocklists are UNRELIABLE and their use is discouraged..
/usr/sbin/grub2-install: error: will not proceed with blocklists.
Changing the size of the boot partition from 32 kiB to 1 MiB (2048
sectors) fixes the issue. This is also described in the following Ubuntu
grub2 bug (as well as 40 duplicates!) from 2012, which suggests the same
fix: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1059827
The Arch Linux wiki also uses 1 MiB in their BIOS/MBR examples for
parted: https://wiki.archlinux.org/title/Parted
I'm not sure why this suddenly stopped working, however I was able to
boot with an image created with this change applied.
In the GNU coreutils version of chown, ":" is a valid argument
(the command will result in a no-op), but POSIX chown does not
consider that valid.
If the user who ran build-image-*.sh was root, SUDO_UID and SUDO_GID
would not be set and, if the version of chown installed on the system
did not allow passing just a ":" as argument, the script would fail.
Let's default the value of SUDO_UID and SUDO_GID to 0 just in case.
