On Oct 23, 2008, at 8:43 AM, Jeremy Chadwick wrote:

On Thu, Oct 23, 2008 at 08:12:38AM -0700, Chris Pratt wrote:
I have a server with 6 hot-swap SATA slots. It was delivered

I was thinking a right approach would be to change fstab to
reference ad2 for all the system disk file systems, shutdown,
move that drive to the first bay and plug the new drive into the
2nd bay. This seemed like more of a permanent solution.

This is the solution I go with, because it's obvious and doesn't add
more complexity to the picture.

If the installation was originally done when the disk was considered
ad4, for example, you should still be able to boot that drive (no matter
what port it's on, assuming SATA), choose single-user at the
beastie/loader menu, then make changes to /etc/fstab.  Upon reboot (in
multi-user mode) things should "just work", sans any programs which you
have that might refer to disks by device (e.g.  smartd.conf, etc.)

You can avoid the single-user step if you enjoy living dangerously.

It was sensed as ad4 and there wasn't an ad2 (which always made me
wonder though not enough to actually look into it). This is why I presumed if I placed the system disk in the first bay, it would be seen as / dev/ad2.
Single user and a console are the key here I can tell. No free lunch.

If those /dev/ad* files are created at boot dynamically,
this should work. I've found docs that imply that they are
dynamically discovered and created from FreeBSD 5 forward
(auto-discovery?). Are they or do I need to create them prior to
start up.

They are, and it's hard to explain why/how.

The "dynamic" aspect is entirely dependent upon different features/ modes
of the ATA configuration though.  For example, a SATA controller
operating in "Legacy/Compatible" mode might show two SATA disks as
ata0-master and ata0-slave (even though they're SATA); the same
controller in "Enhanced" mode might show the disks as ata4-master
and ata5-master; the same controller in AHCI mode might show the disks
as ata8-master and ata10-master.

I think some people deal with this problem using glabel(8), but as I
mentioned, I prefer to do things the old-fashioned way.

I see why a simple answer doesn't pop out on searching. Too many
possible configurations and results vary with each. This driver appears
to enumerate the bays as ad2 (hoping), ad4, 6, 8, 10, and 12. The
device minor numbers seemed they must have been created on the fly
since acd0 is 79, ad4 is presently 80, ad6, 8, 10, and 12 are 81 through
84 respectively.

The thing is, there is no easy recovery from failure here since I
have no console monitor to let me see what's going on or to fix
fstab if it fails (counter-intuitively, the only place I can access
the console is from remote locations ;-)), so I just want to know
if I'm thinking straight?

See bottom of my mail.

The plan is:

1. Change /etc/fstab entries for ad4 filesystems to ad2
2. Shutdown
3. Put the system disk in Bay 1
4. Power up

Should it boot?

How certain are you that "bay 1" correlates with ad4?  That's the real
question here.

I think I see your point, the second bay may not be the system disk.
Getting a console sounds like it's necessary. I didn't really explain that.
It's not a co-locate, but a business's server room with 10 servers all
connected to a KVM. The KVM is reachable only from certain IPs. The
local monitor is fried and I have no spares. You caught me in laziness
here. I need to haul a monitor with me and I can more safely do this
switch. Seeing what's happening at boot will tell me if the above
assumptions are valid and how to proceed. I think you implied that
you move the disk first, boot and see what we end up with. It
eliminates numerous questions and allows a recoverable process. I'll
get a real console on it. This also means I can use a live CD disk
if necessary.

You obviously have *some* form of access to the machine physically --
or, your co-location provider is offering "remote hands" capability.
If you're with a co-lo provider who doesn't offer this capability,
consider switching to one who does.  There is absolutely no reason
to accept lack-of remote management in this day and age.

Thanks for your reply. As always, you give a lot of thought to your
responses. I'll study some of this you've mentioned to see if I can
understand how the devices are created for my specific setups on
all the servers. It's always quite fuzzy to me.

| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |

freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to