Description of problem: with cmdline ks=hd:sda1:/ks.cfg get the following info: kernel command line: initrd=initrd.img BOOT_IMAGE=vmlinuz ks=hd:sda1:/ks.cfg anaconda version 15.20 on i686 staring getting kickstart file getting kickstart file from harddrive loading ks from device on sda1 on path /ks.cfg GetFileFromBlockDevice(sda1, /ks.cfg) sleeping to wait for USB storage devices error code: 32 Failed to mount /dev/sda1: No such file or directory. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1.boot system 2.enter ks=hd:sda1:/ks.cfg at prompt 3. Actual results: Expected results: Additional info: Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda2 229807308 29675652 188458056 14% / tmpfs 4126888 524 4126364 1% /dev/shm /dev/sda1 2015824 74848 1838576 4% /boot nfs.englab.nay.redhat.com:/fedoratest 523860704 20985824 502874880 5% /home/hongqing/mnt
Please attach /tmp/anaconda.log and /tmp/program.log to this bug report.
Created attachment 479804 [details] anaconda log
Created attachment 479805 [details] program log
Okay, that's consistent with the device just never being found. Can you also attach /tmp/syslog and the output of lsmod? Thanks.
Created attachment 480071 [details] syslog
Created attachment 480072 [details] lsmod
Reproduced in anaconda 15.20.1.
Looks like the usb-storage module is never getting loaded. You see no mention of it in lsmod, and there's very little mention of usb anything in your syslog. It's my understanding that usb-storage should just be getting loaded without any anaconda involvement. At least, we don't load it anywhere else and we've gotten bug reports from people farther along in the USB process, so it must be working for some.
(In reply to comment #5) > Created attachment 480071 [details] > syslog Here sda and its partitions get discovered: 09:03:53,944 INFO kernel:[ 5.122413] sda: sda1 sda2 sda3 sda4 < sda5 sda6 > And here sda1 gets mounted: 09:06:24,322 INFO kernel:[ 155.790703] EXT3-fs (sda1): mounted filesystem with ordered data mode 09:06:24,322 DEBUG kernel:[ 155.791610] SELinux: initialized (dev sda1, type ext3), uses xattr
sda1 gets discovered and its partition gets mounted, so what bug are you trying to report here?
Created attachment 483356 [details] kickstart from hard drive the sad1 partition is mounted in the log, but the console also outputs error as the attachment. The kick start file cannot be found.
(In reply to comment #9) > (In reply to comment #5) > > Created attachment 480071 [details] > > syslog > > Here sda and its partitions get discovered: > 09:03:53,944 INFO kernel:[ 5.122413] sda: sda1 sda2 sda3 sda4 < sda5 sda6 > > > And here sda1 gets mounted: > 09:06:24,322 INFO kernel:[ 155.790703] EXT3-fs (sda1): mounted filesystem with > ordered data mode > 09:06:24,322 DEBUG kernel:[ 155.791610] SELinux: initialized (dev sda1, type > ext3), uses xattr When this issue happened, a window would pop up saying unable to find the kickstart file. But I couldn't access to ttys until I clicked cancel on the window to get stage2 started. So I thought sda1 was mounted after I cancelled kickstart install.
Hongqing, when that dialog appears, and no tty's are available, you can press <Ctrl>Z to drop into a shell. The shell environment will be limited, but you can do some debugging there.
Discussed at 2011-03-11 blocker review meeting. On the face of it, this hits criterion "The installer must be able to use all kickstart delivery methods ", but it may be more a case of a problem with _device discovery_ than a generic issue with the hard disk ks delivery method. Hongqing, can you give us a few more details on the exact disk at issue here? Is it a USB flash stick or an actual hard disk connected externally? How is it formatted / partitioned? Can Hongqing (or anyone else) please test with a different USB device, maybe a FAT-formatted USB flash stick?
Hi, Adam, I tested it again, but it is weird, I cannot reproduce it again as I did before. It also not always happened before. I keep the kick start file on a guest hard disk, and install another guest from cdrom. it works now. so I prefer to close it first as it is not a bug.