Re: Canonical way to upgrade an existing nfsroot?

[Thomas Lange]

> On Tue, 6 Sep 2016 17:13:34 +0200, Steffen Grunewald 
>  said:

> I found that you have created a backport for jessie but don't distribute 
that via
> jessie/koeln?
> You might tweak the dracut.maintscript (if it's required at all) ...
Because jessie/koeln already includes the newest FAI and dracut
versions which are identical to the versions in backports.

-- 
regards Thomas

Re: Canonical way to upgrade an existing nfsroot?

[Steffen Grunewald]

On Tue, 2016-09-06 at 16:08:57 +0200, Thomas Lange wrote:
> > On Tue, 6 Sep 2016 16:05:04 +0200, Steffen Grunewald 
> >  said:
> 
> > from scratch. I'm running into Debian bug #830229 now (jessie/koeln, 
> 044+109-1).
> > This did happen before as well (044+105-2) but I didn't notice, and 
> stretch
> > seems to be unaffected (so this may actually be a policy/dpkg issue?).
> I also think that this bug is more a dpkg bug.

Well, you don't "backport" a sid package without asking for trouble sometimes.
The "rm_conffiles" line in debian/dracut.maintscript seems to require a newer
dpkg, indeed...
Checking the differences between dpkg-maintscript-helper scripts in dpkg 1.17.27
(jessie) and 1.18.10 (stretch), one quickly finds a bunch of

-  dpkg --compare-versions "$2" le-nl "$LASTVERSION"; then
+  dpkg --compare-versions -- "$2" le-nl "$LASTVERSION"; then

replacements - which seem to be closely related.
dracut's maintscripts seem to make use of that.

I found that you have created a backport for jessie but don't distribute that 
via
jessie/koeln?
You might tweak the dracut.maintscript (if it's required at all) ...

- S

Re: AW: ACLs on /target/ while installation causing trouble

[Thomas Lange]

> On Tue, 6 Sep 2016 16:18:46 +0200 (MEST), "steven.w...@t-online.de" 
>  said:

> Hi Thomas,
> we used version 1.29 .
Ah, this is in testing and sid. Thanks for the info.

-- 
regards Thomas

AW: ACLs on /target/ while installation causing trouble

[steven.w...@t-online.de]

Hi Thomas,

we used version 1.29 .

#
(FAI) root@fai5-server:~# chroot /srv/fai/nfsroot/fai5/ tar --version
tar (GNU tar) 1.29
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by John Gilmore and Jay Fenlason.
#

#
/etc/fai/fai5/hooks/debs/tar_1.29b-1_amd64.deb:
 new debian package, version 2.0.
 size 752732 bytes: control archive=2519 bytes.
   9 bytes, 1 lines  conffiles
 784 bytes,20 lines  control  
3760 bytes,54 lines  md5sums  
 270 bytes,14 lines   *  postinst #!/bin/sh
 317 bytes,19 lines   *  prerm#!/bin/sh
 Package: tar
 Version: 1.29b-1
 Architecture: amd64
 Essential: yes
 Maintainer: Bdale Garbee 
 Installed-Size: 2749
 Pre-Depends: libacl1 (>= 2.2.51-8), libc6 (>= 2.17), libselinux1 (>= 1.32)
 Suggests: bzip2, ncompress, xz-utils, tar-scripts
 Conflicts: cpio (<= 2.4.2-38)
 Breaks: dpkg-dev (<< 1.14.26)
 Replaces: cpio (<< 2.4.2-39)
 Section: utils
 Priority: required
 Multi-Arch: foreign
 Description: GNU version of the tar archiving utility
  Tar is a program for packaging a set of files as a single archive in tar
  format.  The function it performs is conceptually similar to cpio, and to
  things like PKZIP in the DOS world.  It is heavily used by the Debian package
  management system, and is useful for performing system backups and exchanging
  sets of files with others.
[...]
#

I'am not sure about the origin of the package. But I think it was the testing / 
experimental tree of a debian repository. 


Best regards,

Steven




-Original-Nachricht-
Betreff: Re: ACLs on /target/ while installation causing trouble
Datum: 2016-08-29T12:29:03+0200
Von: "Thomas Lange" 
An: "fully automatic installation for Linux" 

> On Thu, 25 Aug 2016 08:45:38 +0200, Steven Wend  
> said:

> using a hook while creating the nfs root. We added manually a allready
> fixed tar version via dpkg -i. The problem is solved that way.
Which tar version does fix it? It this version available in unstable
or somewhere else?

-- 
regards Thomas



Gesendet mit Telekom Mail  - kostenlos und 
sicher für alle!

Re: Canonical way to upgrade an existing nfsroot?

[Thomas Lange]

> On Tue, 6 Sep 2016 16:05:04 +0200, Steffen Grunewald 
>  said:

> from scratch. I'm running into Debian bug #830229 now (jessie/koeln, 
044+109-1).
> This did happen before as well (044+105-2) but I didn't notice, and 
stretch
> seems to be unaffected (so this may actually be a policy/dpkg issue?).
I also think that this bug is more a dpkg bug.

-- 
regards Thomas

Re: Canonical way to upgrade an existing nfsroot?

[Thomas Lange]

> On Tue, 6 Sep 2016 15:51:06 +0200, Steffen Grunewald 
>  said:

> What's the canonical way to keep a nfsroot updated? Would it be sufficient
> to "hold" the dracut* packages so their postinst scripts don't fail?
I always rebuild my nfsroot. If you save the base.tar.xz before
calling fai-make-nfsroot and then use it this saves you a lot of time.

This is what I do
cp /srv/fai/nfsroot/var/tmp/base.tar.xz /tmp
fai-make-nfsroot -fvB /tmp/base.tar.xz
-- 
regards Thomas

Re: Canonical way to upgrade an existing nfsroot?

[Steffen Grunewald]

On Tue, 2016-09-06 at 15:51:06 +0200, Steffen Grunewald wrote:
> Apparently I have killed a working nfsroot by naively running "apt-get 
> upgrade".
> What's the canonical way to keep a nfsroot updated? Would it be sufficient
> to "hold" the dracut* packages so their postinst scripts don't fail?

To avoid all sorts of hassle, I decided to rebuild the nfsroots (jessie, 
stretch)
from scratch. I'm running into Debian bug #830229 now (jessie/koeln, 044+109-1).
This did happen before as well (044+105-2) but I didn't notice, and stretch
seems to be unaffected (so this may actually be a policy/dpkg issue?).

Back to reinstalling my manual changes...

- S 

Canonical way to upgrade an existing nfsroot?

[Steffen Grunewald]

Apparently I have killed a working nfsroot by naively running "apt-get upgrade".
What's the canonical way to keep a nfsroot updated? Would it be sufficient
to "hold" the dracut* packages so their postinst scripts don't fail?

Thanks,
 S

-- 
Steffen Grunewald, Cluster Administrator
Max Planck Institute for Gravitational Physics (Albert Einstein Institute)
Am Mühlenberg 1
D-14476 Potsdam-Golm
Germany
~~~
Fon: +49-331-567 7274
Fax: +49-331-567 7298
Mail: steffen.grunewald(at)aei.mpg.de
~~~