From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxim Cournoyer Subject: bug#38435: BTRFS open_ctree failed Date: Tue, 18 Feb 2020 11:29:53 -0500 Message-ID: <875zg3zwn2.fsf@gmail.com> References: <20191130144539.218179f0@riseup.net> <87tv6lo1pk.fsf@yamatai> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:45746) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j45m4-0002pZ-31 for bug-guix@gnu.org; Tue, 18 Feb 2020 11:31:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j45m2-000594-Q0 for bug-guix@gnu.org; Tue, 18 Feb 2020 11:31:04 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:35223) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j45m2-00058r-KS for bug-guix@gnu.org; Tue, 18 Feb 2020 11:31:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j45m2-0006AP-H1 for bug-guix@gnu.org; Tue, 18 Feb 2020 11:31:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87tv6lo1pk.fsf@yamatai> (Guillaume Le Vaillant's message of "Sat, 30 Nov 2019 15:53:11 +0100") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane-mx.org@gnu.org Sender: "bug-Guix" To: Guillaume Le Vaillant Cc: 38435@debbugs.gnu.org Hello, Guillaume Le Vaillant writes: > raingloom skribis: > >> This is what I get after a recent `guix system reconfigure` : >> Scanning for Btrfs filesystems >> [ 2.342790] BTRFS error (device sda1): open_ctree failed >> >> Previous profiles work, I haven't modified anything about my config.scm >> between them. >> >> [...] >> >> >> Contents of /etc/profile.scm: >> >> [...] >> >> (file-systems (cons* (file-system >> (device (file-system-label "GUIX")) >> (mount-point "/") >> (options "lazytime,compress") >> (type "btrfs")) >> ;(file-system >> ; (device (uuid "1234-ABCD" 'fat)) >> ; (mount-point "/boot/efi") >> ; (type "vfat")) >> %base-file-systems)) >> > > I just tried adding the 'lazytime' option to my root file system, and > I got the same error as you when booting. Could you try removing it and > see if it works? > > Until recently, the options declared in 'file-system' records were > always ignored when mounting the root file system. Now they are taken > into consideration, and I think it reveals a bug in the way file systems > are mounted. If some options like 'lazytime' or 'defaults' are declared > in a 'file-system' record (root file system or not), mounting it fails. > However some other options like 'compress' or 'autodefrag' work fine. > > I suspect Guix adds some options by default when trying to mount file > systems, and maybe we end up with conflicting options or doubled options > that cause problems. The problem here is that "lazytime" is a file system independent mount options (see FILESYSTEM-INDEPENDENT MOUNT OPTIONS in 'man 8 mount'), which is not understood by the Btrfs file system driver itself. Currently Guix targets mount(2) through its file-system record API, although this could be easily abused before (because the options were not passed to the `mount-file-system' calls that the init RAM disk uses). This leaves some work to be done though, as if we target mount(2), we need some glue code to translate mount(2) flags into mount(8) file system independent mount options (otherwise you wouldn't be able to have 'lazytime' in your /etc/fstab). I have a partial solution posted for review here: https://lists.gnu.org/archive/html/guix-patches/2020-02/msg00382.html, in the patch: https://lists.gnu.org/archive/html/guix-patches/2020-02/msg00382.html. Currently it filters out the file system independent mount options before passing the options to `mount-file-system'. Comments or patches welcome!