Oddness with GPT labels on boot

[Paul Mather]

On Mar 8, 2015, at 10:11 PM, Brett Wynkoop <freebsd-arm at wynn.com> wrote:

> Greeting-
> 
> So just updated my kernel sources and now I have this oddness happening:
> 
> No suitable dump device was found.
> Starting file system checks:
> /dev/mmcsd0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS
> /dev/mmcsd0s2a: clean, 560326 free (12950 frags, 68422 blocks, 0.7%
> fragmentation) ugen1.2: <vendor 0x0781> at usbus1
> umass0: <vendor 0x0781 Staples, class 0/0, rev 2.00/1.22, addr 2> on
> usbus1 umass0:  SCSI over Bulk-Only; quirks = 0xc100
> umass0:0:0: Attached to scbus0
> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> da0: <Staples  1.22> Removable Direct Access SCSI-5 device 
> da0: Serial Number 4C532000071129119192
> da0: 40.000MB/s transfers
> da0: 15267MB (31266816 512 byte sectors: 255H 63S/T 1946C)
> da0: quirks=0x2<NO_6_BYTE>
> Can't stat /dev/gpt/bbexport: No such file or directory
> Can't stat /dev/gpt/bbexport: No such file or directory
> THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY:
>        ufs: /dev/gpt/bbexport (/export)
> Unknown error; help!
> ERROR: ABORTING BOOT (sending SIGTERM to parent)!
> Mar  8 22:04:47 init: /bin/sh on /etc/rc terminated abnormally, going
> to single user mode Enter full pathname of shell or RETURN for /bin/sh: 
> # fsck -p
> /dev/mmcsd0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS
> /dev/mmcsd0s2a: clean, 560326 free (12950 frags, 68422 blocks, 0.7%
> fragmentation) /dev/gpt/bbexport: FILE SYSTEM CLEAN; SKIPPING CHECKS
> /dev/gpt/bbexport: clean, 3375570 free (114 frags, 421932 blocks, 0.0%
> fragmentation) 
> # 
> 
> Note I did nothing more than run fsck -p as soon as I was at
> the /bin/sh prompt. 
> 
> # uname -a
> FreeBSD  11.0-CURRENT FreeBSD 11.0-CURRENT #6 r279797: Sun Mar  8
> 21:22:04 EDT 2015
> wynkoop at beaglebone.wynn.com:/usr/src/sys/arm/compile/BB-BEW  arm 
> # 
> 
> Before this kernel I had no problem with the filesystem being checked
> and mounting at boot.
> 
> I have not rebuilt world, but I am at a loss as to how that could be
> the problem.  Note above that it said it could not
> find /dev/gpt/bbexport. 
> 
> I have even put the late param in /etc/fstab for /dev/gpt/bbexport to
> see if that would help.


One thing that caught me very recently is that when the DTrace code went in, the BEAGLEBONE kernel config file also grew this line:

makeoptions     MODULES_OVERRIDE="opensolaris dtrace dtrace/lockstat dtrace/profile dtrace/fbt"


That has the effect of only building those modules.  If, like me, you were using GEOM labels (which, from the above, it looks like you are using GPT labels), via the geom_label module, then you'd get some breakage with any new kernel, as the /dev/gpt devices would not appear and your file systems would not be mountable. :-(

If you rely on the vanilla BEAGLEBONE kernel then this might be your problem.

So, I suggest you either comment that out (and revert to building all modules) or add a nomakeoptions somewhere.  (I use another kernel config file that includes BEAGLEBONE and then disables some things via nooptions and nomakeoptions.)

Cheers,

Paul.