raspi
March 19, 2022, 10:42am
191
Am i right, to build image for RPi3B i need to do next steps:
sudo apt install git time curl apt-cacher-ng lsb-release fakeroot dpkg-dev fasttrack-archive-keyring
wget https://whonix.org/derivative.asc
gpg --import derivative.asc
git clone --depth=1 --branch 16.0.4.2-developers-only --jobs=4 --recurse-submodules --shallow-submodules https://gitlab.com/whonix/Whonix.git
cd Whonix
git verify-tag 16.0.4.2-developers-only
git checkout --recurse-submodules -b 16.0.4.2-developers-only
git status
sudo ./whonix_build --target raw --flavor whonix-gateway-rpi --build --arch arm64 --kernel linux-image-arm64 --headers linux-headers-arm64 --vmsize 14G
And then i burn that raw in my sd card?
raspi
March 19, 2022, 12:40pm
193
Okay, I’ve written the image to the SD card using: dd if=Whonix.raw of=/dev/sdX
raspi
March 20, 2022, 9:44am
194
Raspbian runs stably under the same conditions. My 16GB SD card has the following sections:
unnalocated 2.00MiB
/dev/sda1 14GiB (used 2.10 GiB), flags: boot
unnalocated 875.00MiB
Something is wrong, where is the FAT32 first-stage bootloader?https://forums.whonix.org/t/whonix-for-arm64-raspberry-pi-rpi/1788/150?u=raspi
Only option:Generic Bug Reproduction
raspi
March 21, 2022, 11:51am
196
The system assembled using your own instructions does not contain the necessary to run first-stage bootloader. As you know, the initialization process of a regular ARM64 processor is different from the RPi… Nothing needs to be debugged, it’s just that at the moment your instructions for assembling the system are out of date and require serious improvement in terms of /boothttps://github.com/Whonix/Whonix/blob/master/build-steps.d/2375_build_rpi_fs
raspi
March 21, 2022, 12:33pm
197
Indeed.
That’s why I posted this link:
RPI support would need to be added here:https://github.com/Whonix/Whonix/blob/master/build-steps.d/2375_build-arm64-fs
It will either be contributed or won’t be happening. I guess chances of this being contributed are slim as there’s no progress for a long time.
raspi
March 21, 2022, 1:11pm
199
1 Like
@raspi I was able to build with zero errors. Yay.
But It can’t boot…
Aw.,…
Edit to my last post:
Patrick
October 25, 2023, 2:33pm
206
grml-debootstrap now merged arm64 build support.
Patrick
December 8, 2023, 9:41am
207
grml-debootstrap bug "VM build failing if combining --vmefi with --arch arm64 which maybe can be worked around in derivative-maker.
opened 09:34AM - 08 Dec 23 UTC
From a user perspective it is valid to combine `--vmefi` with `--arch arm64`.
…
```
+ mkfs.fat -n EFI /dev/mapper/loop0p1
mkfs.fat 4.2 (2021-01-31)
+ MKFS_OPTS=' -F -L LINUX'
+ einfo 'Running mkfs.ext4 -F -L LINUX on /dev/mapper/loop0p3p3'
+ einfon 'Running mkfs.ext4 -F -L LINUX on /dev/mapper/loop0p3p3\n'
+ '[' '' '!=' yes ']'
+ '[' einfon = ebegin ']'
+ printf ' %s*%s Running mkfs.ext4 -F -L LINUX on /dev/mapper/loop0p3p3\n' 'e[32;01m' 'e[0m'
e[32;01m*e[0m Running mkfs.ext4 -F -L LINUX on /dev/mapper/loop0p3p3
+ LAST_E_CMD=einfon
+ return 0
+ return 0
+ mkfs.ext4 -F -L LINUX /dev/mapper/loop0p3p3
mke2fs 1.47.0 (5-Feb-2023)
The file /dev/mapper/loop0p3p3 does not exist and no size was specified.
```
In that case an unexpected code path will be used. `if` is `if [ -n "$VMEFI" ]; then` which means that code path will be used instead of the `if [ "$ARCH" = 'arm64' ]; then` code path.
It's awesome that grml-debootstrap recently learned VMEFI and ARM64 support. Now we can iterate based on that.
I don't think this should be solved on the command line parsing level, i.e. unset VMEFI if using `--arch amd64`? Seems better to refactor, simplify all the related code. But that seems a different request than fixing this. Therefore created a separate issue for that:
* https://github.com/grml/grml-debootstrap/issues/258
Patrick
December 8, 2023, 9:41am
208
related grml-debootstrap arm64 issues:
opened 11:51AM - 20 Oct 23 UTC
```
if [ -n "$VMEFI" ]; then
parted -s "${TARGET}" 'mklabel gpt'
pa… rted -s "${TARGET}" 'mkpart ESP fat32 1MiB 101MiB'
parted -s "${TARGET}" 'set 1 boot on'
parted -s "${TARGET}" 'mkpart bios_grub 101MiB 102MiB'
parted -s "${TARGET}" 'set 2 bios_grub on'
parted -s "${TARGET}" 'mkpart primary ext4 102MiB 100%'
```
Could this lead to issues over time?
Too small? As per:
https://unix.stackexchange.com/questions/623304/size-of-efi-system-partition-esp
calamares [uses](https://github.com/calamares/calamares/blob/calamares/src/modules/partition/partition.conf) `300M`.
[Roderick W. Smith](https://www.rodsbooks.com/linux-uefi/) ([rEFIt](http://refit.sourceforge.net/) boot manager developer) recommends:
> , I recommend creating an ESP that's 550MiB in size.
That's why I would go with.
Quote https://www.rodsbooks.com/efi-bootloaders/principles.html
> Although the EFI specification is mute on the subject of the ESP's size, most OSes make it fairly small—Macs ship with 200MiB ESPs, and the Windows 7 installer creates one of just 100MiB. (That value has been raised to a bit over 200MiB on newer versions of Windows.) Some users, however, have found that some EFIs have bugs that cause problems with FAT32 ESPs that are under 512MiB (537MB) in size. One very common problem is files that can't be read by the EFI. The Linux mkdosfs command defaults to using FAT16 for partitions of up to 520MiB (546MB). Therefore, adding a margin of safety to protect against MiB/MB confusion and rounding errors, I recommend creating an ESP that's at least 550MiB in size. If you must use a smaller ESP and if you encounter mysterious problems, try converting it to FAT16; most ESPs will work fine with this, and it may eliminate your problems. On the other hand, this may cause the Windows installer to fail should you need to install this OS.
https://www.rodsbooks.com/gdisk/advice.html#ESP_Sizing with more detailed reasoning:
> 550 MiB.
I'd like to use the grml-debootstrap created raw image as a base to create an ISO from it so it can be written to USB or DVD.
(Using grml-debootstrap, grml-live or other tools.) (https://github.com/grml/grml-debootstrap/issues/215)
Does that change the size requirements?
opened 09:37AM - 08 Dec 23 UTC
The following code should be refactored, simplified.
```
if [ -n "$VMFILE"… ]; then
qemu-img create -f raw "${TARGET}" "${VMSIZE}"
fi
if [ -n "$VMEFI" ]; then
parted -s "${TARGET}" 'mklabel gpt'
parted -s "${TARGET}" 'mkpart ESP fat32 1MiB 101MiB'
parted -s "${TARGET}" 'set 1 boot on'
parted -s "${TARGET}" 'mkpart bios_grub 101MiB 102MiB'
parted -s "${TARGET}" 'set 2 bios_grub on'
parted -s "${TARGET}" 'mkpart primary ext4 102MiB 100%'
else
# arm64 support largely only exists for GPT
if [ "$ARCH" = 'arm64' ]; then
einfo "Setting up GPT partitions for arm64"
parted -s "${TARGET}" 'mklabel gpt'
parted -s "${TARGET}" 'mkpart EFI fat32 1MiB 10MiB'
parted -s "${TARGET}" 'set 1 boot on'
parted -s "${TARGET}" 'mkpart LINUX ext4 10MiB 100%'
else
parted -s "${TARGET}" 'mklabel msdos'
if [ "$FIXED_DISK_IDENTIFIERS" = "yes" ] ; then
einfo "Adjusting disk signature to a fixed (non-random) value"
MBRTMPFILE=$(mktemp)
dd if="${TARGET}" of="${MBRTMPFILE}" bs=512 count=1
echo -en "\\x41\\x41\\x41\\x41" | dd of="${MBRTMPFILE}" conv=notrunc seek=440 bs=1
dd if="${MBRTMPFILE}" of="${TARGET}" conv=notrunc
eend $?
fi
parted -s "${TARGET}" 'mkpart primary ext4 4MiB 100%'
parted -s "${TARGET}" 'set 1 boot on'
fi
fi
```
Maybe the VMEFI and ARM64 code paths could be merged.
* 1) Use the same labels. `EFI` and `ESP` are currently labels.
* 2) Use the same sizes.
* `1MiB 101MiB` (or the larger sizes discussed in #221)
* Or use variables if you prefer. (I prefer simpler code for something simple as this over complex code that saves a bit of disk space.)
* 3) Use `'mkpart bios_grub 101MiB 102MiB'` and `'set 2 bios_grub on'` also for `--arm64` if that works. Not sure if there are any ARM64 legacy BIOS booting systems,
but all of these changes are for code simplification purposes so this code and related code that comes later can be simplified.
Also maybe the grub installation code can be refactored but perhaps that can be discussed separately.
Why? This would fix or simplify the following issues:
* https://github.com/grml/grml-debootstrap/issues/257
* #221
Patrick
December 22, 2023, 6:14pm
209
VM --arch arm64 builds might now be functional.
It might now even be possible to cross-build arm64 images while the build machine is running Intel / amd64.
I am writing “might” because I only superficially tested that is booting using QEMU and I am not using any ARM64 hardware myself. Since there is no dedicated ARM64 maintainer, this might break in the future. This is because the amount of architectures, platforms I can support is limited by being only 1 person.
While I added a (Kicksecure) CI test for arm64 builds, which will hopefully prevent the build process from breaking again and going unnoticed for a long time, the boot process might break in the future because we don’t have CI testing yet that does not only building but actual booting and testing.
related: Continuous Integration (CI) Whonix Testing - Automated Test Suite