Re: a cautionary tale w/ successful recovery
On 20091104_075158, Paul E Condon wrote:
> On 20091103_114547, Boyd Stephen Smith Jr. wrote:
> > On Tuesday 03 November 2009 10:38:41 Johannes Wiedersich wrote:
> > > Andrew Sackville-West wrote:
> > > > On Sun, Nov 01, 2009 at 07:08:00PM -0500, Andrew Reid wrote:
> > > >> For the sysems I back up at work, we do the dpkg --get-selections
> > > >> thing, but I've never kept a copy of the boot sector -- that's an
> > > >> excellent idea.
> > >
> > > I guess the 'state of the art' way of recording a list of installed
> > > packages, nowadays is
> > >
> > > # aptitude -F "%p" search '~i!~M' > package-list
> > >
> > > You can then just install like
> > >
> > > # aptitude install $(cat pacage-list)
> > >
> > > dpkg --get-selections does not distinguish between packages installed
> > > manually or automatically, so that information is lost on the reinstall.
> > > The search pattern just looks for packages that were installed
> > > manually. The install will automatically install all dependencies.
> >
> > However, because of OR dependencies (i.e. using the '|' character), it might
... snip ...
> > packages", and some combination of dpkg --set-selections, aptitude markauto,
> > and aptitude install should be able to restore them.
>
> My suggestion is:
>
> # aptitude -F "%p %M" search '~i' |tr -s ' '|sed 's/ A$/+M/' > package-list
>
> followed by (without change except for fixing the missing "k" ;-)
>
> # aptitude install $(cat package-list)
>
> I haven't actually tested this. It is just what I think would work
... snip ...
Now I have tested it, and, except for two nits, it works as very well.
Nit 1. An error of unrealistic expectation: I performed the test by
installing from the file packges-list into a different partition and
then overwriting the new /etc with a backup copy of the old
/etc. This, didn't work smoothly because the backup version of
/etc/fstab was _wrong_, really _wrong_ for root being in the new
partition.
Nit 2. sshfs didn't work on the new installation. There was a problem
with permissions and the fuse group. I checked groups for my user
account, and it showed me as being a member of the group fuse, but
something that I had not seen before, was wrong. This was fixed by
purging sshfs (which also removed fuse-utils, as was a hoped for
consequence of this suggestion) and installing it the normal,
interactive way. While this was being processed, I noticed that the
install script created the group fuse. Apparently, in the recreated
system, my user-name was a member of the fuse group, but the fuse
group did not actually exist. This lead to some disfunction in the
Debian Way.
Theory: Aptitude, when instructed to 'install fuse-utils+M', does just
that, namely 'install fuse-utils', followed by setting a boolean flag
to indicate automatic install. But it doesn't actually run any of the
install script of some other package, in this case sshfs, which does
actually create the fuse group.
If this theory is valid, then there can be other automatic installs that
are not properly handled by this suggestion, but don't happen to be part
of what I happen to have installed on my home system.
So, it would be nice if this were fixed in some general way. OTOH, it
might be a problem caused by fuse not being a 'regular' system group,
which would indicate changes, not in aptitude, but in the packaging of
fuse-utils.
Conclusion: I'm happy with this way of preparing a file that automates
the reconstruction of a whole host system. I'll be using it whether or
not my nits can be dealt with in some general way.
--
Paul E Condon
pecondon@mesanetworks.net
Reply to: