Whonix live mode / grub-live

[phabricator-migrator]

Information

ID: 714
PHID: PHID-TASK-kw6a7u5343wlzombc2ig
Author: Algernon
Status at Migration Time: resolved
Priority at Migration Time: Normal

Description

First patches to run Whonix as a live system.

( https://forums.whonix.org/t/whonix-live-mode )

{F844246}

Comments

---

Patrick

2017-09-05 12:54:19 UTC

A tar.xz is not a great source for source code. Could you publish this using git please?

---

Algernon

2017-11-01 18:00:16 UTC

{F1622187}

Attached is the diff against 14.0.0.5.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” .

---

Patrick

2017-11-02 20:33:40 UTC

I can see you know your way around in Whonix source code and found a lot. Gave it a quick review. Looks mostly good for me except…

I don’t like the idea to tell the builder “apply this patch to build Whonix live”. Applying patches on top adds another level of complexity that I don’t like. Could you just send git pull requests please and then implement this with an if/else code style?

Rather than patching grml_packages, just add another file grml_packages_live or so. (This is because inside that file we cannot add if/else.)

“$WHONIX_SOURCE_FOLDER/grml_packages” should be turned into a variable in help-steps/variables and then referenced that way. Not a big deal. If that sounds difficult, just add grml_packages_live or so and leave that to me.

swap-file-creator changes: can these be made if/else changes please as well? I.e. “if live mode is enabled, do it that way, otherwise do it the default way” style?

For example, the following does not even need an if/else for simplicity - just a comment “only used in case of Whonix live build” or so.

• rm --force “$CHROOT_FOLDER/$WHONIX_SOURCES_LIST_TEMP_BUILD_FOLDER/build_sources_testing.list”
• rm --force “$CHROOT_FOLDER/etc/apt/preferences”

Do we still need dracut-live-patches in Whonix 14 which is stretch based? If so, I wouldn’t mind adding another package packages/dracut-live-patches to the mainline.

Please use config-package-dev rather than dpkg-divert. (There are examples in Whonix source code.) (Which we are using for a long term in Whonix and which is a lot better.) If you find config-package-dev difficult, just leave it as is and I will add another revision on top.

For new files in /etc/grub.d/ etc.

• If existing: if it was imported from a third party open source, please copy the link to the original in here.
• If existing and modified: Please add the original to the git history first, then add another change on top in case you needed to add modifications. (Makes it easier to see original and changes.)

/packages/whonix-gw-network-conf/debian/whonix-gw-network-conf.triggers is unfortunate. Can’t we have

activate update-initramfs
activate dracut

at the same time? Or would activate dracut break on systems that do not have it dracut installed? Or would activate update-initramfs break on systems without initramfs? Anyhow… Somehow we’ll manage to avoid a patch here.

packages/whonix-developer-meta-files/package_documentation doesn’t need a patch. That file is not all that strict. Just add it unconditionally with the appropriate comment, that’s it.

packages/anon-meta-packages/debian/control - I hope very much we can avoid a patch here as well. A patch isn’t really suitable - imagine this package gets upgraded from Whonix apt repository. There is only one Whonix repository and not live/not-live. (We also shouldn’t have two repositories. The diff is way to minor (I don’t say developing this is simple - just it does not interfere much with exiting Whonix) for separate Whonix apt repositories.

Perhaps we

• remove initramfs-tools from non-qubes-vm-enhancements and then add to
• add initramfs-tools to non-qubes-whonix-gateway and non-qubes-whonix-workstation
• new packages non-qubes-whonix-gateway-live and non-qubes-whonix-workstation-live that depend on the dracut packages

Or better as per Whonix live mode / amnesia / amnesic / non-persistent / anti-forensics - #6 by Patrick we make initramfs-tools a weak recommended package? Add it to grml_packages (and ensure it does not get purged, keeps kept on Whonix 13 → Whonix 14 upgrades)? If that sounds difficult, I can also look into that.

packages/whonixcheck/etc/apparmor.d/usr.bin.whonixcheck what does it do? Any reason for not having that in the mainline non-live?

As said… Except for this being a patch rather than if/else code style, there is little to complain. Once converted into if/else code style, I can give it a more thoroughly review but I am confident a speedy review/merge is possible here since it interferes little with Whonix non-live.

After that… We make it a build option? What about sudo apt-get install pkg-name method to transform existing Whonix versions into this? Should be quite doable? (Whatever you like to maintain - won’t push you into that.)

So either the profiles have to be adapted or I’ll change the default mode to device-mapper.

Dunno yet. Please elaborate. What options are there? device-mapper is one choice, what’s the other? What are the differences?

In which way the apparmor profiles would have to be changed? Could we consider these bugs in Whonix apparmor profiles? Then we should do-it-right™, just fix them anyhow and not require other packages (yours) to add workarounds. Or is not using device-mapper mode causing other issues as well?

---

Algernon

2017-11-03 12:17:33 UTC

The patch was not meant to be integrated already in the official Whonix source. More like: $interested_person can get an idea how a 14.0.0.5.2 live image would build and look in the end.

For the

if/else

I’m not 100% sure how it should work. As build option or as boot option or both?
I think a dedicated build option like “–live” should be possible and depending on this using the different config files like grml_packages_live

The swap file changes already have some kind of if/else option but more for booting and not for building. I.e. it is tested if the system was booted live and if it was it skips creation of the file and if it boots normally it will just do what it always has done.

The dracut live patches are still required, the version which the patches use is currently in testing. So either the patches have to be added to mainline or the dracut package including the patches could be added (then we could maybe also get rid of the dpkg-divert stuff). I’ll take a look at config-package-dev.

The grub files as well as the dmsquash files are based on the original files for debian. I’ll add them.

activate update-initramfs
activate dracut

I’m also not sure if adding both would break something. Sure one command would not work. Maybe this would interfere with dpkg or the build script. Tbh I don’t know if and when the triggers are run. I couldn’t find anything related during the build process at least.

packages/anon-meta-packages/debian/control

Could maybe stay the same though we need to ensure that dracut + patches gets installed after this package has been installed so initramfs-tools get removed.

packages/whonixcheck/etc/apparmor.d/usr.bin.whonixcheck what does it do? Any reason for not having that in the mainline non-live?

I don’t think there is a reason against it, the flag is required for apparmor to not break on overlayfs systems. There are likely more profiles where this flag is missing.

Device mapper vs overlayfs

Device mapper

pro: no changes needed for apparmor profiles, and other MAC
con: when you add files you won’t get the RAM back when you delete them (except you reboot of course). Not sure how likely this is though.

Overlayfs: you get your memory back if you delete something but you have to change the profiles for apparmor.
In most cases I encountered using an alias and using the attach_disconnected flag was enough, but there seems to be more in case of the Whonix profiles.
I’m in slight favor for device mapper at the moment as the default boot option.

Generally speaking, I’m not 100% sure if we want to make live mode a build option. If we use it as default Whonix should still work as normal with installing new packages, configuring stuff …, just like with the normal initramfs that Whonix currently uses. Additionally, you have new boot options if you want some kind of amnesia/non-persistence/throw-away/disposable vm.
So at some point Whonix could just make new download images available with dracut by default and for upgrading there needs to be some extra-package. I’ll take a closer look at such a package.

---

Patrick

2017-11-03 14:10:38 UTC

! In T714#14714, @Algernon wrote:
The patch was not meant to be integrated already in the official Whonix source. More like: $interested_person can get an idea how a 14.0.0.5.2 live image would build and look in the end.

I see.

(I personally didn’t build it. Not sure I would even build it. Perhaps I would just build and upload whonix.org officially redistributed testers-only, RC and stable releases, but leave all the testing and maintenance to you.)

For the

if/else

I’m not 100% sure how it should work. As build option or as boot option or both?

I find both good to have. It’s up to what you would like to maintain.

I think a dedicated build option like “–live” should be possible and depending on this using the different config files like grml_packages_live

Yes, looks very possible. It’s amazing how few changes to the current Whonix source code is required.

The swap file changes already have some kind of if/else option but more for booting and not for building. I.e. it is tested if the system was booted live and if it was it skips creation of the file and if it boots normally it will just do what it always has done.

Yes, for booting only should be alright.

The following should be if/else.

+[ -n "$SHRED_OPTS" ] || SHRED_OPTS="--verbose --iterations=1 --remove"

-#SHRED_ON_STOP="yes"
+SHRED_ON_STOP="yes"

The dracut live patches are still required, the version which the patches use is currently in testing. So either the patches have to be added to mainline or the dracut package including the patches could be added (then we could maybe also get rid of the dpkg-divert stuff). I’ll take a look at config-package-dev.

Alright.

The grub files as well as the dmsquash files are based on the original files for debian. I’ll add them.

activate update-initramfs
activate dracut

I’m also not sure if adding both would break something. Sure one command would not work. Maybe this would interfere with dpkg or the build script. Tbh I don’t know if and when the triggers are run. I couldn’t find anything related during the build process at least.

Looked around in /var/lib/dpkg/info for .triggers files. Testwise uninstalled initramfs-tools. Removed and reinstalled ntfs-3g which uses activate initramfs. No issue. Tried whonix-ws-network-config package reinstallation with activate dracut. No issue. Probably won’t break the build. Probably safe. Please try.

packages/anon-meta-packages/debian/control

Could maybe stay the same though we need to ensure that dracut + patches gets installed after this package has been installed so initramfs-tools get removed.

Problem is, initramfs-tools conflict with dracut as per their debian/control file. Meaning installation of dracut will result in uninstallation of initramfs-tools. Therefore, installing dracut results in uninstallation of non-qubes-vm-enhancements which results in uninstallation of non-qubes-whonix-gateway / non-qubes-whonix-workstation on current Whonix installations.

sudo apt-get install dracut currently creates a mess, it is related to Debian Packages - Whonix. So initramfs-tools should not be part of non-qubes-vm-enhancements anyhow.

packages/whonixcheck/etc/apparmor.d/usr.bin.whonixcheck what does it do? Any reason for not having that in the mainline non-live?

I don’t think there is a reason against it, the flag is required for apparmor to not break on overlayfs systems. There are likely more profiles where this flag is missing.

Alright, so please send pull requests for mainline non-live so we fix the apparmor bugs in any case (device mapper vs overlyfs does not matter - if we have a bug - we fix it).

Device mapper vs overlayfs

Device mapper

pro: no changes needed for apparmor profiles, and other MAC
con: when you add files you won’t get the RAM back when you delete them (except you reboot of course). Not sure how likely this is though.

Overlayfs: you get your memory back if you delete something but you have to change the profiles for apparmor.
In most cases I encountered using an alias and using the attach_disconnected flag was enough, but there seems to be more in case of the Whonix profiles.
I’m in slight favor for device mapper at the moment as the default boot option.

Alright. Default sounds good.

Generally speaking, I’m not 100% sure if we want to make live mode a build option. If we use it as default Whonix should still work as normal with installing new packages, configuring stuff …, just like with the normal initramfs that Whonix currently uses. Additionally, you have new boot options if you want some kind of amnesia/non-persistence/throw-away/disposable vm.
So at some point Whonix could just make new download images available with dracut by default and for upgrading there needs to be some extra-package. I’ll take a closer look at such a package.

I am open to changing Whonix upgraded builds as well as new Whonix builds from initramfs-tools to dracut.

It would probably only require changing non-qubes-vm-enhancements dependency from initramfs-tools to dracut. Then on upgrade to Whonix 14, apt-get/dpkg would sort out the migration automatically. (uninstall initramfs-tools first since dracut conficts with it, then install dracut)

initramfs-tools was chosen without too much regard. I didn’t follow initramfs-tools vs dracut. It looks pretty much like a drop-in replacement that does not cause any issues? Please open a new Whonix development forum topic suggesting to migrate Whonix by default from initramfs-tools to dracut. Unless there are any strong arguments against it (breaking VirtualBox guest additions or KVM something or so), I don’t see why not.

---

Algernon

2017-11-08 15:03:04 UTC

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:

if [ “$base_name” = “dracut-whonix” ]; then
debuild -b -us -uc
popd
continue
fi

to the loop in the create_whonix_debian_packages function

and started a test build. The package itself builds fine but it does not end up in the local apt repo in the whonix_binary folder and hence also not in the final filesystem image.
In contrast to the other packages the Makefile is different to what whonix expects, additionally some commands are missing like reprepo-add etc, but I guess they wont work anyways.
Is there an easy way to add the package to the repo or has the structure of the package to be adapted so it looks like the other whonix packages?

---

Patrick

2017-11-08 16:24:39 UTC

! In T714#14763, @Algernon wrote:
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.

That could be a problem. When users try to install dracut while dracut-whonix is installed, dpkg will break since the same file may not be owned by two packages at once. So dracut-whonix would need Conflicts: dracut and probably also Provides: dracut. I hope we can avoid forking the whole package and just config-package-dev replace a few files where changes are needed.

added the changes we need for the live systems

What’s the diff?

In 1200_create-debian-packages I added:

if [ “$base_name” = “dracut-whonix” ]; then
debuild -b -us -uc
popd
continue
fi

to the loop in the create_whonix_debian_packages function

and started a test build. The package itself builds fine but it does not end up in the local apt repo in the whonix_binary folder and hence also not in the final filesystem image.
In contrast to the other packages the Makefile is different to what whonix expects, additionally some commands are missing like reprepo-add etc, but I guess they wont work anyways.

The build script is also running…

sudo $SUDO_OPTS make -f "$make_file" reprepro-add

Or somehow do what reprepro-add of the makefile does integrated into 1200_create-debian-packages, i.e. the reprepro-add command.

sudo $SUDO_OPTS "$whonix_dev_meta_files_folder/debug-steps/reprepro-wrapper" includedeb "$WHONIX_BUILD_APT_CODENAME" "$package_absolute_path"

Is there an easy way to add the package to the repo or has the structure of the package to be adapted so it looks like the other whonix packages?

This hasn’t been designed yet.

---

Algernon

2017-11-11 20:42:37 UTC

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?

---

Patrick

2017-11-11 21:55:30 UTC

Algernon (Algernon):

Algernon added a comment.

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.

Alright.

I guess the official Whonix repo will be used when users would upgrade to the live version.

Yes.

From looking at the aptrepo_local which gets created during building it seems to be more or less the same as the online repo?

Yes.

(Just that the aptrepo_remote is versioned for stable,
stable-proposed-updates, testers and developers, but none of this
matters for the sake of this ticket.)

So I could use the local repo for the update tests or is there anything else to look out for?

Yes.

( There are even some developer scripts:

https://github.com/Whonix/whonix-developer-meta-files/blob/master/debug-steps/locally-upgrade-whonix-debian-packages

https://github.com/Whonix/whonix-developer-meta-files/blob/master/debug-steps/qubes-repo-temp

But maybe these could be even simpler.

)

Perhaps try /etc/apt/sources.list.d/whonix_local.list?

deb [trusted=yes] file:/home/user/whonix_binary/aptrepo_local local main

---

Algernon

2017-11-13 18:45:53 UTC

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 :
⚓ T688 Change bindp compile to postinstall
Release Upgrade
State of offical 64 bit builds - #16 by Patrick

the answer looks like “maybe”.
Has there been any final decision or tests?

---

Patrick

2017-11-13 19:53:43 UTC

As it looks now, it will be easily possible to upgrade Whonix 13 i386 to
Whonix 14 i386. New Whonix 14 builds will be amd64. Looks pretty final.
I don’t think it will change for Whonix 14. (That is for
Non-Qubes-Whonix.) (For Qubes-Whonix none of this matters, it always has
been amd64.)

---

Algernon

2017-11-20 19:30:39 UTC

{F1925452}

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.

Some other observations:
In case of the upgrade from 13 to 14 there is also a problem with virtualbox guest additions which don’t get installed. I guess it is due to missing backports from the sources.list. Also the background changes to the (not so shiny) debian default and the desktop icons are missing on the desktop. When I go to /home/user/Desktop the icons are present, however. The same thing happens with a Whonix 14 build, even without dracut + patches iirc.

---

Patrick

2017-11-21 17:36:01 UTC

! In T714#14789, @Algernon wrote:
{F1925452}

Attached is the more or less final patch with only minor changes mostly related to apparmor profiles.

It’s hard to follow any changes with the patches style. Cannot really review this fully in that format.

Could you please merge the non-controversial stuff little by little i.e. creating pull requests for the changes in the apparmor profiles or “swap-file-creator behaves differently in live mode”?

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.

Indeed… as reported by @Algernon · Kicksecure/bindp@d7052e5 · GitHub

bindp is now (with a hack) an architecture independent package. This was done in T688. But the updated package hasn’t been uploaded yet.

Some other observations:
In case of the upgrade from 13 to 14 there is also a problem with virtualbox guest additions which don’t get installed. I guess it is due to missing backports from the sources.list.

VirtualBox guest additions will be downloaded from stretch-backports and uploaded to Whonix repository. This is done in build scripts but not uploaded to Whonix repository.

• https://github.com/Whonix/Whonix/blob/master/build_sources/debian_stable_current_clearnet.list
• https://github.com/Whonix/Whonix/blob/master/build-steps.d/1200_create-debian-packages

I’ll add the new instructions to the wiki and submit a pull request.

Enabling deb http://ftp.us.debian.org/debian testing main contrib non-free is a bad idea. In any case please use specific code names (such as stretch, buster) rather than generic ones (such as stable, testing). We shouldn’t use this anyhow (elaborated below). Please remove from the wiki.

Using apt pinning by Whonix default is a big no.

• Dev/APT Pinning - Kicksecure
• these are tricky and risky
• our electrum instructions using apt-pinning broke apt-get for all who followed these instructions

dracut

• Moving all of Whonix 14 (stretch based) to dracut (stretch version) for Whonix 14 is alright as per https://forums.whonix.org/t/replacing-initramfs-tools-with-dracut-for-live-systems.
• However, mixing stretch with buster is too risky for Whonix 14 official download version. It’s dependencies are too complex so this could break the apt-get dependency resolution in hard to fix ways. If there was a stretch-backport of dracut, that would be alright.
• Sorry if I miscommunicated this earlier!

We can and should still merge everything else.

For Whonix buster based version we could then make live boot work by default or at least more easily without mixing with testing / apt-pinning.

Wondering, isn’t this optimal live-mode boot better implemented as a generic (Whonix independent) package? One that could be merged into dracut upstream and then just apt-get pulled by Whonix?

---

Algernon

2017-11-30 18:31:51 UTC

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.

All changes can now be found here:
https://github.com/Whonix/Whonix/commit/f30b5dba1513d96be4d33febffc813a293b2309b

I’m still trying to accommodate myself to git so at the moment a pull request for the main repo including the relevant submodules is not possible.
Theoretically this one : https://github.com/Whonix/Whonix/compare/master...Algernon-01:master
is mergeable but it is lacking some submodules and some others have missing commits. I probably forgot some important command somewhere …, or should have started from the master branch … (testing was done on the 14.0.0.5.2 tag)

Anyways, I can open pull requests for the submodules. For the main repo maybe it is possible to pull and git hopefully won’t complain or maybe copy the files manually. Otherwise I’ll have to take a look at this again.

---

Patrick

2017-11-30 22:35:26 UTC

For reference:

Patches for Whonix live by Algernon-01 · Pull Request #1 · Kicksecure/developer-meta-files · GitHub
https://github.com/Whonix/anon-meta-packages/pull/6
https://github.com/Whonix/whonixcheck/pull/7
https://github.com/Whonix/apparmor-profile-gwenview/pull/1
https://github.com/Whonix/whonix-ws-network-conf/pull/1
https://github.com/Whonix/whonix-gw-network-conf/pull/1
Patches for Whonix live by Algernon-01 · Pull Request #20 · Kicksecure/sdwdate · GitHub
Patches for Whonix live by Algernon-01 · Pull Request #1 · Kicksecure/apparmor-profile-hexchat · GitHub
https://github.com/Whonix/apparmor-profile-virtualbox/pull/1
Patches for Whonix live by Algernon-01 · Pull Request #2 · Kicksecure/apparmor-profile-torbrowser · GitHub
https://github.com/Whonix/apparmor-profile-okular/pull/1
https://github.com/Whonix/Whonix/pull/414

All non-controversial stuff (apparmor) already merged.

---

Regarding Patches for Whonix live by Algernon-01 · Pull Request #1 · Kicksecure/swap-file-creator · GitHub could you please simplify

if [ -z "$(cat /proc/cmdline | grep "root=live:")" ]; then
 do_start
else
echo "Live mode detected. Swap file creation skipped. "
exit 0
fi

to

if cat /proc/cmdline | grep "root=live:" ; then
   echo "Live mode detected. Swap file creation skipped."
   exit 0
fi

do_start

Does that work?

---

Patches for Whonix live by Algernon-01 · Pull Request #1 · Kicksecure/swap-file-creator · GitHub

Why do you set SHRED_ON_STOP="yes" unconditionally for non-live Whonix?

Is that an unrelated suggestion / fix?

Patches for Whonix live by Algernon-01 · Pull Request #1 · Kicksecure/swap-file-creator · GitHub

Why do you add --remove to SHRED_OPTS?

Is that an unrelated suggestion / fix?

---

https://github.com/Whonix/Whonix/pull/414 is wrong. packages/dracut-live-patches must not be a pull request against Whonix/Whonix. dracut-live-patches has to go into its own git repository, ideally https://github.com/Algernon-01/dracut-live-patches. You could do that by creating a github repository dracut-live-patches.

Whonix/packages/dracut-live-patches/debian/dracut-live-patches.postinst at 09e18cd48b0c5f069f028c6c59db466b13ecf5c5 · Algernon-01/Whonix · GitHub

Why is dracut /boot/initrd.img-$i $i required? Shouldn’t the dracut package by Debian already do that?

Whonix/packages/dracut-live-patches/debian/dracut-live-patches.postinst at 09e18cd48b0c5f069f028c6c59db466b13ecf5c5 · Algernon-01/Whonix · GitHub

Same for update-grub.

---

packages/dracut-live-patches/debian/dracut-live-patches.preinst does nothing so can and should be safely removed.

https://github.com/Whonix/Whonix/pull/414/files#diff-03db39ec0efb2a7676d8fb370a47a075R14

Since you have no man pages, this can be removed:

+override_dh_install:
+	make manpages
+	dh_installman $(CURDIR)/debian/tmp-man/*

---

packages/dracut-live-patches/etc/apparmor.d/tunables/alias.anondist

I doubt a .anondist file / config-package-dev is needed here. And should be avoided at all cost if possible.

I guess a file dracut-live-patches/etc/apparmor.d/tunables/dracut-live-patches with the same contents would do?

---

packages/dracut-live-patches/etc/apparmor.d/tunables/home.d/whonix

A generic package dracut-live-patches shouldn’t have a file named whonix, since not a Whonix specific package.

---

packages/dracut-live-patches/man/dracut_live_patches.8.ronn should be deleted - if there is no user facing tool started from the command line, we don’t need a man page, right?

---

These files contain a lot code:

• dracut-live-patches/etc/grub.d/11_linux_live
• dracut-live-patches/usr/lib/dracut/modules.d/90dmsquash-live/dmsquash-live-root.sh.anondist
• dracut-live-patches/usr/lib/dracut/modules.d/90dmsquash-live/module-setup.sh.anondist

I don’t understand that code very well. Would take me a long time to learn. Cannot simply merge on a “non-malicious just works” basis since that could lead to a lot pressure and headache later when it breaks.

initramfs currently is something that “Debian does”, “that just works”, “that is used by very many people and unlikely to break”. So that requires very little thought, maintenance and time from me.

The suggested code by you is complex so I try to figure out if my time to learn it is well justified and the-clean-way™ to do things.

Correct me if I am wrong, but I understand, the majority of the file has been written by third parties. (Indicated by the copyright of the file.)

What’s the original source of dracut-live-patches/etc/grub.d/11_linux_live so I can see the diff? I couldn’t find it.

Looking at the diff for the two dracut modified files… Using the dracut version from stretch…

diff /usr/lib/dracut/modules.d/90dmsquash-live/dmsquash-live-root.sh yours

31c31
< [ -z "$overlay_size" ] && overlay_size=512
---
> [ -z "$overlay_size" ] && overlay_size=32768
266a267,271
>     else
>       BASE_LOOPDEV=$( losetup -f )
>       umount /run/initramfs/live
>       losetup -r $BASE_LOOPDEV $livedev
>         do_live_from_base_loop
290a296
> 

[ -z "$overlay_size" ] indicates, that this can be configured somewhere. Please:

• try to find out the configuration file (so we can just ship a config snippet rather than config-package-dev divert the whole script
• ask upstream if you are unable to find it
• if there is no config file, please submit a patch to upstream to make that configureable
• only as very last resort, if upstream refuses to cooperate we consider to fork this file and carry a patch

The part after the else looks strange. The intend style confused me. Please fix intend style. I guess you meant like this?

if [ -n "$FSIMG" ] ; then
...
else
    BASE_LOOPDEV=$( losetup -f )
    umount /run/initramfs/live
    losetup -r $BASE_LOOPDEV $livedev
    do_live_from_base_loop
fi

Same as above. Please work with upstream dracut to get this merged.

diff /usr/lib/dracut/modules.d/90dmsquash-live/module-setup.sh new 

20c20
<     instmods squashfs loop iso9660
---
>     instmods squashfs loop iso9660 overlay
25c25
<     inst_multiple umount dmsetup blkid dd losetup grep blockdev find
---
>     inst_multiple umount dmsetup blkid dd losetup grep blockdev find df tail
39a40
>

I don’t understand the diff.

Same. Could you work with upstream please to make this the default or easily configurable? (The ideal configurability would be a .d drop-in folder for config files.)

---

Algernon

2017-12-01 23:39:29 UTC

As stated here: replacing initramfs-tools with dracut
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.

---

Patrick

2017-12-02 19:17:53 UTC

! In T714#14808, @Algernon wrote:
As stated here: replacing initramfs-tools with dracut
there is still option 5 if you feel uncomfortable with dracut in general.

Might be better.

A “normal” live system with overlayfs should be possible without patches. We would mostly need to pull in some debian live packages.

Which ones?

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.

Sounds good.

---

Algernon

2017-12-03 20:50:14 UTC

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.

---

Patrick

2017-12-04 08:36:00 UTC

Algernon (Algernon):> Packages would be: live-boot, live-config-systemd,

live-config-initramfs-tools, live-tools.

Most of them don’t seem to interact with the normal boot process, right?

However, live-tools dpkg-divert’s /usr/sbin/update-initramfs with
/bin/live-update-initramfs.

man update-initramfs shows live-update-initramfs man page.
live-update-initramfs. Will that interfere with normal boot?

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.

I think apparmor-profile-anondist is not the best place - since this is
not an anonymity related configuration.

So either make a dedicated grub-live
package or make the live patch package as before or merge the grub
config file somewhere else.

Think about it that way: how would the package be called if it were
ready to be uploaded to / downloaded from packages.debian.org?

Perhaps a grub-live package with all changes for apparmor and grub live?

Can the apparmor changes be contributed upstream?

Is the functionalist you are inventing here known to the Debian live
project as a missing feature / feature request? Could you contact them
please? Could you try to contribute that missing feature upstream please?

---

Algernon

2017-12-04 20:54:57 UTC

Most of them don’t seem to interact with the normal boot process, right?

None of them does anything unless you write “boot=live” on the kernel command line.

Will that interfere with normal boot?

No, normal boot boots as always. Same with updating initramfs. The live-update-initramfs script calls the original command anyways during building.

Can the apparmor changes be contributed upstream?

Maybe, but there is probably a reason they are not already there or they will be there soon(TM) since Tails needs the same changes once they go from aufs to overlayfs (
https://labs.riseup.net/code/issues/9045 ) and they are usually quite fond of merging stuff upstream. Also intrigeri recently made a proposal to make apparmor enabled by default on debian and hence the package maintainers also have to integrate/test profiles.

Is the functionalist you are inventing here known to the Debian live
project as a missing feature / feature request?

Not really, since I’m using only the stuff already integrated into Debian and not inventing anything new.

---

Algernon

2017-12-08 23:59:11 UTC

Changes for initramfs-tools based live system:

https://github.com/Whonix/anon-meta-packages/pull/7
Patches for live system based on initramfs-tools. by Algernon-01 · Pull Request #2 · Kicksecure/swap-file-creator · GitHub

grub-live is modified version of the default Debian version /etc/grub/10_linux
The apparmor profile is the default Debian version + the attach_disconnected flag

GitHub - Algernon-01/grub-live
GitHub - Algernon-01/apparmor-profile-thunderbird

---

Patrick

2017-12-09 21:19:23 UTC

! In T714#14861, @Algernon wrote:
Changes for initramfs-tools based live system:

https://github.com/Whonix/anon-meta-packages/pull/7

Patches for live system based on initramfs-tools. by Algernon-01 · Pull Request #2 · Kicksecure/swap-file-creator · GitHub

Merged.

grub-live is modified version of the default Debian version /etc/grub/10_linux
The apparmor profile is the default Debian version + the attach_disconnected flag

GitHub - Algernon-01/grub-live

Forked to my personal github account name.

GitHub - adrelanos/grub-live

And made the diff visible.

readd modifications by @Algernon-01 · adrelanos/grub-live@733a5cc · GitHub

Look reasonable, small, maintainable. If it breaks, and you vanish (no offense), and if I wouldn’t know how to fix it, I could just remove the file for the next major release of Debian.

Maintenance effort: diff /etc/grub.d/10_linux /etc/grub.d/11_linux_live at every major Debian release upgrade and rebase.

Do you think you could add this feature by submitting a patch to upstream /etc/grub.d/10_linux, so this could be enabled from a single line, a setting in /etc/default/grub.d/*.cfg (configuration snippet)?

---

grub-live/debian/control at master · Algernon-01/grub-live · GitHub - Why Do not remove.? That’s quite definitive. After discussing this, please elaborate or remove it.

GitHub - Algernon-01/apparmor-profile-thunderbird

Please submit a bug report and/or patch to upstream. (Debian and/or Thunderbird - depending on who invented the apparmor profile.)

No new package please, because we have https://github.com/Whonix/apparmor-profile-icedove. The package hasn’t been renamed yet because that is some work for little benefit but the package is supposed to make the thunderbird apparmor profile compatible with Non-Qubes-Whonix and Qubes-Whonix.

I was happy that in Whonix 14 we only need to drop a snipped /etc/apparmor.d/local/usr.bin.thunderbird and no longer need to modify /etc/apparmor.d/usr.bin.thunderbird but for live mode looks like a config-package-dev diversion cannot be prevented.

---

Patrick

2017-12-09 21:39:46 UTC

Should boot=live union=overlay plainroot be injected at line https://github.com/adrelanos/grub-live/blob/master/etc/grub.d/11_linux_live#L353 as well?

---

Patrick

2017-12-09 22:25:50 UTC

/etc/grub.d/11_linux_live is still a lot code duplication.

Couldn’t /etc/grub.d/11_linux_live just call /etc/grub.d/10_linux?

---

/etc/grub.d/11_linux_live would just do a few things in this order:

• inject boot=live union=overlay plainroot into ${GRUB_CMDLINE_LINUX}

GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX boot=live union=overlay plainroot"

---

• inject Live-mode into GRUB_DISTRIBUTOR

GRUB_DISTRIBUTOR="${GRUB_DISTRIBUTOR} Live-mode"

(This results in variable OS being set to Live -mode GNU/Linux.)

---

• influence variable LINUX_ROOT_DEVICE

This is the only thing I couldn’t think of. [1]

---

• check if /etc/grub.d/10_linux is executable
• run /etc/grub.d/10_linux

if test -x /etc/grub.d/10_linux ; then
    /etc/grub.d/10_linux
fi

---

[1] You changed from

LINUX_ROOT_DEVICE=UUID=${GRUB_DEVICE_UUID}

to

LINUX_ROOT_DEVICE=/dev/disk/by-uuid/${GRUB_DEVICE_UUID}.

Is this absolutely required?

The default (Which is what? Which is LINUX_ROOT_DEVICE=UUID=xxx-uid-here-xxx?) won’t work?

Isn’t the kernel clever enough to know UUID=${GRUB_DEVICE_UUID} means /dev/disk/by-uuid/${GRUB_DEVICE_UUID}?

If that’s the only missing thing, could you please post a feature request against upstream /etc/grub.d/10_linux?

---

Algernon

2017-12-10 21:02:51 UTC

Made the file somewhat smaller:
https://github.com/Algernon-01/grub-live/commit/c8f8a24dbac305cdbbff0d2d53d14b699cc4a2b4

---

Patrick

2017-12-11 13:57:02 UTC

Perfect!

---

Patrick

2017-12-11 16:40:16 UTC

! In T714#14865, @Algernon wrote:
Made the file somewhat smaller:
https://github.com/Algernon-01/grub-live/commit/c8f8a24dbac305cdbbff0d2d53d14b699cc4a2b4

I compared ### BEGIN /etc/grub.d/10_linux ### with ### BEGIN /etc/grub.d/11_linux_live ###.

#! /bin/sh
set -e

GRUB_DEVICE=“/dev/disk/by-uuid/${GRUB_DEVICE_UUID}”
unset GRUB_DEVICE_UUID

Functional, using disk by uuid.

GRUB_CMDLINE_LINUX=“$GRUB_CMDLINE_LINUX boot=live plainroot union=overlay”

Broken, no command line options added.

GRUB_DISTRIBUTOR=“${GRUB_DISTRIBUTOR} Live-mode”

Broken, not included.

if test -x /etc/grub.d/10_linux ; then
/etc/grub.d/10_linux
fi

Functional. New grub menu entry (### BEGIN /etc/grub.d/10_linux ###) gets added.

---

Patrick

2017-12-11 16:49:23 UTC

Fixed.

https://github.com/adrelanos/grub-live/commit/e108ad3af55fc193dd854f8c948b20630716b37f

---

Algernon

2017-12-11 23:34:38 UTC

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?

---

Patrick

2017-12-12 14:21:54 UTC

Test wise installed the package.

It didn’t work because I was testing it in a Debian TemplateBased AppVM
on Qubes, which didn’t have /etc/default/grub. Which results in:

• the variables you are trying to modify not being set
• therefore grub-mkconfig cannot export them
• therefore when /etc/grub.d/11_linux_live modifies them, it will stay
  local to the script, these are lost when it calls /etc/grub.d/10_linux
• the solution to make it work without existing /etc/default/grub (or
  without these variables set) was to unconditionally export the variables.
  Not a big deal.

---

Patrick

2017-12-15 20:26:22 UTC

Added to https://github.com/Whonix/Whonix/tree/master/packages, build, and uploaded to Whonix (14) developers repository.

Would you mind if we don’t install grub-live by default in Whonix 14, and you encourage some people to install and test?

---

Algernon

2017-12-17 12:11:48 UTC

Sure, I’ll add instructions for the installation and some general remarks around live mode to the Whonix live wiki entry.

---

Algernon

2018-01-06 19:35:05 UTC

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.

---

Patrick

2018-01-07 11:59:44 UTC

Merged.

---

Patrick

2018-01-09 14:43:38 UTC

What would be useful is some sort of indication on the desktop that system is running in live mode vs persistent mode.

This is to inform the user about the mode and not having confused the wrong startup option and believing to have booted another boot option. Would be bad if someone thought it is persistent, but accidentally chosen live and then loosing data. Or chosen persistent but wanting to choose live and then persisting data not wanting to persist.

---

Algernon

2018-01-12 13:50:45 UTC

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.

---

Algernon

2018-07-17 21:29:18 UTC

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

---

Patrick

2018-08-08 08:27:28 UTC

! In T714#15381, @Algernon wrote:
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.

One might forget this after a long session.

Created T819 for it.

This ticket is fully implemented. Closing.