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

Re: Return a Debian system to a pristine state



On Sat 06 Jun 2020 at 12:24:51 (+0300), Andrei POPESCU wrote:
> On Jo, 04 iun 20, 09:32:48, David Wright wrote:
> > On Sun 31 May 2020 at 18:43:46 (+0100), Michael Howard wrote:
> > > 
> > > Well then it's not pristine, which is what the OP wanted.
> > 
> > That begs the question of what pristine means, because it has never
> > been defined even by the OP. Their closest attempt at a definition
> > was the "first boot experience" but, unless you install a system as
> > soon as a release is released, you can't return to that configuration
> > without downgrading packages. That would make no sense at all,
> > especially for someone with a serious concern about scanning for
> > vulnerabilities.
> 
> I don't recall anyone in the thread asking for exact versions at the 
> time of installation, just the same package set.
> 
> This would also require exceptions for ABI changes (libfoo1 replaced by 
> libfoo2 or linux-image-x.y.z-1-amd64 replaced by 
> linux-image-x.y.z-2-amd64). These should be rare on stable + 
> stable-security and can be handled with the manual/auto installed 
> mechanism.

I'm quite happy to accept that. As I run stable, I'm unlikely to run
into complications concerning versions, but those running newer suites
might have that problem where the functionality of a group of packages
gets refactorised, so that some versions of A might break other versions
of B.

So the OP is happy with defining "pristine" as the original package
set, and has realised that their life would have been made easier if
they'd made a timely record. Or made a backup, in which case they
could just grep /var/lib/dpkg/status.

If they didn't, they might have to rely on the method I outlined to
Marco (which The Wanderer corrected), using apt's history.log file.

I did try out returning a system to its initial state, admittedly
under favourable circumstances. After installing with the d-i, there
were 531 packages installed. I ran my usual script that installs
"all the rest" of my typical system, requesting 287 packages and,
with their Depends and Recommends, installing about 2050.

I then tac'd my script, edited all the installs to removes, and ran
it. As it progressed, the proffered list of suggestions for
autoremoval got longer and longer, so that by the time the script
was finished, a simple autoremove command wiped out 885 packages.

The system still had plenty of Recommends left installed, as one would
expect, so I diff'd the list of post-installer packages with the
current version to produce a 495-package purge command. (Because I
had removed rather than purged packages, there were plenty of
"rc"-status packages still installed, as well as the Recommends.
That script removed virtually all the packages I had installed myself.

I write "virtually" because, as I was doing all this casually,
I had to reinstall aptitude twice (along with its Depends and
Recommends) in order to run its "why" command, so I ended up
with those extra packages still installed.

I was impressed by apt-get's performance, probably because of dim
memories of how dpkg would react on being asked to install ~2000
packages at once. The latter doesn't have the logic for sorting
operations into a sequence that preserves an unbroken system.

Cheers,
David.


Reply to: