Whonix-Host Operating System (OS) ISO

Patrick · December 8, 2022, 4:22pm

Patrick · December 13, 2022, 1:11pm

3 posts were merged into an existing topic: Whonix’s Host naming

Patrick · February 25, 2023, 2:56pm

Having a hybrid ISO for USB / DVD that supports BIOS legacy boot, EFI boot and SecureBoot is a difficult task.

Hence I am now investigating porting Kicksecure / Whonix’s build script (derivative-maker) to Debian’s live-build which can do all of the above.

Patrick · February 25, 2023, 2:58pm

Patrick · February 27, 2023, 4:42pm

live-boot create “normal”, non-live fully persistent raw disk images?

Patrick · April 5, 2023, 8:18am

A post was split to a new topic: port Whonix to Fedora as base operating system

Patrick · December 5, 2023, 4:37pm

For our dracut based Live ISO there was this dracut usability bug which made the ISO unbootable.

github.com/dracutdevs/dracut

New 90overlayfs module does not set up the overlay in three cases where it happened before (breaks Fedora/RHEL installer image boot)

opened 10:39PM - 23 Feb 23 UTC

AdamWill

bug dmsquash-live regression

**Describe the bug** In dracut 058/059, with commit https://github.com/dracutde…vs/dracut/commit/8caaad4fc2d75982eb87f5ebc72a4c276986f756 and follow-up https://github.com/dracutdevs/dracut/commit/40dd5c90e0efcb9ebaa9abb42a38c7316e9706bd , overlayfs setup was moved from being done in-line at the end of `dmsquash-live-root.sh` to being part of a separate module. There were four codepaths in which overlayfs setup was reached in `dmsquash-live-root.sh`, but with the move to a module, only one of those paths now results in overlayfs setup happening. On the other three paths, it no longer happens, and boot fails. **Distribution used** Fedora 38 and Rawhide. **Dracut version** 058 and 059. **Init system** systemd. **To Reproduce** Boot a Fedora installer image built with dracut 058/059 without the offending commits reverted. They were reverted in https://koji.fedoraproject.org/koji/buildinfo?buildID=2157455 and we caught this before it reached a nightly compose, so you would have to build your own image using the older dracut-059-1 build; the images built by openQA (which caught this bug) have been garbage-collected now. Affected images get stuck in a loop, showing the error "mount: /sysroot: special device LiveOS_rootfs does not exist." **Expected behavior** The image should boot normally. **Additional context** I did a detailed root cause of the problem in [the downstream bug](https://bugzilla.redhat.com/show_bug.cgi?id=2172269). Basically, if you look at `dmsquash-live-root.sh`, the overlayfs setup previously happened near the end of the file, any time the variable `$overlayfs` was a non-zero-length string. There were four paths on which that happened: one where it was set to "yes" (when `rd.live.overlay.overlayfs` is on the cmdline), and three where it was set to "required" (two inside the block that starts `if [ -z "$setup" -a -n "$devspec" -a -n "$pathspec" -a -n "$overlay" ]; then`, and one in the block that starts `if [ -e /run/initramfs/live/${live_dir}/${squash_image} ]; then`). When the overlayfs setup was moved to a module, only the first of these paths was respected: the new module only actually does the overlayfs setup if the cmdline parameter set. In all other cases it exits after doing nothing. So on those three other paths, the overlayfs is not set up and boot will likely fail. Fedora's installer images go down the squashfs path, I don't know in what situations the other two paths are hit. For now in Fedora we have reverted the relevant commits. @lnykryn [suggested](https://bugzilla.redhat.com/show_bug.cgi?id=2172269#c5) having `dmsquash-live-root.sh` do `echo "rd.live.overlay.overlayfs=1" > /etc/cmdline.d/dracut-need-overlay.conf` on the affected paths, which...I guess could work, but seems very hacky. I was kinda assuming there must be a better way to do this, some canonical way for such a script to signal to a module that its action is required?

This long standing development blocker might now be fixed:

github.com/adrelanos/grml-debootstraptest

Make dracut iso image bottable

adrelanos:master ← DanWin:master

opened 02:32PM - 02 Dec 23 UTC

DanWin

+3 -2

The `dmsquash-live` module needs to be explicitly added for the live system to b…e bootable. However, it seems that the overlayfs is not created properly by this module, thus the generated `sysroot.mount` unit is failing. As a workaround, adding the `rd.live.overlay.overlayfs=1` cmdline option seems to do the trick. I could successfully boot the image with these changes.

Patrick · December 9, 2023, 1:41pm

documentation on grub-mkrescue:

Patrick · December 9, 2023, 2:49pm

Major progress has been made. A script that can convert a raw image to an ISO image has been developed.

https://github.com/Kicksecure/grml-debootstraptest/blob/master/image-to-iso

Patrick · December 9, 2023, 2:49pm

https://www.reddit.com/r/osdev/comments/18ef3bq/can_a_bootable_linux_iso_be_created_or_converted/

Mycobee · December 9, 2023, 5:53pm

Huge news

Patrick · December 16, 2023, 11:23am

The problem is now that Secure Boot is unsupported. This is because the ISO doesn’t integrate with shim.

And installing shim inside a Debian bootable ISO is undocumented and difficult for me.

grub feature request written just now:
grub-rescue ISO Secure Boot / shim support

That feature request could take a long time if it ever materializes.

It will be possible without that feature request being implemented too but then additional options have to be passed to grub-rescue (or mkisofs) or other tools have to be used (manual use of grub-mkimage). The code / options to do this can probably be extracted from Debian’s live-build but that’s something that I wanted to avoid because that is very difficult for me.

Patrick · December 16, 2023, 6:22pm

github.com/rhboot/shim

add option to check if shim is in use - How to check if the system is using shim or not?

opened 06:21PM - 16 Dec 23 UTC

adrelanos

I've created an ISO with shim which really wasn't simple at all. Now I am testin…g it with QEMU. Since shim as far as I know and please correct me if I am wrong doesn't produce any visual output, no log messages, hands over control to grub and is then "gone" it seems totally invisible. How can I test if shim has booted first or if grub was booted? Why do I want to know that? For the purpose of developing a QEMU based unit test that checks if the boot sequence (shim first) is correct.

Patrick · December 25, 2023, 1:15pm

Can mkosi replace Kickkstart / Calamares?

Patrick · December 28, 2023, 6:22am

Patrick · January 3, 2024, 10:41am

Debian Live:

cat /etc/fstab

overlay / overlay rw 0 0
tmpfs /tmp tmpfs nosuid,nodev 0 0

Patrick · January 3, 2024, 10:42am

purism calamares configuration:

Patrick · January 3, 2024, 10:48am

github.com/calamares/calamares

Rootless Calamares, native Wayland support without Xwayland

opened 10:48AM - 03 Jan 24 UTC

adrelanos

If calamares is started without root rights, it shows: > the installer is not… running with administrative rights Quote Jan 4, 2018 https://calamares.io/calamares-3.2-plan-revised/ > Rootless Calamares (e.g. not running as root) has not been worked on at all; at the same time, KPMCore has done a great deal of work to be able to run rootless, so progress has been made regardless. Accessibility has been addressed through a patch to Qt, which is unfortunately stalled in Qt’s bug tracker. So rootlessness for accessibility purposes is still desired. I don’t want to make any promises for rootless functionality before 3.2.0. Quote Aug 25, 2020 https://calamares.io/calamares-summer/ > Tidying up partitioning remains a big issue, as does rootless operation (which is also necessary for better accessibility). Also also a short mention here: https://github.com/calamares/calamares/issues/2024#issuecomment-1193007820 Other than that, I haven't found any issue for it. I suppose Rootless Calamares hasn't been completed yet. Hope you're OK leaving this ticket open for reference. I also presume that this is the precondition for Calamares native Wayland support (without Xwayland).

Patrick · January 3, 2024, 11:00am

github.com/calamares/calamares

calamares breaks when using libpam-tmpdir

opened 10:59AM - 03 Jan 24 UTC

adrelanos

Hi, maintainer of Kicksecure (a derivative of Debian) here. **Describe the bu…g** libpam-tmpdir sets TEMP, TEMPDIR, TMP, TMPDIR environment variables to folder `/tmp/user/1000`. If calamares is invoked with `sudo --set-home`, `pkexec` these environment variables are inherited by the chroot. This breaks any packages that run any (postinst) scripts that result in attempting to write temporary folders using one of these environment variables. For example, this breaks `dracut`. Many OS image build tools break when libpam-tmpdir is installed. Here are more references linked: * https://github.com/Kicksecure/security-misc/pull/147 But as far as I understand this is considered a bug in the build too, not in libpam-tmpdir. **To Reproduce** sudo apt install libpam-tmpdir **Expected behavior** These environment variables such not be passed to the chroot or in other words unset inside the chroot. ``` unset TEMP unset TEMPDIR unset TMP unset TMPDIR ``` A different solution might be running inside the chroot something like: ``` mkdir /tmp/user/1000 chown user:user /tmp/user/1000 ```

Patrick · January 3, 2024, 3:27pm

grub-pc: Add option to change keyboard layout

github.com/calamares/calamares

Encryption does not work well with non-QWERTY keyboards

opened 09:46AM - 27 Jul 19 UTC

apt-ghetto

bug: not-really N encryption

**Describe the bug** When you choose to encrypt the disk, the passphrase is sav…ed with the current keyboard layout (changed by the user). After installation, the keyboard layout to unlock the container is the american layout, which is not necessarily the same as the expected layout by the user. So the entered passphrase may differ from the expected passphrase. **To Reproduce** Steps to reproduce the behaviour: 01. Start the installer (Lubuntu 19.10 is used in this example, EFI mode, 64-bit, QEMU/KVM, 12 GiB qcow2) 02. Change the language to "Deutsch" 03. Click "Weiter" 04. Select "Region" => "Europe", select "Zeitzone" => "Zurich" 05. Click "Weiter" 06. Select "German (Switzerland)" and "Default" as keyboard layout 07. Click "Weiter" 08. Select "Festplatte löschen" 09. Select "Verschlüssele System" 10. Enter "Passwort" => "ragazza", enter "Passwort wiederholen" => "ragazza" 11. Click "Weiter" 12. Setup the user and advance to install 13. Reboot after installation 14. Type in the passphrase as if you'd use a swiss-german keyboard layout => "ragazza", but is "ragayya". **Expected behaviour** Entering the passphrase, Grub unlocks the container. **Current behaviour** The user is dropped into a Grub or Grub rescue shell. **Possible solution** Add a third key slot with the current passphrase converted into the "american layout" passphrase. This allows to unlock the container with the american keyboard layout, with the keyfile, and with the user keyboard layout.