Date: Sat, 9 Apr 2022 16:54:23 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: Updating RPi boot materials, was Re: RPI4 panic on boot with -current Message-ID: <05CFCC3A-EE32-468A-9BDD-9A6104F572EE@yahoo.com> In-Reply-To: <20220409221742.GB56550@www.zefox.net> References: <20220409015321.GA52002@www.zefox.net> <D89DA316-FF83-4BB9-A1FD-DE8591B8B3D6@yahoo.com> <20220409154433.GB55458@www.zefox.net> <1B2DD49C-96AD-4586-B9A7-F6D8386D4DE0@yahoo.com> <20220409221742.GB56550@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Apr-9, at 15:17, bob prohaska <fbsd@www.zefox.net> wrote: > On Sat, Apr 09, 2022 at 01:59:10PM -0700, Mark Millard wrote: >> On 2022-Apr-9, at 08:44, bob prohaska <fbsd@www.zefox.net> wrote: >> > >>> Even if one knows which to select and build from ports the >>> make install command doesn't really install; the admin still >>> has to know what files to copy where. >> >> With good reason for where: the msdosfs file system is not part >> of FreeBSD's file systems (UFS or ZFS) and there is no standard >> mount point for the msdosfs in FreeBSD's file system. >> > > I must be missing something here. On the Pi2, Pi3 and Pi4 images > the msdos partition is always mounted at /boot/msdos with /boot > part of UFS and the msdos partition under it. Are you referring > to other platforms? > pkg and such is not limited to RPi* contexts. pkg and such do not have a bunch of logic based on identifying if it is a RPi* or . . . or not and doing different things on that basis. What is it supposed to do for a Rock64, for example? But it is not just that which is at issue . . . I do not have even one example of an aarch64 FreeBSD installation that is limited to booting just one type of aarch64 system. The exact same FreeBSD UFS/ZFS media can be moved between systems and boot almost any of them: HoneyComb, MACCHIATObin Double Shot, various RPi4B's, a RPi3B, and a RPi2B v1.2. (The Rock64 would be in that list if I booted via USB2. But booting it from USB3 is special, requiring a FreeBSD kernel that is not on the media plugged into the USB3 port. But with that kernel, U-Boot, and EFI related material in place on the same media as that extra kernel copy, again all the USB3 aarch64 UFS/ZFS root file systems can be booted. The media with the extra kernel is not as portable.) So how are pkg or other such to deal with updating such generally bootable media? Or: Say that the RPi* has a msdosfs on its USB device that is able to be used for booting. But that, at the time, there is also a microsd card present that capable of being used for booting, at least for the RPi* firmware and u-boot.bin stages. What sort of activity is pkg supposed to do to identify the context? How would pkg even identify, say, which way FreeBSD had been booted? The early stages of RPi* booting are outside FreeBSD's direct control and there are a lot of possibilities. Nothing in FreeBSD says that /boot/msdos should exist or be the mount point used as far as I know. It is just something that the snapshot/PRERELEASE/BETA/RC/RELEASE images happen to currently, do by the free choice of the author(s) involved. In fact, if you tried to use bsdinstall to set up a RPi* context, it would not set up something like the snapshots/PRERELEASEs/BETAs/RCs/RELEASEs as far as I know. Nothing says that RPi*'s have to be set up the same as the snapshot/PRERELEASE/BETA/RC/RELEASE images. The potential differences in question are not part of FreeBSD. Another common convention is /boot/efi (especially when the msdosfs invovled has the FreeBSD efi boot loader as well). FreeBSD does now have some predefined behavior for this convention. What if nothing is mounted to /boot/msdos or to /boot/efi at the time (say, disabled in /etc/fstab)? How much analysis of the context is pkg or such to do and adjust for? The FreeBSD loader.efi has the same sort of "there is no fixed place for it" issue. Other than the /boot/efi use, there is no automatic update of loader.efi either. This is largely because the copy used to boot is not in a FreeBSD UFS/ZFS file system at all --but in some msdosfs file system, possibly with a special partition type. === Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?05CFCC3A-EE32-468A-9BDD-9A6104F572EE>