My backups go to the first partition of a Seagate 1 Tb external drive. Suddenly, although the activity LED lights, the drive cannot be seen, by either MCC or gparted. There is some mention of it in dmesg:-

[ 727.174001] sd 6:0:0:0: [sdc] 1953525167 512-byte logical blocks:
(1.00 TB/932 GiB)
[ 727.174414] sd 6:0:0:0: [sdc] Write Protect is off
[ 727.174419] sd 6:0:0:0: [sdc] Mode Sense: 2b 00 10 08
[ 727.175287] sd 6:0:0:0: [sdc] Write cache: enabled, read cache:
enabled, supports DPO and FUA
[ 727.244894] sdc: sdc1 sdc2
[ 727.265451] sd 6:0:0:0: [sdc] Attached SCSI disk
[ 737.737675] FAT-fs (sdc1): Volume was not properly unmounted. Some
data may be corrupt. Please run fsck.
[ 918.212130] usb 2-7: USB disconnect, device number 9
[ 918.218220] sd 6:0:0:0: [sdc] Synchronizing SCSI cache
[ 918.339041] sd 6:0:0:0: [sdc] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[ 947.718117] usb 2-7: new SuperSpeed Gen 1 USB device number 10 using xhci_hcd
[ 947.732861] usb 2-7: New USB device found, idVendor=0bc2,
idProduct=2312, bcdDevice= 6.37
[ 947.732863] usb 2-7: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 947.732864] usb 2-7: Product: Expansion
[ 947.732864] usb 2-7: Manufacturer: Seagate
[ 947.732865] usb 2-7: SerialNumber: NA4BR1RV
[ 947.748216] scsi host6: uas
[ 947.749762] scsi 6:0:0:0: Direct-Access Seagate Expansion
0637 PQ: 0 ANSI: 6
[ 947.803474] sd 6:0:0:0: [sdc] Spinning up disk...
[ 951.604087] .ready
[ 951.622061] sd 6:0:0:0: [sdc] 1953525167 512-byte logical blocks:
(1.00 TB/932 GiB)
[ 951.622461] sd 6:0:0:0: [sdc] Write Protect is off
[ 951.622465] sd 6:0:0:0: [sdc] Mode Sense: 2b 00 10 08
[ 951.623369] sd 6:0:0:0: [sdc] Write cache: enabled, read cache:
enabled, supports DPO and FUA
[ 951.674935] sdc: sdc1 sdc2
[ 951.719888] sd 6:0:0:0: [sdc] Attached SCSI disk
[ 962.736534] FAT-fs (sdc1): Volume was not properly unmounted. Some
data may be corrupt. Please run fsck.
[ 1219.643950] usb 2-7: USB disconnect, device number 10
[ 1219.645640] sd 6:0:0:0: [sdc] Synchronizing SCSI cache
[ 1219.769142] sd 6:0:0:0: [sdc] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK

The system seems to look for the drive as /dev/sdc, then gives up, and
gives /dev/sdc to the next drive (a USB stick.)e.g. sdc1 is XFS, but the
first partition of the USB stick is FAT32, which would match "FAT-fs."

--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: Aioe.org NNTP Server (2:250/1@fidonet)

On Tue, 02 Feb 2021 00:48:13 +1100, Doug Laidlaw wrote:

[ 727.265451] sd 6:0:0:0: [sdc] Attached SCSI disk [ 737.737675]
FAT-fs (sdc1): Volume was not properly unmounted. Some data may be
corrupt. Please run fsck.

First, you might check the connectors of the disk cable, to see if they
are properly engaged.

Next, the disk should not be mounted.
mount |grep sd
should tell you what is mounted.

umount /dev/sdc1 /dev/sdc2 /dev/sdc
#if sdc is your external, as it appears, and is mounted.

Then,
fsck -M -A /dev/sdc1 /dev/sdc2 /dev/sdc
should check the disk and its partitions, and automatically fix anything
it finds wrong that it can fix.

If /dev/sdc is not your backup disk, you need to run lsblk or otherwise determine what it is. If lsblk cannot find it, a connector is bad or you
have a hardware problem in the drive or its controller.

Cheers!

jim b.

--
UNIX is not user-unfriendly, it merely expects users to be computer-
friendly.

--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Mon, 01 Feb 2021 08:48:13 -0500, Doug Laidlaw <laidlaws@hotkey.net.au> wrote:

My backups go to the first partition of a Seagate 1 Tb external drive. Suddenly, although the activity LED lights, the drive cannot be seen, by either MCC or gparted. There is some mention of it in dmesg:-

[ 727.174001] sd 6:0:0:0: [sdc] 1953525167 512-byte logical blocks:
(1.00 TB/932 GiB)
[ 727.174414] sd 6:0:0:0: [sdc] Write Protect is off
[ 727.174419] sd 6:0:0:0: [sdc] Mode Sense: 2b 00 10 08
[ 727.175287] sd 6:0:0:0: [sdc] Write cache: enabled, read cache:
enabled, supports DPO and FUA
[ 727.244894] sdc: sdc1 sdc2
[ 727.265451] sd 6:0:0:0: [sdc] Attached SCSI disk
[ 737.737675] FAT-fs (sdc1): Volume was not properly unmounted. Some
data may be corrupt. Please run fsck.
[ 918.212130] usb 2-7: USB disconnect, device number 9

Does the disk have it's own power supply? If not, probably not getting enough power. Try getting a powered usb hub.

Regards, Dave Hodgins

--
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

You did notice
737.737675] FAT-fs (sdc1): Volume was not properly unmounted. Some
data may be corrupt. Please run fsck.

Did you follow the advice?

On 2021-02-01, Doug Laidlaw <laidlaws@hotkey.net.au> wrote:

My backups go to the first partition of a Seagate 1 Tb external drive. Suddenly, although the activity LED lights, the drive cannot be seen, by either MCC or gparted. There is some mention of it in dmesg:-

[ 727.174001] sd 6:0:0:0: [sdc] 1953525167 512-byte logical blocks:
(1.00 TB/932 GiB)
[ 727.174414] sd 6:0:0:0: [sdc] Write Protect is off
[ 727.174419] sd 6:0:0:0: [sdc] Mode Sense: 2b 00 10 08
[ 727.175287] sd 6:0:0:0: [sdc] Write cache: enabled, read cache:
enabled, supports DPO and FUA
[ 727.244894] sdc: sdc1 sdc2
[ 727.265451] sd 6:0:0:0: [sdc] Attached SCSI disk
[ 737.737675] FAT-fs (sdc1): Volume was not properly unmounted. Some
data may be corrupt. Please run fsck.
[ 918.212130] usb 2-7: USB disconnect, device number 9
[ 918.218220] sd 6:0:0:0: [sdc] Synchronizing SCSI cache
[ 918.339041] sd 6:0:0:0: [sdc] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[ 947.718117] usb 2-7: new SuperSpeed Gen 1 USB device number 10 using xhci_hcd
[ 947.732861] usb 2-7: New USB device found, idVendor=0bc2,
idProduct=2312, bcdDevice= 6.37
[ 947.732863] usb 2-7: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 947.732864] usb 2-7: Product: Expansion
[ 947.732864] usb 2-7: Manufacturer: Seagate
[ 947.732865] usb 2-7: SerialNumber: NA4BR1RV
[ 947.748216] scsi host6: uas
[ 947.749762] scsi 6:0:0:0: Direct-Access Seagate Expansion
0637 PQ: 0 ANSI: 6
[ 947.803474] sd 6:0:0:0: [sdc] Spinning up disk...
[ 951.604087] .ready
[ 951.622061] sd 6:0:0:0: [sdc] 1953525167 512-byte logical blocks:
(1.00 TB/932 GiB)
[ 951.622461] sd 6:0:0:0: [sdc] Write Protect is off
[ 951.622465] sd 6:0:0:0: [sdc] Mode Sense: 2b 00 10 08
[ 951.623369] sd 6:0:0:0: [sdc] Write cache: enabled, read cache:
enabled, supports DPO and FUA
[ 951.674935] sdc: sdc1 sdc2
[ 951.719888] sd 6:0:0:0: [sdc] Attached SCSI disk
[ 962.736534] FAT-fs (sdc1): Volume was not properly unmounted. Some
data may be corrupt. Please run fsck.
[ 1219.643950] usb 2-7: USB disconnect, device number 10
[ 1219.645640] sd 6:0:0:0: [sdc] Synchronizing SCSI cache
[ 1219.769142] sd 6:0:0:0: [sdc] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK

The system seems to look for the drive as /dev/sdc, then gives up, and
gives /dev/sdc to the next drive (a USB stick.)e.g. sdc1 is XFS, but the first partition of the USB stick is FAT32, which would match "FAT-fs."

--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Mon, 01 Feb 2021 19:37:26 -0500, William Unruh <unruh@invalid.ca> wrote:

You did notice
737.737675] FAT-fs (sdc1): Volume was not properly unmounted. Some
data may be corrupt. Please run fsck.

Did you follow the advice?

While that needs to be done before the file system can be mounted, it will not be possible yet since the device has disappeared, likely due to a lack of power or a bad physical connection (bad cable, loose plug in the connector, etc.).

Regards Dave Hodgins

--
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 2021-02-02, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:

On Mon, 01 Feb 2021 19:37:26 -0500, William Unruh <unruh@invalid.ca> wrote:

You did notice
737.737675] FAT-fs (sdc1): Volume was not properly unmounted. Some
data may be corrupt. Please run fsck.

Did you follow the advice?

While that needs to be done before the file system can be mounted, it will not
be possible yet since the device has disappeared, likely due to a lack of power
or a bad physical connection (bad cable, loose plug in the connector, etc.).

That is certainly possible. But what is confusing is that the boot found
the disk and determined that it needed fsck needs to be run. Surely tht
would not happen if it could not find the disk at all. Of course he
might have kicked the cable and disconnected it. But if the same thing
happens when he reboots again that becomes rather unlikely.

Regards Dave Hodgins

--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 2/2/21 11:37 am, William Unruh wrote:

You did notice
737.737675] FAT-fs (sdc1): Volume was not properly unmounted. Some
data may be corrupt. Please run fsck.

Did you follow the advice?

I couldn't. sdc is a hard drive, not the backup drive (2 partitions.)
But I did notice that every time I plug in the Seagate, sdc1 is mounted automatically. To me, this means one of two things: either the entry in
fstab now points to the hard drive (my original guess, but the UUID
should exclude that, unless fstab was wrong from the very beginning, but
in that case, the Seagate should be hot-plugged when added,) or the
system is borked, and doesn't know which is which (very unlikely.)

I am about to work through Jim's checklist, and will report back.

--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: Aioe.org NNTP Server (2:250/1@fidonet)

On 2/2/21 1:25 pm, Doug Laidlaw wrote:

On 2/2/21 11:37 am, William Unruh wrote:

You did notice
  737.737675] FAT-fs (sdc1): Volume was not properly unmounted. Some
data may be corrupt. Please run fsck.

Did you follow the advice?

I couldn't. sdc is a hard drive, not the backup drive (2 partitions.)
But I did notice that every time I plug in the Seagate, sdc1 is mounted automatically.  To me, this means one of two things: either the entry in fstab now points to the hard drive (my original guess, but the UUID
should exclude that, unless fstab was wrong from the very beginning, but
in that case, the Seagate should be hot-plugged when added,) or the
system is borked, and doesn't know which is which (very unlikely.)

I am about to work through Jim's checklist, and will report back.

I think that I have my answer. Clues:

--The Seagate drive's activity light flashes normally during bootup. --Unplugging the Seagate drive makes drive_c disappear from the file
manager. Therefore, what is on the Seagate drive was on my third hard
drive before. I was identifying it by its contents, not by its UUID.
--Level 5 bootup switches to text half-way through, and ends with a line "Reconfigure..." I need to read the rest from within Mageia.

If that is right, the drive is good (it had no reason not to be,) but
has been wiped. I was doing something with Clonezilla a few days ago,
and must have pressed a wrong key.

Thanks everybody for your help in getting me to tis point. My problem
really, is that I don't think like a tech.

Doug.

--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: Aioe.org NNTP Server (2:250/1@fidonet)

On Mon, 01 Feb 2021 21:01:53 -0500, William Unruh <unruh@invalid.ca> wrote:

That is certainly possible. But what is confusing is that the boot found
the disk and determined that it needed fsck needs to be run. Surely tht
would not happen if it could not find the disk at all. Of course he
might have kicked the cable and disconnected it. But if the same thing happens when he reboots again that becomes rather unlikely.

That's what makes me think it's lack of power. There's enough power for the drive
to be on long enough to read the dirty bit status in the file system, but not enough to go any further, causing the connection to the drive to be lost.

Regards, Dave Hodgins

--
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 2021-02-02, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:

On Mon, 01 Feb 2021 21:01:53 -0500, William Unruh <unruh@invalid.ca> wrote:

That is certainly possible. But what is confusing is that the boot found
the disk and determined that it needed fsck needs to be run. Surely tht
would not happen if it could not find the disk at all. Of course he
might have kicked the cable and disconnected it. But if the same thing
happens when he reboots again that becomes rather unlikely.

That's what makes me think it's lack of power. There's enough power for the drive
to be on long enough to read the dirty bit status in the file system, but not enough to go any further, causing the connection to the drive to be lost.

Except that the drive soaks up most of its power on spin-up (assuming it
is rotating hard drive). So if it is power starved I would expect it
never to be able to even get started. Moving the heads or keeping the
platters coasting should not take that much power.

Regards, Dave Hodgins

--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 2/2/21 2:16 pm, Doug Laidlaw wrote:

My problem really, is that I don't think like a tech.

At the moment, I can't think at all. I know what to fix, but I can't
plan it. Another sign that I am steadily "losing my marbles."

--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: Aioe.org NNTP Server (2:250/1@fidonet)

On 2/2/21 2:16 pm, Doug Laidlaw wrote:

If that is right, the drive is good (it had no reason not to be,) but
has been wiped.  I was doing something with Clonezilla a few days ago,
and must have pressed a wrong key.

Thanks everybody for your help in getting me to tis point.  My problem really, is that I don't think like a tech.

Doug.

And that is all that it was. I disconnected the third hard drive,
formatted and partitioned the Seagate drive, and added the new
partitions back to fstab, then everything worked.

--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: Aioe.org NNTP Server (2:250/1@fidonet)

On Tue, 2 Feb 2021 14:16:48 +1100, Doug Laidlaw wrote:

If that is right, the drive is good (it had no reason not to be,) but
has been wiped. I was doing something with Clonezilla a few days ago,
and must have pressed a wrong key.

I never have used Clonezilla but what you have posted up to this point
shows the problems encountered when you have duplicate UUIDs, media
labels, or Partition labels.

Great argument for using rsync for cloning partitions.
Also a caution about what happens when working with partitions normally
mounted on boot.

On single OS boot systems, it may not hurt to have a rescue cd/usb handy.

--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 2/2/21 5:40 AM, Bit Twister wrote:

On Tue, 2 Feb 2021 14:16:48 +1100, Doug Laidlaw wrote:

If that is right, the drive is good (it had no reason not to be,) but
has been wiped. I was doing something with Clonezilla a few days ago,
and must have pressed a wrong key.

I never have used Clonezilla but what you have posted up to this point
shows the problems encountered when you have duplicate UUIDs, media
labels, or Partition labels.

I was about to post the same thing. As one might expect, Clonezilla's
defaults "clone" the drive, right down to the UUID.

TJ

--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 4/2/21 3:14 am, TJ wrote:

On 2/2/21 5:40 AM, Bit Twister wrote:

On Tue, 2 Feb 2021 14:16:48 +1100, Doug Laidlaw wrote:

If that is right, the drive is good (it had no reason not to be,) but
has been wiped.  I was doing something with Clonezilla a few days ago,
and must have pressed a wrong key.

I never have used Clonezilla but what you have posted up to this point
shows the problems encountered when you have duplicate UUIDs, media
labels, or Partition labels.

I was about to post the same thing. As one might expect, Clonezilla's defaults "clone" the drive, right down to the UUID.

TJ

The mystery deepens. Strange things are still happening. Files have
been replaced with earlier versions.

I looked at the filesystem listing on my backup drive a few minutes ago.
Every file hierarchy has an untitled file at the top. Apart from an
emp;0ty line in the terminal, the giveaway was the two quotes that
Mageia puts around non-standard filenames. That will be my problem, but
for tonight (now just before midnight) I will simply shut down the
computer for tonight and check it out tomorrow.
/.
I looked at the filesystem listing on my backup drive a few minutes ago.
Every file hierarchy has an untitled file at the top. Apart from an
empty line in the terminal, the giveaway was the two quotes that Mageia
puts around non-standard filenames. That will be my problem, but for
tonight (now just before midnight) I will simply shut down the computer
for tonight and check it out tomorrow.

Doug.

--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: Aioe.org NNTP Server (2:250/1@fidonet)

On 28/2/21 12:01 am, Doug Laidlaw wrote:

I looked at the filesystem listing on my backup drive a few minutes ago.
 Every file hierarchy has an untitled file at the top. Apart from an
empty line in the terminal, the giveaway was the two quotes that Mageia
puts around non-standard filenames.  That will be my problem, but for tonight (now just before midnight) I will simply shut down the computer
for tonight and check it out tomorrow.

Looking at one example with "ls -a," the nameless file (about 8
characters long) appears AHEAD of "../" and "./" That should not be happening. Time to format the whole drive.

--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: Aioe.org NNTP Server (2:250/1@fidonet)

On 28/2/21 1:19 pm, Doug Laidlaw wrote:

On 28/2/21 12:01 am, Doug Laidlaw wrote:

I looked at the filesystem listing on my backup drive a few minutes
ago.   Every file hierarchy has an untitled file at the top. Apart
from an empty line in the terminal, the giveaway was the two quotes
that Mageia puts around non-standard filenames.  That will be my
problem, but for tonight (now just before midnight) I will simply shut
down the computer for tonight and check it out tomorrow.

Looking at one example with "ls -a," the nameless file (about 8
characters long) appears AHEAD of "../" and "./"  That should not be happening.  Time to format the whole drive.

Naturally, the sequence of entries is determined by the ASCII sequence.

The 'nameless' directory contains the backup of /usr, which doesn't
appear anywhere else. Maybe, now that everything descends from /usr, it
is a way of keeping the original /usr distinct? Whatever the reason, it
seems to be "normal," not a problem.

--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: Aioe.org NNTP Server (2:250/1@fidonet)

On 28/2/21 4:52 pm, Doug Laidlaw wrote:

On 28/2/21 1:19 pm, Doug Laidlaw wrote:

On 28/2/21 12:01 am, Doug Laidlaw wrote:

I looked at the filesystem listing on my backup drive a few minutes
ago.   Every file hierarchy has an untitled file at the top. Apart
from an empty line in the terminal, the giveaway was the two quotes
that Mageia puts around non-standard filenames.  That will be my
problem, but for tonight (now just before midnight) I will simply
shut down the computer for tonight and check it out tomorrow.

Looking at one example with "ls -a," the nameless file (about 8
characters long) appears AHEAD of "../" and "./"  That should not be
happening.  Time to format the whole drive.

Naturally, the sequence of entries is determined by the ASCII sequence.

The 'nameless' directory contains the backup of /usr, which doesn't
appear anywhere else.  Maybe, now that everything descends from /usr, it
is a way of keeping the original /usr distinct?  Whatever the reason, it seems to be "normal," not a problem.

I think that I have it fixed. Something was wrong with my fstab. I
could clean out backups that went to the hard drive, but the recovered
space wasn't vacant for very long. I think that was the reason why the installer hung. Maybe it needed to write to /tmp, which was full.
Anyway, when I installed immediately after making space, the
installation proceeded normally.

--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: Aioe.org NNTP Server (2:250/1@fidonet)