1

This question is a related but tangent question on problem described in this posting .

While trying to finalize the options during the previous post, I always left the root partition alone, untouched, not modifying the default install options.

When I did update the mount options in fstab to the same as all the others, on the same disk, the system would give me the boot menu, start the actions with the splash screen up (5 animated dots; messages about fsck on filesystems) then when it came time to present the login screen, the splash screen would go away, I would get a black screen (my default boot screen colour), and the system would hang there, never giving me the login screen and no messages, even after waiting for 15 minutes !!!

Conclusion, even if the settings on the secondary partitions did not reveal severe issues with the fstab options that were used, appearing to behave acceptably, the situation is vastly different with applying those same options to the / partition. Attempting to reboot using the advanced options from the grub menu, I was unable to repair "the damage" (i.e. undo the options for / in /etc/fstab). I was forced to boot from my alternate Ubuntu 22.04 system on the secondary drive, go in and make the fix, before being able to reboot with no options other than distro defaults.

That being the case, can someone please tell me what is specifically wrong with my fstab entry if it is as follows:

UUID=00000000-0000-0000-0000-000000000000       /DB001_F2       ext4    defaults,nofail,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,data_err=ignore,nodiscard    0       1

The fact that the given set of options made the system go off the rails to the extent that it did, what seemed like a solution to the previous problem is not the solution it seemed to be, only a pointer to the multiple sources of complexity! What a let-down!

Report from dumpe2fs for root device (/dev/sda3):

root@OasisMega1:/DB001_F2/Oasis/bin# dumpe2fs -h /dev/sda3

dumpe2fs 1.45.5 (07-Jan-2020)
Filesystem volume name:   DB001_F1
Last mounted on:          /
Filesystem UUID:          00000000-0000-0000-0000-000000000000
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              12804096
Block count:              51199951
Reserved block count:     2559997
Free blocks:              37262931
Free inodes:              12246373
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Reserved GDT blocks:      1024
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Wed Oct 28 20:55:52 2020
Last mount time:          Mon Sep 12 13:50:48 2022
Last write time:          Mon Sep 12 13:50:43 2022
Mount count:              1207
Maximum mount count:      -1
Last checked:             Wed Oct 28 20:55:52 2020
Check interval:           0 (<none>)
Lifetime writes:          2862 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     32
Desired extra isize:      32
Journal inode:            8
First orphan inode:       408274
Default directory hash:   half_md4
Directory Hash Seed:      263a14ff-4737-41f7-9c28-228ae1e89263
Journal backup:           inode blocks
Checksum type:            crc32c
Checksum:                 0x428983d0
Journal features:         journal_incompat_revoke journal_64bit journal_checksum_v3
Journal size:             1024M
Journal length:           262144
Journal sequence:         0x004fe3ab
Journal start:            65627
Journal checksum type:    crc32c
Journal checksum:         0x6d639679

root@OasisMega1:/DB001_F2/Oasis/bin# 
6
  • Does your /etc/fstab file line really have spaces in the middle of defaults,nofail,journal_checksum,journal_async_commit,commit=15, errors=remount-ro,journal_ioprio=2,data_err=ignore,nodiscard (between commit=15, and errors=remount-ro)?
    – Sotto Voce
    Commented Sep 13, 2022 at 1:36
  • @Sotto Voce, the sample of fstab input was provided above for the UUID=... entry. There are no spaces, only commas. dumpe2fs replaces those commas with spaces when reporting any multi-valued topic, such as for " Filesystem features". Commented Sep 14, 2022 at 0:45
  • I'm not talking about the part of your question presented with "Report from dumpe2fs ...", but the part presented with "... my fstab entry if it is as follows:". But okay, I'll accept that line is not the same as the line in your fstab file.
    – Sotto Voce
    Commented Sep 14, 2022 at 1:19
  • @Sotto Voce, if you copy the text of the line and paste it into your preferred editor, you will see that there are no spaces in the line provided above. However, I grant that the appearance of how StackExchange presents that text seems to suggest a space character, but there is none. Commented Sep 14, 2022 at 1:23
  • I just tried that and got 4 space characters between commit=15, and errors=remount-ro, exactly as displayed in my browser. But as I said, I get it - that's not what's in your /etc/fstab line.
    – Sotto Voce
    Commented Sep 14, 2022 at 3:33

0

You must log in to answer this question.

Browse other questions tagged .