[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