aboutsummaryrefslogtreecommitdiffstats
path: root/README.md
blob: 4435964adeacf097944037baf7558743db0feedc (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
# nipsy's NixOS configuration

This repository is the starting point for storing all relevant NixOS configurations.

## Layout

This repository currently contains two systems I've configured similarly to track the current unstable NixOS branch, but with one system being a more home focused package set versus the other designed for work.

By building on the modularity of this repository, it should be possible to capture any number of various combinations of system and user configurations from one or more people.  I think everything is mostly laid out in such a way to support doing this very easily.

This also means that as people come up with potentially new combinations of things, other people might be able to also benefit from them.  I think that's sort of part of the charm that Nix in general provides.

The section that follows is about a VM configured more for work and can be thought of as a template or starting point to define your own host, mostly with the same packages potentially, and with whatever personal touches you want for your own standard user account.

## kaitain/richese

Both of these hosts are Virtalbox VM's.  Currently, kaitain is configured as a more modern EFI based system while richese is still configured as an older BIOS based system.  This means that richese needs an extra BIOS boot partition defined in its disko configuration and uses GRUB instead of systemd-boot.

Beyond that, you'll probably want to enable bidirectional clipboard support under General -> Advanced.

Both systems are configured with 12288 MB of RAM currently so they can be run concurrently on a 32GB laptop.

kaitain is using the newer ICH9 chpiset whereas richese is configured using the older PIIX3 chipset.  I/O APIC is enabled on both as well as hardware clock being in UTC.

Both use 8 CPU cores with PAE/NX enabled along with nested paging.

Both use VMSVGA with 3D acceleration enabled (recently disabled due to X segfaulting when trying to initialize GLX) and the default 16MB of video memory.

Both use a virtio-scsi storage controller with host I/O cache enabled.

Both use Intel HD audio.

Both use the virtio-net adapter.  richese is currently configured to use NAT for networking and kaitain uses a bridged adapter using the wireless adapter.  This is necessary to bypass the security theater, but might not always work depending on the exact hardware in the laptop.

Both use an automounted shared folder pointing at my host user's Downloads directory with full read/write access.

Most importantly, depending on the host configuration, you might end up with the green frog icon in the status bar in the bottom right when starting your Virtualbox VM, instead of the preferred blue V which indicates CPU virtualization support is working as intended.  If this is due to the broken ass host OS being Windows and forcing Hyper-V to be enabled, there are a number of features which might need to be turned off in Windows to keep Hyper-V at bay.  Notably, these two links should provide some more information on how to disable everything:

https://forums.virtualbox.org/viewtopic.php?f=25&t=99390
https://learn.microsoft.com/en-us/troubleshoot/windows-client/application-management/virtualization-apps-not-work-with-hyper-v

After doing all of the above nonsense, I still needed to create a task scheduler job in Windows that actively pushes a couple of registry changes to forcibly disable VBS.  This gets reverted every couple of reboots, give or take a few and then persists for usually a couple as well.  Some subsystem in Windows actively tries to reenable VBS periodically which led me to implementing this strategy.  It works, but it's ugly.

You will want to start taskschd.msc.  You will need to create two files related to this also.  I dropped them both in c:\ directly to keep things simple.  You can name them whatever you like, but remember what you use as you will need to reference both files.

The first I created is c:\disable-crap.reg:

```
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard]
"LsaCfgFlags"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"LsaCfgFlags"=dword:00000000
```

The second I created is c:\disable-crap.bat:

```
c:\windows\regedit.exe /s c:\disable-crap.reg
```

Back in task scheduler, I created a folder named disable under the main Task Scheduler Library and created a new task named the same.  Under the General tab, it will list your user name as the author, but below that in the security options, you will want to change the user that this task runs as to SYSTEM and check the box near the bottom to allow it to run with the highest privileges.  Under Triggers, I added two triggers, one at system startup and one at log on of any user.  Under Actions, I told it to start a program and pointed it to c:\disable-crap.bat.  I don't believe I changed any of the other options under any other tabs, but you should be able to check the History tab to see that it is running when it is supposed to be.  That should be everything you need for this step, but as stated above, Windows will actively fight you over this, so you can always check msinfo32 at the very bottom right after you log in to check whether a hypervisor is detected (it will say almost exactly this at the bottom of the window past all of the Hyper-V entries if it has managed to enable itself again).  If it has, simply reboot immediately and try again.  I've had it take upward of three or four reboots sometimes, but usually one or two suffices.

I also had to disable full memory encryption in the BIOS.  Other steps might also be necessary, depending on how broken Windows has become when you're reading this.

### Installation

You can download the minimal ISO image from https://nixos.org/download/ to start.  Once in the installer command line, you can grab this repo using:

```
curl -O https://arrakis.bitgnome.net/nipsy/git/nix/snapshot/nix-master.tar.zst
tar xavf nix-master.tar.zst
```

To start the installation script, including provisioning the local storage via disko, run:

```
nix-master/scripts/install-with-disko richese
```

which should walk you through the rest of the installation.

### Post-installation maintenance

As part of the installation, the Git repo you grabbed above to perform the installation was also copied to /etc/nixos on your new system.  Keeping a NixOS system up to date means keeping your living system configuration up to date also.

To make this task slightly easier if this is your first NixOS installation, you can run the script `/etc/nixos/scripts/pretty-rebuild` as root which will perform a standard nixos-rebuild command to upgrade the system along with some informational output after that command finishes on what may have changed.