On Fri, Jan 23, 2015 at 09:26:34AM -0800, Adam Williamson wrote: > On Thu, 2015-01-22 at 13:36 -0800, Adam Williamson wrote: > > There's a proposed anaconda patch ATM which would disallow mounting > > an existing partition as /boot or /var (or any subdirectory of those > > except /var/www ) without reformatting it. i.e., you can't reuse an > > existing partition with those mountpoints. > > OK, OK, you can (mostly) stop panicking now: David is back to trying > to fix the initramfs re-generation problem: > > https://lists.fedorahosted.org/pipermail/anaconda-patches/2015-January/015699.html > -- > Adam Williamson While this issue may be settled, let me interject my view as an ordinary user of Fedora. I hope, no, I think it imperative, that dual booting be considered mainstream. I have always installed a new version side-by-side with a prior version in two separate root filesystems and a common shared /home filesystem. I would never consider destroying a working system simply to create a new one, either by updating or overwriting. Until recently the boot mechanisms for both have happily cohabitated a single /boot partition. In olden days of grub, this Just Worked; the newer grub2 is less capable and heroic measures are now required. After my BZ grousing, I was persuaded (or bludgeoned) into using three - a /mainboot partition, and two separate /boot subdirectories in the respective root partitions. The /mainboot partition contains a handcrafted grub.cfg with switching entries such as: menuentry "Fedora 21 via multiboot" { insmod ext2 set root=(hd0,msdos6) configfile /boot/grub2/grub.cfg } and the root filesystem contains the usual installer-created stuff. This setup works, but is fragile. For one thing, it is unsupported. Secondly, the boot machinery in /boot is static, and once created, there's no way to recreate it. Should it ever be lost, or made obsolete, I'm screwed. Thirdly, when it's time to install a new Fedora in the parallel root filesytem, I must be exquisitely careful not to allow the Master Boot Record and all the usual boot mechanism to be recreated, but instead to follow these instructions precisely: Here are instructions stolen from Adam Williamson's blog post http://www.happyassassin.net/2014/01/08/how-to-do-manual-multi-boot-configuration-with-fedora/ with slight edits: 1. Begin Fedora installation as usual. 2. Enter the Installation Destination spoke. 3. Click on "Full disk summary and bootloader.." at the bottom left 4. Select the disk with a check and click "Do not install bootloader" 5. Click Close, and proceed with installation as desired 6. When installation is complete and Fedora tells you to reboot, DON'T! Instead hit ctrl-alt-f2, and run the following commands: 7. chroot /mnt/sysimage 8. echo "GRUB_DISABLE_OS_PROBER=true" >> /etc/default/grub 9. grub2-install --no-floppy /dev/sda6 --grub-setup=/bin/true 10. grub2-mkconfig -o /boot/grub2/grub.cfg This actually works! I've done it. Having separate /boot subdirectories offers the advantage that yum updates to, say, F21 affect solely the f21 root filesystem, and likewise for F20. Nothing ever messes with /mainboot (but me). However, I live in terror that one day I might lose Adam Williamson's recipe, mistype it (steps 8, 9, 10), or simply forget to block the installer from its normal actions (step 4). This is all much too cumbersome and puts too much burden on the user. It is the WRONG way. The RIGHT way is to revert to the traditional cohabitation of multiple boot files in a common /boot partition. I'm glad that's being considered. One thing more: The problem being attacked here stems from losing control of what's in initramfs, I sincerely believe. This file, originally was merely an intermediate step - a basic all-purpose kernel that would initialize the conditions to start the real kernel. It contained no or hardly any knowledge of the specific conditions of the machine and, especially, nothing of what filesystems would be encountered. Now we have the spectacle of including virtually every detail embedded redundantly in this file - information that correctly should be found solely in grub.cfg, /etc/fstab, /etc/crypttab, etc. and which, perforce, should not be visible until vmlinuz has been unpacked and taken control. Well, so be it! These complications are the fault of the software designers and the costs should be borne by them, not the user. Good luck. -- David A. De Graaf DATIX, Inc. Hendersonville, NC dad@xxxxxxxx www.datix.us Microsoft isn't evil, they just make really crappy operating systems. -- Linus Torvalds -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
