On Sun, 14 Oct 2018 05:47:15 -0700 (PDT) Rich Shepard <rshep...@appl-ecosys.com> dijo:
>On Sat, 13 Oct 2018, John Jason Jordan wrote: > >> sudo mount /dev/sdc /media/jjj/Movies >> mount: wrong fs type, bad option, bad superblock on /dev/sdc, >> missing codepage or helper program, or other error > 1) What is the reference to that device in /etc/fstab? It is not referenced in fstab. Here is fstab: # /etc/fstab: static file system information. # Use 'blkid' to print the universally unique identifier for a # device; # <file system> <mount point> <type> <options> <dump> <pass> # / was on /dev/sdb1 during installation UUID=27c11f6b-b443-417e-9853-12c99789d8d9 / ext4 errors=remount-ro 0 1 # /home was on /dev/sdb2 during installation UUID=9a201393-e364-4d11-b372-877cded3b9cc /home ext4 defaults 0 2 192.168.1.115:/volume1/Synology /media/jjj/Synology nfs auto,user 0 0 #so clients can see nfs share /media/jjj /export/users none bind 0 0 /dev/disk/by-label/256GB-1 /media/jjj/256GB-1 auto nosuid,nodev,nofail,noauto,x-gvfs-show,x-gvfs-name=256GB-1 0 0 The last line that starts with '/dev/disk/by-label/256GB-1' was added by something involving the two 256GB USB flash drives that I bought recently. When they arrived they were exFAT or something, so I used the GUI Disks utility that comes with Ubuntu to delete the original partition, then created a new one and format it ext4, and give them labels as '256GB-1' and '256GB-2.' I did not create that line in fstab. I asked about it here the other day and the only comment was that it might involve hotplug. I searched on 'hotplug linux' but didn't come up with any explanation. The last few lines of dmesg are: usb 4-5.2: new SuperSpeed USB device number 10 using xhci_hcd usb 4-5.2: New USB device found, idVendor=152d, idProduct=9561 usb 4-5.2: New USB device strings: Mfr=1, Product=2, SerialNumber=5 usb 4-5.2: Product: JMS56x Series usb 4-5.2: Manufacturer: JMicron usb 4-5.2: SerialNumber: 00000000000000000000 scsi host11: uas scsi 11:0:0:0: Direct-Access JMicron Disk 0104 PQ: 0 ANSI: 6 sd 11:0:0:0: Attached scsi generic sg4 type 0 sd 11:0:0:0: [sdc] 23441833984 512-byte logical blocks: (12.0 TB/10.9 TiB) sd 11:0:0:0: [sdc] Write Protect is off sd 11:0:0:0: [sdc] Mode Sense: 67 00 10 08 sd 11:0:0:0: [sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA sd 11:0:0:0: [sdc] Attached SCSI disk [18690.215525] perf interrupt took too long (2503 > 2500), lowering kernel.perf_event_max_sample_rate to 50000 > 2) When you run 'sudo tail -f /var/log/messages' and connect (or > turn on) that unit how does the kernel see that drive? I could > be /dev/sdc/ or /dev/sdc1/. The drive referenced to the mount point > needs to match what /var/log/messages shows. As you can see from the end of dmesg above, the kernel sees it as /dev/sdc, not as /dev/sdc1. My dim recollection is that it used to be sdc1 before I swapped the boards in the enclosure. Altering your command because Ubuntu decided some time back to rename /var/log/messages to /var/log/syslog, I get nothing referring to the device. Last night before going to bed it occurred to me to try the Gparted GUI from the Ubuntu repos. It sees the partition, but like the Disks GUI utility it doesn't know what to make of it. It displays the partition with dotted lines around it. But it offered something new - a utility to 'search for filesystems on /dev/sdc.' It said that it might take a long time, so I started it and left it running. This morning it is still running and apparently has found nothing. I hate to do it because it's such a pain (about 7.5TB of data), but I think the only thing I can do now is to recreate and reformat the partition, then restore the data from the Synology. _______________________________________________ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug