Customizing devos after install for my use-cases
continues from installing NixOS using devos and nix flakes
make sure rebuilding works
bud rebuild $yourHostName switch
Some weird nix error, but I see it’s to do with direnv
issues with DevOS can be annoying, I know this is due to a previous workaround for direnv because of rapid development of Nix flakes while it’s not in NixOS by default.
There’s actually an issue to track this currently at divnix/devos#415 that I linked to in my commit fixing this.
In overlays/overrides.nix:
@@ -15,9 +15,6 @@ channels: final: prev: {
deploy-rs
;
- # nix is set to 2.3 in 21.11
- nix-direnv = prev.nix-direnv.override { nix = prev.nixUnstable; };
-
haskellPackages = prev.haskellPackages.override
(old: {
overrides = prev.lib.composeExtensions (old.overrides or (_: _: { })) (hfinal: hprev:
I feel like it’d be nice for their CI to check for failures like this.
I see there is a failure in their CI though of:
building '/nix/store/vibnw03hyg3cqw52fny26mslchkprwp8-hm_direnvdirenvrc.drv'...
error: unexpected end-of-file
Error: Process completed with exit code 1.
I guess they do test this, but knowing that error means “direnv updated so we can stop using our override” seems pretty tough for anyone but core contributors to notice.
Perhaps the fix would be preventing merges until CI checks pass, though that can be tricky in open source where people are already volunteering their free time and you don’t want to annoy them.
Now that we can successfully rebuild, time to configure!
Or not… During handling of the above exception, another exception occurred :S
Something to do with updating systemd-boot from 249.5 to 249.7 where profile is referenced before it’s defined.
At least the pain brings forth a thought and concept for a new page, just faster than I thought I’d get around to creating it:
Static type systems should be the default in computer programming
Oh wait… no… because there was traceback after traceback I focused on the wrong thing
This is actually an error due to the boot partition only being 96M :S
time to reboot, resize windows partition, move all partitions to the right, and resize the boot partition to the usual 512mb at the start of the disk
Let’s make the boot partion 96mb rather than 512mb to get that sweet 416mb of space and make those who dare to install another OS’s life harder!
many would blame NixOS or their linux distribution their trying to install for this error I bet, especially if they were new
Okay, that’s done reboot and run bud rebuild $host switch
err not quite, this is a new error to add to issues with DevOS:
You cannot use the flake's store path for reference.
/run/current-system/sw/bin/bud: line 29: This script requires a pointer to the writable flake root. : command not found
Oh that’s user error I think, when I cloned the repo as root to /system in the intial install it resulted in this :/
Umm… even though parted reports 512mb available in boot partition the systemd-boot script and df -h report the wrong available size
apparently running fdisk -l will show warnings and it gives us
Partition 1 does not start on physical sector boundary
I’m gonna try booting liveusb and running “check” from gparted first
GNU Parted cannot resize this partition to this size. We’re working on it!
Ah, gparted can’t resize partitions less than 256mb
The inability to resize FAT16/FAT32 file systems that are less than 256 MB remains.
Workaround: Resizing FAT16/FAT32 Partitions (less than 256 MB)
- Backup the data in the FAT16/FAT32 partition
- Reformat the partition to EXT4
- Resize EXT4 partition to desired partition size
- Reformat the partition back to FAT16/FAT32
- Restore the FAT16/FAT32 files from backup
Note that if you use file system labels you may wish to re-label the partition at this time.
https://bugzilla.gnome.org/show%5Fbug.cgi?id=649324#c4
cross fingers… I think we booted… wait no… agh the uuid is now different on the boot device :/
Will I have to reclone/redownload devos for the 4th time
maybe I can just use the first generation that looks for disk/by-label/nixos and it’ll work this time? Hopefully
nope timed out waiting for device /dev/disk/by-label/nixos
Actually it’s not so bad, as long as nixos-enter works
Nope:
$ nix-shell cannot connect to socket at ‘/nix/var/nix/daemon-socket/socket’: Connection refused
nevermind, just redownloading 20GB or w/e again and taking a break lol
Oh goodie… I think trying to use nixos-enter broke nix-shell somehow
And it’s still broke with
getting attributes of path all…-source no such file or directory for flake-utils 747e4319
I’ll update the flake.lock from my other nixos machine, commit it, then try again
that also didn’t work… idk what to even do
That wasn’t enough, what’s going on here is pretty complex
the nix override for nix-direnv is
necessary in the live usb NixOS 21.11
causes an error after you run bud rebuild $host switch
and the flake.lock in github.com/divnix/devos right now can’t be updated without removing the nix-direnv override
This sort of churn that I think is caused by backwards incompatible flake changes is perhaps the biggest source of issues, not necessarily issues with DevOS?
i wonder if flake-utils-plus users experience this as well.