[systemd-devel] [PATCH 2/3] Allow $SYSTEMD_PRETEND_INITRD to override initramfs detection

[Lennart Poettering]

On Mon, 04.05.15 12:51, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:

> On Mon, May 04, 2015 at 02:55:39AM +0200, Lennart Poettering wrote:
> > On Sat, 02.05.15 13:16, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:
> > 
> > > When testing generators and other utilities, it is extremely useful
> > > to be able to trigger initramfs behaviour.
> > 
> > Hmm, what about the following solution: instead of checking with
> > access() for /etc/initrd-release and then also checking with statfs()
> > on / whether the root disk is writable, maybe we should just
> > immediately invoke statfs() on /etc/initrd-release and check the
> > results. If the call returns ENOENT we know that the file doesn't
> > exist, and if it returns useful data we can verify if it's tmpfs. 
> > 
> > Now, with that in place to test initrd code something like this
> > suffices:
> >         
> >         touch /etc/initrd-release /run/initrd-release
> >         mount --bind /run/initrd-release /etc/initrd-release
> > 
> > As that would result in a file in /etc/initrd-release that is backed
> > by tmpfs....
> > 
> > In general I'd be very conservative when adding new APIs (which is
> > basically what $SYSTEMD_PRETEND_INITRD would become), especially if we
> > only need them for debugging, they are are quiet dangerous and when we
> > have other options too...
> Hm, this would require root privileges, and is a global setting. I'd like to
> by able to do something like this:
> 
>  mkdir /tmp/x && SYSTEMD_PRETEND_INITRD=0 ./systemd-fstab-generator /tmp/{x,x,x}
>  mkdir /tmp/y && SYSTEMD_PRETEND_INITRD=1 ./systemd-fstab-generator /tmp/{y,y,y}
>  diff -r /tmp/{x,y}
> 
> If I have to issue some sudo stuff in between than it's probably not
> worth it.
> 
> What about having a compilation time switch (like -DVALGRIND that we
> already have), which would be used to conditionalize support for
> SYSTEMD_PRETEND_INITRD, and potentially similar things later on? This
> would make it fairly easy to build or even install systemd with
> support for this, without creating a public API.

Sure, you could even check for optimized builds with ifdeffery, i'd be
fine with that. I just really don't want this to become API...

Lennart

-- 
Lennart Poettering, Red Hat