Fedora upgrade to a new partition
Joachim Backes
joachim.backes at rhrk.uni-kl.de
Sun Dec 12 07:38:51 UTC 2010
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 at eircom.net>
> | To: users at lists.fedoraproject.org
> | 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 at rhrk.uni-kl.de>
http://www.rhrk.uni-kl.de/~backes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6131 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.fedoraproject.org/pipermail/users/attachments/20101212/bbb6be03/attachment.bin
More information about the users
mailing list