use dd to clone disk

pfr

I have finally come to this happy moment where I get to run NetBSD on a desktop PC. Currently I have a 500gb kingston SSD with Fedora on it. I want to clone my current NetBSD 225gb disk to the 500gb Kingston.

Just wondering what the dd command should look like. I know it'll take a while to clone the disk, but I just want to ask if there is any flags I should use.

dd if=/dev/wd0 of=/dev/sd0 bs=4M msgfmt=human

$ dmesg
[...]
[     3.446207] wd0 at atabus0 drive 0
[     3.446207] wd0: <WDC WDS240G2G0A-00JH30>
[     3.446207] wd0: drive supports 1-sector PIO transfers, LBA48 addressing
[     3.446207] wd0: 223 GB, 465141 cyl, 16 head, 63 sec, 512 bytes/sect x 468862128 sectors
[     3.446207] wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133), NCQ (32 tags)
[     3.446207] wd0(ahcisata0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) (using DMA), NCQ (31 tags)
[...]
[  7535.199860] sd0 at scsibus0 target 0 lun 0: <KINGSTON, SA400S37480G, SBFK> disk fixed
[  7535.209873] sd0: 447 GB, 16383 cyl, 16 head, 63 sec, 512 bytes/sect x 937703088 sectors
[  7535.219873] sd0: GPT GUID: 44a7abb9-2eea-4570-8eb2-f261f54a854f
[...]

EDIT: reminder to myself to send SIGINFO with pkill -INFO dd to get the status of dd

rvp

pfr The way to do this is to use dump and restore in single-user mode (or using the live USB image). Then, you may have to fix-up /etc/fstab and /boot.cfg, and make the new disk bootable too.

Mosfet

I would recommend using raw devices (instead of block) and I think that 1 MByte block (watch out the lower case letter 'm') should be sufficient for obtaining full speed:

dd if=/dev/rwd0d of=/dev/rsd0d bs=1m msgfmt=human

pfr

Well, I tried the dd method first and tried to boot into it from my laptop and no dice. I get the boot prompt, but then fail with

heap full (0x6f384+7120)

and kicks me back to the boot menu

@rvp will dump copy everything? all files and settings? even files in ~/Downloads etc?

# dump -0 -f /dev/rsd0d

Should I use the fss(4) to create a snapshot and then invoke the -x flag?

rvp

pfr will dump copy everything?

dump works at the raw, disk-level, so it will copy everything: animal, vegetable, or mineral.

pfr Should I use the fss(4) to create a snapshot and then invoke the -x flag?

No need for snapshots if the filesystem is read-only (as it would be in single-user mode):

mount -t tmpfs tmp /tmp        # scratch-space for dump(8)
newfs -O2 /dev/r<new-dev>
mount /dev/<new-dev> /targetroot
dump -0af - / | (cd /targetroot; restore -rf -)
export TERM=wsvt25
vi /targetroot/etc/fstab /targetroot/boot.cfg
umount /targetroot

If your NetBSD system is spread across multiple mount-points, you'll have to dump and restore those file-systems as well. Finally, make the new disk bootable--trivial if you have UEFI.

pfr

rvp

Thanks for taking the time to explain. However, I'm still a little confused as to what I put in place of <new-dev> and targetroot

rvp

pfr However, I'm still a little confused as to what I put in place of <new-dev> and targetroot

<new-dev> is a placeholder for the device on which you ran newfs--ie. the new (root) FS.
/targetroot is a directory which already exists on NetBSD.

Since you're essentially just updating your 9.3_STABLE (albeit on another disk), you can also use this procedure:

etcupdate the current system

ftp https://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-9/latest/amd64/binary/sets/etc.tar.xz
ftp https://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-9/latest/amd64/binary/sets/xetc.tar.xz
etcupdate -s etc.tar.xz -s xetc.tar.xz

Do a standard install of the latest 9.3_STABLE onto the new disk.

After install is done, boot that system into single-user mode, then copy your stuff over from the old disk:

mount -w -u /
mount -r /dev/<old-root> /mnt
mv etc/fstab etc/fstab.sav            # save fstab--might be different between old & new
tar -C /mnt -cf - etc home usr/local usr/pkg var/db/pkgin | tar -C / -xvpf -
mv etc/fstab.sav etc/fstab            # restore
sync
mount -r -u /
poweroff

(All this assumes both old and new systems have just a single / wherein everything is installed. If you mount other filesystems, then just mount them (both old and new) before you do the tar)
This way, you can let sysinst make the system bootable.

pfr

rvp This sounds like a more sensible idea. I'll give it a try. Thanks again

EDIT:

~ λ ftp https://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-9/latest/amd64/binary/sets/etc.tar.xz
Trying [2a04:4e42:13::262]:443 ...
ftp: Can't connect to `2a04:4e42:13::262:443': No route to host
Trying 151.101.81.6:443 ...
Requesting https://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-9/latest/amd64/binary/sets/etc.tar.xz
Redirected to /pub/NetBSD-daily/netbsd-9/202210241500Z/amd64/binary/sets/etc.tar.xz
ftp: Can't lookup `/pub/NetBSD-daily/netbsd-9/202210241500Z/amd64/binary/sets/etc.tar.xz:ftp': No address associated with hostname
ftp: Can't connect or login to host `/pub/NetBSD-daily/netbsd-9/202210241500Z/amd64/binary/sets/etc.tar.xz:?'

Of course I can download the sets manually, but what exactly is going on here? I just tested sysupgrade which also gives me the same error.

rvp

pfr PR #57003. Get a new ftp binary from base.tar.xz

pfr

rvp I'm always relieved when it's not just a problem on my end :)

is nycdn preferred over nyftp ?

pfr

rvp so just to clarify, is this now a moving target? If so, any aliases I've got set for sysupgrade likely won't work?

rvp

pfr is nycdn preferred over nyftp?

One is a CDN, the other looks like Columbia Univ. Pick one...

rvp

pfr is this now a moving target?

If the URL has /latest/ in it, then auto-aim is active. Just pull the trigger.