Date: Sat, 9 Apr 2022 20:39:06 -0700 From: bob prohaska <fbsd@www.zefox.net> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-arm@freebsd.org, bob prohaska <fbsd@www.zefox.net> Subject: Re: Updating RPi boot materials, was Re: RPI4 panic on boot with -current Message-ID: <20220410033906.GA57250@www.zefox.net> In-Reply-To: <FFBEF36E-E8F5-4DF6-9598-9417C18DC324@yahoo.com> 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> <05CFCC3A-EE32-468A-9BDD-9A6104F572EE@yahoo.com> <FFBEF36E-E8F5-4DF6-9598-9417C18DC324@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Apr 09, 2022 at 05:22:49PM -0700, Mark Millard wrote: > > > So how are pkg or other such to deal with updating such generally > > bootable media? I don't think they can be expected to update alien media. There are lots of platform-specific ports for u-boot. Why not match the install target to the named platform? If folks go to the trouble of creating a port for a platform it's little extra work to add the pathnames. What you're talking about seems far more ambitious. > > I should have explicitly noted: How likely is that that I'd happen > to always do FreeBSD updates on a aarch64 RPi* instead of one of > the other systems, especially the faster ones? Is pkg to notice and > update RPi* boot materials because the updated system could also > boot an aarch64 RPi*? > Presumably you'd cross compile a package for the intended target and then install the package on the running target. The platform details would be part of the package. If the target is RPi3 and you're compiling on Cavium, the RPi3 paths would be part of the package. The Cavium won't be running the pkg install, but I don't think that's possible in any case. Both pkg and make install work on the host they're running on, no? > This better illustrates what I'm referring to when I reference pkg > and the like identifying contexts and handling a variety of them. > Should it be checking if it happens to be running on a RPi* and > behave differently than it would on other types of systems (same > boot media)? > That's the admin's discretion. He knows what the target architecture is and the media being written. > > 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? > > I'd suggest this is an unrealistic scenario. Pkg can know what files it's supposed to update, the admin has to make those files accessible. If the wrong paths are mounted, that's a wetware problem. > > The early stages of RPi* booting are outside FreeBSD's direct > > control and there are a lot of possibilities. > > Yes, too many. The admin has to constrain them. > > 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. > > But it does exist and is useful. Why not use it? > > 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. > > Can it work at all? I always prefered the installer whose man page said it was "greaty in need of death". > > 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. > > But in practice they are, and it's useful for most folks. > > 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. > > Curiously, my Pi4 has an empty /boot/efi, but I've never tampered with it. > > 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? > > Just report "path not found" and list what was expected. > > 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. > My plea is not for adaptability, but acceptance of convention. Identify a platform and a location then put that info in the port install target. Let convention be set by the image. If you got this far, thanks for reading! bob prohaska
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220410033906.GA57250>