referencing a mount point from inside chroot
Preston Holmes
with a chroot environment.
I'm trying to add a step to my python radmind wrapper, which
implements the idea of running a set of system commands from a
chrooted env that has preserved copies of the versions of tools and
libraries that are compatible with the currently running kernel in the
case when the originals have been upgraded.
One of the artifacts of doing these updates with radmind is that the
volume is not properly blessed. I could copy the boot.efi file
directly, but I'm trying to be less fragile and use the bless command.
However the bless command can't access the target volume from inside
the chroot env
Is there a way? Or do I just accept one verbose boot and put this in
my "first boot after radmind" launchd script
Python:
os.chroot (tools_dir)
boot_loc = os.path.join(radmind_root,'System/Library/
CoreServices/')
bless_cmd = ['bless','--folder', boot_loc, '--bootefi', '--
bootinfo', '--setBoot']
print bless_cmd
call(bless_cmd)
Output:
Post Update Actions
['bless', '--folder', '/System/Library/CoreServices/', '--bootefi', '--
bootinfo', '--setBoot']
No mount point for /System/Library/CoreServices/
Can't determine mount point of '/System/Library/CoreServices/' and ''
restarting now
reboot: / is busy updating; waiting for lock
Karl Kuehn
wrote:
>
> I know there are several of you spent a fair amount of time dealing
> with a chroot environment.
>
> I'm trying to add a step to my python radmind wrapper, which
> implements the idea of running a set of system commands from a
> chrooted env that has preserved copies of the versions of tools and
> libraries that are compatible with the currently running kernel in the
> case when the originals have been upgraded.
Having both experience with a similar wrapper written in Perl, and
with chroot environments, I am going to caution you away from this
approach. The problem I ran into was that if the server got overloaded
while making changes then you could be left with a partially updated
scripting environment. This is especially true since parts of the
scripting environments are in /Library while others are in /bin or /
System. I found that the interpreters still were useable, but that
things broke when trying to get dependancy lists to build the chroot
environment.
My plan had been to create an equivivelent system in C to create
almost no dependancies this summer, but being laid off got in the way,
and in my new job (starting next week) I don't think that I will be
using Radmind.
Preston Holmes
On Jul 24, 2009, at 1:16 PM, Karl Kuehn wrote:
> Having both experience with a similar wrapper written in Perl, and
> with chroot environments, I am going to caution you away from this
> approach
Well, given I don't have the skills or time to create a complete env
in C - this is the best approach I have ;-)
I've yet to see any issues with just calling reboot from the chroot
env - it has relatively few dependencies.
My feeling is that the interpreter and any imported modules are pretty
much "in memory" and safe to finish executing the current run.
A borked radmind run that doesn't error is pretty hard to guard
against - my plan is to set the boot to a netinstall if lapply exits > 0
the netinstall lays a new image - with a first boot launchd item that
radminds the machine
I think I'll just live with a single verbose boot as an acceptable
glitch.
(congrats on scoring a new job - hopefully you will continue to be
able to build great community tools).
-Preston
Greg Neagle
Of course, if a commercial option is available, I'd recommend that
over munki...
-Greg
On Jul 24, 2009, at 1:16 PM, Karl Kuehn wrote: