[The example here happens to be for amd64 -> aarch64 cross builds.]
The following is from after copying/moving the kernel from where it
was originally, such as (locally) installed on the build machine.
Example of symbolic links from some recent activity under head
-r323246 (producing -r323246 again):
# ls -lTt /media/boot/kernel/if_igb.ko /mnt/boot/kerndb/if_igb.ko
lrwxr-xr-x 1 root wheel 25 Sep 8 22:47:36 2017 /mnt/boot/kerndb/if_igb.ko
lrwxr-xr-x 1 root wheel 68 Sep 6 20:27:20 2017 /media/boot/kernel/if_igb.ko
In both of these cases the /mnt and /usr/obj/DESTDIRs/ prefixes
would not exist for booting the PINE64 that the USB SSD is for:
so file not found if a usage attempt is made.
Installing absolute path links messes up even the /boot/kernel.old/
handling unless that process carefully replaces the original link
that was in /boot/kernel/ .
In the /mnt/boot/kerndb/if_igb.ko -> /mnt/boot/kernel/if_em.ko
example I made a copy of the installed /mnt/boot/kernel/ area
while the drive was still mounted.
In the /usr/obj/DESTDIRs/ case I had installed to the local
file system before attaching the USB SSD it was to be copied
A relative path would not have such problems with binding to
the wrong file or to no file when copies are made or renames
along the path are done.
[This has come up before on the lists, multiple-times as I
markmi at dsl-only.net
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"