Hello *!
I am experiencing a very annoying problem when trying to (re-) install
hard drives. This problem has already been described in *.questions and
in two newsgroups (German and English) but sofar I got no response at
all. Now I think it might be because of a change in policy or even a bug.
What happened is this:
I set up a new (private) server, removed all the hard drives from the
old one and installed these drives and one new drive in the new server.
The old server was running 4.11-STABLE, I installed 6.0-RELEASE on the
new one and kept it up to date with cvsup. That was the easy part.
Since the default file system in 6 is UFS2 and I wanted to encrypt a few
of the file systems with gbde or geli, I decided to empty one drive
after the other, create new slices, partitions and file systems on the
drives, copy the data back on the drives and - while I'm at it - clean
up the data itself. :-)
When I installed new drives (ad0, which is the boot drive and ad8 which
is the new one), I created a new slice (dd-mode[1]) and new partition(s)
without any problems. I did notice that the letter for a single
partition changed from 'e' to 'd'. So a drive containing only a
single
file system now is /dev/adxs1d[2].
The problems began with a 160GB Samsung drive (SP1614N). I copied the
files off the drive and tested a few of them - just to be sure. Then I
decided to erase the drive completely, as it was destined to be
encrypted and I didn't want any unencrypted data left on it. So I did a
dd if=/dev/urandom of=/dev/ad6 bs=1024K
After that I started sysinstall and created a new slice and a new
partition which sysinstall called /dev/ad6s1d - which I expected. But
after creating the partition, the mount failed, because "no such file or
directory". And sure enough, ad6s1d did not exist in /dev/:
jon# ls -l /dev/ad6*
crw-r----- 1 root operator 0, 76 Jan 22 15:23 /dev/ad6
crw-r----- 1 root operator 0, 93 Jan 22 15:00 /dev/ad6c
crw-r----- 1 root operator 0, 96 Jan 22 15:00 /dev/ad6cs1
crw-r----- 1 root operator 0, 92 Jan 22 15:00 /dev/ad6s1
crw-r----- 1 root operator 0, 94 Jan 22 15:00 /dev/ad6s1c
These devices look a bit like those of a drive with a "true"
partition-table (so Wintendo can read it). I can't really check that now
because I have no computer with such an installation. However, even if
this *were* so, I have checked and rechecked, the drive is definately
dangerously dedicated - or at least, it should be. None of the other
drives show these devices:
crw-r----- 1 root operator 0, 73 Jan 22 16:20 /dev/ad0
crw-r----- 1 root operator 0, 79 Jan 22 16:20 /dev/ad0s1
crw-r----- 1 root operator 0, 100 Jan 22 16:20 /dev/ad0s1a
crw-r----- 1 root operator 0, 101 Jan 22 16:20 /dev/ad0s1b
crw-r----- 1 root operator 0, 102 Jan 22 16:20 /dev/ad0s1c
crw-r----- 1 root operator 0, 103 Jan 22 16:20 /dev/ad0s1d
crw-r----- 1 root operator 0, 104 Jan 22 16:20 /dev/ad0s1e
crw-r----- 1 root operator 0, 105 Jan 22 16:20 /dev/ad0s1f
crw-r----- 1 root operator 0, 106 Jan 22 16:20 /dev/ad0s1g
crw-r----- 1 root operator 0, 78 Jan 22 16:20 /dev/ad12
crw-r----- 1 root operator 0, 97 Jan 22 16:20 /dev/ad12s1
crw-r----- 1 root operator 0, 121 Jan 22 16:20 /dev/ad12s1c
crw-r----- 1 root operator 0, 122 Jan 22 16:20 /dev/ad12s1e
crw-r----- 1 root operator 0, 74 Jan 22 16:20 /dev/ad2
crw-r----- 1 root operator 0, 87 Jan 22 16:20 /dev/ad2s1
crw-r----- 1 root operator 0, 109 Jan 22 16:20 /dev/ad2s1c
crw-r----- 1 root operator 0, 110 Jan 22 16:20 /dev/ad2s1e
crw-r----- 1 root operator 0, 75 Jan 22 16:20 /dev/ad4
crw-r----- 1 root operator 0, 90 Jan 22 16:20 /dev/ad4s1
crw-r----- 1 root operator 0, 113 Jan 22 16:20 /dev/ad4s1c
crw-r----- 1 root operator 0, 114 Jan 22 16:20 /dev/ad4s1d
crw-r----- 1 root operator 0, 77 Jan 22 16:20 /dev/ad8
crw-r----- 1 root operator 0, 94 Jan 22 16:20 /dev/ad8s1
crw-r----- 1 root operator 0, 117 Jan 22 16:20 /dev/ad8s1c
crw-r----- 1 root operator 0, 118 Jan 22 16:20 /dev/ad8s1d
The drives ad2 and ad12 are still unchanged from the last installation
and therefore are still USF1 formatted.
There were three changes since I installed the USF2-drives:
- I did a cvsup and made a new world.
- ACPI didn't seem to work to well with this mainboard[3], so I
deactivated
it in the board's BIOS. This led to a few error-messages during
booting but that seems to be more of a "cosmetic" problem. I
don't
really believe this is the cause though, because I turned ACPI back on
and got the same results.
- I added 'options GEOM_BDE' to the kernel-config. But I have already
removed this to test further.
Also there are two additional ATA-controllers in the computer. Both are
promise: PDC20268 (for ad4 and ad6) and PDC20775 (for ad8 and ad12). The
other two drives are connected to the southbridge.
As far as I can tell, creating a file system on ad6s1c works fine.
Mounting it works too, aswell as read and write operations.
My beasic question now is:
Where did I mess up? :-) Is it normal for the devices to have different
names? Did I mess up at all? Is this some new policy or a bug?
Regards,
Chris
[1] Since only FreeBSD will ever touch this computer, all the drives are
dd-mode
[2] Is there some text out there explaining these last letters? What are
the first three letters (a-c) reserved for? The handbook seems to be
a little out of date.
[3] The computer would hand up during a shutdown. The last message
always was "shutting down ACPI" and hence had to be rebooted via a
hard-reset, which is a bit of a pain since the computer is nowhere
near anything you could call "workspace".