[bug#50768] [PATCH] installer: Reorder file system type listbox.

[bug#50768] [PATCH] installer: Reorder file system type listbox.

[Tobias Geerinckx-Rice via Guix-patches via]

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

[bug#50768] [PATCH] installer: Reorder file system type listbox.

[John Kehayias via Guix-patches via]

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

[bug#50768] [PATCH] installer: Reorder file system type listbox.

[Ludovic Courtès]

Hello,

Tobias Geerinckx-Rice <me@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’.

[bug#50768] [PATCH] installer: Reorder file system type listbox.

[Tobias Geerinckx-Rice via Guix-patches via]

[-- Attachment #1: Type: text/plain, Size: 1261 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

[bug#50768] ext4 & btrfs

[Ludovic Courtès]

Hello,

Tobias Geerinckx-Rice <me@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’.