Date: Thu, 23 Apr 2020 18:16:14 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Booting from USB on RPI3 Message-ID: <74DB7BC9-8F60-404B-BF7B-02B06D5A1011@yahoo.com> In-Reply-To: <20200423233259.GD3996@www.zefox.net> References: <mailman.61.1587470402.80084.freebsd-arm@freebsd.org> <trinity-4938b1d4-f29f-4907-bedd-65be21112e48-1587489497227@3c-app-webde-bs65> <20200421181224.GC96994@www.zefox.net> <trinity-19081201-3024-4046-817a-48321c51a515-1587587309088@3c-app-webde-bap64> <20200423162124.GA3583@www.zefox.net> <CAJuc1zMHL6ke3LH67iV8%2BogKFO18xwW_v7bRAUsj8CbxD2EOTw@mail.gmail.com> <8D1F6A8D-4910-4C1E-8EB5-2F5F89E31120@yahoo.com> <CAJuc1zOTnoRmeaKXHMTH9po=6ipBYDxvxAoiVmow-sNgwUERVQ@mail.gmail.com> <20200423212614.GA3996@www.zefox.net> <328B7083-1119-43F1-A6E4-61F1FB9E922E@yahoo.com> <20200423233259.GD3996@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Apr-23, at 16:32, bob prohaska <fbsd at www.zefox.net> wrote: > On Thu, Apr 23, 2020 at 03:24:57PM -0700, Mark Millard wrote: >> >> >> >> For USB-only or for microsd card also in use, >> have you tried the equivalent of: >> >> OK lsdev >> > Another surprise. First time I tried, after some time idle: > OK lsdev > unknown command > but a simple > ls > listed the contents of the root directory. Apparently the > drive was asleep after an idle timeout. > > A second attempt at lsdev produced > OK lsdev > disk devices: > disk0: 250085377 X 512 blocks (removable) > disk0s1: DOS/Windows > disk0s2: FreeBSD > disk0s2a: FreeBSD UFS > disk0s2b: FreeBSD swap > disk1: 78140161 X 512 blocks > disk1s1: DOS/Windows > disk1s2: FreeBSD > disk1s2a: FreeBSD UFS > disk1s2b: FreeBSD swap > http: (unknown) > net devices: > net0: Where both the microsd card (disk0) and the USB drive (disk1) set up via installing FreeBSD distributed .iso's, at least for how the file systems were created (even if somewhat adjusted later)? If yes, it may be that you have two instances of each of: /dev/msdosfs/MSDOSBOOT /dev/ufs/rootfs one per disk* for each. These types of naming are expecting to have been set up with what is after the last / being a unique name relative to everything else potentially present at the same time. This means that two .iso installs would need to have been adjusted to make the names distinct before trying to use the media together. If these names are duplicated, then use of the notations in /etc/fstab would be ambiguous for identifying the drives and I've no clue which instance wins --or if which wins is even stable. For ufs, tunefs has an option for setting the file system label: -L volname Add/modify an optional file system volume label. Legal characters are alphanumerics, dashes, and underscores. Once the adjustment is seen (remount/reboot?), that should make: /dev/ufs/... change to the new name. I'm only aware of file systsem creation-time setting for msdos via newfs_msdos : -L label Volume label (up to 11 characters). The label should consist of only those characters permitted in regular DOS (8+3) filenames. That should make /dev/msdosfs/... be the assigned name. But newfs_msdos would not preserve the contents of the file system that was present before (if any). glabel can be used to assign labels that are independent of the file system and of the partition metadata, labels that would appear under /dev/label/ instead of under /dev/ufs/ or /dev/msdosfs/ or /dev/gpt/ . (gpt is not an option for MBR contexts.) >> and then used the naming convention shown in >> the output for any loader commands/settings >> instead of using FreeBSD-stage da0 based naming? >> (You might want to report what lsdev shows.) >> >> Note: the disk0 and disk1 like prefixes are >> copied from the u-boot notations that the >> loader gets from u-boot, if I understand >> right. >> >> Does your loader.conf do anything to control >> what is booted? > > Not in a way I recognize, but you might: > OK more /boot/loader.conf > *** FILE /boot/loader.conf BEGIN *** > # Configure USB OTG; see usb_template(4). > hw.usb.template=3 > umodem_load="YES" > # Multiple console (serial+efi gop) enabled. > boot_multicons="YES" > boot_serial="YES" > # Disable the beastie menu and color > beastie_disable="YES" > loader_color="NO" > *** FILE /boot/loader.conf END *** Nothing there to control what is booted. > As Joanathan asked: what does >> your /etc/fstab have listed? (/etc/fstab should >> have FreeBSD notations, not loader device names.) > > OK more /etc/fstab > *** FILE /etc/fstab BEGIN *** > # Custom /etc/fstab for FreeBSD embedded images > /dev/ufs/rootfs / ufs rw 1 1 > /dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime 0 0 > tmpfs /tmp tmpfs rw,mode=1777,size=50m 0 0 > *** FILE /etc/fstab END *** > OK See earlier notes: each media may be defining what causes /dev/ufs/rootfs , leading to ambiguity. Similarly for /dev/msdosfs/MSDOSBOOT . /etc/fstab should use notation that is a unique identification for each device. The media should have names assigned that are unique compared to anything else potentially connected at the same time if labeling style names are to be used. Names like /dev/da* are not stable from boot to boot if multiple USB media are present at the same time: which media gets which da* name could vary from boot to boot. Using some form of unique label assignment is a way of avoiding this. However, if you stick to only one USB drive being present, likely /dev/da0s2a would be a stable USB drive ufs file system reference for that context. Similarly for /dev/da0s1 being a stable reference to the USB msdosfs . /dev/mmcsd0s1 would likely also be a stable microsd card msdosfs reference for your context. Similarly for /dev/mmcsd0s2a for being a stable reference to your microsd card ufs file system. For now such notations may be better for your /etc/fstab file(s). >> Are there any other boot-contributing files that >> would be appropriate to show together in one >> message for review, including any on the >> msdos file system? >> > > I don't know how to answer that question. Since the machine > has gotten to loader and it's looking at the USB drive it's > very tempting to think the msdos part is done. I'll admit > that names like /dev/ufs/rootfs seem rather obscure. > Are they required for RAID? > An example: does either media have in its msdos file system: /EFI/FreeBSD/loader.env ? If yes, are the settings present in loader.env that contribute to what boots? (That is something from Jonathan's exchanges with you.) A separate question is: Other than bootcode.bin , are the contents in the two msdos files systems identical? === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?74DB7BC9-8F60-404B-BF7B-02B06D5A1011>