Bug 56376
| Summary: | kickstart installations are (sometimes) not longer unattended | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Holger Schurig <h.schurig> |
| Component: | anaconda | Assignee: | Brent Fox <bfox> |
| Status: | CLOSED WORKSFORME | QA Contact: | Brock Organ <borgan> |
| Severity: | low | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.2 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2001-11-21 09:50:19 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Actually, we test kickstart more than any other installation method. We have an automated test suite that spits out all kinds of kickstart files for our test bed machines to install, and they sit there and install around the clock. I was able to do an NFS kickstart install using the file you used, and I only changed the IP address and the name of the NFS server. What driver does your network card use? My best guess is that the driver it needs has been moved to the drvnet.img disk, and the installer is getting confused when it tries to do an NFS install with no network. The driver is eepro100 Ok, sorry, I actually reported more bugs in one message, I shouldn't have done this. Consider the bug on "it looks like the kickstart file has not been processed at all" closed. In the SYSCONFIG.CFG file I forgot the trailing '/'. The ks= entry ends in '.../mundn'. So I guess that kickstart was looking for such a file and not finding it (there was only such a directory there). Maybe an error msg would have been better. I changed this to '.../mundn/ks.cfg' and it worked. However, the other error with ks=floppy and the strange questions still apply. If you just say 'linux ks=floppy', then anaconda looks for a file called 'ks.cfg' on the root of the floppy. I don't really understand what the problem is now that anaconda seems to be processing the kickstart file properly. Please reopen this bug report if you are still seeing problems. Thanks for your report. |
Description of Problem: I did about 50 kickstart installations with RH 6.2, they worked complety unattended. I inserted the bootdisk, and RedHat was installing totally unattended. Wow. Now, with RH 7.2 this seems to be no longer necessary. Version-Release number of selected component (if applicable): How Reproducible: Try the following kickstart file: install lang en_US langsupport --default en_US en_US keyboard de-latin1-nodeadkeys mouse msintellips/2 --device psaux skipx # The following is really only one line network --device eth0 --bootproto static --ip 192.168.233.7 --netmask 255.255.255.0 --gateway 192.168.233.1 --nameserver 192.168.233.1 --hostname mnz7.mn-logistik.de rootpw --iscrypted $1$kTqAzEvP$JOjUIugRoDPKbuDmjDUVa. firewall --disabled authconfig --enableshadow --enablemd5 timezone Europe/Berlin bootloader clearpart --linux part / --fstype ext3 --size=1024 part swap --size=128 and the following SYSLINUX.CFG on the bootnet.img disk: default ks prompt 1 timeout 10 display boot.msg F1 boot.msg F2 general.msg F3 expert.msg F4 param.msg F5 rescue.msg label linux kernel vmlinuz append initrd=initrd.img lang= devfs=nomount ramdisk_size=7168 vga=788 label text kernel vmlinuz append initrd=initrd.img lang= text devfs=nomount ramdisk_size=7168 label expert kernel vmlinuz append expert initrd=initrd.img lang= devfs=nomount ramdisk_size=7168 label ks kernel vmlinuz append ks=floppy initrd=initrd.img lang= devfs=nomount ramdisk_size=7168 label nofb kernel vmlinuz append initrd=initrd.img lang= devfs=nomount nofb ramdisk_size=7168 label lowres kernel vmlinuz append initrd=initrd.img lang= lowres devfs=nomount ramdisk_size=7168 Actual Results: During installation, the system first asks for the language (didn't it find lang=en_US?), then for the keyboard (didn't it find that either in the kickstart file?). Now comes the fun part: when you add the line nfs --server 192.168.233.1 --dir /u1/redhat72 to the ks.cfg file it actually works. Isn't this weird? You can make it weirder, really. In my dhcpd.conf file I have the following: group { use-host-decl-names on; filename "/u1/redhat72/mundn/ks.cfg"; next-server 192.168.233.1; host mnz7 { hardware ethernet 00:10:dc:b0:07:7f; fixed-address mnz7; } } I also changed the 'ks' section in SYSLINUX.CFG to label ks kernel vmlinuz append ks=nfs:192.168.233.1:/u1/redhat72/mundn initrd=initrd.img lang= devfs=nomount ramdisk_size=7168 and again I get questions for language, keyboard .... but wait, now I got TONS of questions (NFS Image/HTTP/NFS, DHCP, NFS server and directory). This is especially weird because before this questions the messages file on 192.168.233.1 showed the DHCP request and NFS mount to be successfully done ... and on console 2 I can do a "cd /mnt/source" and see the files on the main server. And it becomes more and more bad. Now, in the graphical install, I have to select the mouse, paritions and so on. It looks like the kickstart file has not been processed at all. The weirdness is not at it's end, thought. Suppose I don't want to have a default boot, but want to have grub stay idle. So I would deselect "Default boot image". However, this won't work, because now the NEXT button in the lower right corner is disable, too ... Expected Results: It looks like that you did not really test kickstart installation. You have done better at this before, but now I am not impressed by the show performance and quality. If an "nfs" line in the kickstart file is missing, then I would only expect a installation source (NFS, HTTP, FTP) question, but certainly not a question on keyboard and language. Similarly, If I put the ks.cfg file on the NFS and the system is able to do the nfs mount.