Date: Thu, 14 Jul 2016 22:36:35 -0500 From: Karl Denninger <karl@denninger.net> To: freebsd-arm@freebsd.org Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... Message-ID: <bec46aff-a4d5-9c4d-49d0-78534b13f719@denninger.net> In-Reply-To: <7a91fc79-1c85-fac8-aa3f-db90592f3f44@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> <398ae56c-8893-f188-c210-cf7f19ccf433@denninger.net> <1468518953.72182.219.camel@freebsd.org> <7a91fc79-1c85-fac8-aa3f-db90592f3f44@denninger.net>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
On 7/14/2016 13:27, Karl Denninger wrote:
> On 7/14/2016 12:55, Ian Lepore wrote:
> No there wasn't. It was a blank (brand new) card the first time around;
> it had a MSDOS filesystem on it (as do all new cards) but *no*
> BSD-specific geom anything on it.
>> To reliably create a new layout regardless of what may be present
>> already on the media, you have two choices:
>>
>> 1 - dd zeroes to the entire device
>> 2 - use the "no commit" feature of gpart
> Actually in the case at hand #1 isn't impractical since I really only
> care about the first 100MB or so being zeroed. The reason is that my
> boot block (the MSDOS fs) is ~50Mb and the label is obviously next, so
> if we zero the first 100MB we're fine.
>
> And in fact that does work.
>> When you pass no '-f <flags>' to a gpart command, it automatically adds
>> the "-f C" (commit) flag behind your back. There is no "don't commit"
>> flag, so (this is surrealistically crazy...) what you're supposed to do
>> is pass an invalid flag, which it won't complain about, in order to
>> prevent it from automatically adding that 'C' flag you didn't even
>> realize existed. (This is where *I* curse whoever coded this mess.)
>>
>> When you don't commit, the changes take place in a sort of 'virtual
>> workspace' and nothing on the physical disk changes until you do a
>> "gpart commit" (or "gpart undo" to discard the changes). Making all
>> this much-less-cool that it's sounding right now, there is no automatic
>> recursion for commit and undo... if you create a bunch of nested stuff
>> (a slice, a geom within that slice, parititions within that geom), then
>> you have to commit all the pending new geoms *in reverse order of how
>> they were created*.
>>
>> So, using da0 (since it's shorter to type), the sequence goes like:
>>
>> gpart destroy -f x -F da0
>> gpart create -f x -s MBR da0
>> gpart add -f x -t \!12 -s 64M -a 4M da0
>> gpart add -f x -t freebsd -a 4M da0
>> gpart destroy -f x -F da0s2
>> gpart create -f x -s BSD da0s2
>> gpart add -f x -t freebsd-ufs da0s2
>> gpart commit da0s2
>> gpart commit da0
>> newfs_msdos /dev/da0s1
>> newfs -U /dev/da0s2a
>>
>> And that reliably creates a fresh rpi-style layout regardless of what
>> was on the media before you started.
> Ok, I will try this, BUT I suspect it's still screwed (blind) because
> when I zeroed the front of the disk I got a "correct" partition layout
> but after populating it what I get still hangs after it mounts root in
> the same place. The way to prevent the alignment issue from coming up
> is to specify a "-b" switch on the "add", giving you a block offset.
> "-b 64" is sufficient; now if the system tries to "taste" da0s2 it will
> fail (as it does for the card that is running) but "tasting" da0s2a
> succeeds.
>> Now, to address the question of the filesystem existing at da0s2 versus
>> da0s2a, the difference is alignment. Making things even more
>> confusing, alignment (if you don't specify it) sometimes changes based
>> on the type and brand of usb sdcard reader you're using and the fake
>> geometry values it reports to the system. (A USB reader almost always
>> reports different fake geometry than a native sd slot would on a
>> machine with non-USB based sd support.)
> Yes, I understand that; if the alignment matches thus the "a" partition
> starts at offset zero then you can actually reference that (although
> length might be wrong) with the base device. After all, what it really
> does is look at the blocks to see if the magic number is good, and if so
> it tries to read and process it.
>
> But this doesn't explain why, after getting a layout that's correct (by
> writing zeros to the front of the card first, so anything that "might"
> be there isn't) and copying all the file structure over (which facially
> not only appears to be correct but the loader finds and loads the
> kernel, AND the root filesystem mounts!) the system hangs, apparently
> just before init gets started.
>
> If init can't be found you should get a complaint (been there, done
> that) on the console but there is no complaint of any sort.
>
> I've gotten through the bad structure issue on the SD card, and am now
> left with "why does it hang on boot -- with no error or other indication
> of what the problem is" after the kernel loads *and* the root filesystem
> mounts?
>
Found it.
Apparently the current code *requires* the label be set on the msdos
partition. If it's not then not only does it not mount (which shouldn't
matter post-boot as the loader is supposed to pass the dtb file, it is
specified in the config file without any sort of path prefix, and thus
once the kernel has loaded it should not matter if the dos partition if
actually mounted or not) *but* the boot process hangs without any
indication of why!
So, you must do newfs_msdos -L MSDOSBOOT -F 16 {device}
If the "-L" is missing you're hosed; the system facially appears to be
just fine but while the loader comes up and so does the kernel, it hangs
without ever proceeding -- and without any sort of error message
indicating that it is unable to mount something it needs.
I can clone cards now.
--
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
160715033635Z0O *H
1B@Գk7F³EWf3 " &&K9hul
#NIvmaL0l *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
;f U7_M*n$ִO
V/'j`YrB pcߧ~puDMVi &!ϻ3>HҤ+eMGhRuû`qGV LGtDM $7,ѯbȱL7-S w&?a31Ƥy7ljEzT]# ˻VLsv Lz #iw!hV0VNS+' (^1њxq龦N?ʇO6f5 ;<k4ݽv 0Z
锧sj
3-oqJi{hƉ_îIYm0c[Kzp*L h|hU[ *{Cc1XȘ)yS)nRZaP8$4N== Q RkV0aE
Up)_HFrǥ,{F0E=r2T y/<b8>%4 QlX^$o6Ob7$Fܝ)>
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bec46aff-a4d5-9c4d-49d0-78534b13f719>