| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
both don't exist anymore
|
|
|
|
| |
The namespace was kind of hard to remember, so let’s just call it openlab.
|
|
|
|
| |
The machine’s mainboard broke, so it’s gone.
|
| |
|
| |
|
|
|
|
|
|
| |
This is only a placeholder right now so we get Hydra builds.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
| |
Why do I fix up a machine that doesn't exist anymore?
This was from a time where I had no laptop and was travelling around
with an USB stick in order to have a working environment on other
machines, but that's no longer the case.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
| |
This reverts commit dfd3d86562f09d812b330893cec053ab3d371bdf.
The machine is back on NixOS again :-)
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @brokkoliberta
|
|
|
|
|
|
|
| |
Tyree is dead, no further comment...
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @brokkoliberta
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In his configuration he had machine_common.nix which was imported from
the other machine_*.nix files. However in order to start modularizing
I've converted machine_common.nix into a proper NixOS module which now
resides in modules/user/devhell/profiles/base.nix and can be simply
activated via:
vuizvui.user.devhell.profiles.base.enable = true;
Apart from that I've removed the following configuration definitiens
from machine_common.nix:
nix.binaryCaches = [
"https://headcounter.org/hydra/"
"https://cache.nixos.org/"
];
nix.requireSignedBinaryCaches = true;
nix.binaryCachePublicKeys = [
"headcounter.org:/7YANMvnQnyvcVB6rgFTdb8p5LG1OTXaO+21CaOSBzg="
"cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY="
];
nix.nixPath = lib.mkOptionDefault [
"nixpkgs=/home/dev/git/remote/other_github/nixpkgs"
];
The reason for removing them is because we already handle that via the
vuizvui core modules (modules/core/common.nix).
I've tested this by evaluating the machines by temporarily setting
"allowUnfree = true" (which is part of another module I didn't migrate
yet) and it succeeds.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @devhell
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unfortunately, mmrnmhrm has died because of three blown up capacitors
which resulted in hard shut downs due to CPU0 temperature values that
were out of range.
At first I assumed a real temperature problem and thus vacuumed the fan
and everything else, applied new thermal paste and it still failed after
a few minutes. What I found a bit odd was the fact that the machine
powered off even though the last reading of the CPU temperature was 40
degrees Celsius, so that definitly wasn't the problem.
So I went on to look for any blown capacitors on the main board, because
that's probably one of the most frequent cause of hardware failure... at
least for mainboards and monitors. One of the three capacitors I found
to be leaking seems to be leading to the CPU temperature sensor as far
as I can tell (I didn't test with a multimeter though, because I have
lent it out to someone else).
While it shouldn't be hard to fix the blown capacitors (apart from the
fact that we had national holiday during the Easter week), my long-term
goal was to make mmrnmhrm obsolete anyway, so it was a good opportunity
to do exactly that.
The reason why I wanted to get rid of mmrnmhrm was that it has been a
very slow machine since commit 2df7ee103a01da34c9c82235bc286dde35e0f1ba,
which was essentially a hardware downgrade back then.
Dnyarri always has been the better machine hardware-wise but I couldn't
use it to its full potential because it had a cooling issue. The latter
has been resolved a few weeks ago, where I replaced the CPU fan and it's
now not only less noisy but stays at below 50 degrees Celsius even on
high load.
Merging mmrnmhrm into dnyarri also means, that we now have a new disk
layout:
+---------------+--------------+--------------+--------------+
| Disk 1 | Disk 2 | Whole disk 3 | Whole disk 4 |
+---------------+--------------+--------------+--------------+
| EFI partition | crypt-vault | crypt-root-3 | crypt-root-4 |
| crypt-swap-1 | crypt-swap-2 +-----------------------------+
| crypt-root-1 | crypt-root-2 |
+---------------+--------------+
Disk 1 and 2 use GUID partitions while disk 3 and 4 don't have a
partition table but use btrfs across the whole device. The crypt-vault
partition is solely for unlocking other crypto volumes so that a single
passphrase unlocks all of the LUKS containers rather than needing to
provide 6 passphrases.
Also, I've migrated to using UEFI for booting, which is why there now is
an EFI partition as well. Having no redundancy on the EFI and the
crypt-vault partitions doesn't hurt so much because in the event of
drive failure all of the containers can still be unlocked via a
passphrase instead of the vault key.
Disk 3 and 4 are the disks that were formerly installed into mmrnmhrm
and now comprise one big btrfs volume together with the two disks (1 and
2) already present inside dnyarri.
Instead of RAID1 on data and metadata, the btrfs file system layout now
is RAID10 for data and metadata.
This merge also removes synergy for obvious reasons (no other machine
anymore) and disables kmscon because it was just a test in the first
place and I found it a bit annoying to work with.
Summary: Mmrnmhrm is (are?) dead, long live dnyarri!
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
This machine hasn't been in use since a year or even longer and the
successor machine (brawndo) is already in use since a while, so we can
safely drop the machine.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
| |
Currently only a very minimal base configuration, nothing too fancy yet.
The machine is going to serve as a audio/media server in my living room.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
| |
This one more or less shares the same profile as "notsure", but I'm too
lazy right now to consolidate and/or modularize everything properly.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
| |
Only some machines should get the full config (with all packages).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 65435d827c846ab2eef966601cd0490591b8dbe9.
Commit d730df7 fixed the meta.hydraPlatforms attribute, so the generic
channel now should build the patched gitit version as part of its
constituents and we don't need a dummy machine just for that anymore.
Other than that, the package now also gets built as a separate job to
allow for one-click installs.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @Profpatsch
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to 302fb4f4bc0213b231b9bf5b98093c60d3917313 the package should
be included in the hydra build, but it is not usable, because there is
no channel that waits for the gitit build to succeed.
This stub exists until someone finds out how to create such a
channel (aka the channel building mechanism is documented in a way that
it can be used by people not deeply familiar with both nixpkgs and
hydra).
cc @aszlig
|
|
|
|
| |
one can easily tell I don't currently use the vuizvui channel.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to @Profpatsch the whole point of this dummy machine was that
the patched gitit version should be built on Hydra.
We don't need to have such workarounds, because we're already recursing
through all packages in the Vuizvui namespace whether meta.platforms
includes a system that we support on our Hydra.
This has been done with a4d6395 so "website-vm" is obsolete now.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
| |
It doesn't list a single machine and the profile module also uses the
pluralized version, so let's pluralize the file name as well.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @Profpatsch
|
|
|
|
|
|
|
|
|
|
|
|
| |
Right now we're not using the system attribute at all and we can still
use nixpkgs.system to set the attribute for a particular machine.
So we now can pass configuration attributes to the second argument of
callMachine *directly* instead of using specific subattributes, which I
think feels is a more natural way so users don't need to look up that
"extraConfig" is for adding configuration values.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
This is to name it closer to what NixOps calls a network expression, so
that it's clear that there is more abstraction going on like setting the
hostname rather than just being a plain mapAttrs over callMachine.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
We now no longer need to import the call-machine.nix directly but now
can use import <vuizvui/lib> in order to get *both* the callMachine and
the callMachines function.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Should make the configurations much more easy to read.
I did a small comparison between the machine derivations of the old
Labtop and the Labtop with the new callMachines implementation using:
diff -U 0 =(nix-store -qR old_labtop.drv | sort -t- -k 2) \
=(nix-store -qR new_labtop.drv | sort -t- -k 2)
The following store paths were different in the output:
/nix/store/...-etc.drv
/nix/store/...-initrd.drv
/nix/store/...-kernel-modules-shrunk.drv
/nix/store/...-nixos.conf.drv
/nix/store/...-nixos-system-labtop-16.09pre82222.fc92bbf-vuizvui.drv
/nix/store/...-stage-1-init.sh.drv
/nix/store/...-system-units.drv
/nix/store/...-unit-systemd-modules-load.service.drv
This is okay and is due to the reversed module evaluation order, because
we now have the module definition enabling the Labtop profile in
extraConfig instead of in the root config.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @Profpatsch
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is particularly needed for the Labtops and it allows to call a full
attribute set of machines to be incorporated into a single file as one
big attribute set.
Its functionality is kind of similar to the NixOps network expressions
by providing default hostnames (in our case with a priority of 900 to
still make it overridable without pain).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
| |
Draws out the general config for all Labtops in its own module and
creates a structure to specify the setting which are different.
|
|
|
|
|
|
|
|
|
| |
This was a very old effort to NixOSify "heinrich" which unfortunately
didn't happen and I'm not sure whether "heinrich" even exists anymore.
The tests were broken anyway, so I doubt anyone would grief over it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
Obsoleted by tyree, even though tyree isn't fully working yet it doesn't
make sense to build a lot of stuff just for a machine that doesn't get
updated anymore.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently this is just a somewhat basic configuration, because the
hardware (an ASUS T100HA) is going to get us in trouble.
For example right now not even the display is working correctly, neither
is WiFi, but we're going to fix that real soon[TM] :-)
The configuration is pretty much based on the "haenk" config, which this
machine will replace once everything is working.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
Another machine I manage for someone else, currently nothing too fancy
or complex here yet, except that it's very old hardware.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
| |
Not my day I guess. Aahhhhhhh
|
|
|
|
| |
I am stupid
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This gets rid of the use attribute, which is now called "config". We had
the "config" attribute before but it was kinda pointless, because it was
just the import of the path and nothing else.
So the config attribute now is the machine configuration with all of the
vuizvui modules imported as well.
The "build" attribute is now called "eval", which is more appropriate,
because it's the evaluation of the configuration and not the finished
system build.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
The function is gettin rather large, so it makes sense to move it into
another file so that the default.nix in machines/ won't be cluttered up
with all the implementation-specific details.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is to make it easier testing various vuizvui machine
configurations for example with my machine "mmrnmhrm" by using the
following command:
nix-build machines -A aszlig.mmrnmhrm
The build product is a VM that can be started using:
./result/bin/run-*-vm
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
I've added a "managed" namespace here, which should include all machines
that are not my own but I manage for other people.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a very hacky approach, because patching that file also requires
us to patch the imports it's referencing.
The first reason why I needed to patch is that there is no "modeset" you
can add to kernelParams and re-enable modesetting that way.
And the second reason is because we don't have something like mkRemove
or mkFilter in the module system, so we could filter out items from a
list.
Another option here would be to mkForce-override the kernelParams, which
would imply that we'd need to duplicate a lot of these options (for
example init=...).
So in the long run we surely need to have a better way to override
lists, but until that I'm leaving it with the patched approach.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
We can't really do a "mkForce {}" or "mkForce null" on the submodule
type and the upstream module throws an error on null values, so we
simply define a dummy fileSystem with the noauto option set.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We now do it the exact opposite way than introduced in 27dce7b. Instead
of evaluating the machine config and stripping off the options we don't
want to conflict with the iso-image.nix module, we now wrap the
iso-image.nix module itself and just mkForce the values we don't want to
collide.
The reason for this is that the previous implementation just didn't work
because dependent module options from the machine config (for example
config.system.build.*) were already evaluated and thus we end up with
overriding configuration options but get an initrd with the machine
options (which we actually want to override) instead of the
fileSystem/boot options that come with the iso-image.nix module.
Although I'm not quite happy with this approach, it's still better than
the old one and if iso-image.nix gets conflicting options we at least
get a better error message rather than the definitions simply being
stripped off.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
| |
Introduced in NixOS/nixpkgs@f9bd72f24cfc8c160d144615522b0bc692cde9d0.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I know it's a somewhat hacky approach to strip off "_module",
"boot.loader" and "fileSystems" from the machine config, but that should
be the options which are to be set by iso-image.nix but that way we can
re-use the upstream module.
Also, if one of our modules sets an option without a proper "vuizvui."
namespace, we get an error as well. But it's our policy anyway to always
namespace with "vuizvui." so it's even good to get an error here.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
This file is just defaulting to <nixpkgs>, but we're going to substitue
it by the channel generator. We also need to make sure that we don't
have any other references to <nixpkgs>, but the latter can best be done
on Hydra's side if we don't make <nixpkgs> available to vuizvui builds.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
Useful to call the machine from configuration.nix like this:
(import <vuizvui/machines> {}).aszlig.mmrnmhrm.use
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|