On Sun, Jan 1, 2017 at 2:18 PM, Mayavimmer <mayavimmer@xxxxxxxxx> wrote: > On 01/01/2017 18:58, Chris Murphy wrote: >> A possible explanation for this, is this old bug. The installer >> doesn't make all LV's active, therefore grub2-mkconfig won't find >> them, and won't create boot entries for them. >> https://bugzilla.redhat.com/show_bug.cgi?id=825236 > > My new hero, Chris! I think you just found one of the gremlins that made > my previous installs disappear! I knew I didn't just dream that up! > > Ok, I'll study this and see if I can come up with a workaround. I see > there are some good reasons why this has not been solved long ago. That's charitable. I see it as one of the very bad cases of OSS, it's all kinds of finger pointing blame by upstreams, miscooperation at the user expense. And it's replicated at a different layer by distros who don't care about standardizing this basic system booting problem, so there's no interoperability. Why this is not a bigger problem is because installing two Fedoras is rare. So there aren't many complaints. Next, other distros don't use LVM by default, so their installations are found by grub2-mkconfig. It's only Fedora/RedHat default installations that get hit with this bug. >> >> However annoying that is though, about as suboptimal is the w >> grub2-mkconfig makes generic boot entries for other OS's rather than >> just pointing to their "native" grub.cfg using the configfile command. >> This forwarding command is a vastly better workflow than the grub.cfg >> of Distro X becoming responsible for Distro Y. When Distro Y gets a >> kernel update, only Distro Y's grub.cfg is updated; so if you're using >> a configfile forwarding workflow, you'll see that new kernel >> automatically whereas if you depend on GRUB as-designed (including as >> it works in Fedora), you're totally stuffed. Distro X's grub.cfg won't >> reflect the change until you run grub2-mkconfig. > > Yes! That's the other one I kind of suspected, and always bothered me in > the back of my mind. I always thought you should be able to at least > provide a prefix to a config file, perhaps based on the hostname, and > then rebuild grub.cfg from that. Great. Progress at last. The distros variably apply hundreds of patches on top of upstream GRUB. While they aren't literal forks, they are sufficiently different and mutually incompatible, that they're fast becoming different OS's that just so happen to share a kernel. > >> >> >> >>> Also I tried my preferred configuration: Btrfs RAID1 over LVM, which >>> should give the best of both worlds: awesome scrub autorepair and proper >>> pooling of same disk spare partitions! The installer barks. It seems to >>> think that If I want to use Btrfs as a raid fs I also have to use it as >>> a volume manager. According the the Fedora info mentioned a few posts >>> back this should only cost a slight, not consistent as somebody said, >>> performance hit. Is is true that the installer cannot put a Btrfs fs on >>> a LVM partition? I could have missed something. >> >> The Fedora installer will not put Btrfs on either LVM or md RAID. > > Another bullseye! Had I known this I would have saved time! Maybe the > installer should add a line of text alerting the user to that effect, > for the time being. If you advertize that you can install LVM, Vtrfs, Md > and other wonderful things, you should at least, IN THE INSTALLER, warn > the user. Great, thanks. *shrug* well they're mutually exclusive devices, the installer simply won't let you pick them in combination. If there were a warning for every possible unsupported layout, the whole installer would be putting up dozens of placards everytime the user clicked on something. Plus, warning dialogs in an installer are very heavy weight: difficult to get the right wording to convey the problem and work around, they need translations which have different (earlier) deadlines than most everything else, are hard to maintain. It's just a huge resource suck. > >> >> You could use blivet-gui to get the layout you want in advance, and >> the installer should recognize all of those pieces (blivet-gui and >> anaconda both leverage python-blivet and libblockdev to recognize and >> create storage stacks) and let you set them up as mount points. For a >> pre-created Btrfs, the installer will force the creation of a new >> Btrfs subvolume for the "/" mount point; otherwise it will let you >> reuse existing subvolumes and file systems. Blivet-gui is supposedly >> going to be integrated into the Fedora 26 installer as an advanced >> partitioning option. > > Good to know that it's in the works! > >> >> The installer is supposed to enforce /boot on a standard partition or >> md RAID; but not allowing it to be in LVM or Btrfs. > > It _did_ let me install /boot in LVM though. Strange. Some versions permit it. It comes and goes depending on what bugs pop up during release testing. Ostensibly boot on LVM is supportable by GRUB2, kernel, dracut, systemd, and the software updaters. -- Chris Murphy _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
