USB Disk Missing Partitions

B

babler

Hello, Really stumped here; I have a pair of identical external hard drives on a notebook, and when I turn the drive on, while the system is up, it identifies it as da1 but the partitions are not created in /dev. If I reboot the system the drive partitions show up, are mountable and have no problems.

My intent is to turn on the second disk for backup/synchronization weekly, but I don't want to have to reboot every time I want to run rsync. I am hoping I am just missing a kernel option. I do have all the items listed in the manual and, like I said, it does work when the disk is present at boot.

Any ideas? and Thanks!


Logged to syslog when disk is powered up
Code: 
########################################
ugen3.5: <DMI> at usbus3
umass1: <Bulk Only Interface> on usbus3
umass1:  SCSI over Bulk-Only; quirks = 0x0000
umass1:1:1:-1: Attached to scbus1
da1 at umass-sim1 bus 1 scbus1 target 0 lun 0
da1: <  > Fixed Direct Access SCSI-2 device
da1: 40.000MB/s transfers
da1: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
 
yep, that was my last ditch before I posted this morning. no luck.

It is a ufs partition that I created in an earlier version (7.1 I think?) I was worried that was the issue, a problem with the partition table, but I was able to sync about 300gb of data after booting with the disk there so, I am guessing it is more of a USB issue.

But thanks!
 
I don't know if the following does the same thing as

[cmd=""]camcontrol rescan all[/cmd]

but it's also worth trying.

[cmd=""]dd if=/dev/null of=/dev/da0 count=0[/cmd]

It's safe.

More information at mailing list.

Note: replace /dev/da0 with device name the unrecognizable drive appears.
 
Unplugging and plugging it back in gives me the same result. It will remove the da1 device and recreate it after it is plugged back in and powered on.

I am curious what dd would do? da0 already exists and I am able to mount its partition. (that is the drive I am trying to backup) wouldn't that kill the da0 partition?
 
babler said:
I am curious what dd would do? da0 already exists and I am able to mount its partition. (that is the drive I am trying to backup) wouldn't that kill the da0 partition?
Click to expand...
I've seen it recommended here a few times. It should not harm the device since the count is null, in other words it's not writing anything. The explanation of what it does is in the mailing list message linked earlier by pbd:
when you open the raw device for _writing_ (as the
proposed dd command does), then it is possible that the
partition table has changed, so devfs looks at it (actually
the GEOM code, I think), detects the new partitons, and
creates nodes in /dev.
Click to expand...
 
I was a little skeptical about dd, but after reading seems, that was a work around for a while (still not sure if it is fixed in 8.1). It fits the symptoms but didn't fix my problem. I did run it as;
Code: 
[root@Tibas /home/me]# dd if=/dev/null of=/dev/da1 count=0
0+0 records in
0+0 records out
0 bytes transferred in 0.000019 secs (0 bytes/sec)

Can't run it on da0 because it is mounted.
Thanks to each of ya, any other thoughts? Everything seems to work just fine if I boot with it on.
 
# true > /dev/da1

is another way. true(1) is shorter and might be marginally safer, but they both make me nervous.

It's possible that the MBR or label was overwritten and devfs is working correctly.

% fdisk da1
% bsdlabel da1
ought to show what is really on the disk, regardless of what devfs is showing.
 
yikes! So I think I killed my table.. maybe? A little background this drive pair was /home and its backup in a previous install and I have not got it working since upgrading to 8.1 - or reinstalling. (during that process I upgraded my BIOS)

So with that said, did I overwrite my labels? I guess.. since it functioned when it was present on boot I didn't think that would be the case.

My output from the two commands powering the disk on after booted is;
Code: 
[root@Tibas /home/me]# fdisk da1
******* Working on device /dev/da1 *******
parameters extracted from in-core disklabel are:
cylinders=121601 heads=255 sectors/track=63 (16065 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=121601 heads=255 sectors/track=63 (16065 blks/cyl)

fdisk: invalid fdisk partition table found
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 63, size 1953520002 (953867 Meg), flag 80 (active)
        beg: cyl 0/ head 1/ sector 1;
        end: cyl 768/ head 254/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>
[root@Tibas /home/me]# bsdlabel /dev/da1
bsdlabel: /dev/da1: no valid label found

And if I power the disk on before booting (when I am able to mount read and write to it);
Code: 
[root@Tibas /home/me]# fdisk da1
******* Working on device /dev/da1 *******
parameters extracted from in-core disklabel are:
cylinders=121601 heads=255 sectors/track=63 (16065 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=121601 heads=255 sectors/track=63 (16065 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 63, size 1953520002 (953867 Meg), flag 80 (active)
        beg: cyl 0/ head 1/ sector 1;
        end: cyl 1023/ head 254/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>
[root@Tibas /home/me]# bsdlabel /dev/da1
bsdlabel: /dev/da1: no valid label found

So at this point my post seems to be in the wrong place, but it looks as though there is a problem with my labels. I am a little curiouse why fdisk reports
Code: 
invalid fdisk partition table found
when the drive is not mountable but does not when the drive is mountable. And I am surprised the slices show up at all with out a table, but is there a way to correct this?

It is just a backup drive so I think I can wipe it and it will be fine, but I am curious as to if it would be recoverable since I can read and write to it - and access all the data. If there is no table, how is the data addressable? Any ideas?
 
Wiping out the MBR or label is not that easy, unless you actively try to while being logged in as root.

How did you create the slices/partitions in the beginning and what tools did you use?

Did you make the disk "dangerously dedicated", i.e. without an fdisk slice (e.g. da0s1) and with partitions written directly to the device (e.g. da0a)?
 
I want to say this disk as seen two(?) installs, but the original partition was created during a clean installation. It wasn't dangerously dedicated, the partition that exists is da1s1d.

I was concerned I did it during the 8.1 install. If I recall I set the mount point but did not toggle a new fs, but that was my concern anyway...

I don't know enough about the partitioning of the disk and I am going to do some reading here, but it still doesn't make sense to me bsdlabel says there is not one, when it creates the slice devices. I guess, I am also not ruling out it is just not reading it correctly (i.e. USB issues), but I would much rather fix it then wipe it. ...just cuz.

Any thoughts or suggested reading are welcomed! man bsdlabel is where I am headed.
 
babler said:
but it still doesn't make sense to me bsdlabel says there is not one, when it creates the slice devices.
Click to expand...

Slices are MS-DOS partitions, and come from the MBR. So da1s1 is reasonable based on the fdisk output. The label gives the FreeBSD "partition" letters, da1s1a, b, and so on. It says there's no label, and no /dev/da1s1x partitions are created.

I guess, I am also not ruling out it is just not reading it correctly (i.e. USB issues), but I would much rather fix it then wipe it.
Click to expand...

The "fdisk: invalid fdisk partition table found" makes me think there is something not quite right in USB system on the drive, that it's reporting ready before the drive is really ready. That would also explain why turning it on earlier makes it work, and why "retasting" with a zero-byte write to the device finds a valid MBR. I suspect if you turn it on but wait for a bit before attaching it, it will be detected correctly.
 
The v7 devices missing in v8 device detection can probably be
solved with the
geom_bsd.ko, geom_mbr.ko and geom_label.ko. in /boot/loader.conf.
( What I would post if it were ad0 vs da0 anyway, and other
muddying factors (sata vs ide vs scsi ...) (usb vs sata...) too
complex to conjecture about on my part.) (Other threads referencing those drivers are many.)
 
babler said:
I am curious what dd would do? da0 already exists and I am able to mount its partition. (that is the drive I am trying to backup)
Click to expand...

Sorry, I meant to run it on /dev/da1 or whatever device the unrecognizable drive appears.
 
pdb: Thanks, I figured that out, but was not sure what writing a cout of 0 would do

wblock: Thank you also, that made allot of sense. When I tried powering the drive for a minute before pluging it in it didn't work and it failed to detect the da1 device at all. so I tried it again, out of curiosity, and it did work. But I have not been able to get it to work a second time since.

jb fwvm2: And thanks to you too, the idea that there is a module missing is much more appealing to me then the usb hardware is failing. I tried loading the 3 modules you specified, but between google and the other forums, I found many places where it was loaded but it seems like a hit or miss fix and I couldn't find much on their purpose. It is an SATA USB disk, do you know if there is another module needed or someplace I could read up a bit on what they, and the other geom drivers do?
 
Only confusion on my part about whether I will ever de-include those three drivers (GPT vs geom vs...)... reading posts and freebsd-questions messages about the old VS new stuff weekly. BTW v9 may include a new ( 3 > 1 ) usb 3.0 driver; One can also read the official realease_Notes for v8, v9...; Further, maybe the sata driver name(s) changed between v7, v8...
 
Be careful, yesterday I found corrupted the contents of an Iomega USB while using automounter in FreeBSD. An 80 GB disk running w/o a glitch for the last ¿six, eight, ten years?, I do not remember. Hundreds or thousands of family & friend pictures lost.
 
Martillo1 said:
Be careful, yesterday I found corrupted the contents of an Iomega USB while using automounter in FreeBSD. An 80 GB disk running w/o a glitch for the last ¿six, eight, ten years?, I do not remember. Hundreds or thousands of family & friend pictures lost.
Click to expand...

You can try sysutils/testdisk to rescue the pictures, if you don't have backup.
 
You must log in or register to reply here.
Back
Top