From owner-freebsd-current@freebsd.org Sat Sep 9 20:05:04 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3CC3E06D01 for ; Sat, 9 Sep 2017 20:05:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-10.reflexion.net [208.70.210.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 78CEF7714B for ; Sat, 9 Sep 2017 20:05:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1931 invoked from network); 9 Sep 2017 20:05:02 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 9 Sep 2017 20:05:02 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Sat, 09 Sep 2017 16:05:02 -0400 (EDT) Received: (qmail 630 invoked from network); 9 Sep 2017 20:05:02 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 9 Sep 2017 20:05:02 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id CBAE3EC86EF; Sat, 9 Sep 2017 13:05:01 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: 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 Message-Id: Date: Sat, 9 Sep 2017 13:05:01 -0700 To: FreeBSD Toolchain , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 20:05:04 -0000 [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.] =3D=3D=3D Mark Millard markmi at dsl-only.net