Unable to mount the root fs on stable/8 r264339, GENERIC kernel, with MBR, FreeBSD slice, and UFS volume labels

[Trond Endrestøl]

On Fri, 11 Apr 2014 10:04-0700, Chris H wrote:

> > Hi,
> >
> > I have a couple of uncritical systems running stable/8 r258344.
> > Hardware is Dell OptiPlex GX260, BIOS A09, which is the latest rev.
> >
> > The r264339 GENERIC kernel are unable to mount the root fs from the
> > hard drive using MBR, FreeBSD slice, and UFS volume labels.
> 
> You didn't indicate where it won't mount the drives from. Is this from
> the releng_8 install media. In other words, When booting the install
> media, the installer can't find the drive(s)? Or is it something else?
> When you're presented with the problem, what's the output of ls /dev
> do any of ad0* da0* show up? If so, what's the output from
> gpart list ad0s1 and the likes?

It's when the kernel attempts to mount the root fs from the hard 
drive during startup.

Booting the old kernel, r258344 from November 19th, 2013, works as 
expected.

Typing ? at the mountroot> prompt presented by the new and faulty 
kernel reveals acd0 and ad0 as GEOM managed disk devices. The kernel 
printed a few lines or so above the mountroot> prompt that it 
perfectly detected the ad0 harddrive.

The latest kernel simply can't find /dev/ufs/root nor /dev/ad0s1a.

Here's the output from various commands:

trond at amanda:~>uname -a
FreeBSD amanda.[withheld] 8.4-STABLE FreeBSD 8.4-STABLE #0 r258344: Tue Nov 19 21:33:39 CET 2013     root at amanda.[withheld]:/usr/obj/usr/src/sys/AMANDA  i386

trond at amanda:~>gpart show ad0
=>       63  976773105  ad0  MBR  (465G)
         63  976773105    1  freebsd  [active]  (465G)

trond at amanda:~>bsdlabel ad0s1
# /dev/ad0s1:
8 partitions:
#          size     offset    fstype   [fsize bsize bps/cpg]
  a:    2097152          0    4.2BSD        0     0     0
  b:    4194304    2097152      swap
  c:  976773105          0    unused        0     0     # "raw" part, don't edit
  d:    2097152    6291456    4.2BSD        0     0     0
  e:    8388608    8388608    4.2BSD        0     0     0
  f:    4194304   16777216    4.2BSD        0     0     0
  g:   41943040   20971520    4.2BSD        0     0     0
  h:  913858545   62914560    4.2BSD        0     0     0

trond at amanda:~>df -ah
Filesystem            Size    Used   Avail Capacity  Mounted on
/dev/ufs/root         989M    215M    694M    24%    /
devfs                 1.0k    1.0k      0B   100%    /dev
/dev/ufs/home         3.9G    694M    2.9G    19%    /home
/dev/ufs/tmp          989M    7.1M    903M     1%    /tmp
/dev/ufs/usr           19G    8.2G    9.7G    46%    /usr
/dev/ufs/var            2G    326M    1.5G    18%    /var
/dev/ufs/amandahd0    422G    6.0k    422G     0%    /var/spool/amanda/hd0
procfs                4.0k    4.0k      0B   100%    /proc
linprocfs             4.0k    4.0k      0B   100%    /usr/compat/linux/proc
linsysfs              4.0k    4.0k      0B   100%    /usr/compat/linux/sys

The results are the same on the spare system.

There I first wiped the harddrive clean, by booting from the 
8.0-RELEASE dvd1, ran dd if=/dev/zero of=/dev/ad0 bs=128M, before I 
installed 8.0-RELEASE. I then transferred an up-to-date working copy 
of stable/8 to the spare system. Next, I compiled world and the 
GENERIC kernel, without any hassle. I performed make installkernel and 
rebooted.

The boot loader managed its way through the maze, read /etc/fstab and 
found the entry for the root filesystem. The new GENERIC kernel, 
however, simply can't understand what to do with:

vfs.root.mountfrom="ufs:/dev/ufs/root"
vfs.root.mountfrom.options="rw"

as presented by the boot loader. Mind you, the boot loader hasn't been 
replaced yet. Maybe that's the whole issue, however weird it sounds.
/boot/loader.conf is empty btw.

I'm doing a similar attempt in VirtualBox at home as I write this.
There I began with 8.4-RELEASE, and are currently compiling stable/8 
r264351.

I'll later try in VBox, 8.4-R -> stable/8 with GPT + UFS, using GPT 
labels, just to rule out UFS labels.

> > r258344 obviously can.
> >
> > I even tried regular device names like /dev/ad0s1a in /etc/fstab, and
> > at the mountroot> prompt, i.e. ufs:/dev/ad0s1a. The kernel still
> > cannot mount the root fs.
> >
> > The new kernel (r264339) does recognize the ad0 harddrive, and ad0 is
> > listed as one of the GEOM managed disk devices; acd0 being the other
> > one.
> >
> > Do I need to load additional geom modules, or is it a genuine bug?
> >
> > I have recreated the same conditions on a spare GX260, yes, I have
> > plenty of them.
> >
> > In addition there was some problems with the USB subsystem, so I
> > disabled USB in the BIOS for now. USB is not essential for any of my
> > systems.
> >
> > Maybe it's time to leave stable/8 and enter stable/10 or stable/9.
> > I'll try to compile stable/9 on the spare system, and see how it
> > fares.
> >
> > Any thoughts regarding the problem mounting the root fs?

-- 
+-------------------------------+------------------------------------+
| Vennlig hilsen,               | Best regards,                      |
| Trond Endrestøl,              | Trond Endrestøl,                   |
| IT-ansvarlig,                 | System administrator,              |
| Fagskolen Innlandet,          | Gjøvik Technical College, Norway,  |
| tlf. mob.   952 62 567,       | Cellular...: +47 952 62 567,       |
| sentralbord 61 14 54 00.      | Switchboard: +47 61 14 54 00.      |
+-------------------------------+------------------------------------+