Raspberry Pi2 odd booting problem

Paul Mather paul at gromit.dlib.vt.edu
Mon Jul 11 00:41:09 UTC 2016


On Jul 10, 2016, at 6:50 PM, Karl Denninger <karl at denninger.net> wrote:

> 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!


It looks like you didn't label the UFS file system when you made it.  Instead of "newfs -U /dev/da3s2a" you should have used "newfs -U -L rootfs /dev/da3s2a".

You should be able to fix it easily by doing "tunefs -L rootfs /dev/..." on the SD card.

Cheers,

Paul.



More information about the freebsd-arm mailing list