From owner-freebsd-stable@FreeBSD.ORG Sun Jan 29 18:40:18 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4776516A420 for ; Sun, 29 Jan 2006 18:40:18 +0000 (GMT) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9F6843D45 for ; Sun, 29 Jan 2006 18:40:17 +0000 (GMT) (envelope-from freebsd-stable@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1F3HTC-0006py-5G for freebsd-stable@freebsd.org; Sun, 29 Jan 2006 19:40:14 +0100 Received: from p508c1476.dip0.t-ipconnect.de ([80.140.20.118]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 29 Jan 2006 19:40:14 +0100 Received: from christian.baer by p508c1476.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 29 Jan 2006 19:40:14 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Christian Baer Date: Sun, 29 Jan 2006 19:34:37 +0100 (CET) Organization: Convenimus Projekt Lines: 115 Message-ID: X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: p508c1476.dip0.t-ipconnect.de User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: Have the device names for hard discs been changed? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2006 18:40:18 -0000 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".