Bug 49201 - Can't exec shutdown in Kickstart ( ks.cfg)
Summary: Can't exec shutdown in Kickstart ( ks.cfg)
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: installer
Version: 7.1
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Brent Fox
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-07-16 19:55 UTC by Francois Isabelle
Modified: 2007-04-18 16:34 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2001-07-18 15:18:51 UTC
Embargoed:


Attachments (Terms of Use)

Description Francois Isabelle 2001-07-16 19:55:08 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)

Description of problem:
I use a redhat 6.2 system as a remote boot server to perform kickstart 
installations.
I find it nice to use "reboot" to skip the congratulation screen, but what 
I would like is to "shutdown" the installed system.


How reproducible:
Always

Steps to Reproduce:
1.Install via ks=nfs:192.168.1.1:/tftpboot/ks.cfg ....
2.Add a shutdown -h now to ks.cfg in the Post Install section
	

Actual Results:  The System crashed with a "kernel panic" unable to mount 
nfs 08:xx

Expected Results:  The system would properly unmount the filesystem it 
used, and whould halt

Additional info:

Is it possible to replace the reboot sequence in the installer with a few 
commands in the kickstart file?
Or to add parameters to the reboot directive in ks.cfg?

Comment 1 Francois Isabelle 2001-07-16 19:58:10 UTC
N.B. :

The remote server is RedHat 6.2 but this is not relevant.
The kickstart is used to install redhat 7 and redhat 7.1.


Comment 2 Brent Fox 2001-07-18 15:18:46 UTC
The reason that calling shutdown in the %post doesn't work is because the
installer is in a chroot environment, so that /mnt/sysimage appears to be / to
the installer at that point.  Calling shutdown from inside the chroot means that
it can't find the real root filesystem, which causes the behavior that you are
seeing.  
I talked to the other developers, and we agreed that to fix this properly would
require a change to the loader (the first stage of the installer).  The loader
needs to remain as small as possible in order to fit on boot floppies and still
leave room for drivers and such.  Although I think that this feature could be
useful in certain situations, I don't think it would benefit enough people to be
worth implementing.


Note You need to log in before you can comment on or make changes to this bug.