Date: Thu, 14 Jul 2016 11:44:53 -0500 From: Karl Denninger <karl@denninger.net> To: freebsd-arm@freebsd.org Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... Message-ID: <398ae56c-8893-f188-c210-cf7f19ccf433@denninger.net> In-Reply-To: <5475ea53-ae22-2634-6f2a-5737d1b0e308@denninger.net> References: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> <d2eb4035-e494-1a7b-98e5-2aa87efe0763@denninger.net> <EDE65B12-4961-4CEF-8AE9-BFDA4FD508A5@gromit.dlib.vt.edu> <5475ea53-ae22-2634-6f2a-5737d1b0e308@denninger.net>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On 7/13/2016 21:44, Karl Denninger wrote: > > On 7/13/2016 19:13, Paul Mather wrote: >>> On Jul 13, 2016, at 3:54 PM, Karl Denninger <karl@denninger.net> wrote: >>> >>> 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 >> Shouldn't this be /dev/mmcsd0s2a? You're referencing the entire BSD slice in the above command, not the UFS partition upon which the rootfs lives. > Right. Here's the issue; it doesn't work on the original disk (as it > shouldn't) on the entire BSD slice but... >>> 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 >> Cheers, >> >> Paul. > It DOES on the "clone"! > > It ALSO does on the "a" partition of the clone. > > This implies that gpart screwed up the partitioning, but THAT leaves > open how and why the original partitioning (which is defined here > https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi%202%20image) works > at all, since that's what I'm doing -- and yet it gives the results as > above (and no boot when I'm done.) > Ok, so what's broken here folks? This is likely to blow up soon enough on the build systems that the people who are building snapshot releases are using (once they update); I assume this is a function of some sort of change that was made somewhere upstream in the system. The format of the card has to be: 1. MBR 2. First partition is MSDOS (Type "!12") with the various boot code on it (ubldr, etc.) This is fine. 3. The second partition has to be a "BSD" format partition (old-style) 4. Inside the second partition is a "traditional" BSD labeled (bsdlabel style) partititon table. Up to #2 all goes fine on an attached SD card: # gpart show da0 => 63 62552001 da0 MBR (30G) 63 102400 1 !12 (50M) 102463 62449601 - free - (30G) Now we try to create the BSD labeled piece -- I got this from the crochet disk blob creator, incidentally, along with the FreeBSD Wiki (at https://wiki.freebsd.org/FreeBSD/arm/Raspberry Pi 2 image) # gpart add -t freebsd -a 4m /dev/da0 da0s2 added # gpart create -s BSD /dev/da0s2 *gpart: geom 'da0s2': File exists* *Heh, what was that? :)* What's in here? # gpart show 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) Hmmmm... what do we think exists for device nodes? # ls -al /dev/da0* crw-r----- 1 root operator 0x61 Jul 13 20:28 /dev/da0 crw-r----- 1 root operator 0x64 Jul 14 15:23 /dev/da0s1 crw-r----- 1 root operator 0x66 Jul 14 15:23 /dev/da0s2 crw-r----- 1 root operator 0x67 Jul 14 15:23 /dev/da0s2a Wait a minute, I didn't create any BSD slices! WTF? # bsdlabel /dev/da0s2 # /dev/da0s2: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 62439424 0 4.2BSD 0 0 0 c: 62439424 0 unused 0 0 # "raw" part, don't edit_ _ Oh really? How'd that get in there? And by the way, that's probably why the "add" fails (no space left and the first partition already exists) Further, this is *also* why I can "tunefs" the base (/dev/da0s2) because there's no offset (that is, /dev/da0s2 and /dev/da0s2a both point to the same first block) and that may be why the system refuses to boot when I'm done, as it's "tasted" the first entry, found a label and thus it's "open". In fact, that gap is *exactly* what I see when I run bsdlabel on the running card: # bsdlabel /dev/mmcsd0s2 # /dev/mmcsd0s2: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 62443392 90 4.2BSD 0 0 0 c: 62443482 0 unused 0 0 # "raw" part, don't edit It looks like the issue is that the "gpart create -t freebsd" command stuck a partition table in there which causes the "create -s BSD" to fail. Strategically dding /dev/zero to the card's first 100MB or so (beyond the DOS partition and into the label) and then *again* on the freebsd partition *but before calling gpart to put the slice table on* results in the add working properly. # gpart show 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) # gpart show da0s2 => 0 62439424 da0s2 BSD (30G) 0 128 - free - (64K) 128 62439168 1 freebsd-ufs (30G) 62439296 128 - free - (64K) # tunefs -p /dev/da0s2 tunefs: /dev/da0s2: could not read superblock to fill out disk # tunefs -p /dev/da0s2a tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) enabled 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 That looks valid and now matches the other card... but..... the new (duplicated) card still hangs in the same place..... It boots, the kernel loads, the root filesystem mounts and then the system hangs right after the ue0 MAC address displays on the console. How do you get the "why" on that since I have no way to break out of whatever it is hanging on (it ignores a ^C from a USB keyboard, although it *does* know it's there and the kernel displays attach/detach messages if you plug one in or out while it's hung) and there's no error message displayed that would otherwise help? -- 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 160714164453Z0O *H 1B@ (wk:ey(4:T`Kgڙy 7`-IO :cf~O 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 8=1$UC /jLe"$sK8ĜbB >SiI@$9,6<4$FɓLXB3]>uD/ q|3]҆哵?2',!e B#ʃ;YM|ʅ^-7+7ZYJJ;i9 P9/1S}tИNcCp,T5Əa-;x)/I[B.:${U J%Y7;}kZ&~LJ1`lm)eIPŃYq !QS2u>}SS ޮnS|-5SHϓ̧8n"H.wp) <[X$#bc!4ڻs ^N< vyu"S4a*3^ї` v7աW;%q;!w~Q7 (#EiwGFyz L% ǔ"help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?398ae56c-8893-f188-c210-cf7f19ccf433>