As of the latest updates to anaconda and grub2 for Fedora 18, it is now possible to install with /boot as a btrfs subvolume. The way that grub2 is handling this is the "reach down" to the files it needs as if the subvolume was a directory. Is this OK? At this point I am not worried about snapshots or any other complexities. If the subvolume name is known. should grub2 be able to reliably "reach down" as if that subvolume was a directory? It needs some of its configuration files and, of course, the linux kernel. Point: it seems to work OK so far ;} Gene -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Jan 5, 2013, at 2:17 PM, Gene Czarcinski <gene@czarc.net> wrote:> As of the latest updates to anaconda and grub2 for Fedora 18, it is now possible to install with /boot as a btrfs subvolume. The way that grub2 is handling this is the "reach down" to the files it needs as if the subvolume was a directory. > > Is this OK?Mostly, but getting GRUB2 to handle subvolid I think would be better, because then subvols can be moved/renamed and things still would work. Small problem currently is Fedora 18 still depends on grubby to make grub.cfg changes, and grubby is being kinda dumb about updating grub.cfg when /boot is on a boot subvol - ergo there''s an error and it doesn''t update the grub.cfg correctly. https://bugzilla.redhat.com/show_bug.cgi?id=864198 Work around after any kernel update is to run grub2-mkconfig -o /boot/grub2/grub.cfg manually, and then the grub.cfg is correct.> At this point I am not worried about snapshots or any other complexities. If the subvolume name is known. should grub2 be able to reliably "reach down" as if that subvolume was a directory? It needs some of its configuration files and, of course, the linux kernel.It''s two parts. GRUB''s core.img code works as you describe. But grub-install and grub-mkconfig depend on /etc/fstab. If I use subvolid= in /etc/fstab and update either core.img or grub.cfg (with -install or -mkconfig), then the system is no longer bootable. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Jan 5, 2013, at 2:17 PM, Gene Czarcinski <gene@czarc.net> wrote:> As of the latest updates to anaconda and grub2 for Fedora 18, it is now possible to install with /boot as a btrfs subvolume. The way that grub2 is handling this is the "reach down" to the files it needs as if the subvolume was a directory.Also for what it''s worth, it also works for multiple device Btrfs volumes, all profiles supported by GRUB2. For me GRUB fails to navigate Btrfs for RAID0 if there are 5+ devices. Single still works, oddly RAID10 still works. So some regression is needed to figure out what''s going on there. May be a bug, but honestly it''s still pretty cool. Also to test is if installing grub to each device, in a multiple device raid1 or raid10 volume, still allows it to be bootable with any one device removed from the volume. I think it''ll work. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/05/2013 04:32 PM, Chris Murphy wrote:> On Jan 5, 2013, at 2:17 PM, Gene Czarcinski <gene@czarc.net> wrote: > >> As of the latest updates to anaconda and grub2 for Fedora 18, it is now possible to install with /boot as a btrfs subvolume. The way that grub2 is handling this is the "reach down" to the files it needs as if the subvolume was a directory. > Also for what it''s worth, it also works for multiple device Btrfs volumes, all profiles supported by GRUB2. For me GRUB fails to navigate Btrfs for RAID0 if there are 5+ devices. Single still works, oddly RAID10 still works. So some regression is needed to figure out what''s going on there. May be a bug, but honestly it''s still pretty cool. > > Also to test is if installing grub to each device, in a multiple device raid1 or raid10 volume, still allows it to be bootable with any one device removed from the volume. I think it''ll work. >There is also issues with btrfs and os-prober for multiboot ... it does not currently work. I hacked up a patch to get it to work but have since had second thoughts about how multiboot should be handled. I now prefer a separate grub partition, os-prober disabled, and a grub.cfg file which points to the grub.cfg for each individual system. BTW, although you can install and boot boot installed in a logical volume, that system is not supported in os-prober multiboot. Gene -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/05/2013 04:27 PM, Chris Murphy wrote:> On Jan 5, 2013, at 2:17 PM, Gene Czarcinski <gene@czarc.net> wrote: > >> As of the latest updates to anaconda and grub2 for Fedora 18, it is now possible to install with /boot as a btrfs subvolume. The way that grub2 is handling this is the "reach down" to the files it needs as if the subvolume was a directory. >> >> Is this OK? > Mostly, but getting GRUB2 to handle subvolid I think would be better, because then subvols can be moved/renamed and things still would work. > > Small problem currently is Fedora 18 still depends on grubby to make grub.cfg changes, and grubby is being kinda dumb about updating grub.cfg when /boot is on a boot subvol - ergo there''s an error and it doesn''t update the grub.cfg correctly. > https://bugzilla.redhat.com/show_bug.cgi?id=864198 > Work around after any kernel update is to run grub2-mkconfig -o /boot/grub2/grub.cfg manually, and then the grub.cfg is correct. > >> At this point I am not worried about snapshots or any other complexities. If the subvolume name is known. should grub2 be able to reliably "reach down" as if that subvolume was a directory? It needs some of its configuration files and, of course, the linux kernel. > It''s two parts. GRUB''s core.img code works as you describe. But grub-install and grub-mkconfig depend on /etc/fstab. If I use subvolid= in /etc/fstab and update either core.img or grub.cfg (with -install or -mkconfig), then the system is no longer bootable.So, I conclude from the above that the "safe" thing to do is to keep /boot as a separate ext2/3/4 partition. Gene -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Jan 6, 2013, at 7:44 AM, Gene Czarcinski <gene@czarc.net> wrote:> On 01/05/2013 04:27 PM, Chris Murphy wrote: >> On Jan 5, 2013, at 2:17 PM, Gene Czarcinski <gene@czarc.net> wrote: >> >>> As of the latest updates to anaconda and grub2 for Fedora 18, it is now possible to install with /boot as a btrfs subvolume. The way that grub2 is handling this is the "reach down" to the files it needs as if the subvolume was a directory. >>> >>> Is this OK? >> Mostly, but getting GRUB2 to handle subvolid I think would be better, because then subvols can be moved/renamed and things still would work. >> >> Small problem currently is Fedora 18 still depends on grubby to make grub.cfg changes, and grubby is being kinda dumb about updating grub.cfg when /boot is on a boot subvol - ergo there''s an error and it doesn''t update the grub.cfg correctly. >> https://bugzilla.redhat.com/show_bug.cgi?id=864198 >> Work around after any kernel update is to run grub2-mkconfig -o /boot/grub2/grub.cfg manually, and then the grub.cfg is correct. >> >>> At this point I am not worried about snapshots or any other complexities. If the subvolume name is known. should grub2 be able to reliably "reach down" as if that subvolume was a directory? It needs some of its configuration files and, of course, the linux kernel. >> It''s two parts. GRUB''s core.img code works as you describe. But grub-install and grub-mkconfig depend on /etc/fstab. If I use subvolid= in /etc/fstab and update either core.img or grub.cfg (with -install or -mkconfig), then the system is no longer bootable. > So, I conclude from the above that the "safe" thing to do is to keep /boot as a separate ext2/3/4 partition.It depends on what you''re comparing. And also what you mean by "not safe". fstab using labels with ext[234] could see a conflict one day, just the same as possibly renaming/moving a Btrfs subvolume used for boot, or even root for that matter. If you use UUID, and you use subvol=, and you don''t rename/move your subvolume, it''s perfectly safe. Nevertheless, GRUB becoming subvolid aware seems like a good idea to me, but I have no idea what''s involved in that. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Le 06/01/2013 20:11, Chris Murphy a écrit :> If you use UUID, and you use subvol=, and you don''t rename/move your subvolume, it''s perfectly safe. Nevertheless, GRUB becoming subvolid aware seems like a good idea to me, but I have no idea what''s involved in that.I actually run several machines on which I have /boot in a separate BTRFS subvol, without any issue. I have a multiboot between several different distros (typically Ubuntu, Mint, LMDE, Bodhi... All Ubuntu derivatives except for LMDE which is Debian-based...) sharing the same BTRFS container and using different subvols i.e. UBUNTU/@boot, LMDE/@boot etc... Works just great. -- Swâmi Petaramesh <swami@petaramesh.org> http://petaramesh.org PGP 9076E32E Ne cherchez pas : Je ne suis pas sur Facebook. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/06/2013 02:17 PM, Swâmi Petaramesh wrote:> Le 06/01/2013 20:11, Chris Murphy a écrit : >> If you use UUID, and you use subvol=, and you don''t rename/move your subvolume, it''s perfectly safe. Nevertheless, GRUB becoming subvolid aware seems like a good idea to me, but I have no idea what''s involved in that. > I actually run several machines on which I have /boot in a separate > BTRFS subvol, without any issue. I have a multiboot between several > different distros (typically Ubuntu, Mint, LMDE, Bodhi... All Ubuntu > derivatives except for LMDE which is Debian-based...) sharing the same > BTRFS container and using different subvols i.e. UBUNTU/@boot, > LMDE/@boot etc... > > Works just great. >I assume you have a "grub partition" (or its equivalent) with a grub.cfg file having menuentry definitions [pointing to the different grub.cfg file for each system ... that seems to work well (at least for me). Currently, os-prober does not support btrfs. I have taken a little look at the grub2 source code and there is some mention of both btrfs and zfs (and also btrfs subvolumes) in the changelogs. However, it is not clear to me (and I have not had the time yet) to explore exactly what the source code is doing or not doing. Gene -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Jan 6, 2013, at 1:05 PM, Gene Czarcinski <gene@czarc.net> wrote:> On 01/06/2013 02:17 PM, Swâmi Petaramesh wrote: >> Le 06/01/2013 20:11, Chris Murphy a écrit : >>> If you use UUID, and you use subvol=, and you don''t rename/move your subvolume, it''s perfectly safe. Nevertheless, GRUB becoming subvolid aware seems like a good idea to me, but I have no idea what''s involved in that. >> I actually run several machines on which I have /boot in a separate >> BTRFS subvol, without any issue. I have a multiboot between several >> different distros (typically Ubuntu, Mint, LMDE, Bodhi... All Ubuntu >> derivatives except for LMDE which is Debian-based...) sharing the same >> BTRFS container and using different subvols i.e. UBUNTU/@boot, >> LMDE/@boot etc... >> >> Works just great. >> > I assume you have a "grub partition" (or its equivalent) with a grub.cfg file having menuentry definitions [pointing to the different grub.cfg file for each system ... that seems to work well (at least for me). Currently, os-prober does not support btrfs. > > I have taken a little look at the grub2 source code and there is some mention of both btrfs and zfs (and also btrfs subvolumes) in the changelogs. However, it is not clear to me (and I have not had the time yet) to explore exactly what the source code is doing or not doing.Well, at least with the f18 version of GRUB 2 2.00, whether alternative Btrfs bootable systems are mounted or not, -mkconfig isn''t searching/finding for the /etc/fstab and /etc/default/grub of the other system like it appears to do with other file systems. I don''t get any additional entries other than the currently booted Btrfs system. So it looks like I''d need to manually add a configfile menu entry, pointing to each Btrfs bootable system. Chainloading from one grub to another is not useful. Better if they''re all on the same GRUB, and use configfile. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/06/2013 09:00 PM, Chris Murphy wrote:> On Jan 6, 2013, at 1:05 PM, Gene Czarcinski <gene@czarc.net> wrote: > >> On 01/06/2013 02:17 PM, Swâmi Petaramesh wrote: >>> Le 06/01/2013 20:11, Chris Murphy a écrit : >>>> If you use UUID, and you use subvol=, and you don''t rename/move your subvolume, it''s perfectly safe. Nevertheless, GRUB becoming subvolid aware seems like a good idea to me, but I have no idea what''s involved in that. >>> I actually run several machines on which I have /boot in a separate >>> BTRFS subvol, without any issue. I have a multiboot between several >>> different distros (typically Ubuntu, Mint, LMDE, Bodhi... All Ubuntu >>> derivatives except for LMDE which is Debian-based...) sharing the same >>> BTRFS container and using different subvols i.e. UBUNTU/@boot, >>> LMDE/@boot etc... >>> >>> Works just great. >>> >> I assume you have a "grub partition" (or its equivalent) with a grub.cfg file having menuentry definitions [pointing to the different grub.cfg file for each system ... that seems to work well (at least for me). Currently, os-prober does not support btrfs. >> >> I have taken a little look at the grub2 source code and there is some mention of both btrfs and zfs (and also btrfs subvolumes) in the changelogs. However, it is not clear to me (and I have not had the time yet) to explore exactly what the source code is doing or not doing. > Well, at least with the f18 version of GRUB 2 2.00, whether alternative Btrfs bootable systems are mounted or not, -mkconfig isn''t searching/finding for the /etc/fstab and /etc/default/grub of the other system like it appears to do with other file systems. I don''t get any additional entries other than the currently booted Btrfs system. > > So it looks like I''d need to manually add a configfile menu entry, pointing to each Btrfs bootable system. Chainloading from one grub to another is not useful. Better if they''re all on the same GRUB, and use configfile. >There appear to be two situations where you have multiple software systems installed on the same hardware (real or virtual) -- root on a btrfs subvolume or /boot installed on an LV. I worked up a patch to os-prober and a small update to grub2 which addresses the root on a btrfs subvolume -- see https://bugzilla.redhat.com/show_bug.cgi?id=888341 I have not looked into the /boot in a LV so it may involve os-prober also and I am also not sure that it will work with /boot on a btrfs subvolume. Since developing those patches, I have had second thoughts about how multiboot should be done and now believe that it should involve a grub partition with a simple grub.cfg file and os-prober disabled. The simple grub.cfg file had menuentry definitions which point to the "real" grub.cfg file for each system. One of these simple definitions would look like: menuentry "F18 on BTRFS" { insmod part_msdos insmod btrfs set root=''hd0,msdos5'' configfile /boot1/grub2/grub.cfg } where /boot is on btrfs subvol boot1 I do not actually use a grub partition but, instead, a minimal system with grub2 and installation into the MBR. Gene -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Le 06/01/2013 21:05, Gene Czarcinski a écrit :> I assume you have a "grub partition" (or its equivalent) with a > grub.cfg file having menuentry definitions [pointing to the different > grub.cfg file for each system ... that seems to work well (at least > for me). Currently, os-prober does not support btrfs.I don''t have any specific "grub" partition, every Linux install has its own grub install in its own /boot BTRFS subvolume. But I of course have only one grub actually installed in the disk MBR, the one that corresponds to the distro I use most (and for which I redid « grub-install /dev/sda » last). As this grub doesn''t auto-detect the other distros, I simply chain from there the other distro''s grub.cfg, by having crafted once for all a : "/etc/grub.d/40_custom" that contains, i.e. : #!/bin/sh exec tail -n +3 $0 # This file provides an easy way to add custom menu entries. Simply type the # menu entries you want to add after this comment. Be careful not to change # the ''exec tail'' line above. menuentry "DebMint Loader (Chained)" { configfile (hd0,2)/LMDE/@boot/grub/grub.cfg } menuentry "Mint 13 Loader (Chained)" { configfile (hd0,2)/MINT/@boot/grub/grub.cfg } menuentry "Bodhi Loader (Chained)" { configfile (hd0,2)/BODHI/@boot/grub/grub.cfg } That''s all folks ;-)) -- Swâmi Petaramesh <swami@petaramesh.org> http://petaramesh.org PGP 9076E32E Ne cherchez pas : Je ne suis pas sur Facebook. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Jan 7, 2013, at 8:42 AM, Gene Czarcinski <gene@czarc.net> wrote:> On 01/06/2013 09:00 PM, Chris Murphy wrote: >> On Jan 6, 2013, at 1:05 PM, Gene Czarcinski <gene@czarc.net> wrote: >> >>> On 01/06/2013 02:17 PM, Swâmi Petaramesh wrote: >>>> Le 06/01/2013 20:11, Chris Murphy a écrit : >>>>> If you use UUID, and you use subvol=, and you don''t rename/move your subvolume, it''s perfectly safe. Nevertheless, GRUB becoming subvolid aware seems like a good idea to me, but I have no idea what''s involved in that. >>>> I actually run several machines on which I have /boot in a separate >>>> BTRFS subvol, without any issue. I have a multiboot between several >>>> different distros (typically Ubuntu, Mint, LMDE, Bodhi... All Ubuntu >>>> derivatives except for LMDE which is Debian-based...) sharing the same >>>> BTRFS container and using different subvols i.e. UBUNTU/@boot, >>>> LMDE/@boot etc... >>>> >>>> Works just great. >>>> >>> I assume you have a "grub partition" (or its equivalent) with a grub.cfg file having menuentry definitions [pointing to the different grub.cfg file for each system ... that seems to work well (at least for me). Currently, os-prober does not support btrfs. >>> >>> I have taken a little look at the grub2 source code and there is some mention of both btrfs and zfs (and also btrfs subvolumes) in the changelogs. However, it is not clear to me (and I have not had the time yet) to explore exactly what the source code is doing or not doing. >> Well, at least with the f18 version of GRUB 2 2.00, whether alternative Btrfs bootable systems are mounted or not, -mkconfig isn''t searching/finding for the /etc/fstab and /etc/default/grub of the other system like it appears to do with other file systems. I don''t get any additional entries other than the currently booted Btrfs system. >> >> So it looks like I''d need to manually add a configfile menu entry, pointing to each Btrfs bootable system. Chainloading from one grub to another is not useful. Better if they''re all on the same GRUB, and use configfile. >> > There appear to be two situations where you have multiple software systems installed on the same hardware (real or virtual) -- root on a btrfs subvolume or /boot installed on an LV.I''m unclear on the use case. If /boot is on its own LV, why not just use ext4? If Btrfs, then I''d expect boot to be included in one Btrfs volume, along with home and rootfs. If that''s on an LV, the use cases I''m envisioning for that the boot loader wouldn''t be aware of the LV (e.g. VM, iSCSI, etc).> Since developing those patches, I have had second thoughts about how multiboot should be done and now believe that it should involve a grub partition with a simple grub.cfg file and os-prober disabled. The simple grub.cfg file had menuentry definitions which point to the "real" grub.cfg file for each system.It''s messy without agreement on how to boot all distributions. I''ve also thought of this primary/public grub.cfg, and secondary/private grub.cfg. The first "forwards" to the grub.cfg for each distribution using configfile or legacyconfigfile. However, that primary GRUB instance necessarily would need to contain the entry for Windows, etc. So each distribution''s grub-mkconfig would need to know to write out a distribution specific grub.cfg which is based on os-prober disabled; but then also be capable of updating the primary grub.cfg - not merely write out a new one. And then if a distribution is deleted from the system, how is this discovered, and the old entry in the primary grub.cfg removed? Messy.> I do not actually use a grub partition but, instead, a minimal system with grub2 and installation into the MBR.grub''s core.img can accept a baked in grub.cfg Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Jan 7, 2013, at 10:48 AM, Swâmi Petaramesh <swami@petaramesh.org> wrote:> Le 06/01/2013 21:05, Gene Czarcinski a écrit : >> I assume you have a "grub partition" (or its equivalent) with a >> grub.cfg file having menuentry definitions [pointing to the different >> grub.cfg file for each system ... that seems to work well (at least >> for me). Currently, os-prober does not support btrfs. > > I don''t have any specific "grub" partition, every Linux install has its > own grub install in its own /boot BTRFS subvolume.Grub partition, as I''m taking it, means: MBR gap on MBR layouts; and BIOS Boot partition (GUID 21686148-6449-6E6F-744E-656564454649) on GPT layouts. In any case, MBR gap, dedicated GPT partition, or grub.efi application, it''s possible to bake a grub.cfg directly into the core.img. Technically using configfile is not chain loading, you''re just having the same instance of GRUB load an alternate config. Chain loading GRUB implies loading a new binary (boot loader) to replace the first instance of GRUB. Using configfile has the caveat that the GRUB using configfile may be of a different version than the GRUB package that produced the grub.cfg being configfile loaded. And as the syntax of grub.cfg has been changing quite a bit it''s possible to have related failures. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/07/2013 01:42 PM, Chris Murphy wrote:> On Jan 7, 2013, at 8:42 AM, Gene Czarcinski <gene@czarc.net> wrote: > >> On 01/06/2013 09:00 PM, Chris Murphy wrote: >>> On Jan 6, 2013, at 1:05 PM, Gene Czarcinski <gene@czarc.net> wrote: >>> >>>> On 01/06/2013 02:17 PM, Swâmi Petaramesh wrote: >>>>> Le 06/01/2013 20:11, Chris Murphy a écrit : >>>>>> If you use UUID, and you use subvol=, and you don''t rename/move your subvolume, it''s perfectly safe. Nevertheless, GRUB becoming subvolid aware seems like a good idea to me, but I have no idea what''s involved in that. >>>>> I actually run several machines on which I have /boot in a separate >>>>> BTRFS subvol, without any issue. I have a multiboot between several >>>>> different distros (typically Ubuntu, Mint, LMDE, Bodhi... All Ubuntu >>>>> derivatives except for LMDE which is Debian-based...) sharing the same >>>>> BTRFS container and using different subvols i.e. UBUNTU/@boot, >>>>> LMDE/@boot etc... >>>>> >>>>> Works just great. >>>>> >>>> I assume you have a "grub partition" (or its equivalent) with a grub.cfg file having menuentry definitions [pointing to the different grub.cfg file for each system ... that seems to work well (at least for me). Currently, os-prober does not support btrfs. >>>> >>>> I have taken a little look at the grub2 source code and there is some mention of both btrfs and zfs (and also btrfs subvolumes) in the changelogs. However, it is not clear to me (and I have not had the time yet) to explore exactly what the source code is doing or not doing. >>> Well, at least with the f18 version of GRUB 2 2.00, whether alternative Btrfs bootable systems are mounted or not, -mkconfig isn''t searching/finding for the /etc/fstab and /etc/default/grub of the other system like it appears to do with other file systems. I don''t get any additional entries other than the currently booted Btrfs system. >>> >>> So it looks like I''d need to manually add a configfile menu entry, pointing to each Btrfs bootable system. Chainloading from one grub to another is not useful. Better if they''re all on the same GRUB, and use configfile. >>> >> There appear to be two situations where you have multiple software systems installed on the same hardware (real or virtual) -- root on a btrfs subvolume or /boot installed on an LV. > I''m unclear on the use case. If /boot is on its own LV, why not just use ext4? If Btrfs, then I''d expect boot to be included in one Btrfs volume, along with home and rootfs. If that''s on an LV, the use cases I''m envisioning for that the boot loader wouldn''t be aware of the LV (e.g. VM, iSCSI, etc).Oops. It is me that was not clear. Case 1: You have multiple systems installed on one piece of real or virtual hardware. These could be different releases or even different distributions. At least one of these systems has root installed on a btrfs subvolume. When grub2-mkconfig is run on that system everything is OK. Now you are on a different system and you run grub2-mkconfig with os-prober enabled so it will look for other systems that could be booted. It will not "see" the system with root on the btrfs subvolume. That is because os-prober does not understand btrfs. Case2: This is similar to the above situation except that you have /boot installed in an LV rather than a regular partition with the LV formated with ext4. Similar to the above, if, from a different installed system you run grub2-mkconfig with os-prober enabled, the system with the /boot in the LV will not be "seen". I have not looked into this one so it may be os-prober or grub2 itself. Seeing this convinced me to avoid using os-prober and simply have a "boot director" with simple menuentry definitions pointing to the various grub.cfg files for each system.> >> Since developing those patches, I have had second thoughts about how multiboot should be done and now believe that it should involve a grub partition with a simple grub.cfg file and os-prober disabled. The simple grub.cfg file had menuentry definitions which point to the "real" grub.cfg file for each system. > It''s messy without agreement on how to boot all distributions. I''ve also thought of this primary/public grub.cfg, and secondary/private grub.cfg. The first "forwards" to the grub.cfg for each distribution using configfile or legacyconfigfile. However, that primary GRUB instance necessarily would need to contain the entry for Windows, etc. > > So each distribution''s grub-mkconfig would need to know to write out a distribution specific grub.cfg which is based on os-prober disabled; but then also be capable of updating the primary grub.cfg - not merely write out a new one. > > And then if a distribution is deleted from the system, how is this discovered, and the old entry in the primary grub.cfg removed? Messy.The hardware systems have four or five software systems on each. It is not so much of deleting an distribution as much as just ignoring it. Disk space really is pretty inexpensive these days.> >> I do not actually use a grub partition but, instead, a minimal system with grub2 and installation into the MBR. > grub''s core.img can accept a baked in grub.cfgIf this was a true production situation then this would be a good choice but I am dealing with more of a laboratory environment with things that change a lot. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Jan 7, 2013, at 2:41 PM, Gene Czarcinski <gene@czarc.net> wrote:>> >> And then if a distribution is deleted from the system, how is this discovered, and the old entry in the primary grub.cfg removed? Messy. > The hardware systems have four or five software systems on each. It is not so much of deleting an distribution as much as just ignoring it. Disk space really is pretty inexpensive these days.The case of natively booting/rebooting different OS''s/distributions on BIOS is difficult. For VM, I think maybe a simpler approach like syslinux is better, which understands Btrfs I believe. And for UEFI, I think a simpler approach is something like rEFInd or gummiboot, as boot manager, and then for various linux distributions to be built with EFI_STUB.>> >>> I do not actually use a grub partition but, instead, a minimal system with grub2 and installation into the MBR. >> grub''s core.img can accept a baked in grub.cfg > If this was a true production situation then this would be a good choice but I am dealing with more of a laboratory environment with things that change a lot.Yeah currently it''s difficult to do multiple OS native booting. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html