On Sat, Feb 11, 2012 at 2:01 PM, Joe Zeff <joe(a)zeff.us&gt; wrote: You lost me there! What's a DE? :)

On Sun, 12 Feb 2012 15:34:03 -0700 Greg Woods <woods(a)ucar.edu&gt; wrote: I can confirm it happens anyway. But don't repartition - use a map file, and ask wtf Fedora didn't think to check if you wanted to do that anyway. Alan

On Sun, 12 Feb 2012, Greg Woods wrote: I do not have an mdraid on my laptop, and I still got the "embedded area is too small" error when trying to run grub2-mkconfig. I was never able to modify my grub2 configuration until I repartitioned the disk to create a 2048 sector boot area. I had the same issue -- users mailing list users(a)lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org -- --- ========================================================================== Patrick DUPRÉ | | Department of Chemistry | | Phone: (44)-(0)-1904-434384 The University of York | | Fax: (44)-(0)-1904-432516 Heslington | | York YO10 5DD United Kingdom | | email: patrick.dupre(a)york.ac.uk ==========================================================================

grub2 is not the future. Grub2 is an unfortunate accident on the way. That said much of the problem being experienced is because Fedora 16 wasn't properly tested and instead of fixing their grub2 configuration and migration they totally screwed it up and left boxes unbootable. That was *crap*. On a box with insufficient space they should have given the user the choice of grub1 or telling grub2 to install itself using a map file (which is *exactly* how grub1 works). You don't need a bigger reserved boot space. That's a Fedora screwup. Tell Grub2 to use a map file. Would have been easier if Fedora 16 had offered the use of map files. The grub2 people covered this but Fedora blew it, just like the 10,000 lines of garbage that break and mash your grub2 config are a total failure. Fortunately grub2 is not the future. On an EFI system with Matt Fleming's work you can boot a kernel direct from the firmware. Alan

On Sat, 2012-02-11 at 22:20 -0500, Sam Varshavchik wrote: I think I'd be happier if someone could make GRUB 2 less of a nightmare of files everywhere. It's become more fiddly to play with than Apache. -- [tim@localhost ~]$ uname -r 2.6.27.25-78.2.56.fc9.i686 Don't send private replies to my address, the mailbox is ignored. I read messages from the public lists.

On 02/11/2012 07:38 PM, Reindl Harald wrote: And it's only a one-time problem. Once you've done it you'll never have to do it again.

Reindl Harald writes: That. Too lazy to look up the bug number, but everyone who's complaining ended up there because of mdraid. It's possible that there might be some other oddball cases that wind up with the grub2 image being too fat. I think there was one person who claimed that they got bricked by this without mdraid being in the picture, but I don't recall the details. That's certainly possible. The bottom line is that grub's days are numbered. grub2 is the future. No amount of complaining is going to change that. Even if someone stepped up to the plate and volunteered to maintain grub going forward, I wouldn't rely on it, in perpetuity. If someone managed to squeeze by this upgrade, great. But all that practically means is that they bought themselves some extra breathing time to get their affairs in order, and they figure out a schedule for chopping up their disks that works for them, instead of scrambling after it's too late. And, it's certainly possible that the affected hardware might reach its end of life, before the move to a bigger reserved boot space becomes mandatory, so they're off the hook. But there's really no way to tell that. Well, if I were you, I'd start figuring out what to do about it, now. And this highlights a major minus for hardware raid, and the major plus in mdraid's factor. If this were mdraid, you could've moved it. It wouldn't be easily, but moving a RAID1 mdraid partition, like that, is doable. I did it myself. One of my RAID1 mdraid machines did have its partitions starting at sector 63. And I managed to rearrange them without having to backup and restore, and eventually update everything to F16. I did blow an entire weekend, on umpteen incremental tweaks to my mdraid configs and ext4 partitions, and drinking endless cups of tea, waiting for everything to resync, before finally reaching the ultimate goal of both halfs of RAID1, on both physical disks, starting on sector 2048. And I'm still pissed about pretty much wasting an entire weekend on this nonsense. But at least this was doable with mdraid. Theoretically, there is no technical barrier to your RAID hardware not being able to do same task, but I'd be shocked if it actually had the means for doing that.

On 02/11/2012 01:04 PM, JD wrote: Desktop Environment. Try installing either KDE or XFCE and see if either of them works.

On Sat, 2012-02-11 at 12:38 -0800, Joe Zeff wrote: As has been mentioned in other threads, grub2 requires 2048 sectors at the start of the disk. If you were upgrading from a previous version, chances are your disk is not partitioned this way, but instead has only 63 sectors at the start of the disk. In this event, if you attempt to install grub2, or even just update its configuration, you get an "embedded area is too small" error. So I would guess you won't really be using grub2 until your disk has a large enough area for it. I haven't actually tried upgrading a system that was already partitioned with 2048 free sectors to see if grub2 would be automatically installed in that case. --Greg

On Sat, Feb 11, 2012 at 1:48 PM, JD <jd1008(a)gmail.com&gt; wrote: Did you by chance install the proprietary ATI driver from RPMFusion or amd.com? Can you start X from the console? (Add '3' to the kernel argument line in GRUB when botting, login, and run `startx`.) -T.C.

On 02/11/2012 12:18 PM, JD wrote: AIUI, if you upgrade to F16 you will end up with both versions of grub installed but will still be using legacy grub. You have to run grub2-install yourself. I've no idea why, or why the upgrade process doesn't tell you about it. My only guess is that somebody wasn't quite confident enough that the conversion would be 100% transparent and decided that this would be safer.

On 02/11/2012 12:39 PM, Michael Hennebry wrote: Take notes as you go along. By hand, if you don't have a better way. Until you can report what's wrong, there's no way anybody's going to be able to create a permanent fix.

On Sat, Feb 11, 2012 at 1:38 PM, Joe Zeff <joe(a)zeff.us&gt; wrote: Well, that is interesting! I will check and compare with F14 contents of /boot.

On Sat, 11 Feb 2012, Joe Zeff wrote: I know part of the reason. Long before the struggle is over, I feel more like killing something than writing down what, if anything, I learned. The result is that the next install doesn't go any better than the previous. Usually, I do get an install, but there is a lot of "Oh crap, why doesn't that work?". Of course, by the time I get that working, I don't know most of what I've done to make it work. All that said, I think it might be useful to have my printer turned on during the install. -- Michael hennebry(a)web.cs.ndsu.NoDak.edu "On Monday, I'm gonna have to tell my kindergarten class, whom I teach not to run with scissors, that my fiance ran me through with a broadsword." -- Lily

On 02/11/2012 12:01 PM, Michael Hennebry wrote: Have you ever tried to find out why? Part of the testing every new version of Fedora is supposed to go through is making sure that it will install correctly on as many different configurations as possible. Why is your machine different from all of the machines used for testing, and is there anything that can be done to get installations to work right the first time?