Date: Wed, 13 Jul 2016 21:44:18 -0500 From: Karl Denninger <karl@denninger.net> To: freebsd-arm@freebsd.org Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... Message-ID: <5475ea53-ae22-2634-6f2a-5737d1b0e308@denninger.net> In-Reply-To: <EDE65B12-4961-4CEF-8AE9-BFDA4FD508A5@gromit.dlib.vt.edu> References: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> <d2eb4035-e494-1a7b-98e5-2aa87efe0763@denninger.net> <EDE65B12-4961-4CEF-8AE9-BFDA4FD508A5@gromit.dlib.vt.edu>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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.) -- 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 010 UUS10UFlorida10U Niceville10U Cuda Systems LLC10UCuda Systems LLC CA1"0 *H Cuda Systems LLC CA0 150421022159Z 200419022159Z0Z10 UUS10UFlorida10U Cuda Systems LLC10UKarl 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|ef"Vلio74zn">a1qWuɖbFeGE&3(KhixG3!#e_XƬϜ/,$+;4y'Bz<qT9_?rRUpn5 Jn&Rx/p Jyel*pN8/#9u/YPEC)TY>~/˘N[vyiDKˉ,^" ?$T8 v&K%z8C @?K{9f`+@,|Mbia 007++0)0'+0http://cudasystems.net:88880 U0 0 `HB0U0, `HB OpenSSL Generated Certificate0U-h\Ff Y0U#0$q}ݽʒm50U0karl@denninger.net0 *H Owbabɺx&Uk[(Oj!%p MQ0I!#QH}.>~2&D}<wm_>V6v]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#}DZ9;V9#>Sw"[UP7100010 UUS10UFlorida10U Niceville10U Cuda Systems LLC10UCuda Systems LLC CA1"0 *H Cuda Systems LLC CA)0 `He M0 *H 1 *H 0 *H 1 160714024418Z0O *H 1B@OyFSm_+"[g!{*fY/'Y)p^05=z8v^y,S7b0l *H 1_0]0 `He*0 `He0 *H 0*H 0 *H @0+0 *H (0 +710010 UUS10UFlorida10U Niceville10U Cuda Systems LLC10UCuda Systems LLC CA1"0 *H Cuda Systems LLC CA)0*H 1010 UUS10UFlorida10U Niceville10U Cuda Systems LLC10UCuda Systems LLC CA1"0 *H Cuda Systems LLC CA)0 *H v/HH×R b^CQ0Ș Et6Y\>Ohz}F:^783D?\26ྔ,x+,Q ʰnP =5>GmJ\GZ/5CZY&9H$i]#c=4\lk܅%<" AҬ un0ynjYFT2H5W`F*O o+vFy0 z#IXYoZ-+;ǎ^'m; zȖ5iB\I`/F "=qņ!Oʇ>Ik`;YzF .7,H2 Un\TZtáLKPT_9o\\"ƯAc7xnôxYJi|7m\Sݽ 轈t$Xnk`"${A2^QS zPg>:m] ˟whome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5475ea53-ae22-2634-6f2a-5737d1b0e308>
