Pareto Optimal Dev

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: {

-  # 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)

  1. Backup the data in the FAT16/FAT32 partition
  2. Reformat the partition to EXT4
  3. Resize EXT4 partition to desired partition size
  4. Reformat the partition back to FAT16/FAT32
  5. 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.

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


$ 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 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.

That means the “fixes” I committed had to be rolled back

That is fine I guess if you have no issues

Okay, reverting to the flake.lock of devos right now and adding the direnv override back works

I almost forgot to make the change to the uuid with all of these other problems

Alright, did that, ran install command, completed y/n prompts, now waiting for install to finish

rebooting and crossing fingers, selected new generation, and

slight annoyance, too many net devices were in hardware confiuration and have to wait for their timeout

uggh is this gonna mess up dhcp/internet?

Okay, things are working kind of… now issues with DevOS not picking up new modules I add even though called git add on them and added them to nixos.importables.suites.myEnv

and finally… after like 4-5 hours… I have emacs and can move from writing this on my laptop to my new PC