172 lines
5.8 KiB
Plaintext
172 lines
5.8 KiB
Plaintext
A brief guide to backward-incompatible changes
|
|
that are likely to break configurations or workflows
|
|
|
|
2023-07-13
|
|
|
|
* a significant re-arrangement of modules and services, which will
|
|
probably break any configuration written before this time. For a
|
|
detailed explanation, see
|
|
https://www.liminix.org/doc/configuration.html#modules
|
|
|
|
2023-12-10
|
|
|
|
* configurations (usually) need no longer import modules from
|
|
modules/outputs because devices are expected to do this instead. This
|
|
change is because the outputs that make sense in any given context are
|
|
usually a property of the device being installed onto.
|
|
|
|
2023-12-11
|
|
|
|
* rename outputs.flashimage to outputs.mtdimage (and also diskimage to
|
|
mbrimage). This change is made in the expectation that "fooimage" is
|
|
the name of an outputs that gloms together other filesystem-like
|
|
outputs with some kind of partition table - so we might in future have
|
|
gptimage or lvmimage or ubimage.
|
|
|
|
2024-01-03
|
|
|
|
Liminix is now targeted to Nixpkgs 23.11 (not 23.05 as previously).
|
|
Upstream changes that have led to incompatible Liminix changes are:
|
|
|
|
* newer U-Boot version
|
|
* util-linux can now be built (previously depended on systemd)
|
|
|
|
2024-01-30
|
|
|
|
New port! Thanks to Arnout Engelen <arnout@bzzt.net>, Liminix
|
|
now runs on the TP-Link Archer AX23.
|
|
|
|
2024-02-12
|
|
|
|
* We now build wifi drivers (mac80211) from the same kernel source as
|
|
the running kernel, instead of using drivers from the linux-backports
|
|
project. This may be a regression on some devices that depend on
|
|
OpenWrt patches for wireless functionality: if you have a device that
|
|
used to work and now doesn't, refer to OpenWrt
|
|
package/kernel/mac80211/patches/ to see if there's something in there
|
|
that needs to be applied.
|
|
|
|
* in general, we build kernel modules (e.g. for nftables) at the same
|
|
time as the kernel itself instead of expecting to be able to build
|
|
them afterwards as though they were "out of tree". Refer to commit
|
|
b9c0d93670275e69df24902b05bf4aa4f0fcbe96 for a fuller explanation
|
|
of how this simplifies things.
|
|
|
|
2024-02-13
|
|
|
|
So that we can be more consistent about services that would like their
|
|
state to be preserved across boots (assuming a writable filesystem)
|
|
these changes have been made
|
|
|
|
* /run/service-state has been moved to /run/services/outputs
|
|
to better reflect what it's used for
|
|
* /run/services/state is either a symlink to /persist/services/state
|
|
(if there's a writeable fs on /persist) or a directory (if there
|
|
isn't)
|
|
|
|
The change will lose your ssh host key(s) unless you copy them from
|
|
the old location to the new one before rebooting into the new system
|
|
|
|
mkdir -m 02751 -p /run/services/state/dropbear
|
|
cp /persist/secrets/dropbear/* /run/services/state/dropbear
|
|
|
|
The `output`, `mkoutputs` functions defined by ${serviceFns}
|
|
have been updated for the new location.
|
|
|
|
2024-02-16
|
|
|
|
New (or at least, previously unreported) port! Liminix now runs on the
|
|
Turris Omnia and has been serving my family's internet needs for most
|
|
of this week. Thanks to NGI0 Entrust and the NLnet Foundation for
|
|
sponsoring this development (and funding the hardware)
|
|
|
|
2024-02-21
|
|
|
|
New port! Thanks to Raito Bezarius, Liminix now runs on the Zyxel NWA50AX,
|
|
an MT7621 (MIPS EL) dual radio WiFi AP.
|
|
|
|
2024-04-29
|
|
|
|
The setup for using `levitate` has changed: now it accepts an entire
|
|
config fragment, not just a list of services. Hopefully this makes it
|
|
a bit more useful :-)
|
|
|
|
defaultProfile.packages = with pkgs; [
|
|
...
|
|
(levitate.override {
|
|
config = {
|
|
services = {
|
|
inherit (config.services) dhcpc sshd watchdog;
|
|
};
|
|
defaultProfile.packages = [ mtdutils ];
|
|
users.root.openssh.authorizedKeys.keys = secrets.root.keys;
|
|
};
|
|
})
|
|
];
|
|
|
|
2024-07-16
|
|
|
|
* structured parameters are available for the pppoe service
|
|
|
|
* The "wan" configuration in modules/profiles/gateway.nix has changed:
|
|
instead of passing options that are used to create a pppoe interface,
|
|
callers should create a (pppoe or other) interface and pass that as
|
|
the value of profile.gateway.wan. For the pppoe case this is now only
|
|
very slightly more verbose, and it allows using the gateway profile
|
|
with other kinds of upstream.
|
|
|
|
2024-8-16
|
|
|
|
As part of implementing log shipping, the default directory for system
|
|
logs has beenchanged from /run/uncaught-logs to /run/log
|
|
|
|
2024-10-09
|
|
|
|
liminix-rebuild is being deprecated. From hereon in, the preferred way
|
|
to do an incremental update on an installed device with a writable
|
|
filesystem is to build the systemConfiguration output
|
|
|
|
nix-build -I liminix-config=hosts/myhost.nix --argstr deviceName turris-omnia -A outputs.systemConfiguration
|
|
|
|
and then run the generated `install.sh` script
|
|
|
|
result/install.sh root@192.168.8.1
|
|
|
|
2024-12-16
|
|
|
|
Config options changed: if you had set config.hardware.dts.includes
|
|
(maybe in an out-of-tree device port) to specify the search paths
|
|
in which dtc finds include files, you will need to change this to
|
|
hardware.dts.includePaths.
|
|
|
|
The "new" hardware.dts.includes option is now for dtsi files which
|
|
should be merged into the device tree.
|
|
|
|
2024-12-19
|
|
|
|
Incremental updates changed again (but not massively). From hereon in,
|
|
the preferred way to do an incremental update on an installed device
|
|
with a writable filesystem is to build the updater output
|
|
|
|
nix-build -I liminix-config=hosts/myhost.nix --argstr deviceName turris-omnia -A outputs.updater
|
|
|
|
and then run the generated `update.sh` script. See
|
|
https://www.liminix.org/doc/admin.html#updating-an-installed-system
|
|
|
|
2024-12-22
|
|
|
|
outputs.zimage is now outputs.kernel.zImage. This is unlikely to
|
|
affect many people at all but I mention it anyway.
|
|
|
|
2024-03-11
|
|
|
|
The fennel function (svc.open ...) now expects to be given the store
|
|
directory of a service derivation, not a direct path to the .outputs
|
|
directory. Thus
|
|
|
|
(svc.open "/nix/store/eeeeeeeeeeeeee-hellod")
|
|
not
|
|
(svc.open "/nix/store/eeeeeeeeeeeeee-hellod/.outputs")
|
|
|
|
This simplifies most extant uses of it
|