- User Since
- Aug 25 2017, 12:23 PM (103 w, 3 d)
Nov 19 2018
Possible. However, sharing as much code as sensible inside whonix-xfce-desktop-config and use whonix-(gw|ws)-kde-desktop-conf only where required would be preferably.
Nov 18 2018
Seems like a lot effort just to implement this.
Nov 17 2018
I guess the only solution would be two separate packages of the desktop config for the gateway and the workstation. Maybe also some kind of postinst script which detects when it is run on the gateway and changes the xml. However, such a starter is also present on a default Xfce installation without a browser so it is more or less default behaviour.
Jul 17 2018
I opened a small pull request for grub-live. Also the alternative version ro-mode-init lives at https://github.com/Algernon-01/ro-mode-init
Jan 12 2018
It will still depend on the user looking out for this indicator. Easiest is probably something like notify-send with a high duration time so a user will see it and click it away. Could be made part of whonixcheck or maybe use whonixcheck itself instead.
Jan 6 2018
ip=frommedia needs to be added to the kernel command line otherwise the network interfaces won't be configured in live mode. I uploaded the changes to the repo.
Dec 17 2017
Sure, I'll add instructions for the installation and some general remarks around live mode to the Whonix live wiki entry.
Dec 12 2017
Hmm, odd it did not work for you. I tested it with the whonix build script and also the upgrade from 13 to 14 with the local packages repo. Both produced the correct GRUB menu with all options.
What did you do, just copying 11_linux to /etc/grub.d/ and running update-grub I guess?
Dec 10 2017
Made the file somewhat smaller:
Dec 9 2017
Changes for initramfs-tools based live system:
Dec 4 2017
Most of them don't seem to interact with the normal boot process, right?
Dec 3 2017
Packages would be: live-boot, live-config-systemd, live-config-initramfs-tools, live-tools.
I'm wondering if then there really needs to be an extra package for the other files. Currently only the apparmor config for the new home and alias as well as the grub config file would be in there. I think the apparmor related edits could also be merged with the files in the apparmor-profile-anondist. There are some packages for grub but they all have a quite specific name. So either make a dedicated grub-live package or make the live patch package as before or merge the grub config file somewhere else.
Dec 2 2017
As stated here: https://forums.whonix.org/t/replacing-initramfs-tools-with-dracut-for-live-systems/4487
there is still option 5 if you feel uncomfortable with dracut in general.
A "normal" live system with overlayfs should be possible without patches. We would mostly need to pull in some debian live packages.
Copying the whole filesystem to RAM would not work without patches. Of course there is no possibility to use device mapper though maybe most end users won't care about that.
Some minor edits to the grub config file and apparmor stuff would be required.
Nov 30 2017
I changed the patches so the dracut version from stretch is now used and therefore no apt pinning and changes to the sources.list is required.
It also seems like the stretch version, in contrast to same version from upstream, can use overlayfs since the debian package maintainer added some (undocumented) parameters.
Appending "rootovl" to the kernel commandline and using root=UUID=... (so without the "live:") will mount an overlayfs filesystem over / . So not too much loss compared to the version in testing.
Nov 20 2017
Attached is the more or less final patch with only minor changes mostly related to apparmor profiles.
The bindp package was also missing for i386, this is required when upgrading from 13 to 14 and reinstalling non-qubes-whonix-workstation. Therefore the architecture in the control file was changed from "any" to "all. I'll add the new instructions to the wiki and submit a pull request.
A minor issue might be the swap file creator. At the moment it runs at each boot, creates a new swap file and shreds it at shutdown. This takes of course some seconds more. The other option would be to keep the old swap-file-generator but this will always occupy 512MB RAM more when you boot the live system which could be spend for more useful things. Both cases are not optimal but I don't see any other options.
Nov 13 2017
Just figured out Whonix 13 is still i386 and I only tested builds for amd64 up to now. Therefore I also couldn't make any tests upgrading from 13 to 14.
But I was wondering if upgrading Whonix 13 will be supported or work at all.
Reading this :
Nov 11 2017
I switched to config-package-dev instead of forking so no worries.
Next I'm going to try an update from Whonix 13 to 14 and see if something breaks.
I guess the official Whonix repo will be used when users would upgrade to the live version.
From looking at the aptrepo_local which gets created during building it seems to be more or less the same as the online repo? So I could use the local repo for the update tests or is there anything else to look out for?
Nov 8 2017
I'm currently trying to add a custom dracut build to the whonix temporary repository.
I cloned the dracut repository at https://anonscm.debian.org/gitweb/?p=collab-maint/dracut.git and added the changes we need for the live systems.
Then added the folder to the packages directory of the whonix source, renamed it to dracut-whonix and also changed the control file so that packages with the name dracut-whonix-* are created.
In 1200_create-debian-packages I added:
Nov 3 2017
The patch was not meant to be integrated already in the official Whonix source. More like: $interested_person can get an idea how a 188.8.131.52.2 live image would build and look in the end.
Nov 1 2017
Attached is the diff against 184.108.40.206.2-developers-only. It contains minor changes to the original Whonix source and some new files for the dracut live system. I removed some changes which should be only relevant on my side. If it doesn't build I can add them.
With this patch the raw gateway and workstation boot in normal, live and live toram mode. You can choose in the grub menu what option you want to boot. I didn't check each application but I don't see a reason why some app shouldn't work due to running live. Exception is currently Apparmor confined stuff which will complain when booted with overlayfs (currently default). So either the profiles have to be adapted or I'll change the default mode to device-mapper.
If you want to boot without overlayfs and use device-mapper instead just remove rd.live.overlay.overlayfs from the grub menu for the normal live mode. For the toram mode you have to use "rd.live.plainroot" instead of "rd.live.mksquashfs rd.live.overlay.overlayfs" .
Aug 25 2017
I can't reproduce this issue on my side. Tested it with the gateway and workstation 220.127.116.11.6 and with a self build gateway on 18.104.22.168.1. Installing genmkfile works in each case.
However, it depends on the version of genmkfile if exim + a lot of other packages are installed. There are two versions of genmkfile, the latest one is only present in the whonix developers repo. This version requires several packages (see Depends in the control file). One of those packages is devscripts which has the package "at" as recommends which again has some mta like exim as recommends.
The version of genmkfile in jessie, jessie-proposed-updates and testers does not depend on any package. This is also the reason why JasonJAyalaP saw no exim being installed on debian stretch with the whonix jessie repository.
So if you don't want exim etc. to be installed AND you want to use the latest genmkfile version then: use --no-install-recommends.
Otherwise use the whonix jessie repo. Not sure about the differences between the genmkfile versions though.
As already said, for me it also works with the recommended packages and whatever repo, no exim errors.
@JasonJAyalaP can you still reproduce this error on your side?