Re: Fedora upgrade to a new partition
D. Hugh Redelmeier wrote: | 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. I would not have thought that a single shared /boot would work. Different systems might want to have conflicting files (eg. /boot/grub/grub.conf). I've always had a single /boot partition and it seems to work fine, with the same grub.conf for different systems. 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). I have gotten in trouble in a couple of ways: - dot-files for different releases don't always get along. 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. In any case, it would take far longer for me to copy over all the dot files than it would to correct the one or two problems that might arise. - 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. 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. -- Timothy Murphy e-mail: gayleard /at/ eircom.net tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: Fedora upgrade to a new partition
| From: Timothy Murphy gayle...@eircom.net | 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@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: Fedora upgrade to a new partition
On 12/11/2010 08:58 AM, Kam Leo wrote: On Fri, Dec 10, 2010 at 11:33 PM, Joachim Backes joachim.bac...@rhrk.uni-kl.de mailto:joachim.bac...@rhrk.uni-kl.de wrote: Hi, 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. Is the current anaconda able to fulfill such things? Kind regards What important files? For example config files in /etc, or rpms for which no upgrade is available,... If you got the drive space just do the install to the new partition(s) and copy your important data from the old distro to the new. That's exactly the problem. I'm working very long (since years) with fedora (and RedHat), but I really don't know all files which are important for a running fedora. Kind regards -- Joachim Backes joachim.bac...@rhrk.uni-kl.de http://www.rhrk.uni-kl.de/~backes smime.p7s Description: S/MIME Cryptographic Signature -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
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 found remarkably little needed to be changed after this when upgrading from Fedora-13 to Fedora-14. Most of the relevant config files are kept in one's home directory. As you say, this should be a standard part of Fedora, since nearly everyone nowadays has enough space for two Fedora systems on different partitions. -- Timothy Murphy e-mail: gayleard /at/ eircom.net tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: Fedora upgrade to a new partition
On Sat, 11 Dec 2010, Timothy Murphy wrote: | Date: Sat, 11 Dec 2010 17:47:50 + | From: Timothy Murphy gayle...@eircom.net | To: users@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. I would not have thought that a single shared /boot would work. 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 when I have multiple distros on the same machine. The above problems would surely be increased if I tried to share /home between distros. 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. (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 -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: Fedora upgrade to a new partition
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 + | From: Timothy Murphy gayle...@eircom.net | To: users@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.bac...@rhrk.uni-kl.de http://www.rhrk.uni-kl.de/~backes smime.p7s Description: S/MIME Cryptographic Signature -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: Fedora upgrade to a new partition
On Fri, Dec 10, 2010 at 11:33 PM, Joachim Backes joachim.bac...@rhrk.uni-kl.de wrote: Hi, 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. Is the current anaconda able to fulfill such things? Kind regards What important files? If you got the drive space just do the install to the new partition(s) and copy your important data from the old distro to the new. You get the benefit of being able to boot the older distro if the new one has problems.. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
