Re: Fedora upgrade to a new partition

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux