| From: Timothy Murphy <gayleard@xxxxxxxxxx> | I've always had a single /boot partition and it seems to work fine, | with the same grub.conf for different systems. Always is a long time. I've been upgrading my Linux boxes since at least RHL 5.x. A small chance of grief times a lot of instances can still yield greif. Transitions get one into trouble. Luckily LILO->GRUB wasn't bad because they use non-overlapping config files. The GRUB->GRUB2 transition may be a little more annoying since they both "own" /boot/grub. I've got a laptop that currently has WinXP, Fedora 14, Ubuntu 9.10, Ubuntu 10.10. The Ubuntu 10.10 is using GRUB2 and I'm not liking it. The Ubuntu 9.10 can properly resume from a suspend. Neither the Fedora 14 nor the Ubuntu 10.10 can do that. It's a good thing that I saved the Ubuntu 9.10 -- it may be useful for debugging this. I blew away Fedora Core 7 to install Fedora 14. | It is true that Fedora installation moves the old grub.conf | to grub.conf.rpmsave , | but I just append this to the grub.conf the installation creates | (removing the duplication at the beginning). If you update F13, and that update includes a new kernel, won't the F13 muck up the grub.conf? It might work, but I'm not confident that anything guarantees that. | I agree that this has caused minor problems in the past, | but as it happens there were no problems of this kind for me | in the last upgrade from F-13 to F-14. That's only one transition. | > - once (a long time ago) a new Fedora relabeled /home (in the SELinux | > sense, I think) and made it impossible for the old Fedora to access. | | I'm an SELinux coward - I start off in enforcing mode, | but the first time I get an SELinux problem I don't immediately understand | I switch to permissive mode. I think that will SELinux disabled this problem would still have happened. The installation added something to the superblock or some important inode that made the older Fedora unable to mount /home. | > Another issue: how to do booting. What lives in the Master Boot | > Record (the first track on the drive)? What lives in each partition's | > Boot Record? | | Again, I don't understand the problem. | Fedora installation uses the MBR, and this seems to me to work fine. Fedora installation by default uses the MBR. You can tell it to use a partition's Boot Record instead. GRUB2 is anxious to NOT use a partition Boot Record. It wants to live in the space of the first track that isn't in any partition for its stages (it calls this "embedded"). GRUB 1 is pretty benign in handling grub.conf. You can put what you want about another partition into grub.conf and it is retained. GRUB2 is different. It constructs the grub config file from scratch each time grub-update is run. The scripts to create the config file are not inteneded to be modified by the sysadmin (you can add new ones). GRUB2, as automatically configured, directly boots all Linux partitions. So my Ubuntu 10.10's GRUB2 tries to pass arguments suitable for Ubuntu 10.10's kernel to my Fedora 14 kernel. Dumb. Whenever I update my Fedora 14 kernel, I would need to boot Ubuntu 10.10 and run grub-update (or is that update-grub?) to get the new Fedora 14 kernel in the Ubuntu 10.10 grub configuration. Dumb. If I don't like how GRUB2's config file does things, tough. It is built automatically by scripts that I don't own. So any changes made would be washed away whenever grub-update is run. Example problem: it labels a Vista Restore partition (one you reboot to reinitialize your Windows system to factory-fresh) as Windows NT, inviting the unsuspecting to boot it. There is no approved way for me to fix that. Dumb and dangerous. But more relevant, I similarly cannot get it to only chain-load other Lunuxes. Dumb. -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
