GNU bug report logs - #43132
[GUIX SYSTEM]: Malfunction

Previous Next

Package: guix;

Reported by: Raghav Gururajan <raghavgururajan <at> disroot.org>

Date: Mon, 31 Aug 2020 09:51:02 UTC

Severity: normal

Done: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 43132 in the body.
You can then email your comments to 43132 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#43132; Package guix. (Mon, 31 Aug 2020 09:51:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raghav Gururajan <raghavgururajan <at> disroot.org>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Mon, 31 Aug 2020 09:51:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Raghav Gururajan <raghavgururajan <at> disroot.org>
To: bug-guix <at> gnu.org
Subject: [GUIX SYSTEM]: Malfunction
Date: Mon, 31 Aug 2020 05:48:30 -0400
[Message part 1 (text/plain, inline)]
Hello Guix!

[1] Out of no where, when I did `guix environment foo`, I got:

\note: build failure may have been caused by lack of free disk space
builder for `/gnu/store/2ajnpcblwpgzjdhx3050qapy3li31pr5-profile.drv'
failed with exit code 1

[2] When I redid the command 2nd time, I got:

error (ignored): cannot unlink `/tmp/guix-build-profile.drv-0':
Read-only file system
error (ignored): cannot unlink
`/gnu/store/2ajnpcblwpgzjdhx3050qapy3li31pr5-profile.drv.chroot/tmp/guix-build-profile.drv-0':
Read-only file system
guix environment: error: cannot link
`/gnu/store/.links/1jd7y4xvj853m4aygnyixci5h2y7a1py6iavp9kwzvcinyniqwbd' to
`/gnu/store/3klrs2bkcmypwnmx61q24rc7csgk19f8-profile/share/icons/Adwaita/64x64/emotes/face-smile-big
symbolic.symbolic.png': Read-only file system

[3] When I redid the command 3rd time, I got:

guix environment: error: fport_read: Connection reset by peer

[4] When I redid the command 4th time, I got:

guix environment: error: failed to connect to
`/var/guix/daemon-socket/socket': Connection refused

[5] So I tried to restart guix-daemon and got a weird output:

sudo: unable to open /var/run/sudo/ts/rg: Read-only file system
Password:
Service guix-daemon is not running.
Service guix-daemon is currently disabled.

[6] Then I tried to enable the daemon:

sudo: unable to open /var/run/sudo/ts/rg: Read-only file system
Password:
Enabled service guix-daemon.

[7] Then I tried to start the daemon:

sudo: unable to open /var/run/sudo/ts/rg: Read-only file system
Password:
Service guix-daemon has been started.

[8] Now, I retried the `guix environment foo` and got same error as in 4.

[9] At this point, all the other running applications started to throw
errors regarding read-only file-system. I could not even save the above
errors in a text editor. Glad that I had the IceCat running and I was
able to email it to myself. IceCat wasn't affected, as I think the
web-process was containerized. Everything was back to normal after restart.

[10] I am experiencing this situation for the 3rd time this month. It
never happened before this month.

INFO:

`guix describe`

  guix dad963a
    repository URL: https://git.savannah.gnu.org/git/guix.git
    commit: dad963a4393ea51409baa63817b26b449ed58338

Both my user profile and root profile are on the same commit.

Regards,
RG.

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to bug-guix <at> gnu.org:
bug#43132; Package guix. (Mon, 31 Aug 2020 09:55:01 GMT) Full text and rfc822 format available.

Message #8 received at 43132 <at> debbugs.gnu.org (full text, mbox):

From: Efraim Flashner <efraim <at> flashner.co.il>
To: Raghav Gururajan <raghavgururajan <at> disroot.org>
Cc: 43132 <at> debbugs.gnu.org
Subject: Re: [GUIX SYSTEM]: Malfunction
Date: Mon, 31 Aug 2020 12:53:59 +0300
[Message part 1 (text/plain, inline)]
On Mon, Aug 31, 2020 at 05:48:30AM -0400, Raghav Gururajan wrote:
> Hello Guix!
> 
> [1] Out of no where, when I did `guix environment foo`, I got:
> 
> \note: build failure may have been caused by lack of free disk space
> builder for `/gnu/store/2ajnpcblwpgzjdhx3050qapy3li31pr5-profile.drv'
> failed with exit code 1
> 
> [2] When I redid the command 2nd time, I got:
> 
> error (ignored): cannot unlink `/tmp/guix-build-profile.drv-0':
> Read-only file system
> error (ignored): cannot unlink
> `/gnu/store/2ajnpcblwpgzjdhx3050qapy3li31pr5-profile.drv.chroot/tmp/guix-build-profile.drv-0':
> Read-only file system
> guix environment: error: cannot link
> `/gnu/store/.links/1jd7y4xvj853m4aygnyixci5h2y7a1py6iavp9kwzvcinyniqwbd' to
> `/gnu/store/3klrs2bkcmypwnmx61q24rc7csgk19f8-profile/share/icons/Adwaita/64x64/emotes/face-smile-big
> symbolic.symbolic.png': Read-only file system
> 
> [3] When I redid the command 3rd time, I got:
> 
> guix environment: error: fport_read: Connection reset by peer
> 
> [4] When I redid the command 4th time, I got:
> 
> guix environment: error: failed to connect to
> `/var/guix/daemon-socket/socket': Connection refused
> 
> [5] So I tried to restart guix-daemon and got a weird output:
> 
> sudo: unable to open /var/run/sudo/ts/rg: Read-only file system
> Password:
> Service guix-daemon is not running.
> Service guix-daemon is currently disabled.
> 
> [6] Then I tried to enable the daemon:
> 
> sudo: unable to open /var/run/sudo/ts/rg: Read-only file system
> Password:
> Enabled service guix-daemon.
> 
> [7] Then I tried to start the daemon:
> 
> sudo: unable to open /var/run/sudo/ts/rg: Read-only file system
> Password:
> Service guix-daemon has been started.
> 
> [8] Now, I retried the `guix environment foo` and got same error as in 4.
> 
> [9] At this point, all the other running applications started to throw
> errors regarding read-only file-system. I could not even save the above
> errors in a text editor. Glad that I had the IceCat running and I was
> able to email it to myself. IceCat wasn't affected, as I think the
> web-process was containerized. Everything was back to normal after restart.
> 
> [10] I am experiencing this situation for the 3rd time this month. It
> never happened before this month.
> 
> INFO:
> 
> `guix describe`
> 
>   guix dad963a
>     repository URL: https://git.savannah.gnu.org/git/guix.git
>     commit: dad963a4393ea51409baa63817b26b449ed58338
> 
> Both my user profile and root profile are on the same commit.
> 
> Regards,
> RG.
> 


What's the output of 'df -h' and 'df -i'? There's not much change in
error message if you're out of space or just out of inodes.


-- 
Efraim Flashner   <efraim <at> flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-guix <at> gnu.org:
bug#43132; Package guix. (Mon, 31 Aug 2020 10:04:02 GMT) Full text and rfc822 format available.

Message #11 received at 43132 <at> debbugs.gnu.org (full text, mbox):

From: Raghav Gururajan <raghavgururajan <at> disroot.org>
To: Efraim Flashner <efraim <at> flashner.co.il>
Cc: 43132 <at> debbugs.gnu.org
Subject: Re: [GUIX SYSTEM]: Malfunction
Date: Mon, 31 Aug 2020 06:01:40 -0400
[Message part 1 (text/plain, inline)]
Hi Efraim!

> What's the output of 'df -h' and 'df -i'? There's not much change in
> error message if you're out of space or just out of inodes.

rg <at> secondary ~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
none            3.8G     0  3.8G   0% /dev
/dev/dm-0       120G   95G   24G  81% /
tmpfs           3.8G  8.6M  3.8G   1% /dev/shm
none            3.8G   20K  3.8G   1% /run/systemd
none            3.8G     0  3.8G   0% /run/user
cgroup          3.8G     0  3.8G   0% /sys/fs/cgroup
tmpfs           771M  4.0K  771M   1% /run/user/1000
/dev/sdb1        60G   59G  638M  99% /media/rg/CARD
rg <at> secondary ~$ df -i
Filesystem     Inodes IUsed  IFree IUse% Mounted on
none           983678   592 983086    1% /dev
/dev/dm-0           0     0      0     - /
tmpfs          986453    71 986382    1% /dev/shm
none           986453    21 986432    1% /run/systemd
none           986453     2 986451    1% /run/user
cgroup         986453    12 986441    1% /sys/fs/cgroup
tmpfs          986453    14 986439    1% /run/user/1000
/dev/sdb1           0     0      0     - /media/rg/CARD

Regards,
RG.

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to bug-guix <at> gnu.org:
bug#43132; Package guix. (Mon, 31 Aug 2020 10:41:02 GMT) Full text and rfc822 format available.

Message #14 received at 43132 <at> debbugs.gnu.org (full text, mbox):

From: Giovanni Biscuolo <g <at> xelera.eu>
To: Raghav Gururajan <raghavgururajan <at> disroot.org>, 43132 <at> debbugs.gnu.org
Subject: Re: bug#43132: [GUIX SYSTEM]: Malfunction
Date: Mon, 31 Aug 2020 12:39:58 +0200
[Message part 1 (text/plain, inline)]
Hi Raghav

Raghav Gururajan <raghavgururajan <at> disroot.org> writes:

[...]

> [2] When I redid the command 2nd time, I got:
>
> error (ignored): cannot unlink `/tmp/guix-build-profile.drv-0':
> Read-only file system

It seems connected to a filesystem issue: can you also tell us what's
the output of "mount"?

[...]

Thanks, Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-guix <at> gnu.org:
bug#43132; Package guix. (Mon, 31 Aug 2020 10:51:02 GMT) Full text and rfc822 format available.

Message #17 received at 43132 <at> debbugs.gnu.org (full text, mbox):

From: Raghav Gururajan <raghavgururajan <at> disroot.org>
To: Giovanni Biscuolo <g <at> xelera.eu>, 43132 <at> debbugs.gnu.org
Subject: Re: bug#43132: [GUIX SYSTEM]: Malfunction
Date: Mon, 31 Aug 2020 06:48:14 -0400
[Message part 1 (text/plain, inline)]
Hi Gio!


> It seems connected to a filesystem issue: can you also tell us what's
> the output of "mount"?

none on /proc type proc (rw,relatime)
none on /dev type devtmpfs
(rw,relatime,size=3934712k,nr_inodes=983678,mode=755)
none on /sys type sysfs (rw,relatime)
/dev/mapper/secondary on / type btrfs
(rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
none on /dev/pts type devpts (rw,relatime,gid=996,mode=620,ptmxmode=000)
none on /sys/kernel/debug type debugfs (rw,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,relatime)
/dev/mapper/secondary on /gnu/store type btrfs
(ro,relatime,ssd,space_cache,subvolid=5,subvol=/)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
none on /run/systemd type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755)
none on /run/user type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755)
cgroup on /sys/fs/cgroup type tmpfs (rw,relatime)
cgroup on /sys/fs/cgroup/elogind type cgroup (rw,relatime,name=elogind)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu type cgroup (rw,relatime,cpu)
cgroup on /sys/fs/cgroup/cpuacct type cgroup (rw,relatime,cpuacct)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,relatime,freezer)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,relatime,perf_event)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,relatime,pids)
cgroup2 on /sys/fs/cgroup/unified type cgroup2
(rw,nosuid,nodev,noexec,relatime,nsdelegate)
tmpfs on /run/user/1000 type tmpfs
(rw,nosuid,nodev,relatime,size=789160k,mode=700,uid=1000,gid=998)
/dev/sdb1 on /media/rg/CARD type vfat
(rw,nosuid,nodev,relatime,uid=1000,gid=998,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)

Regards,
RG.

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to bug-guix <at> gnu.org:
bug#43132; Package guix. (Mon, 31 Aug 2020 11:12:02 GMT) Full text and rfc822 format available.

Message #20 received at 43132 <at> debbugs.gnu.org (full text, mbox):

From: Giovanni Biscuolo <g <at> xelera.eu>
To: Raghav Gururajan <raghavgururajan <at> disroot.org>, 43132 <at> debbugs.gnu.org
Subject: Re: bug#43132: [GUIX SYSTEM]: Malfunction
Date: Mon, 31 Aug 2020 13:11:13 +0200
[Message part 1 (text/plain, inline)]
Hello Raghav

when forwarding the output of commands next time, plz beware your MUS
does not reformat the relevant :-)

This seems as a system issue on your side, not a Guix bug

Raghav Gururajan <raghavgururajan <at> disroot.org> writes:

>> It seems connected to a filesystem issue: can you also tell us what's
>> the output of "mount"?

[...]

> w on / type btrfs
> (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)

[...]

> /dev/mapper/secondary on /gnu/store type btrfs
> (ro,relatime,ssd,space_cache,subvolid=5,subvol=/)

I see two problems here:

1. the btrfs volume /dev/mapper/secondary seems mounted twice, and with
the same subvolume; I never tryed to mount the same btrfs volume on two
different mountpoints: is this the reason your /gnu/store is read-only?

2. /gnu/store is mounted read-only, that's why you get the errors

Please can you try removing the mounting of /gnu/store from your
filesystem configuration (or fstab if on a foreign distro)? 

[...]

HTH! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-guix <at> gnu.org:
bug#43132; Package guix. (Mon, 31 Aug 2020 12:09:03 GMT) Full text and rfc822 format available.

Message #23 received at 43132 <at> debbugs.gnu.org (full text, mbox):

From: Julien Lepiller <julien <at> lepiller.eu>
To: Giovanni Biscuolo <g <at> xelera.eu>,
 Raghav Gururajan <raghavgururajan <at> disroot.org>, 43132 <at> debbugs.gnu.org
Subject: Re: bug#43132: [GUIX SYSTEM]: Malfunction
Date: Mon, 31 Aug 2020 08:07:45 -0400
[Message part 1 (text/plain, inline)]
No, it's supposed to be like that. /gnu/store is mounted read-only (on the guix system) to prevent you from writing to it. The guix daemon has write access to the store when it wants to add a new item, or garbage collect.

Le 31 août 2020 07:11:13 GMT-04:00, Giovanni Biscuolo <g <at> xelera.eu> a écrit :
>Hello Raghav
>
>when forwarding the output of commands next time, plz beware your MUS
>does not reformat the relevant :-)
>
>This seems as a system issue on your side, not a Guix bug
>
>Raghav Gururajan <raghavgururajan <at> disroot.org> writes:
>
>>> It seems connected to a filesystem issue: can you also tell us
>what's
>>> the output of "mount"?
>
>[...]
>
>> w on / type btrfs
>> (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
>
>[...]
>
>> /dev/mapper/secondary on /gnu/store type btrfs
>> (ro,relatime,ssd,space_cache,subvolid=5,subvol=/)
>
>I see two problems here:
>
>1. the btrfs volume /dev/mapper/secondary seems mounted twice, and with
>the same subvolume; I never tryed to mount the same btrfs volume on two
>different mountpoints: is this the reason your /gnu/store is read-only?
>
>2. /gnu/store is mounted read-only, that's why you get the errors
>
>Please can you try removing the mounting of /gnu/store from your
>filesystem configuration (or fstab if on a foreign distro)? 
>
>[...]
>
>HTH! Gio'
>
>-- 
>Giovanni Biscuolo
>
>Xelera IT Infrastructures
[Message part 2 (text/html, inline)]

Information forwarded to bug-guix <at> gnu.org:
bug#43132; Package guix. (Mon, 31 Aug 2020 12:41:01 GMT) Full text and rfc822 format available.

Message #26 received at 43132 <at> debbugs.gnu.org (full text, mbox):

From: Giovanni Biscuolo <g <at> xelera.eu>
To: Julien Lepiller <julien <at> lepiller.eu>,
 Raghav Gururajan <raghavgururajan <at> disroot.org>, 43132 <at> debbugs.gnu.org
Subject: Re: bug#43132: [GUIX SYSTEM]: Malfunction
Date: Mon, 31 Aug 2020 14:40:15 +0200
[Message part 1 (text/plain, inline)]
Julien Lepiller <julien <at> lepiller.eu> writes:

> No, it's supposed to be like that. /gnu/store is mounted read-only (on
> the guix system) to prevent you from writing to it.

Very sorry for the confusion, I forgot that! (and I did not check before) :-(

>>> /dev/mapper/secondary on / type btrfs
>>> (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
>>
>>[...]
>>
>>> /dev/mapper/secondary on /gnu/store type btrfs
>>> (ro,relatime,ssd,space_cache,subvolid=5,subvol=/)
                                                   ^ Same subvolume as /

This is the output from a running Guix system of mine:

--8<---------------cut here---------------start------------->8---

/dev/sda5 on / type btrfs (rw,relatime,space_cache,subvolid=5,subvol=/)

[...]

/dev/sda5 on /gnu/store type btrfs (ro,relatime,space_cache,subvolid=5,subvol=/gnu/store)

--8<---------------cut here---------------end--------------->8---

Thanks! Gio'

[...]

-- 
Giovanni Biscuolo

Xelera IT Infrastructures
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-guix <at> gnu.org:
bug#43132; Package guix. (Mon, 31 Aug 2020 21:18:01 GMT) Full text and rfc822 format available.

Message #29 received at 43132 <at> debbugs.gnu.org (full text, mbox):

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: Raghav Gururajan <raghavgururajan <at> disroot.org>
Cc: 43132 <at> debbugs.gnu.org
Subject: Re: bug#43132: [GUIX SYSTEM]: Malfunction
Date: Mon, 31 Aug 2020 23:17:30 +0200
[Message part 1 (text/plain, inline)]
Hi Raghav,

On Mon, 31 Aug 2020 05:48:30 -0400
Raghav Gururajan <raghavgururajan <at> disroot.org> wrote:

> Hello Guix!
> 
> [1] Out of no where, when I did `guix environment foo`, I got:
> 
> \note: build failure may have been caused by lack of free disk space
> builder for `/gnu/store/2ajnpcblwpgzjdhx3050qapy3li31pr5-profile.drv'
> failed with exit code 1
> 
> [2] When I redid the command 2nd time, I got:
> 
> error (ignored): cannot unlink `/tmp/guix-build-profile.drv-0':
> Read-only file system
> error (ignored): cannot unlink
> `/gnu/store/2ajnpcblwpgzjdhx3050qapy3li31pr5-profile.drv.chroot/tmp/guix-build-profile.drv-0':
> Read-only file system
> guix environment: error: cannot link
> `/gnu/store/.links/1jd7y4xvj853m4aygnyixci5h2y7a1py6iavp9kwzvcinyniqwbd' to
> `/gnu/store/3klrs2bkcmypwnmx61q24rc7csgk19f8-profile/share/icons/Adwaita/64x64/emotes/face-smile-big
> symbolic.symbolic.png': Read-only file system

Usually that means file-system corruption, which very likely was caused by a
hardware (disk) problem.  I've had it before, and shortly after the disk died.

What does "sudo dmesg" show around the time it made it read-only?
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to bug-guix <at> gnu.org:
bug#43132; Package guix. (Tue, 01 Sep 2020 03:07:01 GMT) Full text and rfc822 format available.

Message #32 received at 43132 <at> debbugs.gnu.org (full text, mbox):

From: Raghav Gururajan <raghavgururajan <at> disroot.org>
To: Danny Milosavljevic <dannym <at> scratchpost.org>
Cc: 43132 <at> debbugs.gnu.org
Subject: Re: bug#43132: [GUIX SYSTEM]: Malfunction
Date: Mon, 31 Aug 2020 23:04:25 -0400
[Message part 1 (text/plain, inline)]
Hi Danny!

> Usually that means file-system corruption, which very likely was caused by a
> hardware (disk) problem.  I've had it before, and shortly after the disk died.

Oh no! My disk is a SSD, which is only about 2 years old. Isn't that too
soon?

Btw, is there a tool to check the health of the disk?

> What does "sudo dmesg" show around the time it made it read-only?

Ah, I will have to wait until it happens again.

Regards,
RG.

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to bug-guix <at> gnu.org:
bug#43132; Package guix. (Tue, 01 Sep 2020 07:59:02 GMT) Full text and rfc822 format available.

Message #35 received at 43132 <at> debbugs.gnu.org (full text, mbox):

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: Raghav Gururajan <raghavgururajan <at> disroot.org>
Cc: 43132 <at> debbugs.gnu.org
Subject: Re: bug#43132: [GUIX SYSTEM]: Malfunction
Date: Tue, 1 Sep 2020 09:58:43 +0200
[Message part 1 (text/plain, inline)]
Hi,

On Mon, 31 Aug 2020 23:04:25 -0400
Raghav Gururajan <raghavgururajan <at> disroot.org> wrote:

> Hi Danny!
> 
> > Usually that means file-system corruption, which very likely was caused by a
> > hardware (disk) problem.  I've had it before, and shortly after the disk died.  
> 
> Oh no! My disk is a SSD, which is only about 2 years old. Isn't that too
> soon?
> 
> Btw, is there a tool to check the health of the disk?

Yes--usually it's a program in the disk firmware.

You can steer it and look at what it did using smartctl (in package
smartmontools).

But I'd advise to check dmesg because it could also be a RAM problem, or a
number of other things.

(UNIX also has fsck to check the filesystem, but it already automatically
does that on reboot when problems arised.  So little need to manually
fiddle with that)
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to bug-guix <at> gnu.org:
bug#43132; Package guix. (Thu, 10 Sep 2020 07:57:02 GMT) Full text and rfc822 format available.

Message #38 received at 43132 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Raghav Gururajan <raghavgururajan <at> disroot.org>
Cc: 43132 <at> debbugs.gnu.org, Danny Milosavljevic <dannym <at> scratchpost.org>
Subject: Re: bug#43132: [GUIX SYSTEM]: Malfunction
Date: Thu, 10 Sep 2020 09:56:35 +0200
Hey Raghav,

Did you eventually find what went wrong?  Should we close this bug or at
least retitle it?

Thanks,
Ludo’.




Reply sent to Maxim Cournoyer <maxim.cournoyer <at> gmail.com>:
You have taken responsibility. (Mon, 14 Sep 2020 15:14:01 GMT) Full text and rfc822 format available.

Notification sent to Raghav Gururajan <raghavgururajan <at> disroot.org>:
bug acknowledged by developer. (Mon, 14 Sep 2020 15:14:01 GMT) Full text and rfc822 format available.

Message #43 received at 43132-done <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 43132-done <at> debbugs.gnu.org, Raghav Gururajan <raghavgururajan <at> disroot.org>,
 Danny Milosavljevic <dannym <at> scratchpost.org>
Subject: Re: bug#43132: [GUIX SYSTEM]: Malfunction
Date: Mon, 14 Sep 2020 11:14:28 -0400
Hello,

Ludovic Courtès <ludo <at> gnu.org> writes:

> Hey Raghav,
>
> Did you eventually find what went wrong?  Should we close this bug or at
> least retitle it?
>
> Thanks,
> Ludo’.

I took Raghav to #btrfs last week, where with the help of gentle folks a
failing drive was established as the most likely culprit.

In other words, Btrfs checksuming capabilities helped quickly
discovering a hardware problem which might otherwise have silently
caused non-recoverable damage to Raghav's data.

I'm closing this bug now.

Thanks!

Maxim




Information forwarded to bug-guix <at> gnu.org:
bug#43132; Package guix. (Mon, 14 Sep 2020 19:35:02 GMT) Full text and rfc822 format available.

Message #46 received at 43132-done <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 43132-done <at> debbugs.gnu.org, Raghav Gururajan <raghavgururajan <at> disroot.org>,
 Danny Milosavljevic <dannym <at> scratchpost.org>
Subject: Re: bug#43132: [GUIX SYSTEM]: Malfunction
Date: Mon, 14 Sep 2020 21:34:19 +0200
Hi,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:

> I took Raghav to #btrfs last week, where with the help of gentle folks a
> failing drive was established as the most likely culprit.
>
> In other words, Btrfs checksuming capabilities helped quickly
> discovering a hardware problem which might otherwise have silently
> caused non-recoverable damage to Raghav's data.

Good, thanks for following up!

Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#43132; Package guix. (Tue, 15 Sep 2020 11:54:02 GMT) Full text and rfc822 format available.

Message #49 received at 43132-done <at> debbugs.gnu.org (full text, mbox):

From: Raghav Gururajan <raghavgururajan <at> disroot.org>
To: Ludovic Courtès <ludo <at> gnu.org>,
 Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 43132-done <at> debbugs.gnu.org, Danny Milosavljevic <dannym <at> scratchpost.org>
Subject: Re: bug#43132: [GUIX SYSTEM]: Malfunction
Date: Tue, 15 Sep 2020 07:51:05 -0400
[Message part 1 (text/plain, inline)]
Hi!

> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
> 
>> I took Raghav to #btrfs last week, where with the help of gentle folks a
>> failing drive was established as the most likely culprit.
>>
>> In other words, Btrfs checksuming capabilities helped quickly
>> discovering a hardware problem which might otherwise have silently
>> caused non-recoverable damage to Raghav's data.
> 
> Good, thanks for following up!
> 
> Ludo’.

Thank you!

Yeah, seems like my disk is shot, but I am not sure. I have reinstalled
guix with ext4, instead of btrfs, as these issues started to arise after
migration to btrfs from ext4. So far, my system is doing well. Lets see
how it goes. :-)

Regards,
RG.

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to bug-guix <at> gnu.org:
bug#43132; Package guix. (Tue, 15 Sep 2020 13:32:02 GMT) Full text and rfc822 format available.

Message #52 received at 43132-done <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Raghav Gururajan <raghavgururajan <at> disroot.org>
Cc: 43132-done <at> debbugs.gnu.org, Danny Milosavljevic <dannym <at> scratchpost.org>,
 Ludovic Courtès <ludo <at> gnu.org>
Subject: Re: bug#43132: [GUIX SYSTEM]: Malfunction
Date: Tue, 15 Sep 2020 09:31:51 -0400
Hello Raghav,

Raghav Gururajan <raghavgururajan <at> disroot.org> writes:

> Hi!
>
>> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>> 
>>> I took Raghav to #btrfs last week, where with the help of gentle folks a
>>> failing drive was established as the most likely culprit.
>>>
>>> In other words, Btrfs checksuming capabilities helped quickly
>>> discovering a hardware problem which might otherwise have silently
>>> caused non-recoverable damage to Raghav's data.
>> 
>> Good, thanks for following up!
>> 
>> Ludo’.
>
> Thank you!
>
> Yeah, seems like my disk is shot, but I am not sure. I have reinstalled
> guix with ext4, instead of btrfs, as these issues started to arise after
> migration to btrfs from ext4. So far, my system is doing well. Lets see
> how it goes. :-)

Sounds like playing with fire to me :-).

Ext4 won't detect bitrot (silent corruption of your drive's data).
You'll probably wake one day with a fsck that won't be able to recover
some files, or worst, a completely dead drive.

Your backups would also contain corrupted data (garbage in, garbage
out!).

Maxim




Information forwarded to bug-guix <at> gnu.org:
bug#43132; Package guix. (Tue, 15 Sep 2020 22:15:02 GMT) Full text and rfc822 format available.

Message #55 received at 43132-done <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>, Raghav Gururajan
 <raghavgururajan <at> disroot.org>
Cc: 43132-done <at> debbugs.gnu.org
Subject: Re: bug#43132: [GUIX SYSTEM]: Malfunction
Date: Tue, 15 Sep 2020 18:13:07 -0400
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:

> Raghav Gururajan <raghavgururajan <at> disroot.org> writes:
>
>>> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>>> 
>>>> I took Raghav to #btrfs last week, where with the help of gentle folks a
>>>> failing drive was established as the most likely culprit.
>>>>
>>>> In other words, Btrfs checksuming capabilities helped quickly
>>>> discovering a hardware problem which might otherwise have silently
>>>> caused non-recoverable damage to Raghav's data.
>>> 
>>> Good, thanks for following up!
>>> 
>>> Ludo’.
>>
>> Thank you!
>>
>> Yeah, seems like my disk is shot, but I am not sure. I have reinstalled
>> guix with ext4, instead of btrfs, as these issues started to arise after
>> migration to btrfs from ext4. So far, my system is doing well. Lets see
>> how it goes. :-)
>
> Sounds like playing with fire to me :-).
>
> Ext4 won't detect bitrot (silent corruption of your drive's data).
> You'll probably wake one day with a fsck that won't be able to recover
> some files, or worst, a completely dead drive.
>
> Your backups would also contain corrupted data (garbage in, garbage
> out!).

For what it's worth, I wholeheartedly agree with Maxim.  Btrfs did you a
great service by calling attention to this problem with your drive, and
it would be a shame to ignore it and switch back to ext4 where your data
may instead be silently corrupted.

I've been using btrfs for several years now on my x86_64 Guix system,
and it has served me well.  Previously, I used ext4, which would
silently leave some of my files empty after crashes.  I've never seen
that happen with btrfs.

       Mark




Information forwarded to bug-guix <at> gnu.org:
bug#43132; Package guix. (Tue, 15 Sep 2020 22:42:01 GMT) Full text and rfc822 format available.

Message #58 received at 43132-done <at> debbugs.gnu.org (full text, mbox):

From: Raghav Gururajan <raghavgururajan <at> disroot.org>
To: Mark H Weaver <mhw <at> netris.org>, Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 43132-done <at> debbugs.gnu.org
Subject: Re: bug#43132: [GUIX SYSTEM]: Malfunction
Date: Tue, 15 Sep 2020 18:38:46 -0400
[Message part 1 (text/plain, inline)]
Hi Mark and Maxim!

>> Ext4 won't detect bitrot (silent corruption of your drive's data).
>> You'll probably wake one day with a fsck that won't be able to recover
>> some files, or worst, a completely dead drive.
>>
>> Your backups would also contain corrupted data (garbage in, garbage
>> out!).
> 
> For what it's worth, I wholeheartedly agree with Maxim.  Btrfs did you a
> great service by calling attention to this problem with your drive, and
> it would be a shame to ignore it and switch back to ext4 where your data
> may instead be silently corrupted.
> 
> I've been using btrfs for several years now on my x86_64 Guix system,
> and it has served me well.  Previously, I used ext4, which would
> silently leave some of my files empty after crashes.  I've never seen
> that happen with btrfs.

Yeah, makes sense. I have placed an order for WDS100T2B0A.

Thanks folks!

Regards,
RG.

[signature.asc (application/pgp-signature, attachment)]

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 14 Oct 2020 11:24:05 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 166 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.