[gentoo-dev] recovering from corrupted vdb

[gentoo-dev] recovering from corrupted vdb

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

Shouldn't portage offer some means to recover from a corrupted vdb?

I just stumbled upon
<http://forums.gentoo.org/viewtopic-t-900382-start-0-postdays-0-postorder-asc-highlight-.html>
and it seems really bad.

It would suck if the only solution to this is reinstall (I remember
package database becoming corrupted in some RPM-based distro I had years
ago and I hated it).

If the recovery is already possible, we should get a doc explaining what
to do. Otherwise it'd be really great to implement some recovery logic.

I think we can't salvage much from a corrupted db (anything can happen,
and the reporter mentions some code being present in the files), but at
least "emerge -e world" or equivalent should be possible.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] recovering from corrupted vdb

[Rich Freeman]

On Thu, Nov 3, 2011 at 7:15 AM, "Paweł Hajdan, Jr."
<phajdan.jr@gentoo.org> wrote:
> I think we can't salvage much from a corrupted db (anything can happen,
> and the reporter mentions some code being present in the files), but at
> least "emerge -e world" or equivalent should be possible.

I'm not sure how portage handles not having ANYTHING in the vdb, but
wouldn't it at least be possible to just wipe out the entire directory
tree and then do an emerge -e world?  As long as the packages
themselves are working I would think that this should work.

The only thing I'm not sure about is that if portage thinks that
nothing is installed it might run into circular dependency issues.
Maybe we need an option to include dependencies in the list of
packages to install but not bail out on circular dependency issues
since the reality is that the packages are there.  Or, we need to give
the user a script to follow (maybe try to follow whatever the logic is
in catalyst since obviously that works).

If the packages themselves are corrupted then installing from binary
packages for @system would make sense.

That thread really sounds like some kind of filesystem corruption
issue, even if fsck doesn't report any problems.  Something like that
happened to me ages ago with some kind of mdadm+lvm+ext3 bug (an fsck
on one lvm partition destroyed data on a different partition).

A more intelligent solution would be to actually check the system for
consistency (file hashes, etc), and then just re-emerge the stuff that
is broken.

Rich

Re: [gentoo-dev] recovering from corrupted vdb

[Zac Medico]

On 11/03/2011 04:15 AM, "Paweł Hajdan, Jr." wrote:
> Shouldn't portage offer some means to recover from a corrupted vdb?
> 
> I just stumbled upon
> <http://forums.gentoo.org/viewtopic-t-900382-start-0-postdays-0-postorder-asc-highlight-.html>
> and it seems really bad.
> 
> It would suck if the only solution to this is reinstall (I remember
> package database becoming corrupted in some RPM-based distro I had years
> ago and I hated it).

Your best protection is to have a redundant backup on a separate disk.
When I do updates, I always clone my root partition to another partition
on a separate disk and chroot into that for the updates, and I keep that
spare partition as a backup in case one of my disks fails. For cloning,
a command like `rsync -axH --delete / /mnt/backup_rootfs/` works well
for me. I've also used btrfs subvolume snapshots for quick and efficient
cloning of my root filesystem, but that doesn't give the kind of
redundancy that a separate filesystem on a separate disk gives.

> If the recovery is already possible, we should get a doc explaining what
> to do. Otherwise it'd be really great to implement some recovery logic.
> 
> I think we can't salvage much from a corrupted db (anything can happen,
> and the reporter mentions some code being present in the files), but at
> least "emerge -e world" or equivalent should be possible.

Due to circular dependencies, you need a seed vdb to start with. If you
don't have a redundant backup, another option would be to simply remove
the corrupt /var/db/pkg and replace it with a copy from a stage3 tarball.
-- 
Thanks,
Zac