Change FreeBSD Loader's loaddev variable

Hello,

I'm searching the way to change loaddev variable of FreeBSD's /boot/loader. There is nothing useful either in FreeBSD's man, or in Google.
By default it should be the same as currdev, but I have currdev=disk0s2:, but loaddev=disk0p2:.

How to change it to load loader.conf and other configs from the partition I want?
When I try set loaddev=disk0s2: I get operation not permitted..

Any idea?
 
Normally you only need to set
"vfs.root.mountfrom"
in loader.conf

In exceptional cases you can set also
"currdev"
in loader.conf.

No idea what loaddev is good for.

Which is the root partition you want to mount during boot ?
Where is the kernel you want to load during boot ?
 
My guess is that loaddev is set from an EFI variable.

efivar -l | grep Loader
cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderDev
 
I'm searching the way to change loaddev variable of FreeBSD's /boot/loader.
As you noticed, modifying the loaddev variable is not permitted, so it can't be changed. covacat has provided an explanation in post # 5 why it's not possible.

How to change it to load loader.conf and other configs from the partition I want?
I suspect you are trying to boot different UFS root partitions installed on one disk or on multiple disks.

There is no need to use loaddev for that, just set currdev. For the loader.conf of the specified root partition to be read, the currdev environment must be set in a configuration file. Manually setting it at the loader prompt won't read the loader.conf of the booted system.

For BIOS systems set the currdev environment by boot.config(5). The configuration file must be created on the first root partition where the boot loader partition (freebsd-boot) is located.

The manual shows examples only for a MBR partition scheme, below are examples for GPT.

/boot.config

Boot loader from the first disk, partition 3:
Code:
0:ad(0p3)/boot/loader

Boot loader from the second disk, partition 2:
Code:
1:ad(1p2)/boot/loader


For UEFI systems set currdev through loader.env, which must be created in the efi partition (ESP).

/boot/efi/efi/freebsd/loader.env
Code:
currdev=disk0p3:
Note! - Mind the colon at the end of the variable.

Set the desired variables in the respective loader.conf of the root partition to be booted.

By default it should be the same as currdev, but I have currdev=disk0s2:, but loaddev=disk0p2:.
Not sure why there are MBR (disk0s2) and GPT (disk0p2) slice/partition names listed. Has the system maybe two disks (disk0 and disk1), one with MBR the other with GPT partition scheme and you miss-typed the disk number of one of them when posting here?

Even then, a MBR root partition slice name should be something like disk0s2a.
 
I can't give a direct answer here, but it does have a faint smell of an XY-problem.

Would you mind to add some details about the problem to solve?
There are 2 partitions. Each of them has /boot.
On each partition there is also /boot/loader.conf.
The first one contains vfs.root.mountfrom="ufs:/dev/ada0s1".
The second contains vfs.root.mountfrom="ufs:/dev/ada0s2".
There is also Grub 2:

menuentry 'disk 0, slice 1' {
kfreebsd /boot/loader
}

menuentry 'disk 0, slice 2'
kfreebsd /boot/loader
}

bsd_disklabel-on-mbr is not used there.


Menuentry 1 (disk 0, slice 1) works fine.
Menuentry 2 (disk 0, slice 2) boots 1st partition's FreeBSD.


Seems loaders of both partitions readloader.conf from the 1st partition.

I need each loader to read respective loader.conf from respective partition.
 
As you noticed, modifying the loaddev variable is not permitted, so it can't be changed. covacat has provided an explanation in post # 5 why it's not possible.


I suspect you are trying to boot different UFS root partitions installed on one disk or on multiple disks.

There is no need to use loaddev for that, just set currdev. For the loader.conf of the specified root partition to be read, the currdev environment must be set in a configuration file. Manually setting it at the loader prompt won't read the loader.conf of the booted system.

For BIOS systems set the currdev environment by boot.config(5). The configuration file must be created on the first root partition where the boot loader partition (freebsd-boot) is located.

The manual shows examples only for a MBR partition scheme, below are examples for GPT.

/boot.config

Boot loader from the first disk, partition 3:
Code:
0:ad(0p3)/boot/loader

Boot loader from the second disk, partition 2:
Code:
1:ad(1p2)/boot/loader


For UEFI systems set currdev through loader.env, which must be created in the efi partition (ESP).

/boot/efi/efi/freebsd/loader.env
Code:
currdev=disk0p3:
Note! - Mind the colon at the end of the variable.

Set the desired variables in the respective loader.conf of the root partition to be booted.


Not sure why there are MBR (disk0s2) and GPT (disk0p2) slice/partition names listed. Has the system maybe two disks (disk0 and disk1), one with MBR the other with GPT partition scheme and you miss-typed the disk number of one of them when posting here?

Even then, a MBR root partition slice name should be something like disk0s2a.
Is there any way for ```loader``` to do it?
Maybe there is a way to do some menu using ```/boot/lua/menu.lua```, so there will be a custom menu with:
1. Boot multiuser from ada0s1
2. Boot multiuser from ada0s2
or something like that?
 
What am I searching for is a way to create custom menu without learning lua or 4th.
Seems menu can be very flexible, but it's flexibility is not used, -- it just boots 1 setup (Yes, there are bootenvs for ZFS...)

Maybe some templates to change menu.lua?


There is an another way -- boot kernel directly by Grub via:
Code:
kfreebsd /boot/kernel/kernel
set kFreeBSD.root.mountfrom="ufs:/dev/adaXsY"

but Grub's ability to load FreeBSD's kernel depends on hardware. On some platforms (including Qemu) Grub won't boot FreeBSD's kernel, but just will reboot.

On EFI is even worse, -- not only Grub can refuse to work with FreeBSD's kernel, but chainloading /boot/loader.efi will lead to some white web on your display instead of letters and numbers.
 
There is also Grub 2:
Then you probably must set the root device from within grub, e.g. something like set root=(hd0,1) for the second entry (that's at least my assumption, I don't use grub....). Note that on an EFI system, you can just chainload with e.g. chainloader /boot/loader.efi (instead of kfreebsd).
 
it looks like grub can set some of the loader vars
dont know if it works but you can try
 
Then you probably must set the root device from within grub, e.g. something like set root=(hd0,1) for the second entry (that's at least my assumption, I don't use grub....). Note that on an EFI system, you can just chainload with e.g. chainloader /boot/loader.efi (instead of kfreebsd).
Loader from (hd0,2) will read config on (hd0,1), no matter what grub thinks about it. Loader from (hd0,{3,4,5,6,7,8,9,etc}) will also read config in (hd0,1). After initiative has passed to FreeBSD's Loader there is no Grub, there is only Loader and it's configs.

Chainloading /boot/loader.efi not always work. Depends on hardware. You can see your system successfully booted or some white thin lines on black screen. May be there is some hack, but I don't know about it.
 
it looks like grub can set some of the loader vars
dont know if it works but you can try
Thanks.
I know those solutions.
It partly works, if you're lucky with your hardware. For some reason Grub can boot FreeBSD on one computer and refuse to bo it one another one (reboots, hangs).
 
That's how "chainloader /boot/loader.efi" looks like.
 

Attachments

  • 22.png
    22.png
    21.9 KB · Views: 178
UPD about loader.efi:
There some info obtained via serial:
Code:
Consoles: EFI console 
    Reading loader env vars from /efi/freebsd/loader.env
Setting currdev to disk0p1:
FreeBSD/amd64 EFI loader, Revision 1.1

   Command line arguments: loader.efi
   Image base: 0x7ccf3000
   EFI version: 2.70
   EFI Firmware: EDK II (rev 1.00)
   Console: efi (0x20001000)
   Load Path: \boot/loader.efi
   Load Device: PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)/HD(1,MBR,0xB942BBED,0x800,0x3FF800)
   BootCurrent: 0008
   BootOrder: 0008[*] 0000 0001 0002 0003 0004 0005 0006 0007
   BootInfo Path: HD(1,MBR,0xB942BBED,0x800,0x3FF800)/\EFI\ubuntu\shimx64.efi
Ignoring Boot0008: Only one DP found
Trying ESP: PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)/HD(1,MBR,0xB942BBED,0x800,0x3FF800)
Setting currdev to disk0p1:
Trying: PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)/HD(2,MBR,0xB942BBED,0x400000,0x3FF800)
Setting currdev to disk0p2:
Trying: PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)/HD(3,MBR,0xB942BBED,0x7FF800,0x3FF800)
Setting currdev to disk0p3:
Trying: PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)/HD(4,MBR,0xB942BBED,0xBFF000,0x401000)
Setting currdev to disk0p4:
Failed to find bootable partition
Seems I need to get somewhere loader.env and put it to /EFI/freebsd/.
 
UPD 2:
loader.efi can't see FAT32 (msdosfs), only UFS2.

UPD 3:
I can pass options currdev="disk0p1" rootdev="disk0p1" to /boot/loader.efi but non-efi /boot/loader just ignore them.
 
So as for now I have 2 questions:
1. Is there any way to pass options to non-efi /boot/loader?
2. Is there any way to force /boot/loader.efi see FAT32?
Found the reason of "white web" instead of letters and numbers -- FreeBSD use serial output instead of VGA.
So, question 3 is:
3. How to pass from Grub2 to Loader.efi to use VGA instead of serial?
 
rEFInd Boot Manager, might be a possible answer to your need for a BOOT MENU. I have used rEFInd with GhostBSD and Linux to select which partition to boot to select which operating system.
http://www.rodsbooks.com/refind/ Getting Refind from ZIP file on Sourceforge Installing Refind

Refind searches all the Partitions for Bootable images and then displays ICONs for each. Then you can move left or right from icon to icon, and hit enter key to boot that one. Works good. If you change the bootable partitions it insitu builds a different display of icons, so you don't have to update the menu. Good working Idea. rEFInd features.

In theory, EFI implementations should provide boot managers. Unfortunately, in practice these boot managers are often so poor as to be useless. The worst I've personally encountered is on Gigabyte's Hybrid EFI, which provides you with no boot options whatsoever, beyond choosing the boot device (hard disk vs. optical disc, for instance). I've heard of others that are just as bad. For this reason, a good EFI boot manager—either standalone or as part of a boot loader—is a practical necessity for multi-booting on an EFI computer. That's where rEFInd comes into play.
From a boot Raspberry Pi 4B
efivar -l | grep Loader
cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderDev
efibootmgr -v
BootCurrent: 0000
efivar -l
8be4df61-93ca-11d2-aa0d-00e098032b8c-SecureBoot
8be4df61-93ca-11d2-aa0d-00e098032b8c-SetupMode
8be4df61-93ca-11d2-aa0d-00e098032b8c-AuditMode
8be4df61-93ca-11d2-aa0d-00e098032b8c-DeployedMode
8be4df61-93ca-11d2-aa0d-00e098032b8c-VendorKeys
8be4df61-93ca-11d2-aa0d-00e098032b8c-PlatformLangCodes
8be4df61-93ca-11d2-aa0d-00e098032b8c-PlatformLang
8be4df61-93ca-11d2-aa0d-00e098032b8c-OsIndicationsSupported
8be4df61-93ca-11d2-aa0d-00e098032b8c-OsIndications
cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderDev
set
BLOCKSIZE=K
ENV=/root/.shrc
HOME=/root
IFS=$' \t
'
LANG=C.UTF-8
LOGNAME=root
MAIL=/var/mail/root
MM_CHARSET=UTF-8
OLDPWD=/boot/efi/EFI
OPTIND=1
PAGER=less
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
PPID=1457
PS1='\u@\h:\w \$ '
PS2='> '
PS4='+ '
PWD=/boot/efi/EFI/freebsd
SHELL=/bin/sh
TERM=vt100
USER=root
_=-l


 

Attachments

  • refind.png
    refind.png
    83.5 KB · Views: 97
Back
Top