From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.4) Gecko/20030701 Description of problem: Installing from hd fails after booting w/pxeboot setup. Error is "Fedora tree at... does not seem to match boot image", but the boot images (vmlinuz, initrd.img) were fetched from matching pxeboot directory within that very same tree. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.populate tftpboot on server with vmlinux and initrd.img and configure pxelinux.cfg/default so as to allow booting I have label text kernel vmlinuz append initrd=initrd.img text devfs=nomount ramdisk_size=9216 hde=none hdg=none 2. Download iso images to /dev/hdd1 3. Boot with PXE and try harddisk install Actual Results: Error message about mismatch between boot and install tree. messages on Alt-F4 suggest that it is trying to open the cdrom and mount something from loop device Expected Results: proceed with install Additional info: Severity set to high since it basically prevents me getting anywhere at all... My disk setup is slightly weird: hde-hdh are on an Adaptec 1210SA controller which doesn't work with the install kernel, hdd is an old drive that I borrowed and attached to a vacant (slave) plug. Hence the disabling of hde and hdg. I had a similar problem with net install from www.mirror.ac.uk. Also (I think) temporarily from download.fedora.redhat.com, but at some point it decided to go on to disk partitioning etc. then crashed trying to obtain package information. The two sites had different netstg2.img files when I checked. Of the two sites, the latter is about ten times slower, so I'm not really motivated to download from there...
The images must match exactly. It sounds like you're just seeing mirror lag (ie boot image bits get to the mirror before netstg2.img etc)
Notice that this also applies to HARD DISK installs where hdstg2 is sitting inside the .iso files. The actual PXE boot files (vmlinuz, initrd.img) does not appear to differ between source and mirror. Besides: all of these files and directories have dates at least one week old. How is one supposed to know if things have gotten out of step? (Preferably before hauling 2GB over the 'net!) And shouldn't there be a way of bypassing the check? Or are you telling me that there is a correct kernel and initrd image sitting inside the .iso files, differing from the extracted tree?
Oops, thought this was devel, not test1. *sigh* Justin -- do you know of any problems with hard drive installs? Things should all match up. And the check is very intentionally not bypassable. If your images don't match, then you very likely don't have the same kernel version and will then be missing all of the kernel modules in the second stage which means no ext3 and numerous other problems.
I have not seen this issue with hard disk installs from iso images. Is it possible the pxeboot environment was not sending the disk1 pxeboot files?
Confirmed: The pxeboot and isolinux dirs inside the yarrow*disc1.iso both contain an initrd.img that is different from the one in the FTP/HTTP dir on download.fedora.redhat.com linux:~ # md5sum /mnt2/images/pxeboot/* f5528650defdc14e2d06ac9d104b6b87 /mnt2/images/pxeboot/TRANS.TBL 762e2ee5d1760daa9cafe5f3efb79af7 /mnt2/images/pxeboot/initrd.img cd1194ff4e6beb5918a007291f337768 /mnt2/images/pxeboot/vmlinuz linux:~ # logout Connection to 192.168.1.10 closed. [root@butterfly tftpboot]# md5sum initrd.img vmlinuz bf1603e992f8ea3624843ea9c6635a83 initrd.img cd1194ff4e6beb5918a007291f337768 vmlinuz And the obvious workaround works!
This is fine with the final release AFAIK.