Post postinstall configuration -- Setup Agent (aka firstboot)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Hi Matt,

The issue you are talking  about here is classic kickstart %post
material. If your network is not setup, activate the network in %post as
well - it would work fine.

Once anaconda has setup the system, %post commands are run inside a
chroot to the the newly installed system. have you tried running
dhclient in %post ?

Something completely off the top of my head : why not use a %post
--nochroot and copy the running environments resolv.conf into the
/mnt/sysimage/etc/ directory :) might work, might not. please try and
let us know how you get along!

Matt Lawrence wrote:
>>There is a "firstboot" init script (e.g.,
>>/etc/init.d/firstboot) that looks for select files (e.g.,
>>/etc/sysconfig/firstboot).  Depending whether it exists or
>>doesn't exist, the firstboot init script -- if set to start
>>for the run-level -- does or doesn't do something.  It will
>>then create/delete the file at the end of the run, as
>>appropriate, to prevent it from running next time.
> 
> 
> The firstboot package has various dependencies that I don't really
> want.  But it could be a good model.
> 

If you do decide to go down this route look at : /usr/share/firstboot
a lot of the dep's for firstboot itself come from its requests on X,
looking through the code - you should be able to easily work around
that. Specific files you prolly want to look at are

firstboot.py and textWindow.py

Add hooks at an appropriate place.


> Given the limitations of what can actually be run during the %post
> phase, I'm not sure if it is easier.  There are warnings about lack of
> name resolution if the system is configured for DHCP.

I havent seen this...

> While it is possible for me to install a custom package before the
> first reboot, mixing it in with all the CentOS packages in the install
> server seems to be a really bad idea. 

yeah :) avoideable. You are otherwise looking at rebuilding installer
components.

> 
>>There are a lot of options.  I just find (and this is just my
>>experience/preference), that the little extra time in
>>creating an /etc/init.d/ script (with a simple
>>start|stop|status parameter) and associated config/flag file,
>>is a lot easier and less ambiguous than running "echo >>" or,
>>better yet, "sed -e" on /etc/rc.d/rc.local.
> 
> 
> Good point, but how do you suggest I bootstrap it in?
> 

perhaps, rpm install into the sysimage chroot ?


-- 
Karanbir Singh : http://www.karan.org/ : 2522219@icq

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux