Whonix 12.0.0.3.2 RC – Testers Wanted!

Development
21

Took v 12 for a spin and can confirm all is looking good here. Shared folders work seamlessly now and the power management is disabled according to system modules in KDE settings.

22

The network manager isn’t complaining like in v 11 can you see it too?

I want to try and push the qxl performance fix before the final release but we’ll see.

23

I haven’t looked yet but did you update the forum links in the TBB local homepage?

24

@nurmagoz:

never used that feature. It’s disabled by default. For similar reasons as https://www.whonix.org/wiki/VirtualBox_Guest_Additions#Clipboard_Sharing. Once you enable it, and if it works, it’s specific to VirtualBox only. Glad it works in Debian, and Whonix also.

whonix gateway Guest to host enabled by default! , the WS both r disabled.

This is expected as per
https://www.whonix.org/wiki/VirtualBox_Guest_Additions#Clipboard_Sharing.

1 Like
25

HulaHoop:

and the power management is disabled
according to system modules in KDE settings.

Yes. One note on that.

Right. That configuration module is now no longer added to kde
sytemsettings. Two things.

    1. disabling power saving is done separately - if that works is a
      different story
    1. disabling the kde systemsettings entry - independent of above. Now,
      if 1 does not work, then things get get awful without 2). The
      alternative would have been a grayed out kde systemsettings power
      savings entry.
26

HulaHoop:

The network manager isn’t complaining like in v 11 can you see it too?

Yes, this was fixed.

I want to try and push the qxl performance fix before the final release but we’ll see.

Too late now. That would go into Whonix 13. The RC stands for release
candidate. That candidate is going to be released without
rebuild/without changes. I don’t plan to create new builds before Whonix
13 before something is seriously broken.

27

HulaHoop:

I haven’t looked yet but did you update the forum links in the TBB local homepage?

No. Will do for Whonix 13. (Low priority, because the redirection works.)

28

The source build works well but it shows the new packge as extraneous so I’ll have to wait until Whonix next.

Can you please post an example build command that targets x64 and stretch sources for both WG and WS.

29

Then you did build from a tag that did not have that package yet.[quote=“HulaHoop, post:28, topic:1646”]
Can you please post an example build command that targets x64 and stretch sources for both WG and WS.
[/quote]
sudo ./whonix_build --gnw – --build --target qcow2

FYI: If it could not be made to build because of some extraneous package, that would be an awful evironment. Add --allow-untagged true --allow-uncommitted true.

sudo ./whonix_build --gnw -- --build --target qcow2 --allow-untagged true --allow-uncommitted true

Debian jessie is currently being used by default for builds as of Whonix 12 / 13. Debian stretch is too far in the future. Currently totally untested. It does not have a command line switch.

You would need to set

whonix_build_sources_list="build_sources/debian_testing_current.list"

one way or another. Try this.

sudo whonix_build_sources_list="build_sources/debian_testing_current.list" ./whonix_build --gnw -- --build --target qcow2 --allow-untagged true --allow-uncommitted true

Or use a different method as per Whonix ™ Source Code Introduction to set this build variable.

30

Are there xargs I can use to make the build script use 4 cores instead of one?

To be extra sure, there is no security risk in keeping those extraneous files? The build guide has a very strong warning against them.

31

HulaHoop:

Are there xargs I can use to make the build script use 4 cores instead of one?

I don’t think anything would limit it to 1 core.

To be extra sure, there is no security risk in keeping those extraneous files?

Depends on which extraneous files. IF, you understand them, there is no
risk.

Temporary package files, binary files can be deleted using

help-steps/cleanup-files

Or using the build scripts --clean parameter.

That function is in place to enforce clean build results. A git tag
12.0.0.3.2 resulting really in what that tag provides. If any extra
files were added accidentally - and this happened more than once to
users - then they would not exactly build that tag, but something modified.

32

Does this multicore example look useful?

33

What’s the problem you want to solve?

34

I wanted to make the build script use as many cores as possible to speed up builds.

I found a really cool utility called gnu-parallel that may allow just that but I want to figure out how to run it with the build command.

see:

35

Not sure that makes sense…

Is one CPU core 100% busy while others are idle?

CPU is most likely not bottleneck. I/O is. Building gw and ws at the
same time is unsupported.

The build script is a bash script that runs lots of tools such as
[grml-]debootstrap, tar, debuild and so forth to create an image. So
this translates partly into “how to make
[[grml-]debootstrap/tar/debuild] make use of multiple CPU’s?” If they’re
not already doing this anyhow.

Most stuff is sequential. You cannot build the image before packages
have been build. Some stuff might be worth parallelization. Perhaps
building multiple packages at once could speed up building. I expect
this would require several physical hdds. Or perhaps also building
packages while in parallel creating the Debian base image using
grml-debootstrap.

While it might be worth speed wise, it would complicate the code. Very
low priority for me.

36

Yes that’s it.

I see.

I wasn’t suggesting you change anything in the scripts just looking for better CPU utilization when running it.

It seems not to be a problem with bash so nevermind.

37

Running:

sudo whonix_build_sources_list=“build_sources/debian_testing_current.list” ./whonix_build --gnw – --build --target qcow2 --allow-untagged true --allow-uncommitted true --arch amd64 --kernel linux-image-amd64 --headers linux-headers-amd64

gives:

  • ARCHCMD=‘–arch amd64’
  • ARCHINFO=’ (amd64)’
    ++ uname -m
  • CURRENT_ARCH=i686
  • ‘[’ i686 ‘!=’ x86_64 ‘]’
  • ‘[’ amd64 = amd64 ‘]’
  • eerror ‘It is not possible to build amd64 on i686.’
  • ‘[’ ‘’ ‘!=’ yes ‘]’
  • ‘[’ ‘’ = ebegin ‘]’
  • printf ’ * It is not possible to build amd64 on i686.\n’
  • It is not possible to build amd64 on i686.
  • LAST_E_CMD=eerror
  • return 0
  • eend 1
  • local retval=1
  • shift
  • ‘[’ 1 -gt 0 ‘]’
  • printf ’ → Failed (rc=1)\n’
    → Failed (rc=1)

Which makes sense because you can’t simply run a x64 kernel on a system with i386 binaries to have a x64 system.

38

Consider installing and booting the ‘linux-image-amd64’ kernel or using ‘–arch i386’ instead.

This is a limitation of grml-debootstrap. (Btw one that I patched to make fail with a feasible error message rather than much more obscure one.)

Also submitted a pull request to improve that error message.

39

Consider installing and booting the ‘linux-image-amd64’ kernel or using ‘–arch i386’ instead.

Do you mean install the kernel after the build process or to change the command to something like this:

sudo
whonix_build_sources_list=“build_sources/debian_testing_current.list”
./whonix_build --gnw – --build --target qcow2 --allow-untagged true
–allow-uncommitted true --arch i386 --kernel linux-image-amd64
–headers linux-headers-amd64

40

Install and boot the kernel on the build system.

NOT after the build process. (Won’t fix the build running through.)

Or try that build command. You can also drop --arch i386, since that is the default anyhow.