Solved Strange errors on boot using 11.1

Maelstorm

Maelstorm

I'm getting the following errors on system boot:

Code: 
GEOM: ada0a: invalid disklabel.
g_dev_taste: make_dev_p() failed (gp->name=ada0a, error=17)
g_dev_taste: make_dev_p() failed (gp->name=ada0b, error=17)
g_dev_taste: make_dev_p() failed (gp->name=ada0d, error=17)
g_dev_taste: make_dev_p() failed (gp->name=ada0e, error=17)
g_dev_taste: make_dev_p() failed (gp->name=ada0f, error=17)
g_dev_taste: make_dev_p() failed (gp->name=ada0g, error=17)
GEOM: ada1a: invalid disklabel.
g_dev_taste: make_dev_p() failed (gp->name=ada1a, error=17)
g_dev_taste: make_dev_p() failed (gp->name=ada1b, error=17)
g_dev_taste: make_dev_p() failed (gp->name=ada1d, error=17)
g_dev_taste: make_dev_p() failed (gp->name=ada1e, error=17)
g_dev_taste: make_dev_p() failed (gp->name=ada1f, error=17)
g_dev_taste: make_dev_p() failed (gp->name=ada1g, error=17)
Now I looked up error code 17 in errno(2) and it says that the file exists, but it's complaining that the disklabel is invalid? Well, obviously the disklabel is valid because everything mounts and I have been using the system.

My disk layout is as follows:
Code: 
strata:/root 239 ### ->df
Filesystem 1M-blocks Used Avail Capacity  Mounted on
/dev/ada0a      1983  290  1534    16%    /
devfs              0    0     0   100%    /dev
/dev/ada0d      3958  187  3454     5%    /var
/dev/ada0e      3958   43  3597     1%    /tmp
/dev/ada0f      7916  887  6396    12%    /usr
/dev/ada0g     16857  170 15338     1%    /home
/dev/ada1b      3958 2475  1165    68%    /usr/src
/dev/ada1d      7916 4605  2678    63%    /usr/obj
/dev/ada1e      3958 1106  2535    30%    /usr/doc
/dev/ada1f      7916 1700  5582    23%    /usr/ports
/dev/ada1g     85077  510 77761     1%    /usr/local

/etc/fstab:
Code: 
strata:/etc 244 ### ->cat fstab
# Device        Mountpoint      FStype  Options Dump    Pass#
/dev/ada0a      /               ufs     rw      1       1
/dev/ada0b.eli  none            swap    sw      0       0
/dev/ada0d      /var            ufs     rw      2       2
/dev/ada0e      /tmp            ufs     rw      2       2
/dev/ada0f      /usr            ufs     rw      2       2
/dev/ada0g      /home           ufs     rw      2       2
/dev/ada1a.eli  none            swap    sw      0       0
/dev/ada1b      /usr/src                ufs     rw      2       2
/dev/ada1d      /usr/obj                ufs     rw      2       2
/dev/ada1e      /usr/doc                ufs     rw      2       2
/dev/ada1f      /usr/ports              ufs     rw      2       2
/dev/ada1g      /usr/local              ufs     rw      2       2

fdisk on ada0:
Code: 
strata:/root 240 ### ->fdisk
******* Working on device /dev/ada0 *******
parameters extracted from in-core disklabel are:
cylinders=77545 heads=16 sectors/track=63 (1008 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=77545 heads=16 sectors/track=63 (1008 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
<UNUSED>
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 0, size 50000 (24 Meg), flag 80 (active)
        beg: cyl 0/ head 0/ sector 1;
        end: cyl 1023/ head 254/ sector 63

fdisk on ada1:
Code: 
trata:/root 241 ### ->fdisk /dev/ada1
******* Working on device /dev/ada1 *******
parameters extracted from in-core disklabel are:
cylinders=232581 heads=16 sectors/track=63 (1008 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=232581 heads=16 sectors/track=63 (1008 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
<UNUSED>
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 0, size 50000 (24 Meg), flag 80 (active)
        beg: cyl 0/ head 0/ sector 1;
        end: cyl 1023/ head 254/ sector 63

When I created the partitions, I didn't specify MBR or GPT. I specified BSD Disklabel, but it is using MBR. I found this thread https://forums.freebsd.org/threads/59464/ that shows something similar. I tried the solution presented and it still comes up.

Taking a second look at it, it looks like it's trying to create device nodes in /dev but the nodes already exist so it throws error code 17...

Any ideas?
 
Maelstorm said:
Well, obviously the disklabel is valid because everything mounts and I have been using the system.
Click to expand...
Something's not quite right about them though. You're missing the slices and have the BSD labels directly on the disk. These look like "dangerously dedicated" disks.
 
I don't understand why they are called "dangerously dedicated" disks. Since FreeBSD is the only OS on the machine, or that will ever be on the machine, why is it an issue? I just put down the disklabel and left it at that. Then I split it up into the different partitions. Maybe I'm missing something but that is how I have always done it.
 
Maelstorm said:
I don't understand why they are called "dangerously dedicated" disks. Since FreeBSD is the only OS on the machine, or that will ever be on the machine, why is it an issue?
Click to expand...
This is a thing I also never understood.
Maybe it's meant in the sense that multi-OS users could think that this disk contains garbage?
Another possibilty could be (also only affecting multi-OS users) that some versions of Windows installers happily considered such disks as "free disks" ready to be FAT partitioned. (Preventing such "accidents" was then one of my reasons to always use a partition table.)
 
I did some research.

Apparently, a "dangerously dedicated" disk that does not have an MBR. The BSD Disklabel is laid down at the top level of partitioning with NO MBR or GPT. Also, since the partition starts at LBA 1 instead of LBA 64, most (if not all) 3rd-party disk tools will throw fits because they see this as an invalid partitioning scheme and may nuke your LBA 1 sector, which could cause loss of data or an unbootable system.

So, I'm going to correct it. I have to change partition sizes anyways so I'll just reinstall using the MBR this time. It's in the middle of a backup (I use tar for that purpose). So backup, ftp to a different machine, and away we go.

So I'm backing up a few things in /boot, /etc, /home, /usr/src, /usr/obj (just because it takes too freaking long to compile), /usr/ports/, /usr/doc, and /usr/local. Total space is upwards of 9-10gb. That will take a little bit over ftp from my Windows machine, even at 100BaseT Ethernet.
 
Back to the original problem. It took me awhile, but I figured it out...and it makes sense when you think about it.

Apparently, when you build a custom kernel, certain options are automatically included based on a variety of different criteria. If you specify these options manually in the config file, you will get a warning about duplicate options/devices...

So, for example, if the platform is i386/amd64, you automatically get the following:

device isa
device orm

So, unbeknownst to me, the build for 11.1 automatically includes

options GEOM_PART_MBR
options GEOM_PART_BSD

When I included GEOM_BSD into my config, it conflicted with GEOM_PART_BSD. One would grab the disks before the other. When the other tried to get it, the disks were locked down by the first one and it threw an error.

Maybe it's just me, but I think it's a bad idea to include options that are not in the config file. If something was forgotten, then the kernel will not boot. That puts the onus on the admin. I want to see every option that goes into the kernel that I build without stuff being hidden from me.
 
Any news about this problem? I have searched, without luck.


Maelstorm said:
I want to see every option that goes into the kernel that I build without stuff being hidden from me.
Click to expand...

I have a image, every time I mount the image this happen.

g_dev_taste: make_dev_p() failed (gp->name=md0a, error=17)
g_dev_taste: make_dev_p() failed (gp->name=md0a, error=17)

Then I build kernel without GEOM_BSD, and the error stop.

# GEOM
options GEOM_PART_BSD
options GEOM_PART_EBR
options GEOM_PART_EBR_COMPAT
options GEOM_PART_MBR
options GEOM_PART_GPT # GUID Partition Tables.
#options GEOM_RAID # Soft RAID functionality.
options GEOM_LABEL # Provides labelization
#options GEOM_BSD # Provides labelization
options GEOM_ELI # Provides ELI
 
Please explain why you built the kernel in the first place. And check whether the problem exists with a stock distribution kernel or not. It is possible that you found a very minor bug which exists only for hand-built kernels, which were built with options that perhaps "make no sense" (having GEOM_BSD and _PART_BSD both on seems a bit suspicious), and which is minor because it just creates a pointless warning message on the console without impacting functionality. If you can drill down enough to verify that, then you should probably open a bug report. Why drill down first? If you just file a bug report with your observation, without some debugging help, the developers will probably ignore it as "person configured his system strange, and built a custom kernel weird, and that combination is not important".
 
Hello ralphbsz, we have a system that uses the FreeBSD kernel as a base.

First I apply Kernel patches, then recompile it.

In a moment, I added these GEOM options to my system, and I did not comment on GEOM_BSD. What led my system to generate those logs: g_dev_taste: make_dev_p () failed (gp-> name = md0a, error = 17).

Searching the internet, I found this post. And I felt the need to add information to the Maelstorm message, and to explain to other people what might cause those messages. And maybe, somebody at some point can tell if it's a bug or just an insignificant log.

I do not have the need to compile the kernel with _BSD and _PART_BSD both active. This was only a small mistake after hours of programming.
 
You must log in or register to reply here.
Back
Top