Raspberry Pi2 odd booting problem

Karl Denninger karl at denninger.net
Sun Jul 10 22:50:45 UTC 2016


So I'm trying to modify an existing SD card image to do something
different.  I imaged the card, re-wrote it onto a new card, and then
mounted the FreeBSD partition.  All was well doing this.

Next, I did a "newfs -U /dev/da3s2a" to clear the FreeBSD partition and
then wrote a *different* build back onto it using pax.  Why do this
rather than image the (other) card?  Because it's a hell of a lot faster
and you only write part of the card instead of all of it.  This should
work, and does on Intel-based systems without a problem.

Butttttt.... not this time.  /dev/ufs/rootfs is not there when the
system boots and the mount of the root filesystem fails.  If I plug a
keyboard and monitor in and hit "?" I can see the partition and if I
specify THAT as "ufs:partitionmame" the system comes up.

So what's going on here?  All I did to the existing format on the card
was run a newfs on the UFS partition and then replace the files, which
really isn't any different than what you do when you're doing a manual
install on an Intel box, and suddenly what I get is non-functional --
some part of the kernel's idea of how the device tree lays out for that
SD card (with the ufs partition under /dev/ufs) disappeared on me.

Any ideas how this got boogered up?  I can fix it of course but I'd
prefer not to wait the hour for the SD card image method per-card!

-- 
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/20160710/2afee747/attachment.bin>


More information about the freebsd-arm mailing list