# Customizing devos after install for my use-cases

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


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

https://bugzilla.gnome.org/show%5Fbug.cgi?id=649324#c4

## Actually it’s not so bad, as long as nixos-enter works

Nope:

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