Previously, fdisk was used by sending commands into its stdin, which is
not very robust (since it heavily relies on the interactive prompts
offered by fdisk as well as the default values it offers, which seem
prone to changing in future version).
It seems likely that in the past, fdisk was easier than parted since it
provides default values that make it easier to create adjacent
partitions, without precalculating all positions in the script. However
now that partitions are manually being aligned, all data must be
calculated anyway.
This commit changes the partition generation to use parted rather than
fdisk. For this, it rewrites various calculations and renames variables
to be easier to read as well. All values are now in number of bytes,
rather than mixing bytes and sectors.
This commit also makes makes sure that the boot partition and root
partition are always adjacent (previously the root partition was aligned
without also rounding the boot partition size, leaving some empty space
in between).
As a side effect of using parted, this also causes the "bootcode" part
of the MBR to be filled with some default x86 bootcode. This is totally
irrelevant for booting the Raspberry Pi, but it does prevent triggering
a bug in parted. When using parted to change the partition table (e.g.
when resizing the root partition on first boot by raspi-config's
init_resize.sh), the disk identifier would be changed due to this bug,
which would change the PARTUUID of all partitions. The init_resize.sh
script would work around this by updating the PARTUUID in e.g. fstab,
but that's fragile at best. This commit prevents the bug from
triggering and keeps the disk identifier the same.
See https://debbugs.gnu.org/35714 for details about this parted bug.
This commit fixes#284.
The example for enabling IR transmission in `/boot/config.txt` is still using the deprecated `lirc-rpi` overlay.
The documentation in `/boot/overlays/README` indicates that this overlay has been deprecated in favor of `gpio-ir` / `gpio-ir-tx`.
This updates the actual config.txt to suggest `gpio-ir` instead of `lirc-rpi`.
* Use `&&` instead of `;` in Docker pipeline
* In case of error, `&&` does not continue execution
* Silence shellcheck warning
* SC2086: Double quote to prevent globbing and word splitting.
* Ensure that the configuration file is an absolute path in Docker build
The specific problem is in commit 2ddd7c1, where the passed config file
(using the `-c` option) is now mounted inside the container using the
`--volume src:dest:opt` Docker option.
The problem is that Docker requires absolute paths for mounting single
files inside the container, otherwise it silently tries to mount a volume
name instead as an empty directory. Therefore the Docker build no longer
works with the following invocation forms (relative config-paths):
./build-docker.sh -c myconfig
/path/to/build-docker.sh -c myconfig # also doesn't work
This commit uses `realpath` (included in coreutils) in the Docker build
script to ensure that the passed configuration file is always an
absolute path before passing it to Docker.
Last commit made the script break on macOS.
From `man sed` (On Linux):
```
-E, -r, --regexp-extended
use extended regular expressions in the script (for portability use POSIX -E).
```
This reverts commit 1806504983.
In Buster, APT has built‐in support for HTTPS repos (since version 1.5).
The ca-certificates package is already included in the modified file, so
this commit shouldn’t break anything.
* bash variables in build-docker.sh are wrapped by curly brackets
* Ensure presence of config file while running build-docker.sh
* Do not assume that build-docker.sh is run from the repository root directory
* Mount config file in predictable location in docker container
Turning off IPv6 by aliasing `net-pf-10` to `off` does not work anymore.
Also, turning off IPv6 on system level breaks apps depending on IPv6
loopback or IPv6 link-local addresssing and creates issues in both
dual-stack and IPv6-only environments.
Signed-off-by: Ondřej Caletka <ondrej@caletka.cz>
Added a handy message to make it clear that compiling on a 64 bit OS is causing issues. After spending over an hour of troubleshooting think it should be made clearer as it'll affect quite a few users.
With the Qemu version shipped with Debian Stretch, the `man-db` package
being installed for Buster in the image triggers many of these errors:
qemu: Unsupported syscall: 383
This is a manifestation of the following bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891109
This is resolved in the current Qemu version shipped with Debian Buster.
