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.
I'm curious to know if anyone / many people do this, and if so, if there's a particularly good use case for it; if so, we might want to provide that feedback to the anaconda folks.
There are a few references to using shared /boot on Google, but not that many, and mostly for crazy multiboot configurations that we really don't want to be stuck dealing with. Does anyone know of a really sensible use case for this?
For the record, this is actually re-hooking up code that was used in oldUI - that is, F17 and earlier - but in oldUI it just produced a warning you had to click through; the current patch flat disallows it. The main driving force for this is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1074358 , as it keeps turning out to be annoyingly tricky to make sure that only newly- installed kernels have their initramfs regenerated when installing to a shared /boot partition.
On 01/22/2015 02:36 PM, 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.
I'm curious to know if anyone / many people do this, and if so, if there's a particularly good use case for it; if so, we might want to provide that feedback to the anaconda folks.
Yes, I very recently reused the /boot mountpoint when installing a fresh F21 build on top of an earlier F19 install, where I thought it was easier to start fresh than do incremental upgrades. Since my machine is multi-boot, my F19 install had stored grub directly into /dev/sda1 (the /boot partition) rather than the overall drive /dev/sda (that was reserved for my master bootloader that then chainloads the appropriate /boot according to which OS I would be booting). Since newer Fedora installation no longer allows per-partition grub installation for easy chainloading, all I had to do was remount the old /boot, tell anaconda to not install any bootloader, then manually touch up /boot/grub2.cfg to point to the new install's kernel version, without having to futz around with reinstalling grub into the /boot partition.
But I'm in a minority, and I know that chainloading multi-boot installs is already in the fringe. I'm perfectly capable of getting my system to work if /boot is forced to be wiped rather than reused, even if it is more of a hassle on my end.
There are a few references to using shared /boot on Google, but not that many, and mostly for crazy multiboot configurations that we really don't want to be stuck dealing with. Does anyone know of a really sensible use case for this?
I didn't think my situation was that crazy. But you anticipated my use case :)
For the record, this is actually re-hooking up code that was used in oldUI - that is, F17 and earlier - but in oldUI it just produced a warning you had to click through; the current patch flat disallows it. The main driving force for this is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1074358 , as it keeps turning out to be annoyingly tricky to make sure that only newly- installed kernels have their initramfs regenerated when installing to a shared /boot partition.
Ah, a good reason for a forced wipe of /boot.
On Thu, Jan 22, 2015 at 01:36:35PM -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.
Well, somebody with a carefully crafted configuration in /var/named/, for example, presumably will be not very happy. I wonder why /var/www/ is singled out for a special treatment?
The main driving force for this is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1074358
And /var comes into this picture how? Just curious.
Michal
On Thu, 2015-01-22 at 15:54 -0700, Michal Jaegermann wrote:
On Thu, Jan 22, 2015 at 01:36:35PM -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.
Well, somebody with a carefully crafted configuration in /var/named/, for example, presumably will be not very happy. I wonder why /var/www/ is singled out for a special treatment?
The main driving force for this is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1074358
And /var comes into this picture how? Just curious.
As I mentioned, it's a re-use of an existing bit of logic; I don't have the history behind the exact list of mountpoints handy, but you can likely track it out from the commit history and Bugzilla. I would imagine we became aware of multiple cases where re-using an existing /var caused problems. It could obviously cause issues with package manager databases for e.g.
As for /var/www , if I had to bet, the check for /var was introduced and then someone complained that it covered /var/www but re-using /var/www is safe, so the exception was added. More exceptions can be added if desired, it's a simple list.
On 01/23/2015 04:24 AM, Michal Jaegermann wrote:
On Thu, Jan 22, 2015 at 01:36:35PM -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.
Well, somebody with a carefully crafted configuration in /var/named/, for example, presumably will be not very happy. I wonder why /var/www/ is singled out for a special treatment?
The main driving force for this is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1074358
And /var comes into this picture how? Just curious.
And why the subdirectories in /var cannot be mountpoints for existing partitions ? There are a way lot of subdirectories, where partitions with existing data would have to be mounted, like www, ftp, tftp, named, spool/mail ....
- rejy (rmc)
Michal
On Fri, 2015-01-23 at 12:16 +0530, Rejy M Cyriac wrote:
On 01/23/2015 04:24 AM, Michal Jaegermann wrote:
On Thu, Jan 22, 2015 at 01:36:35PM -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.
Well, somebody with a carefully crafted configuration in /var/named/, for example, presumably will be not very happy. I wonder why /var/www/ is singled out for a special treatment?
The main driving force for this is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1074358
And /var comes into this picture how? Just curious.
And why the subdirectories in /var cannot be mountpoints for existing partitions ? There are a way lot of subdirectories, where partitions with existing data would have to be mounted, like www, ftp, tftp, named, spool/mail ....
I couldn't say precisely why, I don't know the background of why the design is that way. I'd guess the logic is that there's nothing important in /var itself, it's all subdirectories of /var we care about, and it's 'better' to whitelist known-OK ones than blacklist known-bad ones. The 'allowed' and 'disallowed' lists can be adjusted and extended, as I mentioned, it's not a difficult thing to do in theory to allow /var/ftp , /var/tftp , /var/named , /var/spool ... but it'd have to go through anaconda patch review/discussion.
On Thu, Jan 22, 2015 at 11:27:56PM -0800, Adam Williamson wrote:
On Fri, 2015-01-23 at 12:16 +0530, Rejy M Cyriac wrote:
And why the subdirectories in /var cannot be mountpoints for existing partitions ? There are a way lot of subdirectories, where partitions with existing data would have to be mounted, like www, ftp, tftp, named, spool/mail ....
I couldn't say precisely why, I don't know the background of why the design is that way. I'd guess the logic is that there's nothing important in /var itself,
Hmm, this is getting really curious. OTOH if you are going to sick anaconda on an existing system that means that you are reinstalling. So one may argue that a "nothing important" logic really applies across the board and why some "weird exceptions"? In other words if you care you better have backups as you cannot really predict in advance what all of sudden will be deemed disposable.
Michal
On Fri, 2015-01-23 at 10:30 -0700, Michal Jaegermann wrote:
On Thu, Jan 22, 2015 at 11:27:56PM -0800, Adam Williamson wrote:
On Fri, 2015-01-23 at 12:16 +0530, Rejy M Cyriac wrote:
And why the subdirectories in /var cannot be mountpoints for existing partitions ? There are a way lot of subdirectories, where partitions with existing data would have to be mounted, like www, ftp, tftp, named, spool/mail ....
I couldn't say precisely why, I don't know the background of why the design is that way. I'd guess the logic is that there's nothing important in /var itself,
Hmm, this is getting really curious. OTOH if you are going to sick anaconda on an existing system that means that you are reinstalling. So one may argue that a "nothing important" logic really applies across the board and why some "weird exceptions"? In other words if you care you better have backups as you cannot really predict in advance what all of sudden will be deemed disposable.
There's nothing 'unpredictable' in this, it's for custom partitioning, and it raises an error with details when it decides not to let you do something. Just try re-using an existing partition as / without formatting it to see what I mean (that check exists in the F21 code). It doesn't just start silently formatting stuff behind your back.
Historically /boot is owned by a particular OS installation whether its a separate volume or a directory. I think it's sloppy as hell to share /boot without a spec like bootloaderspec to define the exact location each OS installs its stuff into. It's completely sane the installer team wants to explicitly do away with shared /boot unless there's a spec. And there is a spec there just isn't enough momentum to support it apparently.
/boot as a directory achieves both space savings and separation of boots between OS's. Where /boot is on a LUKS encrypted volume is the one exception, which although GRUB2 supports that, it's not automatically configured for the user and would need installer support to do that configuration to make it a sane option.
Chris Murphy
Looks like UsrMove fixed the problem with separate /usr volume.
This is the layout I tested: UUID=5AC5-5766 /boot/efi vfat x-systemd.automount,noauto,umask=0077,shortname=winnt 0 0 UUID=8fd67b94-0dd5-4df0-a690-066460e47fd8 / btrfs subvol=root 0 0 UUID=8fd67b94-0dd5-4df0-a690-066460e47fd8 /usr btrfs subvol=usr 0 0 UUID=8fd67b94-0dd5-4df0-a690-066460e47fd8 /boot btrfs subvol=boot 0 0 UUID=8fd67b94-0dd5-4df0-a690-066460e47fd8 /home btrfs subvol=home 0 0
Boot and updates with yum, dnf and pk-offline all work.
The stateful settings and files in /var, /etc, and optionally /home can all go together on root. And stateless stuff on /usr. This seems more coherent than a bunch of different mountpoints under var; and even var on its own has been rather problematic.
I'm guessing the installer doesn't permit separate /usr for legacy, pre-usrmove reasons. This layout is also compatible with the proposal found here: http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html
On Thu, Jan 22, 2015 at 2:36 PM, Adam Williamson adamwill@fedoraproject.org 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.
I'm curious to know if anyone / many people do this, and if so, if there's a particularly good use case for it; if so, we might want to provide that feedback to the anaconda folks.
The upstream Bootloaderspec calls for a shared /boot on BIOS. And mjg59's derivative bootloaderspec calls for a shared /boot on both BIOS and UEFI.
http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ http://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/
The main driving force for this is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1074358 , as it keeps turning out to be annoyingly tricky to make sure that only newly- installed kernels have their initramfs regenerated when installing to a shared /boot partition.
Each distro is to have its own directory on /boot per the bootloaderspecs (both of them) which would resolve this problem.
If we're serious about stateless systems, and if /var is the right place to store stateful data that's also portable, then it's plausible we'd want a prepopulated /var and just restore root and boot in order to do a system reset. In effect everyone else (Windows, OS X, Android, iOS) are doing things this way but with the cloud storing such configuration data and restoring it automatically, I don't know what'd intended here, maybe it's the realm of Fedora Atomic.
On Thu, Jan 22, 2015 at 4:00 PM, Chris Murphy lists@colorremedies.com wrote:
The upstream Bootloaderspec calls for a shared /boot on BIOS.
It calls for a shared /boot on UEFI also, but it's the EFI System partition, so of course this needs to always be preserved unless the entire drive is selected for erasing. Oh, oops:
wrongly permits deletion of shared EFI System partition https://bugzilla.redhat.com/show_bug.cgi?id=1183880
Seeing as anaconda puts a bullseye on the EFI system partition, why not just nuke /boot from orbit? Don't ask. Don't warn. Just do it.
On Thu, 2015-01-22 at 16:06 -0700, Chris Murphy wrote:
On Thu, Jan 22, 2015 at 4:00 PM, Chris Murphy < lists@colorremedies.com> wrote:
The upstream Bootloaderspec calls for a shared /boot on BIOS.
It calls for a shared /boot on UEFI also, but it's the EFI System partition, so of course this needs to always be preserved unless the entire drive is selected for erasing. Oh, oops:
The exception mechanism would allow for an exception to be added for /boot/efi , though that doesn't cover the BLS specifying /boot itself of course.
On 01/22/2015 04:00 PM, Chris Murphy wrote:
On Thu, Jan 22, 2015 at 2:36 PM, Adam Williamson adamwill@fedoraproject.org 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.
I'm curious to know if anyone / many people do this, and if so, if there's a particularly good use case for it; if so, we might want to provide that feedback to the anaconda folks.
The upstream Bootloaderspec calls for a shared /boot on BIOS. And mjg59's derivative bootloaderspec calls for a shared /boot on both BIOS and UEFI.
http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ http://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/
The main driving force for this is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1074358 , as it keeps turning out to be annoyingly tricky to make sure that only newly- installed kernels have their initramfs regenerated when installing to a shared /boot partition.
Each distro is to have its own directory on /boot per the bootloaderspecs (both of them) which would resolve this problem.
Couldn't anaconda just be taught to install its new kernel under a just-created /boot/$subdir and leave the rest of /boot untouched? That sounds to me like both what bootloaderspec variants are proposing - it would get rid of the issue of what do to with any pre-existing kernels, because there are no pre-existing kernels if we always install new kernels under a subdirectory specific to the installation rather than in the top level directory of the partition's filesystem. What good is a proposed shared bootloaderspec document if we aren't willing to implement its ideas, including sharing /boot across multiple distros?
On Fri, 2015-01-23 at 10:07 -0700, Eric Blake wrote:
On 01/22/2015 04:00 PM, Chris Murphy wrote:
On Thu, Jan 22, 2015 at 2:36 PM, Adam Williamson < adamwill@fedoraproject.org> 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.
I'm curious to know if anyone / many people do this, and if so, if there's a particularly good use case for it; if so, we might want to provide that feedback to the anaconda folks.
The upstream Bootloaderspec calls for a shared /boot on BIOS. And mjg59's derivative bootloaderspec calls for a shared /boot on both BIOS and UEFI.
http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ http://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/
The main driving force for this is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1074358 , as it keeps turning out to be annoyingly tricky to make sure that only newly- installed kernels have their initramfs regenerated when installing to a shared /boot partition.
Each distro is to have its own directory on /boot per the bootloaderspecs (both of them) which would resolve this problem.
Couldn't anaconda just be taught to install its new kernel under a just-created /boot/$subdir and leave the rest of /boot untouched?
Sure it *could*, but that's a major change in behaviour that isn't really sensible just to throw in as a bug fix and hope it doesn't break anything else. Also, it's not really anaconda's job, it's the kernel package that decides where its files live.
That sounds to me like both what bootloaderspec variants are proposing - it would get rid of the issue of what do to with any pre- existing kernels, because there are no pre-existing kernels if we always install new kernels under a subdirectory specific to the installation rather than in the top level directory of the partition's filesystem. What good is a proposed shared bootloaderspec document if we aren't willing to implement its ideas, including sharing /boot across multiple distros?
Well, a) so far I don't think anyone else has committed to adopting it so doing it for Fedora wouldn't really achieve a whole lot (except maybe improving multi-Fedora-boot and happening to solve this problem), b) it's a pretty major change and it's all in stuff pjones maintains and he has a lot else to do. mjg59 sent an incomplete implementation to desktop@ (for some reason?) back last July, but that's all I can find:
https://lists.fedoraproject.org/pipermail/desktop/2014-July/009995.html
There's also some discussion from 2013 on systemd-devel:
http://lists.freedesktop.org/archives/systemd-devel/2013-June/011192.html
so basically I think a few people are interested and pushing it along, but it's not top priority for anyone? That's what it looks like. CCing pjones and mjg59 for comment, if they like.
On Qui, 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.
I'm curious to know if anyone / many people do this, and if so, if there's a particularly good use case for it; if so, we might want to provide that feedback to the anaconda folks.
There are a few references to using shared /boot on Google, but not that many, and mostly for crazy multiboot configurations that we really don't want to be stuck dealing with. Does anyone know of a really sensible use case for this?
For the record, this is actually re-hooking up code that was used in oldUI - that is, F17 and earlier - but in oldUI it just produced a warning you had to click through; the current patch flat disallows it. The main driving force for this is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1074358 , as it keeps turning out to be annoyingly tricky to make sure that only newly- installed kernels have their initramfs regenerated when installing to a shared /boot partition.
My test machine in office got Debian and Fedora and both systems have same /boot , because /boot can't be on LVM [1], so /boot is just to hold kernels at boot time for Debian and for Fedora , grub2 from Fedora keeps boots entries of Debian system .
[1] /dev/sda2 2048 1026047 500M Linux filesystem /dev/sda3 1026048 488396799 232,4G Linux LVM
Adam Williamson composed on 2015-01-22 13:36 (UTC-0800):
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.
I'm curious to know if anyone / many people do this, and if so, if there's a particularly good use case for it; if so, we might want to provide that feedback to the anaconda folks.
No comment on /var.
Not mounting as boot a partition containing kernels and/or initrds in its root I could understand and agree with, but not forced reformatting.
From my experience with the various distros' utilities responsible for
installing and updating kernels and initrds I see sharing a /boot partition as a virtual demand for the trouble like that described in bug 1074358.
As long as kernels, initrds and the normal files accompanying them in /boot are not present, other content should be allowed to remain. If any such are present, it should be OK to wipe them away, but not format, which would lose both content Anaconda should have no need to care about (which might include an installation and/or rescue image), and a UUID one or more prior installations are probably depending on.
There are a few references to using shared /boot on Google, but not that many, and mostly for crazy multiboot configurations that we really don't want to be stuck dealing with. Does anyone know of a really sensible use case for this?
Whether others might see what I do as sensible I can't say, but what I do for a first OS installation on a BIOS with software RAID system, I:
1-partition 2-format non-RAID partition(s) 3-install Grub to master/realboot primary partition 4-copy small number of scripts & binaries to one or more subdirectories on realboot 5-install sans bootloader 1st "OS", mounting realboot partition on /boot
Before a 2nd OS installation, I reconfigure fstab on the original by mounting realboot elsewhere, let /boot fall on /, and copy the appropriate content to the new /boot location. Next installations get no bootloader installed and have /boot on respective /. I copy their kernels and initrds to realboot and add them to my personally managed custom bootloader menu on realboot.
On Thu, 2015-01-22 at 21:21 -0500, Felix Miata wrote:
Not mounting as boot a partition containing kernels and/or initrds in its root I could understand and agree with, but not forced reformatting.
As things stand anaconda just doesn't have this degree of precision. I think I'm right in saying nothing in anaconda looks at the actual contents of existing partitions at all. It just knows whether there's already a filesystem on the device, and whether you're reformatting it.
Whether others might see what I do as sensible I can't say, but what I do for a first OS installation on a BIOS with software RAID system, I:
So honestly I pretty much consider most multiboot configs more trouble than they're worth, but what I'm not understanding from any of the descriptions so far is what actual value you get from sharing a partition mounted at /boot between multiple distributions?
The point of the partition mounted at /boot *to a Linux distribution* is that it's where it should install its kernels and things to. Nothing I've seen so far actually seemed to indicate any situation where it was useful for one distribution to be able to see another's kernels.
All the setups discussed so far seem to be based on the design where you have a 'master' bootloader which chainloads each distro's own bootloader. OK, but then what's the point of sharing or reusing a /boot partition?
I don't actually see, in your description, where you need to reuse a /boot partition. The first OS install creates it fresh, then subsequent installs don't use it - they have their /boot directories on their root partitions. You don't actually seem to re-use the partition you call 'realboot' in a later OS installation at all, do you? Or am I missing a step somewhere?
Adam Williamson composed on 2015-01-22 18:39 (UTC-0800):
On Thu, 2015-01-22 at 21:21 -0500, Felix Miata wrote:
Not mounting as boot a partition containing kernels and/or initrds in its root I could understand and agree with, but not forced reformatting.
As things stand anaconda just doesn't have this degree of precision. I think I'm right in saying nothing in anaconda looks at the actual contents of existing partitions at all. It just knows whether there's already a filesystem on the device, and whether you're reformatting it.
Even so, I don't understand what the problem is that dracut can't be limited to producing images based on /lib/modules, name matches to the installing arch, whatever is in the list of packages Anaconda has selected to install, or some other kind of matching. Simply recognizing that a filesystem is supported or not ought to be enough for it to decide if a fresh filesystem is appropriate for the little activity /boot gets.
So honestly I pretty much consider most multiboot configs more trouble than they're worth, but what I'm not understanding from any of the descriptions so far is what actual value you get from sharing a partition mounted at /boot between multiple distributions?
I provided no use case for sharing a /boot partition among more than one / on a multiboot system. I objected to eradicating non-conflicting subdirectories located on a filesystem proposed for use as /boot, and provided reasons supporting my objection.
The point of the partition mounted at /boot *to a Linux distribution* is that it's where it should install its kernels and things to.
Right, but I recall nothing in FHS that says an admin should have no right to store other things that do not conflict with what is expected to live there, rather like /mnt or /media.
FWIW, something is putting "theme" files in /boot even though what the theme is for is not installed. Why aren't theme files for the bootloader among the places other things that use themes expect to find them?
Nothing I've seen so far actually seemed to indicate any situation where it was useful for one distribution to be able to see another's kernels.
Neither I.
All the setups discussed so far seem to be based on the design where you have a 'master' bootloader which chainloads each distro's own bootloader. OK, but then what's the point of sharing or reusing a /boot partition?
Creating extra trouble potential?
I don't actually see, in your description, where you need to reuse a /boot partition. The first OS install creates it fresh, then
In my scenario, the OS installation does not create a filesystem on a /boot partition. I first create partitioning, then format partition for bootloader, put bootloader on partition, and only afterward install the first operating system.
subsequent installs don't use it - they have their /boot directories on their root partitions. You don't actually seem to re-use the partition you call 'realboot' in a later OS installation at all, do you? Or am I missing a step somewhere?
Maybe you skipped over #2, #3 & #4 in my list? I don't re-use *as* /boot. Use as /boot only ever happens here for the first OS installation. But, I do on occasion have use for the content I put on it both before and after the first OS installation, as well as while the first is the only, regardless of where it's mounted.
For "before" it might have a rawhide directory with network installation kernel and initrd, which I would expect to use again later if I abort the installation before completion, or it aborts itself when the network goes down for several hours. I can't be the only one doing network installs without using removable media or PXE.
It *does* already have a bootloader on it, and since I don't ever allow Grub2 to be installed except to a *buntu installation, Anaconda wiping mine would mean no booting HD at all, and me having to redo everything I did to get Anaconda started in the first place, after backing up what Anaconda put there, and afterward putting it back.
On Fri, 2015-01-23 at 00:58 -0500, Felix Miata wrote:
Adam Williamson composed on 2015-01-22 18:39 (UTC-0800):
On Thu, 2015-01-22 at 21:21 -0500, Felix Miata wrote:
Not mounting as boot a partition containing kernels and/or initrds in its root I could understand and agree with, but not forced reformatting.
As things stand anaconda just doesn't have this degree of precision. I think I'm right in saying nothing in anaconda looks at the actual contents of existing partitions at all. It just knows whether there's already a filesystem on the device, and whether you're reformatting it.
Even so, I don't understand what the problem is that dracut can't be limited to producing images based on /lib/modules, name matches to the installing arch, whatever is in the list of packages Anaconda has selected to install, or some other kind of matching.
None of the easy ones are entirely reliable, and none of the reliable ones are particularly easy. anaconda does not in fact have a concept of 'all the files I am installing', except in live installs. Well, it could theoretically do a sort of 'rpm -ql' on every package it had installed, but that's unwieldy and extremely slow. We went through all the others in #anaconda yesterday, for all of them there's either a reason it's not easy to do or a use case it doesn't cover...there are some candidates that might be 'good enough', but it was one of those things where everything was sufficiently annoying/difficult that it triggered someone's 'why do we let this happen in the first place' reflex.
Right, but I recall nothing in FHS that says an admin should have no right
I really hate this phrasing of things in terms of 'rights', we're not talking about rights, we're talking about the behaviour of software. No-one's inflicting on anyone else's human rights, here. We're just trying to make software that works as well as possible.
FWIW, something is putting "theme" files in /boot even though what the theme is for is not installed. Why aren't theme files for the bootloader among the places other things that use themes expect to find them?
I've no idea what you're talking about here, I'm afraid...
But, I do on occasion have use for the content I put on it both before and after the first OS installation, as well as while the first is the only, regardless of where it's mounted.
OK, so the case for you is that you have a process where you stick some bits in a partition that you then want to mount as /boot...they don't really *have* to be there, but it's a configuration you're accustomed to using?
Adam Williamson composed on 2015-01-23 02:25 (UTC-0500):
On Fri, 2015-01-23 at 00:58 -0500, Felix Miata wrote:
triggered someone's 'why do we let this happen in the first place' reflex.
"Let"? This is after all Linux, not Windows. Traditional home of choices, within reason of course. Hard of itself isn't a reason of itself to disallow. Everything can't be easy, especially within an installation system that must be functional within a minimal RAM pool. Nevertheless, limit choices in what seems to be an arbitrary manner and it starts smelling like tryanny of the majority wanting to exorcise a minority, too much outside control limiting autonomy of the local admin, bullying at the least.
Thinking about this from another direction, does any other major distro demand this ancient non-root component of FHS be wiped clean as prerequisite to installation?
Right, but I recall nothing in FHS that says an admin should have no right
I really hate this phrasing of things in terms of 'rights', we're not talking about rights, we're talking about the behaviour of software. No-one's inflicting on anyone else's human rights, here. We're just trying to make software that works as well as possible.
As well is practical? As well as possible means disallowing most or all choice, rather like Apple does.
FWIW, something is putting "theme" files in /boot even though what the theme is for is not installed. Why aren't theme files for the bootloader among the places other things that use themes expect to find them?
I've no idea what you're talking about here, I'm afraid...
Why need /boot/grub2 exist on a system without grub2 installed?
But, I do on occasion have use for the content I put on it both before and after the first OS installation, as well as while the first is the only, regardless of where it's mounted
OK, so the case for you is that you have a process where you stick some bits in a partition that you then want to mount as /boot...they don't really *have* to be there, but it's a configuration you're accustomed to using?
Yes, a convenience that can amount to a virtual necessity when there are no available USB sticks that are suited to task and yet another cheap junk OM drive has gone kaput. My "realboot" partitions usually don't get mounted as /boot very many times before reconfiguring them elsewhere.
Without them, though, there is usually no available Linux bootloader at all. It, rather than MBR, is the springboard from which all else flows here, out of habit designed to minimize potential inconvenience where Windows is on a system. With DOS/Windows compatible MBR code that does that, the master bootloader must live on a primary partition, even if it means the master bootloader must be Redmond's.
I'm tired and rambling. Sign off.
On 01/22/2015 02:36 PM, 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.
I'm curious to know if anyone / many people do this, and if so, if there's a particularly good use case for it; if so, we might want to provide that feedback to the anaconda folks.
There are a few references to using shared /boot on Google, but not that many, and mostly for crazy multiboot configurations that we really don't want to be stuck dealing with. Does anyone know of a really sensible use case for this?
For the record, this is actually re-hooking up code that was used in oldUI - that is, F17 and earlier - but in oldUI it just produced a warning you had to click through; the current patch flat disallows it. The main driving force for this is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1074358 , as it keeps turning out to be annoyingly tricky to make sure that only newly- installed kernels have their initramfs regenerated when installing to a shared /boot partition.
One specific case does come to mind. Some unfortunate users will have MBR drives stuck in a partition layout where creation of new partitions is a limited thing, maybe they don't have an extended partition, and it's somehow too late to change it - or anaconda can't handle creating the new partition, anecdotal report here only - and they want to boot another linux-based OS too. Oh, and they're really attached to the idea of /boot outside of /, or they're attached to the idea of a separate /home, so they want to use the one possible new partition as a PV and reuse the existing /boot.
I have a suspicion that disallowing reuse of /boot is going to hit a lot of people who are finally getting the gumption to move away from XP on their old systems and are shopping around for a distro to replace it. It's an edge case, sure, and likely a self-inflicted one, but there's probably a whole lot of impoverished schools or users that are just stuck there for whatever reason, and I'd hate to see Fedora burn them or turn them away.
On 22.01.2015 22:36, 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.
I'm curious to know if anyone / many people do this, and if so, if there's a particularly good use case for it; if so, we might want to provide that feedback to the anaconda folks.
There are a few references to using shared /boot on Google, but not that many, and mostly for crazy multiboot configurations that we really don't want to be stuck dealing with. Does anyone know of a really sensible use case for this?
For the record, this is actually re-hooking up code that was used in oldUI - that is, F17 and earlier - but in oldUI it just produced a warning you had to click through; the current patch flat disallows it. The main driving force for this is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1074358 , as it keeps turning out to be annoyingly tricky to make sure that only newly- installed kernels have their initramfs regenerated when installing to a shared /boot partition.
I use a share in the boot. Please just drop the entire proposal.
Thanks, poma
Le 22/01/2015 22:36, Adam Williamson a écrit :
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.
I reuse tons of sub-directory of /var
/var/lib/mysql /var/lib/libvirt/images /var/cache/mock /var/lib/mock
Ok, I don't really need them on install (I usually re-enable them after install)
I'm curious to know if anyone / many people do this, and if so, if there's a particularly good use case for it; if so, we might want to provide that feedback to the anaconda folks.
There are a few references to using shared /boot on Google, but not that many, and mostly for crazy multiboot configurations that we really don't want to be stuck dealing with. Does anyone know of a really sensible use case for this?
Yes, I use shared /boot for multi-boot (multiple fedora version).
I don't think disallowint mounting an existing partition without reformatting it is a good idea.
Remi.
For the record, this is actually re-hooking up code that was used in oldUI - that is, F17 and earlier - but in oldUI it just produced a warning you had to click through; the current patch flat disallows it. The main driving force for this is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1074358 , as it keeps turning out to be annoyingly tricky to make sure that only newly- installed kernels have their initramfs regenerated when installing to a shared /boot partition.
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/01569...
On Fri, 23 Jan 2015 09:26:34 -0800 Adam Williamson adamwill@fedoraproject.org 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/01569...
I know it's a bit late, but still: at my previous $JOB we put a bootloader entry in GRUB that kickstarts the system from scratch, preserving some key stuff from the old install.
The kernel + initrd for that were stored in /boot, along with some (smaller) temporary stuff that needed to be saved (SSH host key, etc). The kickstart script used (from over the network) preserved this /boot so as to be able to copy things back in the post kickstart scripts.
For this usecase, it's all good if the interactively started anaconda refuses a non-formatted /boot but it would be useful to keep this while kickstarting. And of course there's loads of workarounds such as copying stuff over the network instead of storing it locally.
So workaroundable, but still it intrudes on the usecase. I guess it's up to the anaconda developers whether it's a sane one :-)
Regards,
--Stijn
On Mon, 2015-01-26 at 22:52 +0100, Stijn Hoop wrote:
For this usecase, it's all good if the interactively started anaconda refuses a non-formatted /boot but it would be useful to keep this while kickstarting. And of course there's loads of workarounds such as copying stuff over the network instead of storing it locally.
FWIW, the change as proposed would not have affected the kickstart path, and that was pretty much intentional (it's generally a principle that kickstart lets you shoot yourself rather harder in the foot than the UI does).
On Mon, Jan 26, 2015 at 2:52 PM, Stijn Hoop stijn@sandcat.nl wrote:
On Fri, 23 Jan 2015 09:26:34 -0800 Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2015-01-22 at 13:36 -0800, Adam Williamson wrote:
So workaroundable, but still it intrudes on the usecase. I guess it's up to the anaconda developers whether it's a sane one :-)
I think it's sane to say we shouldn't support shared boot without an agreed upon spec in place. But I don't think it's sane to require reformatting a volume to achieve that lack of support. Just fsck the filesystem and maybe warn the user that overwriting (same named files) is going to happen and get on with it. There's nothing actually wrong with the fs, so I think required formatting is excessive. This isn't required on Windows or OS X btw, so long as the fs is a valid volume format and mounts without error, it's a legitimate install target.
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/01569...
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-configur... 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.
On Tue, 2015-02-03 at 13:58 -0500, David A. De Graaf wrote:
This setup works, but is fragile. For one thing, it is unsupported.
Well, 'supported' is always a somewhat weird notion when you're dealing with free operating systems. Do we 'support' shared /boot ? The installer happens to allow it, but we don't do any tests on it, and no-one seems hugely enthused about fixing any problems it causes, so...is it 'supported'?
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.
Well, you can always just take a backup. The 'configfile' directive is a supported part of grub2. It shouldn't change so long as grub2 is around.
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-configur... with slight edits:
- Begin Fedora installation as usual.
- Enter the Installation Destination spoke.
- 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
Yeah, I do wish someone would pick up the bug about creating the grub config file when not installing the bootloader...
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).
Yes, this is why I'd strongly advise using a setup like this *anyway* over using a shared /boot.
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).
Well, that wouldn't really be unrecoverable if it ever happened. You'd be able to recreate the 'master' bootloader config from the newly- installed OS. It'd just be a case of doing an appropriate grub2- install invocation. And you'd at least have the OS you just installed available.
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.
I disagree. It's not 'traditional', and it's not a good design, it's a mess.
There are a million different ways people do multiboot, and more or less everyone thinks theirs is the obvious, sensible, normal, traditional way to do it...and really, none of them is any good and it's a miracle they don't all fall apart more often. Having dealt with all the multifarious bugs in all of 'em over the years, FWIW, I avoid multiboot like the plague. One system, one OS. If I want to run any others I do it in virtualization. Makes life much simpler. Multiboot is fundamentally and unavoidably a hacky mess.
If the bootloader spec proposal ever gets any traction it would improve matters a bit, but I'm not sure where we stand on that.
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.
Er...it's not a kernel and never has been. It's a filesystem.
The initramfs has always been specific to at least a kernel version. We now have the dracut stuff which customizes initramfs to the installed system, but even before that, you couldn't safely have let Fedora N anaconda re-generate the initramfs for Fedora N-1. It'd never have been a good idea. What changed was various stuff in how anaconda deals with initramfs files, all for good reason - I went through the history already, it's in an older post somewhere.
-
Adam Williamson -
Chris Murphy -
David A. De Graaf -
Eric Blake -
Felix Miata -
Michal Jaegermann -
Pete Travis -
poma -
Rejy M Cyriac -
Remi Collet -
Stijn Hoop -
Sérgio Basto