GNU bug report logs - #50768
[PATCH] installer: Reorder file system type listbox.

Previous Next

Package: guix-patches;

Reported by: Tobias Geerinckx-Rice <me <at> tobias.gr>

Date: Thu, 23 Sep 2021 18:00:02 UTC

Severity: normal

Tags: patch

To reply to this bug, email your comments to 50768 AT debbugs.gnu.org.

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

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


Report forwarded to guix-patches <at> gnu.org:
bug#50768; Package guix-patches. (Thu, 23 Sep 2021 18:00:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tobias Geerinckx-Rice <me <at> tobias.gr>:
New bug report received and forwarded. Copy sent to guix-patches <at> gnu.org. (Thu, 23 Sep 2021 18:00:02 GMT) Full text and rfc822 format available.

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

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: guix-patches <at> gnu.org
Subject: [PATCH] installer: Reorder file system type listbox.
Date: Thu, 23 Sep 2021 19:59:50 +0200
Recommending ext4 over btrfs is probably ill-advised nowadays.  See the
regular bug reports about running out of /gnu/store directory entries,
for which the documented fix then breaks booting with GRUB.

Instead, just list regular file systems alphabetically.  We can bikeshed
bcachefs later ;-)

Move second-class file systems like NTFS to their own section at the end
of the list.

* gnu/packages/package-management.scm (run-fs-type-page): Reorder the
LISTBOX-ITEMS.
---
 gnu/installer/newt/partition.scm | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/gnu/installer/newt/partition.scm b/gnu/installer/newt/partition.scm
index ea524eb4c3..70c11ed8ad 100644
--- a/gnu/installer/newt/partition.scm
+++ b/gnu/installer/newt/partition.scm
@@ -119,31 +119,35 @@ Be careful, all data on the disk will be lost.")
                          '(extended)))))
     (run-listbox-selection-page
      #:info-text (G_ "Please select a partition type.")
      #:title (G_ "Partition type")
      #:listbox-items items
      #:listbox-item->text symbol->string
      #:sort-listbox-items? #f
      #:button-text (G_ "Exit")
      #:button-callback-procedure button-exit-action)))
 
 (define (run-fs-type-page)
   "Run a page asking the user to select a file-system type."
   (run-listbox-selection-page
    #:info-text (G_ "Please select the file-system type for this partition.")
    #:title (G_ "File-system type")
-   #:listbox-items '(ext4 btrfs fat16 fat32 jfs ntfs xfs swap)
+   #:listbox-items '(btrfs ext4 jfs xfs
+                           swap
+                           ;; These lack basic Unix features.  Their only use
+                           ;; on GNU is for interoperation, e.g., with UEFI.
+                           fat32 fat16 ntfs)
    #:listbox-item->text user-fs-type-name
    #:sort-listbox-items? #f
    #:button-text (G_ "Exit")
    #:button-callback-procedure button-exit-action))
 
 (define (inform-can-create-partition? user-partition)
   "Return #t if it is possible to create USER-PARTITION. This is determined by
 calling CAN-CREATE-PARTITION? procedure. If an exception is raised, catch it
 an inform the user with an appropriate error-page and return #f."
   (guard (c ((max-primary-exceeded? c)
             (run-error-page
              (G_ "Primary partitions count exceeded.")
              (G_ "Creation error"))
             #f)
            ((extended-creation-error? c)
-- 
2.33.0





Information forwarded to guix-patches <at> gnu.org:
bug#50768; Package guix-patches. (Fri, 24 Sep 2021 21:25:01 GMT) Full text and rfc822 format available.

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

From: John Kehayias <john.kehayias <at> protonmail.com>
To: "50768 <at> debbugs.gnu.org" <50768 <at> debbugs.gnu.org>
Subject: [PATCH] installer: Reorder file system type listbox.
Date: Fri, 24 Sep 2021 21:24:11 +0000
Hello,

On this front, a related issue has been ext4 and large directories in Guix. Namely, that /gnu/store/.links quickly has many, many files (I'm at 9.9 million right now). This leads to warnings on ext4 and usually one will find that enabling large_dir will increase the file directory cap. Unfortunately, that is not compatible with Grub. This is what happened to me and was a bit of a mess (I reinstalled with Btrfs), and I know you (Tobias) also saw this in this thread: https://lists.gnu.org/archive/html/help-guix/2020-06/msg00015.html

So to the patch at hand, I'm wondering if we should make a note of this in file system selection in the installer (and in the manual in a few places). I don't know the actual ramifications of getting those directory full warnings in ext4, but I can see it easily leading to a problem booting a system with large_dir, as happened to me. I've submitted a bug to Grub, though this is well known, without response in plans to support a 4-year-old ext4 option. Since we expect Guix to have this huge directory, at least currently, I think we could avoid this issue with some warnings.

Sorry if this is a little astray for this patch, but thought it would be good to bring up.

Thanks,
John





Information forwarded to guix-patches <at> gnu.org:
bug#50768; Package guix-patches. (Wed, 13 Oct 2021 08:59:01 GMT) Full text and rfc822 format available.

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Tobias Geerinckx-Rice <me <at> tobias.gr>
Cc: 50768 <at> debbugs.gnu.org
Subject: Re: bug#50768: [PATCH] installer: Reorder file system type listbox.
Date: Wed, 13 Oct 2021 10:57:47 +0200
Hello,

Tobias Geerinckx-Rice <me <at> tobias.gr> skribis:

> Recommending ext4 over btrfs is probably ill-advised nowadays.  See the
> regular bug reports about running out of /gnu/store directory entries,
> for which the documented fix then breaks booting with GRUB.

I’ve seen Keyras mention such a problem here, but again, I have not seen
“regular bug reports”.  Are there open bug reports about ext4 issues?

What I do regularly see is rants about ext4 :-), which might be
justified, but in my many years with a store I have never had problems
with ext4.  Also, the deduplication code gracefully handles ENOSPC on
/gnu/store/.links.

> Instead, just list regular file systems alphabetically.  We can bikeshed
> bcachefs later ;-)
>
> Move second-class file systems like NTFS to their own section at the end
> of the list.
>
> * gnu/packages/package-management.scm (run-fs-type-page): Reorder the
> LISTBOX-ITEMS.

Otherwise LGTM, thanks!

Ludo’.




Information forwarded to guix-patches <at> gnu.org:
bug#50768; Package guix-patches. (Thu, 21 Oct 2021 19:04:01 GMT) Full text and rfc822 format available.

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

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 50768 <at> debbugs.gnu.org
Subject: Re: bug#50768: [PATCH] installer: Reorder file system type listbox.
Date: Thu, 21 Oct 2021 20:41:53 +0200
[Message part 1 (text/plain, inline)]
Ludo',

Ludovic Courtès 写道:
> I’ve seen Keyras mention such a problem here, but again, I have 
> not seen
> “regular bug reports”.

I've seen enough.  s/bug reports/worried questions, not always 
prior to messing with file system options/ for accuracy.

> Are there open bug reports about ext4 issues?
 
As in issues: no idea.  I would expect them to be closed, so it's 
not much of a metric.

> What I do regularly see is rants about ext4 :-), which might be
> justified, but in my many years with a store I have never had 
> problems
> with ext4.  Also, the deduplication code gracefully handles 
> ENOSPC on
> /gnu/store/.links.

The kernel doesn't discriminate and logs warnings.  Several people 
do notice these, don't realise that they are ‘harmless’, and 
follow some on-line tutorial to enable large_dir.  Which 
apparently breaks GRUB.

None of this is Guix's fault.  It does happen.

I'm not happy with this patch: it's the tiniest possible tweak and 
puts a lot of implicit meaning into the default ordering.

I didn't find a good way to dynamically display a description of 
each file system, but I wouldn't know what kind of Newt UI 
primitives/concepts to search for.

Kind regards,

T G-R
[signature.asc (application/pgp-signature, inline)]

Information forwarded to guix-patches <at> gnu.org:
bug#50768; Package guix-patches. (Mon, 25 Oct 2021 09:31:01 GMT) Full text and rfc822 format available.

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Tobias Geerinckx-Rice <me <at> tobias.gr>
Cc: 50768 <at> debbugs.gnu.org
Subject: ext4 & btrfs
Date: Mon, 25 Oct 2021 11:29:54 +0200
Hello,

Tobias Geerinckx-Rice <me <at> tobias.gr> skribis:

> Ludovic Courtès 写道:

[...]

>> What I do regularly see is rants about ext4 :-), which might be
>> justified, but in my many years with a store I have never had
>> problems
>> with ext4.  Also, the deduplication code gracefully handles ENOSPC
>> on
>> /gnu/store/.links.
>
> The kernel doesn't discriminate and logs warnings.

What do those warnings look like?

> Several people do notice these, don't realise that they are
> ‘harmless’, and follow some on-line tutorial to enable large_dir.
> Which apparently breaks GRUB.
>
> None of this is Guix's fault.  It does happen.

Oh, so it’s some tutorial out there that leads users to use ‘large_dir’
when they see those warnings?  Bah.

> I'm not happy with this patch: it's the tiniest possible tweak and
> puts a lot of implicit meaning into the default ordering.

Yeah.

That said, recommending btrfs (it’s now the first and default choice)
has implications.  It has its pros, but it doesn’t come for free either
in terms of usability and observable change in behavior in some cases.

For example, we’ll likely see reports of test suites that fail on user
machines (btrfs) but work on our build farms (ext4).

So I think we should be careful here.

Another option would be to document the ‘large_dir’ limitation, or to
use a newer GRUB if that limitation has been addressed in the meantime?

WDYT?

Thanks,
Ludo’.




This bug report was last modified 2 years and 190 days ago.

Previous Next


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