100GB breaks cptofs but 50GB is fine and benchmarks shows it takes the same time as building the demo VBox VM with a 10GB disk
+ enabled VM sound output by default
+ set USB controller in USB2.0 mode
+ add manifest file in the OVA as it allows integrity checking on imports
10G is not enough for a desktop installation, and resizing a Virtualbox disk image is a pain.
Let's increase the default disk size to 100G. It does not require more storage space, since the empty bits are left out.
* nixos/virtualbox: Adds more options to virtualbox-image.nix
Previously you could only set the size of the disk.
This change adds the ability to change the amount of memory
that the image gets, along with the name / derivation name /
file name for the VM.
* Incorporates some review feedback
- Add a new parameter `imageType` that can specify either "efi" or
"legacy" (the default which should see no change in behaviour by
this patch).
- EFI images get a GPT partition table (instead of msdos) with a
mandatory ESP partition (so we add an assert that `partitioned`
is true).
- Use the partx tool from util-linux to determine exact start + size
of the root partition. This is required because GPT stores a secondary
partition table at the end of the disk, so we can't just have
mkfs.ext4 create the filesystem until the end of the disk.
- (Unrelated to any EFI changes) Since we're depending on the
`-E offset=X` option to mkfs which is only supported by e2fsprogs,
disallow any attempts of creating partitioned disk images where
the root filesystem is not ext4.
VirtualBox user space binaries now no longer reside in linuxPackages, so
let's use the package for the real user space binaries instead.
Tested using the following command:
nix-build nixos/release.nix -A ova.x86_64-linux
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes#13927
cc @edolstra
configFile in make-disk-image clashes with clone-config as the latter does
nothing if it finds a a /etc/nixos/configuration.nix during stage-2.
Previously this was done in three derivations (one to build the raw
disk image, one to convert to OVA, one to add a hydra-build-products
file). Now it's done in one step to reduce the amount of copying
to/from S3. In particular, not uploading the raw disk image prevents
us from hitting hydra-queue-runner's size limit of 2 GiB.
Setting nixosVersion to something custom is useful for meaningful GRUB
menus and /nix/store paths, but actuallly changing it rebulids the
whole system path (because of `nixos-version` script and manual
pages). Also, changing it is not a particularly good idea because you
can then be differentitated from other NixOS users by a lot of
programs that read /etc/os-release.
This patch introduces an alternative option that does all you want
from nixosVersion, but rebuilds only the very top system level and
/etc while using your label in the names of system /nix/store paths,
GRUB and other boot loaders' menus, getty greetings and so on.
Booting the demo/installer image won't work if the video memory is too
low. It boots into KDE, shows the background image and doesn't do
anything, according to @domenkozar.
Thanks to @domenkozar for reporting and testing this with 32MB.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
pkgs/os-specific/linux/kernel/common-config.nix defines HIGHMEM64G on
line 441 for 32bit systems, which implies PAE.
We now creating the OVA with PAE support enabled, which fixes bootup of
the image if people are just importing it without setting PAE
explicitly.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Especially new users could be confused by this, so we're now marking
services.virtualbox.enable as obsolete and defaulting to
services.virtualboxGuest.enable instead. I believe this now makes it
clear, that this option is for guest additions only.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Using pkgs.lib on the spine of module evaluation is problematic
because the pkgs argument depends on the result of module
evaluation. To prevent an infinite recursion, pkgs and some of the
modules are evaluated twice, which is inefficient. Using ‘with lib’
prevents this problem.
This is a rather large commit that switches user/group creation from using
useradd/groupadd on activation to just generating the contents of /etc/passwd
and /etc/group, and then on activation merging the generated files with the
files that exist in the system. This makes the user activation process much
cleaner, in my opinion.
The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be
properly defined (if <user>.createUser is true, which it is by default). My
pull request adds a lot of uids/gids to config.ids to solve this problem for
existing nixos services, but there might be configurations that break because
this change. However, this will be discovered during the build.
Option changes introduced by this commit:
* Remove the options <user>.isSystemUser and <user>.isAlias since
they don't make sense when generating /etc/passwd statically.
* Add <group>.members as a complement to <user>.extraGroups.
* Add <user>.passwordFile for setting a user's password from an encrypted
(shadow-style) file.
* Add users.mutableUsers which is true by default. This means you can keep
managing your users as previously, by using useradd/groupadd manually. This is
accomplished by merging the generated passwd/group file with the existing files
in /etc on system activation. The merging of the files is simplistic. It just
looks at the user/group names. If a user/group exists both on the system and
in the generated files, the system entry will be kept un-changed and the
generated entries will be ignored. The merging itself is performed with the
help of vipw/vigr to properly lock the account files during edit.
If mutableUsers is set to false, the generated passwd and group files will not
be merged with the system files on activation. Instead they will simply replace
the system files, and overwrite any changes done on the running system. The
same logic holds for user password, if the <user>.password or
<user>.passwordFile options are used. If mutableUsers is false, password will
simply be replaced on activation. If true, the initial user passwords will be
set according to the configuration, but existing passwords will not be touched.
I have tested this on a couple of different systems and it seems to work fine
so far. If you think this is a good idea, please test it. This way of adding
local users has been discussed in issue #103 (and this commit solves that
issue).
A null password allows logging into local PAM services such as "login"
(agetty) and KDM. That's not actually a security problem for EC2
machines, since they do not have "local" logins; for VirtualBox
machines, if you local access, you can do anything anyway. But it's
better to be on the safe side and disable password-based logins for
root.
