[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#813506: zipl-installer: set up re-IPL to boot newly installed Debian/Linux



Hi Philipp,

On Mon, Feb 08, 2016 at 08:59:23AM +0100, Hendrik Brueckner wrote:
> On Sun, Feb 07, 2016 at 01:31:49AM +0100, Philipp Kern wrote:
> > On Tue, Feb 02, 2016 at 05:40:34PM +0100, Hendrik Brueckner wrote:
> > > --- a/debian/zipl-installer.postinst
> > > +++ b/debian/zipl-installer.postinst
> > > @@ -57,8 +57,5 @@ EOF
> > >  sed -e 's/^do_bootloader.*$/do_bootloader = yes/' < /target/etc/kernel-img.conf > /target/etc/kernel-img.conf.$$
> > >  mv /target/etc/kernel-img.conf.$$ /target/etc/kernel-img.conf
> > >  
> > > -mount -t proc none /target/proc || true
> > > -
> > > -log-output -t zipl-installer chroot /target /sbin/zipl
> > > -
> > > -umount /target/proc || true
> > > +# Run zipl in the installed target instance
> > > +in-target /sbin/zipl -V
> > 
> > I'm a bit sad that this loses the zipl-installer tagging in
> > /var/log/syslog because in-target does not support customized logging.
> > It will log everything as "in-target".
> > 
> > At least there's prior art here in grub-installer calling in-target
> > if $ROOT is /target. in-target does a bunch of stuff with policy-rc.d,
> > for instance. But I guess that should be safe then...
> 
> For me "in-target" seems to be more convenient.  Of course, logging target
> is different but I think that it is OK for zipl.  The alternative would be
> something like this:
> 
> =========================================================
> --- a/debian/zipl-installer.postinst
> +++ b/debian/zipl-installer.postinst
> @@ -57,8 +57,18 @@ EOF
>  sed -e 's/^do_bootloader.*$/do_bootloader = yes/' < /target/etc/kernel-img.conf > /target/etc/kernel-img.conf.$$
>  mv /target/etc/kernel-img.conf.$$ /target/etc/kernel-img.conf
> 
> -mount -t proc none /target/proc || true
> +mount -o bind /proc /target/proc || true
> +mount -o bind /sys /target/sys || true

For running zipl on an (linear) mapped LVM device, the device mapper helper
for zipl (and resp. for chreipl too) requires access to sysfs.  That means
mounting /sys is an important step.  Michael Roesch on CC reported this
issues to me.  With this problem solved (either manually or using in-target)
zipl'ing on linear mapped LVM devices will work.

Thanks and kind regards,
  Hendrik


Reply to: