Date: Sun, 29 Jan 2006 19:34:37 +0100 (CET) From: Christian Baer <christian.baer@informatik.uni-dortmund.de> To: freebsd-stable@freebsd.org Subject: Have the device names for hard discs been changed? Message-ID: <drj1rt$1ouq$3@nermal.rz1.convenimus.net>
next in thread | raw e-mail | index | archive | help
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".
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?drj1rt$1ouq$3>