The original problem was that a new disk that I installed a month ago, did not mount after a reboot, yes a month later. From Disk UI, I click "mount selected portion" and nothing happens, no error reported. Also, from Disk UI, I click the gears icon, then I click "check Filesystem..." and it returns "Filesystem Disk_4TB on ST4000DM005-2DP166 is undamaged.".
devconnected provided instructions to mount from the command line.
sudo mount /dev/sda1 /Disk_4TB
This works fine, so the modified questions are
- Why automatically mount failing given entry in fstab.
- Should I report a bug that the GUI fails to mount and fails to indicate any error code? If so, where do I do this?
**$ sudo gdisk -l /dev/sda**
[sudo] password for john:
GPT fdisk (gdisk) version 1.0.5
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 7814037168 sectors, 3.6 TiB
Model: ST4000DM005-2DP1
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 27569B50-D174-424A-A7BF-4A0E7353C4D9
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 7814037134
Partitions will be aligned on 2048-sector boundaries
Total free space is 3693 sectors (1.8 MiB)
Number Start (sector) End (sector) Size Code Name
1 2048 7814035455 3.6 TiB 8300 Basic data partition
$ lsblk -f
NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
loop0 squashfs 0 100% /snap/canonical-livepatch/95
loop1 squashfs 0 100% /snap/core/10859
loop2 squashfs 0 100% /snap/core/10823
loop3 squashfs 0 100% /snap/core18/1944
loop4 squashfs 0 100% /snap/gnome-3-34-1804/66
loop5 squashfs 0 100% /snap/core18/1988
loop6 squashfs 0 100% /snap/gtk-common-themes/1506
loop7 squashfs 0 100% /snap/gnome-3-34-1804/60
loop8 squashfs 0 100% /snap/gtk-common-themes/1514
loop9 squashfs 0 100% /snap/microk8s/2035
loop10 squashfs 0 100% /snap/microk8s/2074
loop11 squashfs 0 100% /snap/snap-store/467
loop12 squashfs 0 100% /snap/snapd/11107
loop13 squashfs 0 100% /snap/snap-store/518
loop14 squashfs 0 100% /snap/snapd/11036
sda
└─sda1 ext4 Disk_4TB c4eaf980-50c9-4c49-9d73-3855be4c91f9
sdb
└─sdb1 ext4 External_2TB a8500ff3-9465-4238-9ada-22ab9ec590ae 1.7T 0% /External_2TB
nvme0n1 ext4 Disk2 16352634-91e0-4567-92cf-065e01395794 757.1G 54% /Disk2
nvme1n1
├─nvme1n1p1 vfat 112E-F7FA 511M 0% /boot/efi
├─nvme1n1p2
└─nvme1n1p5 LVM2_member 4bj3wl-VTM6-f16H-8gXR-bQLV-1Dj0-vtSulI
├─vgubuntu-root ext4 f1ab115e-a7b7-4737-b62d-2a6cca1a1016 692G 19% /
└─vgubuntu-swap_1 swap 1418c65e-e718-49af-a1a5-57f78209480e [SWAP]
cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/vgubuntu-root / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/nvme1n1p1 during installation
UUID=112E-F7FA /boot/efi vfat umask=0777 0 1
/dev/mapper/vgubuntu-swap_1 none swap sw 0 0
/dev/disk/by-uuid/16352634-91e0-4567-92cf-065e01395794 /Disk2 auto suid,nodev,nofail,x-gvfs-show,auto,exec,rw 0 0
/dev/disk/by-id/usb-BUFFALO_External_HDD_020100005036-0:0-part1 /External_2TB auto nosuid,nodev,nofail,x-gvfs-show 0 0
/dev/disk/by-uuid/92D6CA0AD6C9EE93 /Disk_4TB auto nosuid,nodev,nofail,x-gvfs-show 0 0
/dev/disk/by-uuid/c4eaf980-50c9-4c49-9d73-3855be4c91f9 /Disk_4TB auto nosuid,nodev,nofail,x-gvfs-show 0 0
SOLVED Wayne observed that /Disk_4TB in fstab had 2 entries with different UUIDs?
I once installed the disk with one of those docking stations before later installed it internally. This creates a second entry in fstab with different UID.
Disk UI did not complain about the conflicting stale entry and succeeded in mounting it the first time around. Subsequent reboots is when this conflict kicks in.
