You are not logged in.

#1 2017-06-15 15:41:14

maep
Member
Registered: 2011-07-09
Posts: 12

Pacman froze during upgrade, local database corrupted

Greetings,

I haven't upgraded for roughly 2 months, and I ran out of disk space during upgrade. The system froze and I had to reset. Now pacman just segfaults, I think my local db might be corrupted. Here are the last lines of pacman --debug -Syu :

:: Synchronizing package databases...
debug: url: http://mirror.metalgamer.eu/archlinux/core/os/x86_64/core.db
debug: maxsize: 26214400
debug: using time condition: 1497506706
debug: opened tempfile for download: /var/lib/pacman/sync/core.db.part (wb)

error: segmentation fault
Please submit a full bug report with --debug if appropriate.

What to do now? This is a serious flaw in pacman, a full disk should not cause this kind of havoc.

Offline

#2 2017-06-15 15:56:44

apg
Developer
Registered: 2012-11-10
Posts: 211

Re: Pacman froze during upgrade, local database corrupted

maep wrote:

Greetings,

I haven't upgraded for roughly 2 months, and I ran out of disk space during upgrade. The system froze and I had to reset. Now pacman just segfaults, I think my local db might be corrupted. Here are the last lines of pacman --debug -Syu :

:: Synchronizing package databases...
debug: url: http://mirror.metalgamer.eu/archlinux/core/os/x86_64/core.db
debug: maxsize: 26214400
debug: using time condition: 1497506706
debug: opened tempfile for download: /var/lib/pacman/sync/core.db.part (wb)

error: segmentation fault
Please submit a full bug report with --debug if appropriate.

Looks like curl is probably segfaulting, possibly due to a version mismatch: https://bugs.archlinux.org/task/53818

What to do now? This is a serious flaw in pacman, a full disk should not cause this kind of havoc.

And what exactly would you have pacman do to avoid breaking when you try to update without enough space?

Offline

#3 2017-06-15 16:11:11

maep
Member
Registered: 2011-07-09
Posts: 12

Re: Pacman froze during upgrade, local database corrupted

Ah thanks. So this could still be salvagable.

And what exactly would you have pacman do to avoid breaking when you try to update without enough space?

For starters, ensure there is enough space. Or upgrade pacman dependencies separately. To avoid versioning problems alltogether, linking all libs statically into pacman would prevent these kind of situations. I'm surprised this already isn't the case for such a critical component.

Offline

#4 2017-06-15 16:14:23

apg
Developer
Registered: 2012-11-10
Posts: 211

Re: Pacman froze during upgrade, local database corrupted

pacman.conf(5) wrote:

CheckSpace
           Performs an approximate check for adequate available disk space before installing packages.

Offline

#5 2017-06-15 16:32:02

maep
Member
Registered: 2011-07-09
Posts: 12

Re: Pacman froze during upgrade, local database corrupted

CheckSpace is enabled, but never seems to work for me. This isn't the first time I ran out of space during upgrade, and I never got any warning. In the past I could always recover easily so I assumed pacman is resilient to this kind of situation...

Offline

#6 2017-06-15 16:40:22

apg
Developer
Registered: 2012-11-10
Posts: 211

Re: Pacman froze during upgrade, local database corrupted

Are you using btrfs (https://bugs.archlinux.org/task/37402)?  There's really not much pacman can do other than check for enough space beforehand and hope nothing fills the space in the meantime.  Even if pacman were statically compiled, you could run out of space in the middle of extracting the pacman binary itself.

Offline

#7 2017-06-15 16:50:44

maep
Member
Registered: 2011-07-09
Posts: 12

Re: Pacman froze during upgrade, local database corrupted

Btrfs indeed. I think I'm going back to ext4 smile.

Even if pacman were statically compiled, you could run out of space in the middle of extracting the pacman binary itself.

A common practice to ensure data integrity in this type of situation is to write to a tmp file on the same drive an then rename. It's still not 100% safe but a lot more robust than overwriting.

Offline

Board footer

Powered by FluxBB