Bizarre clone attempt failures on Raspberry Pi2...
Karl Denninger
karl at denninger.net
Wed Jul 13 19:45:31 UTC 2016
The latest conundrum.....
I am attempting to "clone" a running SD card for the Pi2.
I have re-created the SD filestructure using gpart using the following
sequence, starting with a blank card (e.g. "da0") and aligning the Unix
filestructure on a 4MB boundary (which is my usual practice for any sort
of solid-state device)
#!/bin/sh
gpart create -s MBR $1
gpart add -t '!12' -s 50m $1
gpart set -a active -i 1 $1
gpart add -t freebsd -a 4m $1
newfs_msdos $1s1
gpart create -s bsd $1s2
gpart add -t freebsd-ufs $1s2
newfs -U -L rootfs $1s2a
then mounted the two "working" partitions this generates (da0s1 and
da0s2a) and successfully transferred the root and msdos filesystems
using rsync. The result appears to be fine when examined side-by-side
with the original, other than the fact that it looks like there were
sparse files that have been expanded, but when you try to boot the
result it starts, appears to mount the root filesystem, says it's not
clean (which is odd since it certainly was dismounted cleanly with
umount!), and the system hangs after displaying the UE (ethernet)
hardware MAC address on an HDMI console. There is no response from a
USB connected keyboard if you try to ^C out of wherever it is (although
it DOES know it's there and displays the "found" message when you plug
the keyboard in.)
If you wait long enough it will tell you it has unblocked the random
device. Unfortunately I have no idea where it's hanging in the startup
beyond this and have no way to find out since I can get out of wherever
it is, even with a physical keyboard plugged into it.
Putting the original card back in and sticking the one that failed to
boot in an SD card reader produces the following.
Base partition structure of the working sd card:
# gpart show /dev/mmcsd0
=> 63 62552001 mmcsd0 MBR (30G)
63 102375 1 !12 [active] (50M)
102438 62443482 2 freebsd (30G)
62545920 6144 - free - (3.0M)
Of the other card:
# gpart show /dev/da0
=> 63 62552001 da0 MBR (30G)
63 102400 1 !12 [active] (50M)
102463 4033 - free - (2.0M)
106496 62439424 2 freebsd (30G)
62545920 6144 - free - (3.0M)
# ls -al /dev/mm*
crw-r----- 1 root operator 0x4e Jul 10 19:24 /dev/mmcsd0
crw-r----- 1 root operator 0x4f Jul 10 19:24 /dev/mmcsd0s1
crw-r----- 1 root operator 0x50 Jul 10 19:24 /dev/mmcsd0s2
crw-r----- 1 root operator 0x53 Jul 10 19:24 /dev/mmcsd0s2a
And of the one that will not come up but does boot, in a SD card reader:
# ls -al /dev/da0*
crw-r----- 1 root operator 0x56 Jul 13 19:27 /dev/da0
crw-r----- 1 root operator 0x58 Jul 13 19:27 /dev/da0s1
crw-r----- 1 root operator 0x5d Jul 13 19:27 /dev/da0s2
crw-r----- 1 root operator 0x60 Jul 13 19:27 /dev/da0s2a
# mount -t msdosfs /dev/da0s1 /mnt
# df
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/ufs/rootfs 30229724 824548 26986800 3% /
devfs 1 1 0 100% /dev
/dev/msdosfs/MSDOSBOOT 51128 7560 43568 15% /boot/msdos
tmpfs 51200 4 51196 0% /tmp
/dev/da0s1 51128 7560 43568 15% /mnt
# ls /mnt
BOOTCODE.BIN START_CD.ELF
CONFIG.TXT START_X.ELF
FIXUP.DAT System Volume Information
FIXUP_CD.DAT U-BOOT.BIN
FIXUP_X.DAT UBLDR
RPI2.DTB UBLDR.BIN
START.ELF
Now here's the thing -- the unix-side filesystem has to be good too,
because the kernel is not in the MSDOS partition, it's in /boot/kernel
on the Unix side and it both loads and starts! But just for good
measure, here's what we got in there:
# mount -o ro /dev/da0s2a /mnt
# df
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/ufs/rootfs 30229724 824548 26986800 3% /
devfs 1 1 0 100% /dev
/dev/msdosfs/MSDOSBOOT 51128 7560 43568 15% /boot/msdos
tmpfs 51200 4 51196 0% /tmp
/dev/da0s2a 30233340 2299932 25514744 8% /mnt
I can mount it, and everything is there. Specifically, if I look
through /etc/rc.d and the /etc/rc file itself, both are present, as is
/sbin/init and the checksums match too.
With both filesystems mounted (the sd card cloned to on /mnt) tunefs
says they both have the label set correctly and all the flags are the
same -- the only difference is the space to hold for metadata blocks,
which is likely because the original load was done with an image and
then growfs resized it.
# tunefs -p /mnt
tunefs: POSIX.1e ACLs: (-a) disabled
tunefs: NFSv4 ACLs: (-N) disabled
tunefs: MAC multilabel: (-l) disabled
tunefs: soft updates: (-n) enabled
tunefs: soft update journaling: (-j) disabled
tunefs: gjournal: (-J) disabled
tunefs: trim: (-t) disabled
tunefs: maximum blocks per file in a cylinder group: (-e) 4096
tunefs: average file size: (-f) 16384
tunefs: average number of files in a directory: (-s) 64
tunefs: minimum percentage of free space: (-m) 8%
tunefs: space to hold for metadata blocks: (-k) 6408
tunefs: optimization preference: (-o) time
tunefs: volume label: (-L) rootfs
# tunefs -p /
tunefs: POSIX.1e ACLs: (-a) disabled
tunefs: NFSv4 ACLs: (-N) disabled
tunefs: MAC multilabel: (-l) disabled
tunefs: soft updates: (-n) enabled
tunefs: soft update journaling: (-j) disabled
tunefs: gjournal: (-J) disabled
tunefs: trim: (-t) disabled
tunefs: maximum blocks per file in a cylinder group: (-e) 4096
tunefs: average file size: (-f) 16384
tunefs: average number of files in a directory: (-s) 64
tunefs: minimum percentage of free space: (-m) 8%
tunefs: space to hold for metadata blocks: (-k) 2488
tunefs: optimization preference: (-o) time
tunefs: volume label: (-L) rootfs
I've never had trouble cloning a disk like this in the Intel world and
quite-clearly the system CAN find the cloned card's filesystem structure
or the kernel would not come up -- but it does....
What the hell am I doing wrong?
--
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2996 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20160713/7b487d93/attachment.bin>
More information about the freebsd-arm
mailing list