This checks if nixpart is able to mount the filesystems from scratch again, just
with the information provided by the kickstart file.
Found an odd issue about findmnt here, because it seems to not show /mnt/boot,
even though it _is_ mounted and even shows up in /proc/self/mountinfo. I'm not
quite sure whether this is a bug or I'm doing something wrong here, but might
need some investigation.
Mountpoints are checked by adding empty canary files, remounting and checking if
the same canaries still exist. If they don't, the partitioner either has
formatted the filesystem or just not mounted the device. Either way, both
shouldn't happen, but that's why we're testing it, no? :-)
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
As the whole partitioning run is quite an invasive procedure, we want to
especially make sure that it doesn't unmount any filesystems that were mounted
before the partitioner was run.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This will ensure that we don't get errors because the kernel doesn't recognize
the new partitioning scheme on some conditions or architectures, such as i686.
See here for the Hydra build log on i686:
http://hydra.nixos.org/build/5432090/download/1/log.html
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
At the moment, we still use kickstart syntax, but this is going to change
soon[TM] to be more NixOS-integrated. The tests use emptyDiskImages option
introduced in the previous commit, so we don't have to create a whole bunch of
duplicate expressions.
Testing itself is done exclusively on /dev/vdb and /dev/vdc. And there is a
check (ensureSanity) to make sure none of the tests are actually mutating
/dev/vda.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This allows to add additional raw disk images to the VM, which therein are
available as /dev/vdb, /dev/vdc, /dev/vde and so on. Especially when testing
partitioning, this could be useful.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This works around a bug in infinality that causes broken rendering in
some cases. Issue NixOS/nixpkgs#663.
Upstream suggests that "slight" is a better/safer default in any case.
It also looks better, IMHO, YMMV.
lighttpd doesn't support loading a module more than once. If you attempt
to load a module again, lighttpd prints an error message:
(plugin.c.131) Cannot load plugin mod_cgi more than once, please fix your config (we may not accept such configs in future releases
And it's not just the error message. The module isn't loaded (or is
messed up somehow) so that neither sub-service will work properly after
this.
This is bad news for the current approach to sub-services, where each
sub-service lists the needed modules in a server.modules += (...) block.
When two sub-services need the same module we get the above issue. (And,
AFAIK, there is no way to check if a module is already loaded either.)
First I thought about an approach where each sub-service specifies the
list of plugins it needs, and that a common server.modules = (...) list
is built from the union of those lists. That would loosly couple the
sub-services with the main lighttpd nixos module expression. But I think
this is a bad idea because lighttpd module loading order matters[1], and
the module order in the global server.modules = (...) list would be
somewhat cumbersome to control.
Here is an example:
Sub-service A needs mod_fastcgi. Sub-service B needs mod_auth and
mod_fastcgi. Note that mod_auth must be loaded *before* mod_fastcgi to
take effect. The union of those modules may either be ["mod_auth"
"mod_fastcgi"] or ["mod_fastcgi" "mod_auth"] depending on the evaluation
order. The first order will work, the latter will not.
So instead of the above, this commit moves the modules from
service.modules += (...) snippets in each sub-service to a global
server.modules = (...) list in the main lighttpd module expression. The
module loading order is fixed and each module is included only if any of
the sub-services that needs it is enabled.
The downside to this approach is that sub-services need a (tiny) bit of
change to the main lighttpd nixos module expression. But I think it is
the only sane way to do it (as long as lighttpd is written the way it
is).
References:
[1] http://redmine.lighttpd.net/projects/1/wiki/Server_modulesDetails
[2] http://redmine.lighttpd.net/issues/2337
This is because it's quite commonly used in the wild. Especially at some "weird"
server hosters (no names here) which doesn't allow to change the baudrate for
their serial consoles.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
