if_igb.ko symbolic link generation is still messed up in that it hard wires the path at installkernel time, messing up copying to other places

[Mark Millard]

[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 -> /mnt/boot/kernel/if_em.ko
lrwxr-xr-x  1 root  wheel  68 Sep  6 20:27:20 2017 /media/boot/kernel/if_igb.ko -> /usr/obj/DESTDIRs/clang-cortexA53-installkernel/boot/kernel/if_em.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
to.

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
remember.]

===
Mark Millard
markmi at dsl-only.net