# special device /dev/sdb1 does not exist

## luna80

I don't understand why my usb hard disk doesn't mount automatically on boot

this is my /etc/fstab and the log of dmesg

```
/dev/nvme0n1p2      /boot         vfat      auto,noatime      1 2 

/dev/nvme0n1p3      none         swap      sw         0 0 

/dev/nvme0n1p4      /         ext4      noatime         0 1 

/dev/sda1      /mnt/data      ext4      auto,noatime,user   0 1 

/dev/sdb1      /mnt/mybook      ext4      auto,noatime,user   0 1 

/dev/sdc1      /mnt/mybookduo      auto      auto,noatime,user   0 1 
```

```
[    2.791477] sd 6:0:0:0: [sdb] Spinning up disk... 

[   12.006411] sd 6:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16). 

[   12.006658] sd 6:0:0:0: [sdb] 7813969920 512-byte logical blocks: (4.00 TB/3.64 TiB) 

[   12.006662] sd 6:0:0:0: [sdb] 4096-byte physical blocks 

[   12.007231] sd 6:0:0:0: [sdb] Write Protect is off 

[   12.007235] sd 6:0:0:0: [sdb] Mode Sense: 47 00 10 08 

[   12.007511] sd 6:0:0:0: [sdb] No Caching mode page found 

[   12.007515] sd 6:0:0:0: [sdb] Assuming drive cache: write through 

[   12.057037]  sdb: sdb1 

[   12.057903] sd 6:0:0:0: [sdb] Attached SCSI dis 

```

during the boot I get the error "special device /dev/sdb1 does not exist" but after login I can mount it manually without problem, and it works when I reboot too (not if I turn off the computer)

some udev problem?

thanks a lot in advance   :Smile: 

----------

## NeddySeagoon

luna80,

I suspect that the localmount service runs before the drive has spun up when you do a cold boot.

/dev/sdb1 will not exist until the drive becomes ready. That means that it has spun up the platters and done its internal self tests.  

We can see that it takes 

```
[   12.057037]  sdb: sdb1 
```

just over 12 seconds.

What happens if you power up the drive, wait 15 seconds, so the drive is ready, then boot?

I suspect that will work.

If that's the problem, there are several workarounds.

----------

## luna80

 *NeddySeagoon wrote:*   

> 
> 
> What happens if you power up the drive, wait 15 seconds, so the drive is ready, then boot?

 

no, it doesn't works, same problem

thanks

----------

## Anon-E-moose

I have that problem too, with some of my external usb raid enclosures.

If I cold boot the system, it takes a while for the usb drives to be recognized. NOTE: the main system is cold booted, the usb raid enclosures never power down.

I've never investigated it too much since the system is up most of the time (24x7) but if I have to power it off to replace something then I notice it.

If I hot reboot (shutdown -r ...) it works perfectly fine when it comes back up. 

It could be that that when the main system is powered down, the usb enclosure puts the disk into a sleep state and then it takes a while to wake up.

If that's the case, then I don't know what the fix would be, for early in the boot process.

But what I did for mine was to turn off automount in fstab and explicitly mount the drives in /etc/local.d/baselayout1.start, that seemed to work ok.

----------

## luna80

 *Anon-E-moose wrote:*   

> 
> 
> But what I did for mine was to turn off automount in fstab and explicitly mount the drives in /etc/local.d/baselayout1.start, that seemed to work ok.

 

thanks! this is a workaround that I thought but I'm more happy if I can solve the problem

----------

## NeddySeagoon

luna80,

Can you put the entire dmesg from a normal cold boot and from a cold boot where you power up the USB HDD 15 seconds before the system onto separate pastebins please?

Also your entire kernel .config file.

The idea I want to look at is that your USB subsystem is slow to get started.

The two different dmesg outputs will help confirm that and your kernel .config may suggest ways to improve it.

----------

## molletts

I'm not sure whether it affects USB devices or not but have you tried adding the udev-settle pseudoservice to the sysinit runlevel?

```
rc-update add udev-settle sysinit
```

I had to do this to ensure that the md-raid array on my home server was ready before localmount ran - the drives took just a little bit too long to be identified, scanned for partitions and assembled into the array.

(You could add an rc_need dependency on udev-settle to localmount instead, which might be a "neater" way of doing it, assuming it works at all.)

----------

## luna80

 *NeddySeagoon wrote:*   

> luna80,
> 
> Can you put the entire dmesg from a normal cold boot and from a cold boot where you power up the USB HDD 15 seconds before the system onto separate pastebins please?
> 
> Also your entire kernel .config file.
> ...

 

normal cold boot: https://pastebin.com/vPs2YmkT

15s cold boot: https://pastebin.com/ddSved7F

.config: https://pastebin.com/HxfkyNWm

many thanks for your help

----------

## NeddySeagoon

luna80,

There is a couple of surprises there.

First mention of /dev/sdb is 

```
[    2.793983] sd 6:0:0:0: Attached scsi generic sg2 type 0

[    2.794761] sd 6:0:0:0: [sdb] Spinning up disk...
```

It looks like a USB enclosure power on does not spin up the drive, it waits until the device is actually addressed.

```
[   12.009057] sd 6:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16).

[   12.194830] sd 6:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16).
```

both times are about 12 seconds.

So it really takes 10 seconds for the drive to spin up

You have your USB Storage built into the kernel too.

Turning on 

```
# CONFIG_USB_UAS is not set
```

 is harmless and will give you overlapping commands and other good things for USB storage devices.

Its USB 3 only and your hardware has to support it end to end.

You are doing all the right things. Mounting from fstab fails because localmount has completed before the /dev entry is created by the kernels DEVTMPFS

There are several things you can do. All involve a delay for the drive to spin up

There is the /etc/local.d/sdb.start script, which way need something like 

```
sleep 12
```

 so it doesn't run too fast too. It will not delay the rest of booting but you won't get the login prompt until the local service completes. You are using that now. 

You can add rootdelay=12 to your kernel command line. This is abuse of rootdelay, which is intended to provide a pause before the kernel mounts root because its on some slow media.

The whole boot process will be delayed by 12 seconds but your sdb will spin up in that time as the USB code is built into the kernel.

You can add 

```
sleep 12
```

 into the top of the start () function in /etc/init.d/localmount.

This gets you a 12 second delay before localmount runs. 

You can't beat the spinup time. I was trying to move it outside the boot process.

----------

## luna80

thanks NeddySeagoon,

set CONFIG_USB_UAS in the kernel doesn't help me but I enabled it as you suggested me.

I created a script in /etc/local.d with the sleep (of 5s, so it's work) and now it works, it's a good workaround I think, 

I would have preferred to find another solution but the important it's that now it works

many many thanks!!   :Very Happy: 

```
#!/bin/bash

sleep 5

mount /dev/sdb1 /mnt/mybook

```

----------

## Anon-E-moose

I'm curious what does smartctl -A /dev/sdb return (need to be root to run), that is if you have smartmontools installed.

----------

## NeddySeagoon

Anon-E-moose,

Smartmontools will hate the USB/SATA bridge.

luna80,

USB Attached SCSI (UAS) adds extra commands for USB block devices and does not need to use bulk transfer mode.

It makes data transfers faster but it can't change the laws of physics. If your HDD takes 10 seconds to spin up, it takes 10 seconds.

Fitting a different HDD spin motor is not really an option :)

----------

## Anon-E-moose

 *NeddySeagoon wrote:*   

> Anon-E-moose,
> 
> Smartmontools will hate the USB/SATA bridge.
> 
> 

 

Sometimes, I have several usb to sata chipsets that will work with it and one that doesn't, sometimes it needs a device type set though.

Look at man pages "-d TYPE, --device=TYPE" option for several flavors of device types.

lsusb can tell what type usb chipset, and then he could try.

Edit to add: -d sat works on a surprising number of them, at least among those I own.

----------

