External USB disks not recognized - Leap 15.3
Hello. I use openSUSE Leap 15.3. Trouble is, when I attach USB sticks from 16-128 GB there are no problems. They are mounted and read immediately upon being attached. When I attach large external USB disks, there is a different story. The disks most often do not show up. Sometimes they do, but most times I must read the disks (formatted with EXT4, FAT32 and EXFAT) on a Mac laptop in order to access them. Which, admittedly, makes me ashamed. The question is why this happens. To elucidate the problem, I have typed fdisk -l and dmesg, and the results are in the links below. I shall be extremely thankful if you can have a look at these outputs and see if you can spot the source of my problem. If these files do not provide a clue, please tell me what commands I should try next. In both cases, an external disk was attached. However, the system failed to see it. The fdisk -l output: http://www.coldsiberia.net/technics/fdisk_l_21042022.txt The dmesg output: http://www.coldsiberia.net/technics/dmesg_21042022.txt Sincerely, Per Inge Oestmoen, Norway
Hello,
In the Message;
Subject : External USB disks not recognized - Leap 15.3
Message-ID : <6373dbd0-b074-35f6-011c-1e5c597ddcc8@coldsiberia.org>
Date & Time: Fri, 22 Apr 2022 00:03:34 +0200
[PIO] == Per Inge Oestmoen
On 4/21/22 19:28, Masaru Nomiya wrote:
Hello,
In the Message;
Subject : External USB disks not recognized - Leap 15.3 Message-ID : <6373dbd0-b074-35f6-011c-1e5c597ddcc8@coldsiberia.org> Date & Time: Fri, 22 Apr 2022 00:03:34 +0200
[PIO] == Per Inge Oestmoen
has written: PIO> Hello.
PIO> I use openSUSE Leap 15.3. Trouble is, when I attach USB sticks PIO> from 16-128 GB there are no problems. They are mounted and read PIO> immediately upon being attached.
PIO> When I attach large external USB disks, there is a different PIO> story. The disks most often do not show up. Sometimes they do, PIO> but most times I must read the disks (formatted with EXT4, FAT32 PIO> and EXFAT) on a Mac laptop in order to access them. Which, PIO> admittedly, makes me ashamed.
PIO> The question is why this happens.
Does the same phenomenon occur if you change the USB port?
Along the same lines, I'm wondering if there is a power issue where the USB port is not supplying enough power. Are these external enclosures? Almost all 2.5" external disks I've used are either USB 3.0 where enough power is supplied by the port, or if they are USB 2.0, they have a Y connector where they draw power from 2 different ports at the same time. Larger enclosures usually need external DC supply.
Payam Firouztala wrote:
Along the same lines, I'm wondering if there is a power issue where the USB port is not supplying enough power. Are these external enclosures? Almost all 2.5" external disks I've used are either USB 3.0 where enough power is supplied by the port, or if they are USB 2.0, they have a Y connector where they draw power from 2 different ports at the same time. Larger enclosures usually need external DC supply.
They are all external enclosures, with their own power supplies. Per Inge Oestmoen, Norway
Masaru Nomiya wrote:
[PIO] == Per Inge Oestmoen
has written: PIO> I use openSUSE Leap 15.3. Trouble is, when I attach USB sticks PIO> from 16-128 GB there are no problems. They are mounted and read PIO> immediately upon being attached. PIO> When I attach large external USB disks, there is a different PIO> story. The disks most often do not show up. Sometimes they do, PIO> but most times I must read the disks (formatted with EXT4, FAT32 PIO> and EXFAT) on a Mac laptop in order to access them. Which, PIO> admittedly, makes me ashamed. PIO> The question is why this happens.
Does the same phenomenon occur if you change the USB port?
Yes, it is the same for all the USB ports. Per Inge Oestmoen, Norwawy
Hello,
Sorry for late reply.
In the Message;
Subject : Re: External USB disks not recognized - Leap 15.3
Message-ID :
Hello,
In the Message;
Subject : Re: External USB disks not recognized - Leap 15.3
Message-ID :
On 2022-04-24 02:51, Masaru Nomiya wrote:
Hello,
In the Message;
Subject : Re: External USB disks not recognized - Leap 15.3 Message-ID :
Date & Time: Sun, 24 Apr 2022 01:02:03 +0200 [PIO] == Per Inge Oestmoen
has written: PIO> Masaru Nomiya wrote:
MN> > cat /sys/module/usbcore/parameters/autosuspend
PIO> I did it just now:
PIO> cat /sys/module/usbcore/parameters/autosuspend
PIO> Result:
PIO> -1
PIO> What is next to be tried?
Then,
In the Message;
Subject : External USB disks not recognized - Leap 15.3 Message-ID : <6373dbd0-b074-35f6-011c-1e5c597ddcc8@coldsiberia.org> Date & Time: Fri, 22 Apr 2022 00:03:34 +0200
[PIO] == Per Inge Oestmoen
has written: [...] PIO> Sometimes they do, but most times I must read the PIO> disks (formatted with EXT4, FAT32 and EXFAT) on a Mac laptop in PIO> order to access them. Which, admittedly, makes me ashamed.
Please show the 3 results of;
# fsck -n /dev/sdX
I see where you are going :-) A Windows filesystem that is marked "dirty" can not be mounted in Linux. However, I doubt this would be the case, because the log does not even indicate any USB being connected. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Hello,
In the Message;
Subject : Re: External USB disks not recognized - Leap 15.3
Message-ID : <7d7397c9-9d35-e07c-8870-614cccc9d862@telefonica.net>
Date & Time: Sun, 24 Apr 2022 12:19:04 +0200
[CER] == "Carlos E. R."
Masaru Nomiya wrote:
PIO> What is next to be tried? Subject : External USB disks not recognized - Leap 15.3
[...] PIO> Sometimes they do, but most times I must read the PIO> disks (formatted with EXT4, FAT32 and EXFAT) on a Mac laptop in PIO> order to access them. Which, admittedly, makes me ashamed.
Please show the 3 results of;
# fsck -n /dev/sdX
Thank you. Here is the result: localhost:/home/siberia # fsck -n /dev/sdX fsck from util-linux 2.36.2 e2fsck 1.43.8 (1-Jan-2018) fsck.ext2: No such file or directory while trying to open /dev/sdX Possibly non-existent device? localhost:/home/siberia # Per Inge Oestmoen, Norway
On Sun, 24 Apr 2022 16:46:32 +0200
Per Inge Oestmoen
Masaru Nomiya wrote:
PIO> What is next to be tried? Subject : External USB disks not recognized - Leap 15.3
[...] PIO> Sometimes they do, but most times I must read the PIO> disks (formatted with EXT4, FAT32 and EXFAT) on a Mac laptop PIO> in order to access them. Which, admittedly, makes me ashamed.
Please show the 3 results of;
# fsck -n /dev/sdX
Thank you.
Here is the result:
localhost:/home/siberia # fsck -n /dev/sdX fsck from util-linux 2.36.2 e2fsck 1.43.8 (1-Jan-2018) fsck.ext2: No such file or directory while trying to open /dev/sdX Possibly non-existent device? localhost:/home/siberia #
He meant run the command 3 times, substituting the letters of your actual drives for the variable X e.g. fsck -n /dev/sda etc
Per Inge Oestmoen, Norway
Dave Howorth wrote:
He meant run the command 3 times, substituting the letters of your actual drives for the variable X e.g. fsck -n /dev/sda
OK, good. Here we go: ---- localhost:/home/siberia # fsck -n /dev/nvme0n1 fsck from util-linux 2.36.2 e2fsck 1.43.8 (1-Jan-2018) Warning! /dev/nvme0n1 is in use. ext2fs_open2: Bad magic number in super-block fsck.ext2: Superblock invalid, trying backup blocks... fsck.ext2: Bad magic number in super-block while trying to open /dev/nvme0n1 The superblock could not be read or does not describe a valid ext2/ext3/ext4 filesystem. If the device is valid and it really contains an ext2/ext3/ext4 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 <device> or e2fsck -b 32768 <device> Found a gpt partition table in /dev/nvme0n1 ---- ---- localhost:/home/siberia # fsck -n /dev/sda fsck from util-linux 2.36.2 e2fsck 1.43.8 (1-Jan-2018) ext2fs_open2: Bad magic number in super-block fsck.ext2: Superblock invalid, trying backup blocks... fsck.ext2: Bad magic number in super-block while trying to open /dev/sda The superblock could not be read or does not describe a valid ext2/ext3/ext4 filesystem. If the device is valid and it really contains an ext2/ext3/ext4 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 <device> or e2fsck -b 32768 <device> Found a gpt partition table in /dev/sda ---- ---- localhost:/home/siberia # fsck -n /dev/sdb fsck from util-linux 2.36.2 e2fsck 1.43.8 (1-Jan-2018) Warning! /dev/sdb is in use. ext2fs_open2: Bad magic number in super-block fsck.ext2: Superblock invalid, trying backup blocks... fsck.ext2: Bad magic number in super-block while trying to open /dev/sdb The superblock could not be read or does not describe a valid ext2/ext3/ext4 filesystem. If the device is valid and it really contains an ext2/ext3/ext4 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 <device> or e2fsck -b 32768 <device> Found a gpt partition table in /dev/sdb ---- Per Inge Oestmoen, Norway
On 2022-04-24 20:08, Per Inge Oestmoen wrote:
Dave Howorth wrote:
He meant run the command 3 times, substituting the letters of your actual drives for the variable X e.g. fsck -n /dev/sda
OK, good.
No no, this is a confusion. It has to be the device name assigned to the USB stick, and we know it doesn't exist. The entire USB bus is not working with the disk. This might be a BIOS setting re USB power, that is disabled. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Carlos E. R. wrote:
On 2022-04-24 20:08, Per Inge Oestmoen wrote:
Dave Howorth wrote:
He meant run the command 3 times, substituting the letters of your actual drives for the variable X e.g. fsck -n /dev/sda
OK, good.
No no, this is a confusion. It has to be the device name assigned to the USB stick, and we know it doesn't exist. The entire USB bus is not working with the disk. This might be a BIOS setting re USB power, that is disabled.
The interesting thing is that when I attach a USB stick, there are no problems whatsoever. Here, the last disk here is the /dev/sdc, the USB stick I now attached: ---- localhost:/home/siberia # fdisk -l Disk /dev/nvme0n1: 465.76 GiB, 500107862016 bytes, 976773168 sectors Disk model: Seagate FireCuda 510 SSD ZP500GM30001 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 5E9039C2-A348-49FC-BD23-791E5F3CF7E9 Device Start End Sectors Size Type /dev/nvme0n1p1 2048 18431 16384 8M BIOS boot /dev/nvme0n1p2 18432 972578815 972560384 463.8G Linux filesystem /dev/nvme0n1p3 972578816 976773134 4194319 2G Linux swap Disk /dev/sda: 2.73 TiB, 3000592982016 bytes, 5860533168 sectors Disk model: WDC WD30EFRX-68E Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: D2DBC106-C525-4AC9-B3B5-61F66DCB09F8 Device Start End Sectors Size Type /dev/sda1 40 409639 409600 200M EFI System /dev/sda2 411648 4028684287 4028272640 1.9T Microsoft basic data /dev/sda3 4028684288 4294969343 266285056 127G Microsoft basic data /dev/sda4 4294969344 5860532223 1565562880 746.5G Microsoft basic data Disk /dev/sdb: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors Disk model: Samsung SSD 860 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 672F0DAE-668F-45C2-9E33-ED8E30212660 Device Start End Sectors Size Type /dev/sdb1 2048 2000409230 2000407183 953.9G Linux filesystem Disk /dev/sdc: 29.84 GiB, 32044482560 bytes, 62586880 sectors Disk model: Survivor 3.0 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000 Device Boot Start End Sectors Size Id Type /dev/sdc1 2048 62586879 62584832 29.8G b W95 FAT32 localhost:/home/siberia # ---- Per Inge Oestmoen, Norway
On 2022-04-24 21:12, Per Inge Oestmoen wrote:
Carlos E. R. wrote:
On 2022-04-24 20:08, Per Inge Oestmoen wrote:
Dave Howorth wrote:
He meant run the command 3 times, substituting the letters of your actual drives for the variable X e.g. fsck -n /dev/sda
OK, good.
No no, this is a confusion. It has to be the device name assigned to the USB stick, and we know it doesn't exist. The entire USB bus is not working with the disk. This might be a BIOS setting re USB power, that is disabled.
The interesting thing is that when I attach a USB stick, there are no problems whatsoever. Here, the last disk here is the /dev/sdc, the USB stick I now attached:
---- localhost:/home/siberia # fdisk -l
...
Disk /dev/sdc: 29.84 GiB, 32044482560 bytes, 62586880 sectors Disk model: Survivor 3.0 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type /dev/sdc1 2048 62586879 62584832 29.8G b W95 FAT32 localhost:/home/siberia # ----
You could remove that stick and connect the one that does not work, and try directly: fdisk -l /dev/sdc fsck -n /dev/sdc1 But I expect them to fail. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Hello,
Sorry, I missed,
But, unbelivable!!!
In the Message;
Subject : Re: External USB disks not recognized - Leap 15.3
Message-ID : <9eb9884e-38bd-f637-ce8e-d03f2b64f2c4@coldsiberia.org>
Date & Time: Sun, 24 Apr 2022 20:08:12 +0200
[PIO] == Per Inge Oestmoen
On 2022-04-27 15:57, Masaru Nomiya wrote:
Hello,
PIO> ---- PIO> localhost:/home/siberia # fsck -n /dev/sdb PIO> fsck from util-linux 2.36.2 PIO> e2fsck 1.43.8 (1-Jan-2018) PIO> Warning! /dev/sdb is in use. PIO> ext2fs_open2: Bad magic number in super-block PIO> fsck.ext2: Superblock invalid, trying backup blocks... PIO> fsck.ext2: Bad magic number in super-block while trying to open /dev/sdb
PIO> The superblock could not be read or does not describe a valid ext2/ext3/ext4 PIO> filesystem. If the device is valid and it really contains an ext2/ext3/ext4 PIO> filesystem (and not swap or ufs or something else), then the superblock PIO> is corrupt, and you might try running e2fsck with an alternate superblock: PIO> e2fsck -b 8193 <device> PIO> or PIO> e2fsck -b 32768 <device>
PIO> Found a gpt partition table in /dev/sdb
First.
It is common knowledge that checking HDDs must be done in an unmounted state.
In other words, you should boot your PC with the opensuse installation disc, enter rescue mode, and perform an internal or external HDD check.
I must say that your approach is extremely dangerous!
Second.
Did you try to understand the meaning of the message after the check?
It should be accepted that there are very few people who will continue to use the system after seeing this message.
Usually, they will immediately make a backup and replace the HDD.
Nono, this is normal. he is attempting to fsck the entire disk, not the partition. On the other hand, this should not be done on a mounted filesystem -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2022-04-27 15:57, Masaru Nomiya wrote:
PIO> Found a gpt partition table in /dev/sdb
First.
It is common knowledge that checking HDDs must be done in an unmounted state.
In other words, you should boot your PC with the opensuse installation disc, enter rescue mode, and perform an internal or external HDD check.
I must say that your approach is extremely dangerous!
Second.
Did you try to understand the meaning of the message after the check?
It should be accepted that there are very few people who will continue to use the system after seeing this message.
Usually, they will immediately make a backup and replace the HDD.
Nono, this is normal.
he is attempting to fsck the entire disk, not the partition.
On the other hand, this should not be done on a mounted filesystem
This was done on a data backup disk, not on my system disk. Per Inge Oestmoen, Norway
On 2022-04-27 16:31, Per Inge Oestmoen wrote:
Carlos E. R. wrote:
On 2022-04-27 15:57, Masaru Nomiya wrote:
PIO> Found a gpt partition table in /dev/sdb
First.
It is common knowledge that checking HDDs must be done in an unmounted state.
In other words, you should boot your PC with the opensuse installation disc, enter rescue mode, and perform an internal or external HDD check.
I must say that your approach is extremely dangerous!
Second.
Did you try to understand the meaning of the message after the check?
It should be accepted that there are very few people who will continue to use the system after seeing this message.
Usually, they will immediately make a backup and replace the HDD.
Nono, this is normal.
he is attempting to fsck the entire disk, not the partition.
On the other hand, this should not be done on a mounted filesystem
This was done on a data backup disk, not on my system disk.
Yes, but that is irrelevant. You must not do an fsck on a mounted filesystem.
Per Inge Oestmoen, Norway
-- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2022-04-27 16:31, Per Inge Oestmoen wrote:
Carlos E. R. wrote:
On the other hand, this should not be done on a mounted filesystem
This was done on a data backup disk, not on my system disk.
Yes, but that is irrelevant. You must not do an fsck on a mounted filesystem.
Ouch, how can I ascertain whether or not my file system has become corrupt? Unmount it and then run fsck, of course. By the way: How do I do it if I want to run fsck on my system disk? From a USB stick? Per Inge Oestmoen, Norway
On 2022-04-27 22:30, Per Inge Oestmoen wrote:
Carlos E. R. wrote:
On 2022-04-27 16:31, Per Inge Oestmoen wrote:
Carlos E. R. wrote:
On the other hand, this should not be done on a mounted filesystem
This was done on a data backup disk, not on my system disk.
Yes, but that is irrelevant. You must not do an fsck on a mounted filesystem.
Ouch, how can I ascertain whether or not my file system has become corrupt? Unmount it and then run fsck, of course.
Yes. But it is very rare for a filesystem to become corrupt while mounted. It could happen if the machine is hibernated, then you remove a disk and put it in another machine or system.
By the way: How do I do it if I want to run fsck on my system disk? From a USB stick?
Yes. Or just reboot. Usually there is a quick check at boot. There was a way to force an fsck on boot by creating a file on / of a certain name; I have forgotten the name, and I don't know if systemd honours this. Google says it is "/forcefsck". You can try if you are curious, and then you tell us :-) # touch /forcefsck -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
Dave Howorth composed on 2022-04-24 17:33 (UTC+0100):
He meant run the command 3 times, substituting the letters of your actual drives for the variable X
e.g. fsck -n /dev/sda
man page for fsck here in 15.3 has no such option "-n". e2fsck is for checking unmounted filesystems, not disks or sticks. Numbers are required to follow letters, e.g. for EXT4 filesystems: e2fsck -f /dev/nvme0n1p3 e2fsck -f /dev/sdb5 e2fsck -f /dev/sde1 -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 2022-04-24 20:32, Felix Miata wrote:
Dave Howorth composed on 2022-04-24 17:33 (UTC+0100):
He meant run the command 3 times, substituting the letters of your actual drives for the variable X
e.g. fsck -n /dev/sda
man page for fsck here in 15.3 has no such option "-n".
But there is. -s Serialize fsck operations. This is a good idea if you are checking multiple filesystems and the checkers are in an interactive mode. (Note: e2fsck(8) runs in an interactive mode by default. To make e2fsck(8) run in a non-interac- tive mode, you must either specify the -p or -a option, if you wish for errors to be corrected automatically, or the ===> -n option if you do not.) It is a documentation error, they forgot to create a paragraph for it. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Carlos E. R. composed on 2022-04-24 20:41 (UTC+0200):
Felix Miata wrote:
man page for fsck here in 15.3 has no such option "-n".
But there is.
-s Serialize fsck operations. This is a good idea if you are checking multiple filesystems and the checkers are in an interactive mode. (Note: e2fsck(8) runs in an interactive mode by default. To make e2fsck(8) run in a non-interac- tive mode, you must either specify the -p or -a option, if you wish for errors to be corrected automatically, or the ===> -n option if you do not.)
It is a documentation error, they forgot to create a paragraph for it.
More than that was forgotten: [quote] SYNOPSIS fsck [-lsAVRTMNP] [-r [fd]] [-C [fd]] [-t fstype] [filesystem...] [--] [fs-specific-options] However: # fsck -n /dev/sda11 fsck from util-linux 2.36.2 e2fsck 1.43.8 (1-Jan-2018) root11p775: clean, 150467/1155072 files, 1368780/4607996 blocks -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 2022-04-22 00:03, Per Inge Oestmoen wrote:
Hello.
I use openSUSE Leap 15.3. Trouble is, when I attach USB sticks from 16-128 GB there are no problems. They are mounted and read immediately upon being attached.
When I attach large external USB disks, there is a different story. The disks most often do not show up. Sometimes they do, but most times I must read the disks (formatted with EXT4, FAT32 and EXFAT) on a Mac laptop in order to access them. Which, admittedly, makes me ashamed.
The question is why this happens.
To elucidate the problem, I have typed fdisk -l and dmesg, and the results are in the links below. I shall be extremely thankful if you can have a look at these outputs and see if you can spot the source of my problem. If these files do not provide a clue, please tell me what commands I should try next.
In both cases, an external disk was attached. However, the system failed to see it.
The fdisk -l output:
http://www.coldsiberia.net/technics/fdisk_l_21042022.txt
The dmesg output:
As you can see in your outputs, the disks are recognized. I see sdb with one partition, and sda, with 4. [ 2.428846] usb 1-2: New USB device found, idVendor=0b05, idProduct=190e, bcdDevice= 2.00 [ 2.428852] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 2.428855] usb 1-2: Product: ASUS USB-BT500 [ 2.428857] usb 1-2: Manufacturer: Realtek [ 2.428860] usb 1-2: SerialNumber: 00E04C239987 [ 2.444976] scsi 2:0:0:0: Direct-Access ATA WDC WD30EFRX-68E 0A82 PQ: 0 ANSI: 5 [ 2.446060] scsi 3:0:0:0: Direct-Access ATA Samsung SSD 860 2B6Q PQ: 0 ANSI: 5 [ 2.461082] sd 2:0:0:0: [sda] 5860533168 512-byte logical blocks: (3.00 TB/2.73 TiB) [ 2.461083] sd 2:0:0:0: [sda] 4096-byte physical blocks [ 2.461087] sd 2:0:0:0: [sda] Write Protect is off [ 2.461087] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 2.461092] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA It is your desktop that doesn't open or offer to open them automatically, but you do not even say what desktop you are using. You can probably find the entries in the file browser of your desktop, and click to open them. The technique to investigate these things is not to send the entire dmesg log. Open a terminal, su to root if necessary, then issue one of these commands: tail -f /var/log/messages dmesg --follow journalctl --follow (and hit enter twice or more) THEN, plug in the external media. What is interesting are only the new lines that appear in the window. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2022-04-22 00:03, Per Inge Oestmoen wrote:
In both cases, an external disk was attached. However, the system failed to see it.
The fdisk -l output: http://www.coldsiberia.net/technics/fdisk_l_21042022.txt The dmesg output: http://www.coldsiberia.net/technics/dmesg_21042022.txt
As you can see in your outputs, the disks are recognized. I see sdb with one partition, and sda, with 4.
The sdb is the program/startup disk. The sda is the internal working disk. It has four partitions. The external disk is still not seen. I have two here. None is seen.
It is your desktop that doesn't open or offer to open them automatically, but you do not even say what desktop you are using. You can probably find the entries in the file browser of your desktop, and click to open them.
No, that is the problem. I use the KDE desktop, and the external disk is not seen let alone mounted.
The technique to investigate these things is not to send the entire dmesg log.
Open a terminal, su to root if necessary, then issue one of these commands:
tail -f /var/log/messages dmesg --follow journalctl --follow (and hit enter twice or more)
THEN, plug in the external media. What is interesting are only the new lines that appear in the window.
Thank you! Here is the output *before* I attach the external disk: localhost:/home/siberia # tail -f /var/log/messages 2022-04-22T12:54:29.645387+02:00 localhost systemd[1]: Started Daily Cleanup of Snapper Snapshots. 2022-04-22T12:54:29.663491+02:00 localhost dbus-daemon[996]: [system] Activating via systemd: service name='org.opensuse.Snapper' unit='snapperd.service' requested by ':1.53' (uid=0 pid=3782 comm="/usr/lib/snapper/systemd-helper --cleanup ") 2022-04-22T12:54:29.664466+02:00 localhost systemd[1]: Starting DBus interface for snapper... 2022-04-22T12:54:29.669171+02:00 localhost dbus-daemon[996]: [system] Successfully activated service 'org.opensuse.Snapper' 2022-04-22T12:54:29.669304+02:00 localhost systemd[1]: Started DBus interface for snapper. 2022-04-22T12:54:29.670536+02:00 localhost systemd[1]: snapper-cleanup.service: Succeeded. 2022-04-22T12:54:43.466347+02:00 localhost kwin_x11[1790]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 9551, resource id: 35652125, major code: 18 (ChangeProperty), minor code: 0 2022-04-22T12:54:43.711262+02:00 localhost kwin_x11[1790]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 10029, resource id: 37754445, major code: 3 (GetWindowAttributes), minor code: 0 2022-04-22T12:54:50.176884+02:00 localhost su: (to root) siberia on pts/1 2022-04-22T12:54:50.178239+02:00 localhost su: pam_unix(su:session): session opened for user root by siberia(uid=1000) Then I attach the external disk, and here is the result *after* it was attached: localhost:/home/siberia # tail -f /var/log/messages 2022-04-22T12:54:50.176884+02:00 localhost su: (to root) siberia on pts/1 2022-04-22T12:54:50.178239+02:00 localhost su: pam_unix(su:session): session opened for user root by siberia(uid=1000) 2022-04-22T12:55:29.733129+02:00 localhost systemd[1]: snapperd.service: Succeeded. 2022-04-22T12:57:27.597895+02:00 localhost konsole[3786]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 2231, resource id: 37755122, major code: 40 (TranslateCoords), minor code: 0 2022-04-22T12:57:33.265358+02:00 localhost kwin_x11[1790]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 25091, resource id: 8388665, major code: 18 (ChangeProperty), minor code: 0 2022-04-22T12:57:33.273893+02:00 localhost kwin_x11[1790]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 25095, resource id: 35652143, major code: 18 (ChangeProperty), minor code: 0 2022-04-22T12:57:35.206089+02:00 localhost kwin_x11[1790]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 25934, resource id: 35652145, major code: 18 (ChangeProperty), minor code: 0 2022-04-22T12:57:35.406901+02:00 localhost kwin_x11[1790]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 26382, resource id: 37755312, major code: 3 (GetWindowAttributes), minor code: 0 2022-04-22T12:57:42.926962+02:00 localhost su: (to root) siberia on pts/2 2022-04-22T12:57:42.928260+02:00 localhost su: pam_unix(su:session): session opened for user root by siberia(uid=1000) Per Inge Oestmoen, Norway
On 2022-04-22 13:00, Per Inge Oestmoen wrote:
Carlos E. R. wrote:
On 2022-04-22 00:03, Per Inge Oestmoen wrote:
In both cases, an external disk was attached. However, the system failed to see it.
The fdisk -l output: http://www.coldsiberia.net/technics/fdisk_l_21042022.txt The dmesg output: http://www.coldsiberia.net/technics/dmesg_21042022.txt
As you can see in your outputs, the disks are recognized. I see sdb with one partition, and sda, with 4.
The sdb is the program/startup disk.
The sda is the internal working disk. It has four partitions.
Oh. I thought it was the nvme disk. ...
THEN, plug in the external media. What is interesting are only the new lines that appear in the window.
Thank you!
Here is the output *before* I attach the external disk:
...
Then I attach the external disk, and here is the result *after* it was attached:
localhost:/home/siberia # tail -f /var/log/messages 2022-04-22T12:54:50.176884+02:00 localhost su: (to root) siberia on pts/1 2022-04-22T12:54:50.178239+02:00 localhost su: pam_unix(su:session): session opened for user root by siberia(uid=1000) 2022-04-22T12:55:29.733129+02:00 localhost systemd[1]: snapperd.service: Succeeded. 2022-04-22T12:57:27.597895+02:00 localhost konsole[3786]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 2231, resource id: 37755122, major code: 40 (TranslateCoords), minor code: 0 2022-04-22T12:57:33.265358+02:00 localhost kwin_x11[1790]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 25091, resource id: 8388665, major code: 18 (ChangeProperty), minor code: 0 2022-04-22T12:57:33.273893+02:00 localhost kwin_x11[1790]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 25095, resource id: 35652143, major code: 18 (ChangeProperty), minor code: 0 2022-04-22T12:57:35.206089+02:00 localhost kwin_x11[1790]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 25934, resource id: 35652145, major code: 18 (ChangeProperty), minor code: 0 2022-04-22T12:57:35.406901+02:00 localhost kwin_x11[1790]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 26382, resource id: 37755312, major code: 3 (GetWindowAttributes), minor code: 0 2022-04-22T12:57:42.926962+02:00 localhost su: (to root) siberia on pts/2 2022-04-22T12:57:42.928260+02:00 localhost su: pam_unix(su:session): session opened for user root by siberia(uid=1000)
Ok, this is much clearer. You have a kernel or hardware problem, it doesn't see the connection of the USB at all. Can you try with another operating system in the same computer, same cables and disks? If you don't have any installed, try booting from live media. First an openSUSE live, then some other distribution. Or try with a different external enclosure. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
Carlos E. R. wrote:
Ok, this is much clearer. You have a kernel or hardware problem, it doesn't see the connection of the USB at all. [See below]
Can you try with another operating system in the same computer, same cables and disks? If you don't have any installed, try booting from live media. First an openSUSE live, then some other distribution.
I now installed one more hard drive, and detached the others. Then I installed the Kubuntu operating system. The result was the same: No contact with the disks. The strange thing is that there is no problem whatsoever when attaching USB sticks to the same cable and the same USB port. Per Inge Oestmoen, Norway ----
Then I attach the external disk, and here is the result *after* it was attached:
localhost:/home/siberia # tail -f /var/log/messages 2022-04-22T12:54:50.176884+02:00 localhost su: (to root) siberia on pts/1 2022-04-22T12:54:50.178239+02:00 localhost su: pam_unix(su:session): session opened for user root by siberia(uid=1000) 2022-04-22T12:55:29.733129+02:00 localhost systemd[1]: snapperd.service: Succeeded. 2022-04-22T12:57:27.597895+02:00 localhost konsole[3786]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 2231, resource id: 37755122, major code: 40 (TranslateCoords), minor code: 0 2022-04-22T12:57:33.265358+02:00 localhost kwin_x11[1790]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 25091, resource id: 8388665, major code: 18 (ChangeProperty), minor code: 0 2022-04-22T12:57:33.273893+02:00 localhost kwin_x11[1790]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 25095, resource id: 35652143, major code: 18 (ChangeProperty), minor code: 0 2022-04-22T12:57:35.206089+02:00 localhost kwin_x11[1790]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 25934, resource id: 35652145, major code: 18 (ChangeProperty), minor code: 0 2022-04-22T12:57:35.406901+02:00 localhost kwin_x11[1790]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 26382, resource id: 37755312, major code: 3 (GetWindowAttributes), minor code: 0 2022-04-22T12:57:42.926962+02:00 localhost su: (to root) siberia on pts/2 2022-04-22T12:57:42.928260+02:00 localhost su: pam_unix(su:session): session opened for user root by siberia(uid=1000)
----
On 2022-04-23 11:49, Per Inge Oestmoen wrote:
Carlos E. R. wrote:
Ok, this is much clearer. You have a kernel or hardware problem, it doesn't see the connection of the USB at all. [See below]
Can you try with another operating system in the same computer, same cables and disks? If you don't have any installed, try booting from live media. First an openSUSE live, then some other distribution.
I now installed one more hard drive, and detached the others. Then I installed the Kubuntu operating system. The result was the same: No contact with the disks.
Ok, you should try what Masaru Nomiya suggested.
The strange thing is that there is no problem whatsoever when attaching USB sticks to the same cable and the same USB port.
Per Inge Oestmoen, Norway
-- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
On Fri, 22 Apr 2022 00:03:34 +0200
Per Inge Oestmoen
Hello.
I use openSUSE Leap 15.3. Trouble is, when I attach USB sticks from 16-128 GB there are no problems. They are mounted and read immediately upon being attached.
When I attach large external USB disks, there is a different story. The disks most often do not show up. Sometimes they do, but most times I must read the disks (formatted with EXT4, FAT32 and EXFAT) on a Mac laptop in order to access them. Which, admittedly, makes me ashamed.
The question is why this happens.
To elucidate the problem, I have typed fdisk -l and dmesg, and the results are in the links below. I shall be extremely thankful if you can have a look at these outputs and see if you can spot the source of my problem. If these files do not provide a clue, please tell me what commands I should try next.
In both cases, an external disk was attached. However, the system failed to see it.
The fdisk -l output:
http://www.coldsiberia.net/technics/fdisk_l_21042022.txt
The dmesg output:
http://www.coldsiberia.net/technics/dmesg_21042022.txt
Sincerely, Per Inge Oestmoen, Norway
Those links aren't very easy to use. Better would be to bring up your system without the USB disk and then type the command $ sudo journalctl -f > junk Then insert your USB followed by typing ^C then paste the file 'junk' somewhere we can read. That will show the events concerning the USB disk in an easier to digest form.
On Thursday, April 21, 2022 5:03:34 PM CDT Per Inge Oestmoen wrote:
Hello.
I use openSUSE Leap 15.3. Trouble is, when I attach USB sticks from 16-128 GB there are no problems. They are mounted and read immediately upon being attached.
When I attach large external USB disks, there is a different story. The disks most often do not show up. Sometimes they do, but most times I must read the disks (formatted with EXT4, FAT32 and EXFAT) on a Mac laptop in order to access them. Which, admittedly, makes me ashamed.
The question is why this happens.
To elucidate the problem, I have typed fdisk -l and dmesg, and the results are in the links below. I shall be extremely thankful if you can have a look at these outputs and see if you can spot the source of my problem. If these files do not provide a clue, please tell me what commands I should try next.
In both cases, an external disk was attached. However, the system failed to see it.
The fdisk -l output:
http://www.coldsiberia.net/technics/fdisk_l_21042022.txt
The dmesg output:
http://www.coldsiberia.net/technics/dmesg_21042022.txt
Sincerely, Per Inge Oestmoen, Norway
The dmesg you have provided does not show you plugging in the USB cable. Could you run dmesg -w and then plug in the USB cable? Then post the new output.
On 2022-04-24 21:12, Mark Petersen wrote:
On Thursday, April 21, 2022 5:03:34 PM CDT Per Inge Oestmoen wrote:
Hello.
I use openSUSE Leap 15.3. Trouble is, when I attach USB sticks from 16-128 GB there are no problems. They are mounted and read immediately upon being attached.
When I attach large external USB disks, there is a different story. The disks most often do not show up. Sometimes they do, but most times I must read the disks (formatted with EXT4, FAT32 and EXFAT) on a Mac laptop in order to access them. Which, admittedly, makes me ashamed.
The question is why this happens.
To elucidate the problem, I have typed fdisk -l and dmesg, and the results are in the links below. I shall be extremely thankful if you can have a look at these outputs and see if you can spot the source of my problem. If these files do not provide a clue, please tell me what commands I should try next.
In both cases, an external disk was attached. However, the system failed to see it.
The fdisk -l output:
http://www.coldsiberia.net/technics/fdisk_l_21042022.txt
The dmesg output:
http://www.coldsiberia.net/technics/dmesg_21042022.txt
Sincerely, Per Inge Oestmoen, Norway
The dmesg you have provided does not show you plugging in the USB cable. Could you run dmesg -w and then plug in the USB cable? Then post the new output.
He did already. https://lists.opensuse.org/archives/list/users@lists.opensuse.org/message/KO... -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Not sure if that is somehow related, but I do have some external SSD cases that behave weird: They often (not always, but most of the time) need very long (30s to a minute) to actually show up on the USB bus after being plugged in. I cannot really find anything going on during that wait time, kernel log is silent. They tend to come up properly (i.e.: right away) when connected via a powered hub. Maybe try that (if you have one)?
Hello,
In the Message;
Subject : Re: External USB disks not recognized - Leap 15.3
Message-ID :
The problem has been solved! First; thank you very much to all who have responded. It turned out to be the external docking station which created the hardware problem. I naturally assumed that the operating system or the USB port was the culprit, because Mac OS X has no problem with finding the disk whereas openSUSE Leap 15.3 almost always fails to see the disk. Now it turns out that the docking station to the left in this picture does not work with Leap 15.3, even if it works beautifully in OS X. The thing is that the one that does not work in Leap 15.3 is a twin station, whereas the one that works is a single station as this picture illustrates: http://www.coldsiberia.net/technics/docking_station_nonfunctional_functional... Anyone who has experienced a similar problem? It is definitely noteworthy, and the next question is whether it is possible to make this work in Leap. Per Inge Oestmoen, Norway
On 2022-04-27 13:36, Per Inge Oestmoen wrote:
The problem has been solved!
First; thank you very much to all who have responded.
It turned out to be the external docking station which created the hardware problem.
I naturally assumed that the operating system or the USB port was the culprit, because Mac OS X has no problem with finding the disk whereas openSUSE Leap 15.3 almost always fails to see the disk.
Now it turns out that the docking station to the left in this picture does not work with Leap 15.3, even if it works beautifully in OS X. The thing is that the one that does not work in Leap 15.3 is a twin station, whereas the one that works is a single station as this picture illustrates:
Did you try both receptacles? source or target?
http://www.coldsiberia.net/technics/docking_station_nonfunctional_functional...
Anyone who has experienced a similar problem? It is definitely noteworthy, and the next question is whether it is possible to make this work in Leap.
What brand? I had recently problems with a Conceptronics docking station. I partitioned a 6 TB hard disk, filled it with data, but it was unreadable when the disk was connected directly to the SATA bus or to other USB-SATA converters. It used a different layout. Single disk, never tried a double station, I don't have one. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2022-04-27 13:36, Per Inge Oestmoen wrote:
The problem has been solved! First; thank you very much to all who have responded. It turned out to be the external docking station which created the hardware problem. I naturally assumed that the operating system or the USB port was the culprit, because Mac OS X has no problem with finding the disk whereas openSUSE Leap 15.3 almost always fails to see the disk. Now it turns out that the docking station to the left in this picture does not work with Leap 15.3, even if it works beautifully in OS X. The thing is that the one that does not work in Leap 15.3 is a twin station, whereas the one that works is a single station as this picture illustrates:
Did you try both receptacles? source or target?
Yes, I tried both. The same result, to no avail.
http://www.coldsiberia.net/technics/docking_station_nonfunctional_functional...
[...]
What brand?
This is ICY BOX. It is among the more expensive.
I had recently problems with a Conceptronics docking station. I partitioned a 6 TB hard disk, filled it with data, but it was unreadable when the disk was connected directly to the SATA bus or to other USB-SATA converters. It used a different layout.
Single disk, never tried a double station, I don't have one.
It dawns on me that I have to buy more single disk stations. Per Inge Oestmoen, Norway
On 2022-04-27 15:14, Per Inge Oestmoen wrote:
Carlos E. R. wrote:
On 2022-04-27 13:36, Per Inge Oestmoen wrote:
The problem has been solved! First; thank you very much to all who have responded. It turned out to be the external docking station which created the hardware problem. I naturally assumed that the operating system or the USB port was the culprit, because Mac OS X has no problem with finding the disk whereas openSUSE Leap 15.3 almost always fails to see the disk. Now it turns out that the docking station to the left in this picture does not work with Leap 15.3, even if it works beautifully in OS X. The thing is that the one that does not work in Leap 15.3 is a twin station, whereas the one that works is a single station as this picture illustrates:
Did you try both receptacles? source or target?
Yes, I tried both. The same result, to no avail.
http://www.coldsiberia.net/technics/docking_station_nonfunctional_functional...
[...]
What brand?
This is ICY BOX. It is among the more expensive.
I had recently problems with a Conceptronics docking station. I partitioned a 6 TB hard disk, filled it with data, but it was unreadable when the disk was connected directly to the SATA bus or to other USB-SATA converters. It used a different layout.
Single disk, never tried a double station, I don't have one.
It dawns on me that I have to buy more single disk stations.
Also, you should report this in Bugzilla. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
On Wed, 27 Apr 2022 13:36:04 +0200
Per Inge Oestmoen
The problem has been solved!
First; thank you very much to all who have responded.
It turned out to be the external docking station which created the hardware problem.
I naturally assumed that the operating system or the USB port was the culprit, because Mac OS X has no problem with finding the disk whereas openSUSE Leap 15.3 almost always fails to see the disk.
Now it turns out that the docking station to the left in this picture does not work with Leap 15.3, even if it works beautifully in OS X. The thing is that the one that does not work in Leap 15.3 is a twin station, whereas the one that works is a single station as this picture illustrates:
http://www.coldsiberia.net/technics/docking_station_nonfunctional_functional...
Anyone who has experienced a similar problem? It is definitely noteworthy, and the next question is whether it is possible to make this work in Leap.
How is it powered? If it is via the USB cable then what's the power rating of the ports you use?
Per Inge Oestmoen, Norway
On 2022-04-27 18:26, Dave Howorth wrote:
On Wed, 27 Apr 2022 13:36:04 +0200 Per Inge Oestmoen <> wrote:
The problem has been solved!
First; thank you very much to all who have responded.
It turned out to be the external docking station which created the hardware problem.
I naturally assumed that the operating system or the USB port was the culprit, because Mac OS X has no problem with finding the disk whereas openSUSE Leap 15.3 almost always fails to see the disk.
Now it turns out that the docking station to the left in this picture does not work with Leap 15.3, even if it works beautifully in OS X. The thing is that the one that does not work in Leap 15.3 is a twin station, whereas the one that works is a single station as this picture illustrates:
http://www.coldsiberia.net/technics/docking_station_nonfunctional_functional...
Anyone who has experienced a similar problem? It is definitely noteworthy, and the next question is whether it is possible to make this work in Leap.
How is it powered? If it is via the USB cable then what's the power rating of the ports you use?
On another post he said external power supplies. Archived-At: https://lists.opensuse.org/archives/list/users@lists.opensuse.org/message/HX... -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
Dave Howorth wrote:
On Wed, 27 Apr 2022 13:36:04 +0200 Per Inge Oestmoen
wrote:
http://www.coldsiberia.net/technics/docking_station_nonfunctional_functional... Anyone who has experienced a similar problem? It is definitely noteworthy, and the next question is whether it is possible to make this work in Leap.
How is it powered? If it is via the USB cable then what's the power rating of the ports you use?
I should be more specific. Here is the model that does not work: https://www.computeruniverse.net/en/p/90439554 Here is the model that works: https://www.computeruniverse.net/en/p/90409285 As you can see, both use an external power supply. Per Inge Oestmoen, Norway
On Wed, 27 Apr 2022 20:33:14 +0200
Per Inge Oestmoen
Dave Howorth wrote:
On Wed, 27 Apr 2022 13:36:04 +0200 Per Inge Oestmoen
wrote: http://www.coldsiberia.net/technics/docking_station_nonfunctional_functional... Anyone who has experienced a similar problem? It is definitely noteworthy, and the next question is whether it is possible to make this work in Leap.
How is it powered? If it is via the USB cable then what's the power rating of the ports you use?
I should be more specific.
Here is the model that does not work:
It claims Linux compatibility, so what have they had to say about it not working? Just return it as not fit for purpose and get a refund if they don't provide a good answer.
Here is the model that works:
https://www.computeruniverse.net/en/p/90409285
As you can see, both use an external power supply.
Per Inge Oestmoen, Norway
Dave Howorth wrote:
On Wed, 27 Apr 2022 20:33:14 +0200 Per Inge Oestmoen
wrote:
I should be more specific. Here is the model that does not work: https://www.computeruniverse.net/en/p/90439554
It claims Linux compatibility, so what have they had to say about it not working? Just return it as not fit for purpose and get a refund if they don't provide a good answer.
It did not work with the very latest kernel, so it definitely is not Linux-compatible. Per Inge Oestmoen, Norway
Dave Howorth wrote:
On Wed, 27 Apr 2022 20:33:14 +0200 Per Inge Oestmoen
wrote:
I should be more specific. Here is the model that does not work: https://www.computeruniverse.net/en/p/90439554
It claims Linux compatibility, so what have they had to say about it not working? Just return it as not fit for purpose and get a refund if they don't provide a good answer.
New information: It seems that this particular docking station has a problematic construction and is not functional: https://forums.raspberrypi.com/viewtopic.php?t=269828 Per Inge Oestmoen, Norway
Peter Suetterlin wrote:
Not sure if that is somehow related, but I do have some external SSD cases that behave weird: They often (not always, but most of the time) need very long (30s to a minute) to actually show up on the USB bus after being plugged in. I cannot really find anything going on during that wait time, kernel log is silent. They tend to come up properly (i.e.: right away) when connected via a powered hub. Maybe try that (if you have one)?
It may be related. Sometimes the system finds the disk, but in most cases not. Per Inge Oestmoen
participants (8)
-
Carlos E. R.
-
Dave Howorth
-
Felix Miata
-
Mark Petersen
-
Masaru Nomiya
-
Payam Firouztala
-
Per Inge Oestmoen
-
Peter Suetterlin