On 12/12/2010 08:13 AM, D. Hugh Redelmeier wrote: > On Sat, 11 Dec 2010, Timothy Murphy wrote: > > | Date: Sat, 11 Dec 2010 17:47:50 +0000 > | From: Timothy Murphy <gayleard@xxxxxxxxxx> > | To: users@xxxxxxxxxxxxxxxxxxxxxxx > | Followup-To: gmane.linux.redhat.fedora.general > | Subject: Re: Fedora upgrade to a new partition > | > | Joachim Backes wrote: > | > | > having the following question: sometimes it happens that after an > | > upgrade of a Fedora-x to a Fedora-y, the Fedora-y does not run correctly > | > (there may be a lot of reasons for this...). So going back to a running > | > system, but how to achieve this? > | > > | > So my question (or proposal): it would be very helpful if an upgrade > | > could be done to a new partition (including copying all imporant files > | > from the Fedora to be updated). This would save oneself a lot of backups > | > and restores. > | > | I always do exactly that. > | Nb I keep separate /home and /boot partitions, > | which I don't format when upgrading. > | (I choose the Custom Upgrade choice, > | not the disastrously bad default which re-partitions your machine.) > > I do something quite similar. > > I don't have a separate /boot partition: I keep /boot as part of the > per-version / partition. Me too. > > I would not have thought that a single shared /boot would work. +1 > Different systems might want to have conflicting files (eg. > /boot/grub/grub.conf). > > I have gotten in trouble in a couple of ways: > > - dot-files for different releases don't always "get along". > > - 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. > > This was made worse by > + no big warning signs in the release notes > + an inscrutable diagnostic (from the old version) > + the new Fedora didn't support the video card on the machine > so we needed to go back to the old Fedora but it could not > be made to work > > I have separate /home partitions for different distros I have this only during the alpha/beta/testing phase of fedora-y, but after fedora-y is officially released and working, I do the merge between the two homes to that of fedora-y. when I have > multiple distros on the same machine. The above problems would surely > be increased if I tried to share /home between distros. Not obligatory. > > 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? > > There are essentially two ways to do this using GRUB (other > bootloaders are not mainstream Linux approaches on a PC): > > (a) one GRUB to boot any system on the disk, or > > (b) one GRUB chainloads any other partition: GRUB loads that > partition's Boot Record and transfers control to it. So each > system uses its own bootstrapping. This is my preferred method, loading fedora-y by the mbr, and fedora-x and other OSes (Win for example) by chainloading. If fedora-y is flawlessly running, I can remove the chainloader entry for fedora-x, and I can use the fedora-x root partition for other purposes. Or you can boot fedora-x by mbr, and let boot Win and fedora-y by chainloading. I have no preference. > > (c) some mixture of (a) and (b) > > - booting MS Windows requires (b) because GRUB doesn't know how to load > Windows. > > - GRUB2 almost forces (a) for Linux partitions but gets it wrong. > It forces it because the conventional automatic config-file > generation creates entries of this type for each partition with > Linux. > It gets it wrong because it cannot possibly know what the > requirements are of that partition's Linux (example: kernel flags). > > Furthermore, I think that the new standard for partitioning, GPT, only > allows for one boot partition. I don't know how multiboot works > there. > > > One thing that I don't do, but I should is to copy ssh server keys from > the old system's /etc/ssh files to the new system so folks ssh'ing in > don't get told that the system isn't the one they last used. See > <http://docs.fedoraproject.org/en-US/Fedora/14/html/Deployment_Guide/s2-ssh-configuration-sshd.html> Kind regards -- Joachim Backes <joachim.backes@xxxxxxxxxxxxxx> http://www.rhrk.uni-kl.de/~backes
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- 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
