Description of problem: I did a successful network install on a Dell T3500 that installed 3.7.2-204.fc18 a few days ago (Jan 23). Today I did a network install on a second T3500 with identical hardware and disk partitioning and the result was a non-bootable system. On boot I get "grub: error file not found" (or something very similar). I have no idea which component to blame so I chose anaconda and the main name I recognize related to the installation process. Version-Release number of selected component (if applicable): How reproducible: Twice in a row (2 installs, same bad results) Steps to Reproduce: 1. Use 64-bit net install on Dell T3500 configured as below. 2. Select MATE desktop and no other software 3. Attempt reboot at completion Actual results: Reboot fails with grub "error: file not found". Repeated install, same results. Expected results: Successful boot. Additional info: As noted in the description this worked fine on Jan 23. On the "bad" system the /boot directory contains fewer items and the /boot/grub2 directory contains only the themes directory, nothing else which I assume is part of the problem. Both machines are Dell T3500's, with dual 1-TB boot drives in a RAID-1 mirror using the builtin Intel disk controller (ICH9R?). The modest boot partition is EXT4 and the other partition is an LVM PV used to create the root partition and home partition. I'm reusing the existing partions and LVs, but marking /boot and root to be reformatted (both are EXT4).
I tried use the F18 net installer in rescue mode to try to fix the grub2 config info. I managed to get what seemed to be most of the missing pieces recreated, BUT i still cannot boot. Same error. What I tried: 1) boot in rescue mode 2) chroot /mnt/sysimage 3) grub2-install /dev/sda 4) grub2-mkconfig -o /boot/grub2/grub.cfg That created lots of interesting stuff, but no joy on reboot. Then I noticed the good system had "device.map" and the bad system did not. I created that file on the bad system with the same contents as the good, but still no joy :-( device.map: (hd0) /dev/sda (hd1) /dev/sda On the bad system, when the boot fails its falls into the laughably titled "grub rescue mode". In that mode "set" shows the following, which seem reasonable or at least plausible. prefix=(hd0,msdos1)/grub2 root=hd0,msdos1 Time for bed
Please attach /var/log/anaconda/program.log and /var/log/anaconda/anaconda.log from the failed installed system (or, /tmp/ at the end of installation before you reboot) to this bug report. Thanks.
Created attachment 690110 [details] Zipped contents of /var/log directory tree As requested
Created attachment 690123 [details] anaconda-ks.cfg Perhaps this will also help. I can also upload the /boot tree if that would be useful. I started that upload, but when I noticed it was 38-MB I cancelled the upload.
Is there some way I could do a network install and skip whatever bugs were introduced in the updates repo?
On F19 at least, there's a box on the source spoke that lets you disable automatically getting the updates repo. Alternatively, if it's a problem introduced by an update, you can just periodically try again later.