Patrick
August 11, 2021, 3:21pm
306
That has potential to generate a bad reputation.
For sure.
Implementing a host user clearnet is simple. (Similar to Whonix-Gateway user clearnet.) White listing VM traffic is a lot harder.
There’s a lot more todo.
https://forums.whonix.org/search?q=%23status_open_issue_todo%20%23component_whonix-host%20%20tag%3Acomponent_whonix-host
https://phabricator.whonix.org/project/view/26/
Not all has to be done but essentials seems to be EFI boot support, SecureBoot support, Anon Connection Wizard host support, an installer ISO that works for both EFI and non-EFI booting (⚓ T979 co-install grub-efi-amd64 and grub-pc by default on Whonix-Host ISO ).
tempest
August 26, 2021, 3:05am
307
maybe not? since whonix host will be using kvm, all that traffic should be owned by user “libvirt-qemu.” it’s not as perfect as filtering by vm name. but, it’s a start and narrows traffic down a little bit.
or, here’s another idea, what about filtering by source ip? for example, the whonix gateway in the kvm version has the local ip address on the host of 10.0.2.2. could this not effectively serve as a “virtual machine name” in implementation?
1 Like
Patrick
December 13, 2022, 1:11pm
309
3 posts were merged into an existing topic: Whonix’s Host naming
Patrick
February 25, 2023, 2:56pm
310
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 27, 2023, 4:42pm
312
1 Like
Patrick
April 5, 2023, 8:18am
313
Patrick
December 5, 2023, 4:37pm
314
For our dracut based Live ISO there was this dracut usability bug which made the ISO unbootable.
opened 10:39PM - 23 Feb 23 UTC
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:
adrelanos:master ← DanWin:master
opened 02:32PM - 02 Dec 23 UTC
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.