Re: Raspberry Pi 4B is now booting single user mode on FreeBSD 14.0 aarch64. Does it work for you?
Date: Mon, 23 Jan 2023 21:41:28 UTC
On Jan 23, 2023, at 06:53, Fred Finster <fred@thegalacticzoo.com> wrote: > On 1/21/23 17:12, Mark Millard wrote: >> On Jan 20, 2023, at 06:22, Fred Finster<fred@thegalacticzoo.com> wrote: >> >>> was just trying to boot into single user mode from this documentation below: >>> https://people.freebsd.org/~rodrigc/doc/handbook/makeworld.html >>> Once in single-user mode, run these commands if the system is formatted with UFS: >>> >>> |#| *|mount -u /|* >>> |#| *|mount -a -t ufs|* >>> |#| *|swapon -a|* >>> >>> example I created this blog post:https://ghostbsd-arm64.blogspot.com/2023/01/time-make-j4-buildworld.html >>> I could boot into multi-user mode but not into Single User Mode on this Raspberry Pi 4B. >>> What do you suggest and how to trouble shoot? I turned on verbose mode and saw that it hung after starting /sbin/init >>> but do not know why this aarch64 ARM64 BCM2711 cpu hangs on FreeBSD 14.0 going into "single user mode". >>> >>> This Version: >>> >>> root@Fred_RasPi4B:~ # uname -Kmnopr >>> FreeBSD Fred_RasPi4B 14.0-CURRENT arm64 aarch64 1400077 >>> root@Fred_RasPi4B:~ # uname -a >>> FreeBSD Fred_RasPi4B 14.0-CURRENT FreeBSD 14.0-CURRENT #6 main-n259952-7e2600ea7be2-dirty: Sun Jan 15 18:14:05 PST 2023root@Fred_RasPi4B:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-VCHIQ arm64 >> . . . >> >> I've never tried GENERIC-VCHIQ. >> >> Have you tried testing a standard build on some >> media, such as trying a dd of an uncompressed: >> >> http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/14.0/FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20230120-43703bc489ec-260163.img.xz >> >> and seeing if the problem replicates for that in >> your context? If it replicates, then at least you >> know it is not something more specific to your >> context and other folks would be able to test >> similarly with a sufficiently analogous context. >> >> But, if it does not replicate when you try such a >> test, then folks likely would have to try to >> reproduce your context to have a sufficiently >> analogous context to test. >> >> === >> Mark Millard >> marklmi at yahoo.com >> > Mark thank you for answering my email question directly! I realize you, Mark, are busy, with some many details. Your suggestion of using a Snapshot image is good for debugging. > http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/14.0/FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20230120-43703bc489ec-260163.img.xz > Is there a shell script file to build this image, just like FreeBSD.org does? I would like to natively build an image with the VCHIQ patch included from my /usr/src hosted > on the Raspberry Pi 4B /8G dram with a 500GB SSD drive with 92GB FreeBSD partition. The 43703bc489ec part of the *.img.xz name indicates the exact commit used for the snapshot build. Thus you can set up to be using the exact same source content for buildkernel (or even buildworld). This does get into avoiding src.conf and make.conf tailoring and using the same kernel configuration file in order to fully have things the same when that happens to be what is wanted. (This can allow seeing if your own build of deliberately-the-same manages to match the snapshot's behavior.) You can rename the original /boot/kernel in the installed snapshot ( such as to /boot/kerorg ). You can installkernel your own kernel build as /boot/kernel . From the loader you can pick kernel which to boot. The renaming I used as an example makes your build the default for booting. This avoids needing to buildworld or installworld at the time: just a kernel update. It allows trying both kernels with the rest held constant in order to compare/constrast. You can also go the other way: do possible renaming (or deleting) of the kernel on the media that you have been using and copy over /boot/kernel from the snapshot to a desired /boot/* name on your media and then use the snapshot's kernel to try booting with your build of world. Again, it can allow booting both ways and doing comparison and contrast investigations. Of course, you can also do buildworld buildkernel with your intended tailoring, such as using the alternate kernel configuration file, but otherwise based on the same source files used for a snapshot. The official release building scripts and such are intended generally for avoiding any non-standardness in the builds. So I doubt that you would use them for making locally-tailored builds. I do not use them. The tail part of UPDATING has material about doing various types of personal builds/installs/updates, starting with the text "To build a kernel". There are also more instructions in the likes of the /usr/src/Makefile in its initial comment block. It starts around the text: "If you want to build your system from source," It does not cover as many variations. But it can be good to read both sets of instructions. === Mark Millard marklmi at yahoo.com