Trisquel install to an external USB drive stalls with repetitive errors

Try to "self-test" the disk with the "Disks" utility in the "System settings" (the corresponding entry is under the menu button in the upper-right corner of the interface). It looks like the disk is not OK and you do not want to use a disk that may fail at any time.

Also, why ext3? Maturity is not a good answer: in the latest 4.3 version of the kernel, ext3 is handled by ext4's code. Ted T'so gave in http://lkml.iu.edu/hypermail/linux/kernel/1508.3/05063.html the rationale for the removal of ext3 as a separate filesystem:

The main rationale is that two code bases is harder to support than
one. When bugs get fixed in ext4, they don't necessarily get
back-propagated to ext3 except for a manual process where Jan notices
that a bug fixed in ext4 is also in ext3, and he manually ports the
patch over.

Both Red Hat and SuSE, as well as Debian and Ubuntu, are using ext4
with CONFIG_EXT4_USE_FOR_EXT23 for a couple of years now to support
ext2 and ext3 file systems. So with the exception of some really
ancient enterprise Linux distros, and people who are manually
configuring their systems, very few people are likely using ext3 code
base, which means the chances that it bitrots increases. Basically,
it's only been Jan's tireless work that has kept that from happening,
given that all of the major distro's have been using ext4 to support
ext2 and ext3 file systems.

Thanks to Magic Banana for constructive comments.

I tried reformatting sdb1 from ext3 to ext4, using a different USB cable, and plugging the USB cable into different ports, all to no avail, except that the error messages are now different and don't add up to obvious zero progress, but the progress bar of the Trisquel installation gets to the halfway point and then stops.

Some files did get copied into the 30GB ext4 partition, but none into the root (/) folder.

The error messages during my attempts at the Trisquel installation were again repetitive, with the "high speed USB device number 4 using ehci-pci" getting reset at 36 second intervals until it stops with an I/O error before starting another round of several resets.

I also tried the Benchmark test under Disks in System Settings and found that it makes a difference into which port the USB cable is placed, with the port having the shorter access time (9mS) apparently identified as USB-1.2 and the one with longer access time (18mS) identified as USB-2-1.2 in the reset messages that appeared during the Trisquel installation attempts. Read/write speeds were about the same either way.

After running the Benchmark test on sdb, a second instance of the drive appears on the Disks menu, and the odd man out is described as having no media, disk OK, and having one bad sector, but no partition information.

I also got messages like this in the strangely accompanying console:

> ** (gnome-disks:2911): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-Ruw5cIPIIg: Connection refused
> (gnome-disks:2911): Gtk-DEBUG: Connecting to session manager
> ======================
> libparted : 2.3
> ======================
> (gpartedbin:3177): GLib-CRITICAL **: Source ID 7 was not found when attempting to remove it
...
> (gpartedbin:3177): GLib-CRITICAL **: Source ID 55 was not found when attempting to remove it
> (gpartedbin:3177): GLib-CRITICAL **: Source ID 54 was not found when attempting to remove it
> (gpartedbin:3177): GLib-CRITICAL **: Source ID 58 was not found when attempting to remove it
...
> (gpartedbin:3177): GLib-CRITICAL **: Source ID 1508 was not found when attempting to remove it
> (gpartedbin:3177): GLib-CRITICAL **: Source ID 1512 was not found when attempting to remove it
> (gpartedbin:3177): GLib-CRITICAL **: Source ID 1511 was not found when attempting to remove it

(NNNN is different each time ...)

Solved ... I took the Sabrent external disk adapter back to the seller and replaced it with a more expensive one made by NexStar, and that caddy allowed the complete installation of Trisquel to the Seagate 1TB SSHD without incident ... no I/O errors.

Naturally I ended up with three home folders in the xfs DATA partition, and when I moved /mnt/DATA/home/home/home/user to /mnt/DATA/home/user, I could no longer log in when I start the Trisquel installation that is on the external SSHD. That was easy to correct by re-installing Trisquel, this time being sure to set sdb1 as the root (/) boot point and sdb3 as the home (/home) boot point.

Then I discovered that if I copied the .icedove folder from the internal HDD's home folder to the external SSHD's home folder and [only] then installed icedove with apt-get, that icedove could then be started from the Trisquel menu in the new Trisquel installation on the SSHD drive with no further ado. Nice !

Went through the external disk install with an IDE drive from a Sony VAIO whose screen had disintegrated for the second time, and this time another Sabrent enclosure/adapter worked just fine. Could be their SATA adapter wasn't up to snuff.