1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
|
Some tips what to do if (hopefully never), your database gets
corrupted:
First there are three different databases used, residing in three
files in your --dbdir (normally db/):
1) references.db
This file only contains the information which file in the pool/
is needed by which target (i.e. which type/distribution/
component/architecture quadruple). This is simply repairable by
deleting references.db and running "rereference".
The current state of this database can be seen with "dumpreferences".
All references from some specific target can be removed with
"_removereferences".
2) files.db and checksums.db
These files contain the information about which files in the pool/ dir
are known and what checksums they have. Files not in here will not be
deleted with "deleteunreferenced". Files being wrong here will not realized
(and thus not corrected even if told to be newly included)
If both files exist, files.db is the canonical information and checksums.db
can be regenerated with a call to collectnewchecksums.
If only checksums.db is there, only that it used. (This means: if you
have called collectnewchecksums since you last used a version prior to 3.3
with this repository, you can just delete files.db. But make sure to
never ever use a version prior to 3.0 on this repository after that.)
To get this database in text form use "_listchecksums" without argument,
to add items manually pipe it into "_addchecksums". (Filenames
are handled as strings, so be careful).
If the database is completely lost or broken, you can regain it by moving
files.db and checksums.db out of the way and running:
find $BASEDIR/pool -type f -printf "pool/%P\n" | reprepro -b $BASEDIR _detect
(or cd $BASEDIR && find pool -type f -print | reprepro -b . _detect)
Also single files can be removed or added by "_forget" and "_detect".
(Again note filekeys will be handled as strings, so leading "./", double
slashes, "/./", symlinks and the like make them differ).
4) packages.db
This file contains multiple databases, one for each target, containing
the chunks from the Packages or Sources files, indexed by package name.
This one is the hardest to reconstruct. If you have still an uncorrupted
"dists/" directory around, (e.g. you just deleted db/ accidentally),
it can be reconstructed by moving your dists/ directory to some other place,
moving the packages.db file (if still existent) away, and set every distribution
in conf/distributions a "Update: localreadd" with localreadd in conf/updates like:
Name: localreadd
Suite: *
Method: copy:/<otherplace>
with otherplace being the place you moved the dists/ directory too.
If the packages database is corrupt, the described way can at least reconstruct
the Packages still landing in the Packages.gz and Sources.gz files.
If references.db is still accessible via dumpreferences, it can give hints
where the other files belong to. Otherwise removing references.db and calling
"rereference" and then "dumpunreferenced" will give you a list of files not
yet anywhere.
Last but not least, there are also the "check" and "checkpool" commands, which
can give some hints about inconsistencies. (Check will also read files missing
from files.db+checksums.db if they are needed by packages but in the pool).
|
