Bizarre clone attempt failures on Raspberry Pi2...
Karl Denninger
karl at denninger.net
Wed Jul 13 19:54:15 UTC 2016
Oh, there is one difference:
tunefs -p on the new device *works* (no idea why however since there's
no slice there) where it FAILS on the original:
root at Test-MCP:/home/karl # tunefs -p /dev/mmcsd0s2
tunefs: /dev/mmcsd0s2: could not read superblock to fill out disk
root at Test-MCP:/home/karl # tunefs -p /dev/da0s2
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
Huh?
On 7/13/2016 14:45, Karl Denninger wrote:
> 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/407fbe8c/attachment.bin>
More information about the freebsd-arm
mailing list