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