[PATCH] add capability to install grub2 but not update the MBR

Vratislav Podzimek vpodzime at redhat.com
Tue Sep 16 10:57:22 UTC 2014


On Tue, 2014-09-16 at 06:45 -0400, Gene Czarcinski wrote:
> On 09/16/2014 02:49 AM, Vratislav Podzimek wrote:
> > On Mon, 2014-09-15 at 09:26 -0400, Gene Czarcinski wrote:
> >> On 09/15/2014 08:59 AM, Vratislav Podzimek wrote:
> >>> On Mon, 2014-09-15 at 08:54 -0400, Gene Czarcinski wrote:
> >>>>> On 09/15/2014 02:30 AM, Vratislav Podzimek wrote:
> >>>>>>> Where is the kickstart support? Or do you by "Kickstart install" mean
> >>>>>>> installation where both 'ks=...' and 'inst.nombr' are provided as boot
> >>>>>>> options? I think we still need something like 'bootloader --nombr' if
> >>>>>>> this is the right way to go to fix that bug.
> >>>>>>>
> >>>>>>>
> >>>>> I decided to keep things as simple as possible and just have to boot
> >>>>> parameter "nombr" which will apply to any install including kickstart.
> >>>>> I did consider adding code so that like --extlinux, you could specify
> >>>>> --nombr on kickstart's bootloader command.  But, more code is a chance
> >>>>> for additional errors.
> >>>>>
> >>>>> But, if there is a strong desire to have --nombr as another option on
> >>>>> kickstart's bootloader command, I can add it.
> >>> A general policy in the Anaconda installer is that every feature should
> >>> be implemented in kickstart first. That's the most comprehensive and
> >>> feature-complete "installation mode". So please add that code as well.
> >> v1.1 coming "real soon now"
> >>
> >> Since you brought up the fact that it is Anaconda Installer policy that
> >> every feature be implemented in kickstart first, how about my kickstart
> >> "--reclaim" option for kickstart's btrfs command.
> >>
> >> The problem:  When I manually configure the storage layouts on a regular
> >> gui or live install, one of the things I can do is to delete an existing
> >> subvolume so that the space and the subvolume's name can be reused.  In
> >> kickstart, currently I can one create new subvolumes or re-use an
> >> existing subvolume.  There is also the requirement that the the rootfs
> >> ("/") subvolume always be freshly "formatted".
> >>
> >> So, to provide the same capability to kickstart that is available in a
> >> regular install, I create a "reclaim" patch.  With the patch applied,
> >> you can specify something like:
> >>            btrfs  /           --subvol  --name=root1  btrfs_vol --reclaim
> >>            btrfs  /home  --subvol  --name=home  btrfs_vol  --noformat
> >>
> >> which will result in two subvolume.  The home subvolume is reused
> >> whereas if the root1 subvolume already exists, it will be deleted and
> >> then reallocated.
> >>
> >> Comments??
> > I'm not a BTRFS expert, but as far as I understand the issue and use
> > case, that looks good to me except that I don't understand why you need
> > the --reclaim option at all. I think that if --noformat is omitted the
> > subvolume should be "formatted"/reused.
> >
> As currently implemented in anaconda for btrfs, --noformat and 
> --useexisting do the same thing and simply reuse an existing subvolume.  
> If neither is specified, the anaconda attempt to allocate a new 
> subvolume which fails because the name already exists.  You could 
> specify a new name which did not already exist but that leaves the space 
> unavailable.  You could also boot into rescue mode and delete the 
> unwanted subvolume.  Anaconda requires that rootfs ("/") and /boot be 
> freshly formatted.
> 
> This is different that the meanings of --noformat and --useexisting on 
> the logvol command where --useexisting means to reuse and format it (in 
> btrfs the equivalent of reformat is to delete the subvol and then 
> reallocate it).
> 
> When I originally suggested this functionality, I suggested that 
> --useexisting be the option but I was shot down because that would be a 
> significant change in how things worked and could break some existing 
> kickstart configuration files.  Thus, --reclaim
Thanks for the additional explanation. Makes sense to me then.

-- 
Vratislav Podzimek

Anaconda Rider | RHCE | Red Hat, Inc. | Brno - Czech Republic




More information about the anaconda-patches mailing list