Date: Wed, 13 Jul 2016 14:54:12 -0500 From: Karl Denninger <karl@denninger.net> To: freebsd-arm@freebsd.org Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... Message-ID: <d2eb4035-e494-1a7b-98e5-2aa87efe0763@denninger.net> In-Reply-To: <548783e1-9047-68f7-5f50-449db684d602@denninger.net>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
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@Test-MCP:/home/karl # tunefs -p /dev/mmcsd0s2
tunefs: /dev/mmcsd0s2: could not read superblock to fill out disk
root@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@denninger.net <mailto:karl@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
[-- Attachment #2 --]
0 *H
010
`He 0 *H
_0[0C)0
*H
01 0 UUS10UFlorida10U Niceville10U
Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H
Cuda Systems LLC CA0
150421022159Z
200419022159Z0Z1 0 UUS10UFlorida10U
Cuda Systems LLC1 0 UKarl Denninger (OCSP)0"0
*H
0
X@vkY
Tq/vE]5#֯MX \8LJ/V?5Da+
sJc*/r{ȼnS+ w")ąZ^DtdCOZ ~7Q '@a#ijc۴oZdB&!Ӝ-< ? HN5y
5}F|e f"V لio74zn">a1qWuɖbFeGE&3(KhixG3!#e_XƬ Ϝ/,$+;4y 'Bz<qT9_?rRUpn5
Jn&Rx/p Jyel*pN8/#9u/YP EC)TY>~/˘N[vyiDKˉ ,^" ?$T8 v& K%z8C @?K{9f`+@,| Mbia 007++0)0'+0http://cudasystems.net:88880 U 0 0 `HB0 U 0, `HB
OpenSSL Generated Certificate0 U -h\Ff Y0 U #0$q}ݽʒm50 U 0karl@denninger.net0
*H
Owbabɺx&Uk[ (Oj!%p MQ0I!#QH}.>~2&D}<wm_>V6 v ]f>=Nn+8;q wfΰ/RLyUG#b}n!Dր _up|_ǰc/%ۥ
nN8:d;-UJd/m1~VނיnN I˾$tF1&}|?q?\đXԑ&\4V<lKۮ3%Am_(q -(cAeGX)f}-˥6cv~Kg8m~v ;|9:-iAPқ6ېn-.)<[$KJtt/L4ᖣ^Cmu4vb{+BG$M0c\[MR|0FԸP&78"4p# }D Z9;V9#>Sw"[UP710001 0 UUS10UFlorida10U Niceville10U
Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H
Cuda Systems LLC CA)0
`He M0 *H
1 *H
0 *H
1
160713195412Z0O *H
1B@he
,WA ʐS; -RliX"Mr5!M 0l *H
1_0]0 `He*0 `He0
*H
0*H
0
*H
@0+0
*H
(0 +71001 0 UUS10UFlorida10U Niceville10U
Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H
Cuda Systems LLC CA)0 *H
101 0 UUS10UFlorida10U Niceville10U
Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H
Cuda Systems LLC CA)0
*H
,I ƥ{;I; +YJR<!SbWظ#ʹZ=S~pኈ2zGG2&6];B2Tx#bܮwT_ZڌǶ,DhTkRdS$D]W0 *! j;`9pTnS
J܃R0[4}m>_ `~~ ]gxh g"K}3+wZ$)0n(d⠍:
>03vB$^>RB" v{]G@h };diB^` o{ ^c_enIcr^
E<VGՏ+L.(.#b
ȐnnlLM>;]>
cl ]ݛ~#9YNKTartUс~\7v2K!
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d2eb4035-e494-1a7b-98e5-2aa87efe0763>