As of 15.0.1.0.7, the following behavior is observed:

These tests are fully independent.

Ok, so you want me to:

• boot a Whonix-Host ISO
• Install on HDD
• Reboot on Whonix-Host ISO, do some stuff, shutdown
• See if HDD has been modified (why would it be?)

Correct?

In T910#19667, @onion_knight2 wrote:

Whonix Live ISO runs without an HDD.

Whonix Live ISO runs without an HDD.
I am not sure what you want to test here? Please precise.

Not fully fixed.

This ticket was written at a time when there was only grub-live. I.e. install Whonix on hardware (or Debian + grub live). Boot in live mode. Test if that works. If yes, take an hdd image. Boot again into live mode. Then take another hdd image. Compare these hdd images. Do they 100% match or are there differences? Differences: something wrong. No differences: that would be nice.

Do you mean: starting an installed version in live-mode (not tested, not supported yes) or starting a Whonix-Host iso file?

Sub pages or sub chapters of 1 wiki page?

https://forums.whonix.org/t/whonix-host-calamares-branding-suggestion/7772/31

Thanks!

This issue is fixed now due to the quiet boot parameter. kernel.printk=3 3 3 3 isn't needed anymore.

We actually ended up using Whonix KVM and placing images to:

Do you know how to run calamares hook scripts? I think I saw this before but I can't find it anymore. Or we have to invent our own mini calamares module similar to how package calamares-settings-debian invented new calamares modules?

In T914#19541, @onion_knight2 wrote:

I don't know. Not implemented yet. Currently installed (persistent) Whonix-Host does not have live-boot option.

Will come in Whonix 15.0.0.9.4 and above.

Works well in Non-Qubes-Whonix. Solution was this one:

In T950#19249, @Patrick wrote:

The loader of tirdad is currently using dmesg.

The loader of tirdad is currently using dmesg.

In T950#19231, @madaidan wrote:

quiet

This just prevents writing to /dev/kmsg. It doesn't stop kernel logs being displayed during boot.

Still wondering if initramfs modification this can be avoided... Still wondering if kernel.printk can be set through a kernel parameter. Looking again at https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/kernel-parameters.txt...

Sounds good.

https://github.com/Whonix/security-misc/pull/51

We can use a sysctl.d drop-in and an initramfs hook in security-misc so non-initramfs users will still be mostly protected.

I guess because a sysctl.d drop-in config file is easy and catches most.
initramfs hook covers only initramfs users. Not dracut. But
security-misc initramfs hook sounds good enough. dracut support can
come later, if ever. Please implement.

Why not use an initramfs hook in security-misc? Not everyone will have security-misc and apparmor-profile-everything installed. Users with just security-misc installed will still have some kernel logs shown during early boot.

Yes. Probably both. initramfs for apparmor-profile-everything users and
/etc/sysctl.d/ security-misc.

Should this be set in the initramfs?

Yes Zulucrypt included and functional on KVM 15. However fixes for both zulucrypt and tomb haven't made it into Buster from what I've tested. Zulucrypt has a tomb plugin to open Tomb files too.

In T913#18744, @Patrick wrote:

Do you see any issues with "create home directory on first login" in Qubes?

In T913#18743, @marmarek wrote:

Can you give some more context here?

Can you give some more context here? Is it the problem that user is created too early (before /etc/skel is fully populated)? Or is it a problem that it's created at all? Should there be a difference between Qubes and non-Qubes case?

Removed a few. Would not start without openat, so kept.

Yay, we have ProtectSystem=strict now.

Yay, we have ProtectSystem=strict now.

Can we exclude ExecStartPre=/usr/lib/onion-grater-merger from systemd hardening?

Error back after reboot.

https://github.com/Whonix/onion-grater/blob/master/lib/systemd/system/onion-grater.service currently works without ReadWritePaths. So let's not add?

https://github.com/Whonix/onion-grater/blob/master/lib/systemd/system/onion-grater.service currently works without ReadWritePaths. So let's not add?

It's a file, not a folder.

https://github.com/Whonix/onion-grater/commit/8480cff304ea019b25dc49d91672e7c3f8599a07

It's a file, not a folder. Nothing in the code of
/usr/lib/onion-grater-merger writes to /usr/lib/onion-grater-merger.

I just re-read the error message. Try adding

That's weird. Onion-grater is trying to write to somewhere that's being mounted read-only by systemd.

Merged your changes.

I see.
BTW it's certainly about fonts. here you can select whonix_firstrun-whonix-14-firstrun-20180915 from the dropdown above the screenshot (click eye icon at the right) and slide vertical bar to see old and new version.

marmarek (Marek Marczykowski-Górecki):

Is there a reason for fixed geometry of those widgets, instead of letting Qt figure it out based on the content?

Maybe different fonts installed? Is there a reason for fixed geometry of those widgets, instead of letting Qt figure it out based on the content? I suppose there may be more problems like this in the future. Especially if proper HiDPI support will come into play...

I have no idea why this started happening without changes. Perhaps due to underlying libraries changes. Anyhow, fixed in git master.

Work for me too in new build https://forums.whonix.org/t/qubes-whonix-15-templatevms-debian-buster-based-4-0-1-201906232114-testers-wanted/7601

Does this work in https://forums.whonix.org/t/whonix-virtualbox-15-0-0-3-3-debian-buster-based-testers-wanted/7604? @HulaHoop