[Novalug] It really *IS* systemd's fault this time!

Bryan J Smith b.j.smith@ieee.org
Tue Jul 21 17:19:50 EDT 2015


Here's the thing ...

There's a general issue with the Anaconda chroot environment that causes
issues with more than just systemd.  Just because old init scripts and
legacy functions allowed it doesn't mean it always worked.  ;)

And to go one step further ...

Most Linux (let alone non-Linux) installation environments (not just
Anaconda), one that aren't a "Live" and "Full" system, have this issue in
general, let alone when you chroot to another instance/install even in a
"Live" environment.

Hence ... what do other solutions use?

You hinted at it ... They do things on first-boot, when the "real" system
is actual, known state and results in a very determistic mode and related
results.  ;)

And what would be one of those examples?

Big one:  Cloud-init.  ;)

Another one:  Start the service manually.  Why?  Because the init system
often doesn't start it, and its dependencies, correctly on the chroot
environment, for the actual, real, non-chroot system.  Seen that many times
-- including with data loss as a result.  :_(

I.e., yes, it's systemd PID 1's fault it (but not the only one that) no
longer allows you to do things in a chroot environment, because it's not a
best practice to do such, except manually and/or via the for the specific,
designed chroot environment.

Kinda like setting init=/bin/sh is a horrendous practice, and served much
better by hitting breakpoints (via the rd.break parameter) in the
all-important, all-essential initrd (instead of bypassing it entirely).

It's not that systemd cannot do something ... it's that it will not do it,
because it's a bad thing.

Although it wouldn't surprise me in the future that the Fedora/RHEL
Anaconda environment lets you start services in the non-chroot environment,
so you can modify things in a chroot.  This would be a more capable, safer
solution.

-- bjs
 On Jul 21, 2015 3:48 PM, "James Ewing Cottrell, III via Novalug" <
novalug@firemountain.net> wrote:

> Doing a CentOS 7 install, and in my %post script I want to configure the
> BMC.
>
> So I do something like:
>
> systemctl enable ipmi.service
> systemctl start  ipmi.service
> ipmitool this-command
> ipmitool that-command
> ipmitool something else
>
> The enable command works nicely, but I get a message from the start
> command saying:
>
> Running in chroot, ignoring request
>
> OOPS!!!
>
> Yes, I know why. RedHat's Bugzilla Bug 111065 dated 6/18/2014 has status
> Closed/WontFix.
>
> Sigh.
>
> Well, I suppose I can simply create a script in /root (or even in
> /etc/rc.local) to do it later.
>
> JIM
> **********************************************************************
> The Novalug mailing list is hosted by firemountain.net.
>
> To unsubscribe or change delivery options:
> http://www.firemountain.net/mailman/listinfo/novalug
>



More information about the Novalug mailing list