Esteemed Colleagues:
FreeBSD 13 is installed on /dev/ada0s3, which is a "primary partition" of the MBR-partitioned root disk (more specifically, the root filesystem is on /dev/ada0s3a, which begins 16 blocks away from the beginning of /dev/ada0s3 because that's where bsdlabel offered to put it, during the installation procedure, and I also have a /dev/ada0s3b which is available for swap if I ever need a swap area, which currently I am doing without).
Why did I choose MBR partitioning for my disk? Because this computer is a multiboot machine, and I intend to install operating systems on it, like ReactOS, which, to the best of my knowledge, do not know how to boot themselves from a GPT slice.
FreeBSD does not know how to install itself onto, or boot itself from, a logical slice, so I installed in onto one of the 3 primary slices. And it's a good thing that I did, because I am running it now, and it does not even see the logical slices. Behold:
There should be a /dev/ada0s5 and a /dev/ada0s6, and there is not. /dev/ada0s4 is my extended slice, and I have logical slices inside of it. One is a Linux volume group containing Linux logical volumes on which various Linux distributions will be installed (at the moment, only ZorinOS is installed, but there will be others). The other I am using as a ZFS pool. It is a minor inconvenience that the FreeBSD system cannot see the Linux volume group, because I want the Linux filesystems to be visible to the FreeBSD system, which has partly functional lvm drivers and fully functional ext2 drivers. But it is a major inconvenience that the FreeBSD system cannot see the ZFS pool. The ZFS pool is where I am putting the shared storage, such as the /home filesystem, that will be common to the Linux and FreeBSD systems, as well as my not-yet-installed OpenIndiana and NetBSD systems (parenthetically, why did we have to wait years for NetBSD to get ZFS drivers that weren't broken? But I digress). If I cannot get my FreeBSD system to see my ZFS pool, then I will not use it. And this is after already investing the mandatory post-installation week that you have to spend building the ports that render a FreeBSD system minimally functional.
When my FreeBSD system boots, it issues, inter alia, the following complaints:
I do not know why it is complaining of a failed integrity check. My ZorinOS system has no problem finding the logical slices inside the extended slice (and a good thing too, since otherwise it could not boot, because that's where it lives). More to the point, I am doing everything I can to disable the integrity check. Behold:
It may be that I have the right idea, that
is the way to solve this problem, but that by the time /etc/sysctl.conf is read, it is too late, devfs has already been created. I tried to
; but I did succeed by putting the appropriate line inside /etc/fstab and doing a
Perhaps the solution is to do the
at an earlier stage in the boot process. But I cannot figure out how to do that. One thinks of using
statements in the grub menu, after doing
, or perhaps even after doing
. But that is not how I boot my FreeBSD system. I boot it with
That is the only way I have been able to boot my system. I have not been able to get any other technique to work. I cannot boot my system with
, because I cannot get grub to see any filesystem on
, even after doing
. Now, this might be because, as I mentioned earlier, /dev/ada0s3a begins 16 blocks after /dev/ada0s3. Behold:
But even if that were the problem, I should be able to get grub to see the bsd subpartitioning after doing an
, and I should be able to get the following to work:
But it does not work; grub chokes on the
, because it fails to see the bsd subpartitioning.
My theory is that I might solve my problem if I can get the kernel to do
early enough, before creating the devfs filesystem and mounting it on /dev. How do I do this on a system which is booted with
? Is there a file somewhere in the /boot directory where I can put that line, because it clearly doesn't work when I put it in /etc/sysctl.conf? Or am I totally wrong, and the solution lies elsewhere? Thank you in advance for any and all replies.
Jay F. Shachter
FreeBSD 13 is installed on /dev/ada0s3, which is a "primary partition" of the MBR-partitioned root disk (more specifically, the root filesystem is on /dev/ada0s3a, which begins 16 blocks away from the beginning of /dev/ada0s3 because that's where bsdlabel offered to put it, during the installation procedure, and I also have a /dev/ada0s3b which is available for swap if I ever need a swap area, which currently I am doing without).
Why did I choose MBR partitioning for my disk? Because this computer is a multiboot machine, and I intend to install operating systems on it, like ReactOS, which, to the best of my knowledge, do not know how to boot themselves from a GPT slice.
FreeBSD does not know how to install itself onto, or boot itself from, a logical slice, so I installed in onto one of the 3 primary slices. And it's a good thing that I did, because I am running it now, and it does not even see the logical slices. Behold:
Code:
# ls -las /dev/ada0s*
0 crw-r----- 1 root operator 0x5c Nov 8 21:40 /dev/ada0s1
0 crw-r----- 1 root operator 0x5d Nov 8 21:40 /dev/ada0s2
0 crw-r----- 1 root operator 0x5e Nov 8 21:40 /dev/ada0s3
0 crw-r----- 1 root operator 0x62 Nov 8 21:40 /dev/ada0s3a
0 crw-r----- 1 root operator 0x63 Nov 8 21:40 /dev/ada0s3b
0 crw-r----- 1 root operator 0x5f Nov 8 21:40 /dev/ada0s4
#
When my FreeBSD system boots, it issues, inter alia, the following complaints:
Code:
# dmesg | grep -i geom
GEOM_PART: integrity check failed (ada0s4, EBR)
GEOM_PART: integrity check failed (diskid/DISK-WD-WX51A3805XTFs4, EBR)
GEOM_PART: integrity check failed (diskid/DISK-WD-WX51A3805XTFs4, EBR)
GEOM_PART: integrity check failed (diskid/DISK-WD-WX51A3805XTFs4, EBR)
#
Code:
# sysctl -a | grep integrity
kern.geom.part.check_integrity: 0
# cat /etc/sysctl.conf
# $FreeBSD$
#
# This file is read when going to multi-user and its contents piped thru
# ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details.
#
# Uncomment this to prevent users from seeing information about processes that
# are being run under another UID.
#security.bsd.see_other_uids=0
kern.geom.part.check_integrity=0
#
It may be that I have the right idea, that
Code:
kern.geom.part.check_integrity=0
mount -F devfs devfs /mnt/dev
after the system was up, and the command failed with the error message
Code:
mount: devfs: No such file or directory
mount -a
. It did not make a difference. There is still no /dev/ada0s5 or /dev/ada0s6 underneath /mnt/dev, just as there is none underneath /dev.Perhaps the solution is to do the
Code:
kern.geom.part.check_integrity=0
Code:
set
Code:
kfreebsd /boot/kernel/kernel
Code:
kfreebsd /boot/loader
Code:
set root=(hd0,3)
chainloader +1
Code:
kfreebsd
Code:
(hd0,3)
Code:
insmod ufs
Code:
# bsdlabel /dev/ada0s3
# /dev/ada0s3:
8 partitions:
# size offset fstype [fsize bsize bps/cpg]
a: 40000000 16 unused 0 0
b: 1943024 40000016 unused 0 0
c: 41943040 0 unused 0 0 # "raw" part, don't edit
#
Code:
insmod bsd
Code:
insmod bsd
set root=(hd0,3,a)
insmod ufs
kfreebsd /boot/loader
Code:
set root=(hd0,3,a)
My theory is that I might solve my problem if I can get the kernel to do
Code:
kern.geom.part.check_integrity=0
Code:
chainloader +1
Jay F. Shachter