Help moving a system from a SATA, to a PATA drive. Please.

Chris_H

Chris_H

Greetings,
Yeah. I know... why would I want to move from SATA to PATA?!
Fair enough. This is actually part 1, of a 2 part process to move the entire system to completely new hardware. But the current SATA drive will be used in the new system. So before I wipe it, I need to move the data to a PATA temporarily. So the old system will continue to serve. While the new system is being built. Basically; I want to hijack the SATA drive from a working system.

OK. Here's my plan. I don't need to do things like this very often, so I'm always hard pressed to remember all the details. But strangely, @wblock@ seems to know that, and always has just the documentation I need, to accomplish the task:
Disk Setup on FreeBSD - http://www.wonkity.com/~wblock/docs/html/disksetup.html
and
Backup Options for FreeBSD - http://www.wonkity.com/~wblock/docs/html/backup.html
Thank you, @wblock@! :)

Now following the Formatting section; I intend to drop the old box, then plug the PATA drive in, then start it back up confirming/tweaking the BIOS settings, as necessary to run with the added drive properly. Then, while the system is Live, and in MultiUser mode; I'll wipe the PATA, then reslice, and format it with the same number, and named slices:
Code: 
swap
/
/usr
/var
As I write this, I have no idea what the device name(s) will actually be. In fact, I'm a bit confused by the (drive) device names it currently uses:
Code: 
/dev/ad4s1a    /
/dev/ad4s1b    <swap>
/dev/ad4s1e    /usr
/dev/ad4s1d    /var
point being; I have the SATA drive plugged into port 1. Yet (unintuitively) it uses ad4s1*
Shouldn't that be 1, not a 4?
Anyway. After booting the system with the added PATA drive, I'll format it thusly:
Code: 
#
# Currently MBR, but will be GPT in the new system
#
gpart destroy -F <PataDeviceName>

gpart create -s mbr <PataDeviceName>

gpart bootcode -b /boot/mbr <PataDeviceName>

gpart add -t freebsd <PataDeviceName>

# Mark it active, so it'll be bootable when I bounce it using this drive only
gpart set -a active -i 1 <PataDeviceName>

# Create a bootable slice
gpart create -s bsd <PataDeviveName>s1

# Install the bootcode
gpart bootcode -b /boot/boot <PataDeviceName>s1

# Create /
gpart add -t freebsd-ufs -s 3g <PataDeviceName>s1

# Create <swap>
gpart add -t freebsd-swap -s 3g <PataDeviceName>s1

# Create /var
gpart add -t freebsd-ufs  -s 4g <PataDeviceName>s1

# Create /usr
gpart add -t freebsd-ufs <PataDeviceName>s1
OK. So far, so good. Now it's time to format them (newfs())
Code: 
# NOTE soft updates enabled on all slices
# Format /
newfs -U /dev/<PataDeviceName>s1a

# Format /var
newfs -U /dev/<PataDeviceName>s1d

# Format /usr
newfs -U /dev/<PataDeviceName>s1e
OK. So far, so good.
At this point I'm wondering if all of this will be OK to perform on a Live system in MultiUser mode.
Also, will following the strategy listed under:
Copying Filesystems
in http://www.wonkity.com/~wblock/docs/html/backup.html (Backup Options for FreeBSD)
also be OK on a live system, like this?

Thank you very much, for all your time, and consideration.

--Chris
 
Last edited by a moderator:
Re: Help moving a system from a Sata, to a Pata drive. Pleas

The old disk drivers (ad(4)) used static device numbering. The number assigned to the drive depended on the port where it was connected.

The new drivers (ada(4)) use dynamic device numbering. The first drive found is ada0 and the second is ada1, regardless of the port.

Either way, do not copy filesystems until you have a full backup. It is just to easy to get drives mixed up and overwrite the wrong one.

This is an ideal time to switch to GPT partitioning to get away from the silliness that is MBR and BSDlabel partitioning, partitions inside a partition. That assumes you have a motherboard with a decent BIOS, but most do.

Thanks to filesystem snapshots, a live filesystem can be backed up or copied with dump(8). However, any changes made after the snapshot will not be included. The easiest way to avoid that is to do it without users, but there are other after-the-fact things like rsync(1) that can be used to fix up the differences. The differences may not even matter. It depends on what the system is doing.
 
Re: Help moving a system from a Sata, to a Pata drive. Pleas

I'm not sure about the process of duplicating the drive, I'll let @wblock@ (or someone else) comment on that. ;)

Regarding the ad4 SATA device. With the old ad devices, the numbers were/are tied to a port. Traditionally motherboards had 2 PATA ports, each which could support a master and slave drive. The master on port 1 would be ad0, slave ad1 and so on (up to the second port slave on ad3). If you only plugged a drive into the second port as master, you would just have an ad2 device. For boards that also had SATA, this means that the first SATA disk would be ad4. Because SATA has no concept of master/slave, they are always treated as a master and so further SATA disks would show as ad6, ad8, etc.

On newer boards with no PATA, I believe the first SATA disk does actually appear as ad0 although it's not something I've taken any notice of for a long time so I may be wrong.

In recent FreeBSD versions, SATA disks appear as adaX devices, and these are always numbered staring from 0, in the order they are found. The first disk will be ada0 regardless of the physical port used, the second ada1 and so on. (Unfortunately this means a disk can change its device number these days after a reboot even if it hasn't moved if the disks before it change)

Edit - was beaten to it but I've still submitted the post as I've explained how the PATA ports cause the first SATA device to be ad4
 
Last edited by a moderator:
Re: Help moving a system from a Sata, to a Pata drive. Pleas

wblock@ said:
The old disk drivers (ad(4)) used static device numbering. The number assigned to the drive depended on the port where it was connected.

The new drivers (ada(4)) use dynamic device numbering. The first drive found is ada0 and the second is ada1, regardless of the port.
Click to expand...
Weird. Aside from the DVD-RW, the SATA drive is the only thing attached.

wblock@ said:
Either way, do not copy filesystems until you have a full backup. It is just to easy to get drives mixed up and overwrite the wrong one.

This is an ideal time to switch to GPT partitioning to get away from the silliness that is MBR and BSDlabel partitioning, partitions inside a partition. That assumes you have a motherboard with a decent BIOS, but most do.
Click to expand...
Of course. I mentioned I'd be using GPT on the new system I'm replacing this one with -- the one the SATA platter will be going into, after I back it up. I'm only duplicating the currently running setup. So I'm using MBR on the PATA (temporary).

wblock@ said:
Thanks to filesystem snapshots, a live filesystem can be backed up or copied with dump(8). However, any changes made after the snapshot will not be included. The easiest way to avoid that is to do it without users, but there are other after-the-fact things like rsync(1) that can be used to fix up the differences. The differences may not even matter. It depends on what the system is doing.
Click to expand...
Not terribly concerned here. Anything added won't be missed. It's a pretty fast system, and I don't anticipate the dump() && restore() process to take very long with the right switches used (increased buffering, ...).

Thank you, as always @wblock@, for your unending wealth of knowledge, and support. :beer :beer

--Chris
 
Last edited by a moderator:
Re: Help moving a system from a Sata, to a Pata drive. Pleas

usdmatt said:
I'm not sure about the process of duplicating the drive, I'll let @wblock@ (or someone else) comment on that. ;)

Regarding the ad4 SATA device. With the old ad devices, the numbers were/are tied to a port. Traditionally motherboards had 2 PATA ports, each which could support a master and slave drive. The master on port 1 would be ad0, slave ad1 and so on (up to the second port slave on ad3). If you only plugged a drive into the second port as master, you would just have an ad2 device. For boards that also had SATA, this means that the first SATA disk would be ad4.
Click to expand...

Ahh. Of course. I should have known better myself.

usdmatt said:
Because SATA has no concept of master/slave, they are always treated as a master and so further SATA disks would show as ad6, ad8, etc.

On newer boards with no PATA, I believe the first SATA disk does actually appear as ad0 although it's not something I've taken any notice of for a long time so I may be wrong.

In recent FreeBSD versions, SATA disks appear as adaX devices, and these are always numbered staring from 0, in the order they are found. The first disk will be ada0 regardless of the physical port used, the second ada1 and so on. (Unfortunately this means a disk can change its device number these days after a reboot even if it hasn't moved if the disks before it change)

Edit - was beaten to it but I've still submitted the post as I've explained how the PATA ports cause the first SATA device to be ad4
Click to expand...
Thank you @usdmatt, for taking the time to respond, (and spell it out for me). :)

--Chris
 
Last edited by a moderator:
Re: Help moving a system from a SATA, to a PATA drive. Pleas

Greetings,
Following along on @wblock@'s "Disk Setup on FreeBSD" (http://www.wonkity.com/~wblock/docs/html/disksetup.html)
Everything goes as anticipated, until I reach:
gpart create -s bsd ad1s1 (...create a bsdlabel partitioning scheme. Bootcode is needed here also.).
Attempts to do this return:
gpart: geom 'ad1s1' : File exists
What's wrong, and what command should I perform next?

Thank you for all your time, and consideration.

--Chris
 
Last edited by a moderator:
Re: Help moving a system from a SATA, to a PATA drive. Pleas

Bummer,
All attempts to gpart destroy -F, followed by the same attempts to recreate the MBR && slices fail. Following along on the gpart() pages also return fail. Attempting to continue omitting the failed command listed above, also fail when attempting to gpart add -t freebsd-ufs -s 4g ad1s1, with
Code: 
gpart: autofill: No space left on device.
Performing a gpart destroy -F, then rebooting, in an attempt to flush the changes to disk(s). Then returning to re-start the entire process, again, fail. :(

--Chris
 
Re: Help moving a system from a SATA, to a PATA drive. Pleas

sysinstall() doesn't give it to me either. Oh. It makes all the slices, and all. But the slices start at ad1s1b.
So, while I guess I could list them accordingly in fstab(). I'm not sure this is the best approach to use.
Bummer. Looks pretty grim. :(

--Chris
 
Re: Help moving a system from a SATA, to a PATA drive. Pleas

Well aparently gpart(), or geom() on a 8.4-STABLE release synced, and rebuilt about 2.5 wks. ago. Aren't yet ready for prime time. Like the newer releases are (pure suposition). Cause after reading, and trying all the advertized options. I was unable to "re-format||partition" the drive on a live system. I was forced to choose a very unelegant option, which caused much grief -- bounce the box to the live DVD, and slice/format from there. :(
However, on the brite side, after slicing, and dicing the platter, and booting back to the regular system. The live dump() && restore() seem to be progressing as one would hope.

--Chris
 
Re: Help moving a system from a SATA, to a PATA drive. Pleas

What you have to realize is that MBR/BSDlabel is a partition-inside-a-partition format.

If you don't destroy ad0s1, the BSDlabel partitioning inside the MBR slices, it will reappear when you recreate those slices.

Again, I suggest using GPT. With GPT, they are just partitions. The standard GPT layout allows up to 128 partitions, and they are just p1, p2, and so on.

The only change you need to make to use these with the old system is in /etc/fstab.
 
Re: Help moving a system from a SATA, to a PATA drive. Pleas

@@wblock@
Correct, as always, I'm sure. But I was pressed, so moved ahead, as best I knew how.
As to MBR v GPT; I have no arguments there. I have every intention of using it (GPT) moving forward. In fact, all my other systems utilize GPT. This was the last "old timer" left in the lot. The one I'm building to replace it will be using GPT (once I get the Sata platter out of the "old timer"). :)

Thank you again, @wblock@. Always appreciated.

--Chris

EDIT:
Just to reiterate, for future reference;
I need to
Code: 
gpart delete -i N ad1
until all the slices have disappeared (been removed/deleted)? Where N is the slice number?
 
Last edited by a moderator:
Re: Help moving a system from a SATA, to a PATA drive. Pleas

Chris_H said:
Just to reiterate, for future reference;
I need to
Code: 
gpart delete -i N ad1
until all the slices have disappeared (been removed/deleted)? Where N is the slice number?
Click to expand...

No. gpart destroy -F just allows destroying a GEOM that still contains partitions.

The key part to understand here is that MBR/BSDlabel has two entirely different partitioning systems, one inside the other.

First is the MBR. This has up to four partitions ("slices"), but usually there is only one defined. The MBR is on ada0.
Inside that slice, there is a BSDlabel partition table. This is in ada0s1.

Code: 
+ada0:MBR-----------------------------+
|                                     |
| +ada0s1:BSDlabel-----------------+  |
| |  ada0s1a: first BSD partition  |  |
| |  ada0s1b: second BSD partition |  |
| |  ada0s1d: ...and so on...      |  |
| +--------------------------------+  |
|                                     |
+-------------------------------------+

One partitioning structure (MBR) contains the other (BSDlabel). It is much like extended DOS partitions. Destroy the MBR without destroying the BSDlabel, and both seem to disappear. But add an MBR partition, and the BSDlabel GEOM magically reappears, because that data is still on disk, and in just the spot expected.

To get rid of both formats entirely, the inner, BSDlabel partitioning must be destroyed first.
# gpart destroy -F ada0s1

Then the MBR can be destroyed.
# gpart destroy -F ada0
 
Re: Help moving a system from a SATA, to a PATA drive. Pleas

@@wblock@
Ahh. Sure, that makes all the sense in the world. 'fraid I wasn't seeing too clearly last night. I get that way when I'm under a lot of pressure. :P

Thank you very much, @wblock@, for all your help, and patients. :)

--Chris
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top