/gnu/store/ corruption on crash

/gnu/store/ corruption on crash

[Danny Milosavljevic]

Hi,

I've got a problem on an X200 where, after I did standby 3 times, it will wake up fine but at the first larger disk access hang the machine.

This E-Mail is not directly about that problem.

However, this time, guix did package install when that happened and now /gnu/store/ is corrupted.

/gnu/store/7k7wicjr8rpb65h2f33j8ibpmffwjp6d-fontconfig-2.11.94.tar.bz2.drv now has 0 Byte.

Should it be possible for that to happen?

UNIX journalling filesystems in general only provide guarantees for filesystem metadata, not file content. Is this taken into account? (f.e. don't overwrite existing file but rather create new file, rename atomically; is fsync done when important?)

crashkernel; was: /gnu/store/ corruption on crash

[Danny Milosavljevic]

On Mon, 22 Feb 2016 22:11:25 +0100
Danny Milosavljevic <dannym@scratchpost.org> wrote:

> I've got a problem on an X200 where, after I did standby 3 times, it will wake up fine but at the first larger disk access hang the machine.

Also, is kdump crashkernel supported in GuixSD?

The minimal support would be:
  pass kernel command line option "crashkernel", for example crashkernel=256M.
  This reserves a region of memory not to be touched by anyone but the crash analyzer (especially not by DMA).

Better support would be (see linux/Documentation/kdump/ ):
  Enable CONFIG_DEBUG_INFO in the kernel config. The remaining are all already active in GuixSD.
  For x86_64, after booting, run
  	kexec -p kernelimagefile --initrd=... --append="root=... 1 irqpoll maxcpus=1 reset_devices"

Re: /gnu/store/ corruption on crash

[Ludovic Courtès]

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> I've got a problem on an X200 where, after I did standby 3 times, it will wake up fine but at the first larger disk access hang the machine.
>
> This E-Mail is not directly about that problem.
>
> However, this time, guix did package install when that happened and now /gnu/store/ is corrupted.
>
> /gnu/store/7k7wicjr8rpb65h2f33j8ibpmffwjp6d-fontconfig-2.11.94.tar.bz2.drv now has 0 Byte.
>
> Should it be possible for that to happen?

.drv files should never be empty, so it’s definitely a corruption.

You can try ‘guix gc --verify’ or ‘guix gc --verify=contents’
(expensive.)

HTH,
Ludo’.