Description of problem: I booted the Live Games Spin (i686) and then did an install to hard drive using swap, /boot, / and /backup (an external USB drive) using ext4 and luks (except /boot) without LVM. When I tried rebooting the machine I didn't see any output after the BIOS messages stoped appearing The file systems did seem to be setup when I tried a second install. I don't know if this is really an anaconda problem. I don't think this machine supports EFI. Assuming this isn't hardware dependent (which it certainly could be), this should be a final blocker.
I guess this wouldn't be a blocker if it was specific to the Games Spin (or even XFCE that it is based on), but it doesn't like something that would be tied to a particular desktop.
Bruno, can you please attach the logs? Boot the LiveCD again, mount the installed partitions, and attach everything from /var/log/anaconda. How did you create the boot medium - CD or USB, and created how? Also, can you please try the same approach with Workstation LiveCD? Thanks.
Created attachment 962062 [details] install log file (anaconda.log) I used the TC4 i686 Games spin iso dd'd to a usb drive to run a live image and then used install to hard drive from that.
Created attachment 962063 [details] install log file (ifcfg.log)
Created attachment 962064 [details] install log file (journal.log)
Created attachment 962066 [details] install log file (packaging.log)
ks-script-Q92f5N.log is empty.
Created attachment 962067 [details] install log file (program.log)
Created attachment 962069 [details] install log file (storage.log)
I see this in the program.log: 14:40:57,141 INFO program: Running... new-kernel-pkg --mkinitrd --dracut --depmod --update 3.17.4-300.fc21.i686 14:41:18,200 INFO program: 14:41:18,202 INFO program: gzip: stdout: No space left on device 14:41:18,202 INFO program: cpio: write error: Broken pipe 14:41:18,203 INFO program: dracut: creation of /boot/initramfs-3.17.4-300.fc21.i686.img failed 14:41:18,204 INFO program: mkinitrd failed 14:41:18,205 DEBUG program: Return code: 1 Have you created a fresh /boot partition, or have you reused an existing one? How large is it? Can you confirm that there's no free space? Has anaconda claimed that the installation completed successfully? It should have said that it failed. Weren't you warned?
I did the install twice. Both times I thought it completed successfully according to anaconda. /boot was supposed to be 100 MiB. For the second install I reused the partitions and luks containers, but believe I asked to reformat all of these with new ext4 filesystems. It's kind of late now, so I'll check the /boot file system tomorrow to see if it is really over size.
This is probably going to be user error. I did check /boot and it was at 91 out 100 MB. So it could have been full at some point during the install. It looked like everything the was needed was there with reasonable sizes. What I think the real problem is, is that I didn't include a biosboot partition. I am retesting now with TC4 using 200 MiB for /boot install of 100 MiB. And I have included a 1 MiB biosboot partition. The results should be available within an hour.
anaconda should've failed earlier if there was no biosboot partition. From storage.log I don't see any GPT disks involved, so there shouldn't be any need for a biosboot.
Now I am thinking the issue was the bios trying to boot off the USB attached externel drive before the internal drive. I am not sure why that would be a problem now when it wasn't when Windows was installed on that box. (I am just replacing XP with Fedora on that box because my wife doesn't want to use it any more.) When I changed the boot order to not check USB devices it seemed to behave as expected. It's possible that the install should have done something to the MBR on the external drive that wasn't done, but that wouldn't be a blocker. So I am going to remove that. I'm going to test wiping the external drive entirely and setting it back up and see if that allows me to change the boot order back. If that works it suggests there is still a bug here, if not, then it is a local bios issue.
So this looks like it might be an issue where booting off only one of the disks works correctly. When I cleared the first 512 bytes (I think I should have just done 128), then the system starting booting. (It appears to have hung part way through because I got the partition table as well as the MRB on the second disk). Because the second disk is an external disk, when I have the bios set to boot off usb first (for testing live images), then it will try that disk if there appears to be a valid MBR there, otherwise it seems to boot off of the internal drive and things work.
I tried RC1 and am seeing the same problem. No partition is marked as bootable for /dev/sdb. There is code in the first 466 bytes. However zeroing those bytes still had the bios trying to boot off sdb and failing. I'm going to attach the anaconda logs and the mbr from this try. I still can't tell if this is anaconda's issue or bios flakiness.
Created attachment 962779 [details] rc1 anaconda.log
Created attachment 962780 [details] rc1 ifcfg.log
Created attachment 962781 [details] rc1 journal.log
Created attachment 962782 [details] rc1 packaging.log
Created attachment 962783 [details] rc1 program.log
Created attachment 962784 [details] rc1 storage.log
Created attachment 962785 [details] rc1 mbr
Fedora installed the bootloader to sda: anaconda.log 11:41:17,835 INFO anaconda: bootloader stage1 target device is sda 11:41:17,835 INFO anaconda: bootloader stage2 target device is sda1 program.log 11:41:18,455 INFO program: Running... grub2-install --no-floppy /dev/sda 11:41:36,472 INFO program: Installing for i386-pc platform. 11:41:36,473 INFO program: Installation finished. No error reported. If you don't explicitly set a 'boot disk' on the Full Disk Summary and Bootloader page, anaconda will use the first disk that passes its checks as the 'boot disk' (the disk to whose MBR it installs grub2 stage1, referred to as 'stage1 target' above). What disk your firmware attempts to boot from is, for the BIOS case, something anaconda has no control over. It's entirely up to you and your firmware. If it's trying to boot from sdb, that is probably because you have told it to - check the boot order configuration in your firmware UI.
I realize that anaconda can't control which drive the bios boots from. When it was set up with Windows I think it used to skip over the external USB drive even when it was before the main Windows drive in the boot order. I thought maybe that was due to some difference between how ananconda set up the MBR and how it the external drive was set up under Windows. But maybe it really did start booting from there and correctly finish booting from the other drive. The reason I care is the BIOS boot order choices suck. If I don't boot off USB devices then I have to manually enter a boot selection menu during boot to boot live images and if I turn it on, then if there isn't a live image it will try to boot off the external drive and fail. I'll see if I can run grub2-install on that drive and get things to work. It's odd that it isn't run on both. Also I was kind of looking for where I choose the boot drive and missed it. I look more carefully, but I expected it to be easy to notice.
Manually doing grub2-install /dev/sdb seemed to fix things. I did another install and found a page that showed which devices were boot devices and sda had a check, sdb did not have a check, and I couldn't figure any way to change those settings.
There's a button at the bottom of that pane which lets you pick the selected disk as the boot disk. Click it and the check will move. But yes, there's a ui bug there. The screen uses the 'clickable checkbox' image but you can't actually click it. Gtk for provide a different check mark widget for use in such non-clickable situations, anaconda should use it. I actually noticed the same thing yesterday and was going to try and patch it if I could find time. I'm not sure why you'd expect anaconda to install to the MBR of every install target disk, though. It never has, not going all the way back to oldui and even rhl. It's always used the design that you nominate a single disk to install to the MBR of.
OK. Thanks. I think this one is beat to death now.
For the record it looks like fixing the 'ui bug' isn't straightforward - the GTK+ element being used there only has a few options for selection-type widgets and there are none really which just indicate selection. You could pick radio buttons instead of checkboxes, but people expect those to be clickable too, and they're not supposed to be used to indicate 'no selection' (one radio button is always supposed to be active), which is a valid choice on this screen.