From nobody Sun Mar 12 04:31:32 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PZ6Lh11w5z3xKq3 for ; Sun, 12 Mar 2023 04:31:40 +0000 (UTC) (envelope-from dpostolov@yandex.ru) Received: from forward500b.mail.yandex.net (forward500b.mail.yandex.net [IPv6:2a02:6b8:c02:900:1:45:d181:d500]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PZ6Lf61HWz3j6R for ; Sun, 12 Mar 2023 04:31:38 +0000 (UTC) (envelope-from dpostolov@yandex.ru) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yandex.ru header.s=mail header.b=vuKsVOry; spf=pass (mx1.freebsd.org: domain of dpostolov@yandex.ru designates 2a02:6b8:c02:900:1:45:d181:d500 as permitted sender) smtp.mailfrom=dpostolov@yandex.ru; dmarc=pass (policy=none) header.from=yandex.ru Received: from myt6-fe378243d6ea.qloud-c.yandex.net (myt6-fe378243d6ea.qloud-c.yandex.net [IPv6:2a02:6b8:c12:488f:0:640:fe37:8243]) by forward500b.mail.yandex.net (Yandex) with ESMTP id 54C895ED19 for ; Sun, 12 Mar 2023 07:31:34 +0300 (MSK) Received: by myt6-fe378243d6ea.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id WVXlV4UbkuQ1-llojbyKQ; Sun, 12 Mar 2023 07:31:33 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1678595493; bh=9a4lGXNvMS7evb6tcSc6Xioe/EGNmdCq1qoivA//keQ=; h=In-Reply-To:From:Date:References:To:Subject:Message-ID; b=vuKsVOryYztkbyle4pLnSJQ7PrsrJKHDUGOAEZO+sBA47PSkI8lpY4a78xyUYc1SE X3MlSKBRMtOT0bzlwzdj4CYgGz6BdiTjKIzfkmmt9WVY6vsL6/LDbwCLjJGNSd32gh OCdrCUSlaNzoThvwk4xrGCaYYI+gSwFbaFf9EbjI= Message-ID: Date: Sun, 12 Mar 2023 09:31:32 +0500 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: FreeBSD 13.2-RC1 and RC2 FPS in screensaver drops after hours To: stable@freebsd.org References: Content-Language: en-US From: Dmitrii Postolov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[yandex.ru,none]; R_SPF_ALLOW(-0.20)[+ip6:2a02:6b8:c00::/40]; R_DKIM_ALLOW(-0.20)[yandex.ru:s=mail]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[stable@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[yandex.ru]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:208722, ipnet:2a02:6b8::/32, country:FI]; DKIM_TRACE(0.00)[yandex.ru:+]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_FROM(0.00)[yandex.ru]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; DWL_DNSWL_NONE(0.00)[yandex.ru:dkim] X-Rspamd-Queue-Id: 4PZ6Lf61HWz3j6R X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Hi to all! Sorry for my bad English... Intel NUC7PJYH (Intel J5005 Intel UHD Graphics 605) The problem persists in FreeBSD 13.2-RC2. FPS40: https://disk.yandex.ru/i/0cYL4oSDi1vAtQ FPS18: https://disk.yandex.ru/i/qYSVdda2YPnOaQ dmitrii@nuc7:~ % pkg info drm-510-kmod drm-510-kmod-5.10.163_2 Name           : drm-510-kmod Version        : 5.10.163_2 dmitrii@nuc7:~ % pkg info gpu-firmware-intel-kmod-geminilake gpu-firmware-intel-kmod-geminilake-20230210_1 Name           : gpu-firmware-intel-kmod-geminilake Version        : 20230210_1 dmesg FreeBSD-13.2-RC2 Copyright (c) 1992-2021 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994     The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.2-RC2 releng/13.2-n254580-5a905d8219bb GENERIC amd64 FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git llvmorg-14.0.5-0-gc12386ae247c) VT(efifb): resolution 1920x1080 CPU: Intel(R) Pentium(R) Silver J5005 CPU @ 1.50GHz (1497.60-MHz K8-class CPU)   Origin="GenuineIntel"  Id=0x706a1  Family=0x6  Model=0x7a Stepping=1 Features=0xbfebfbff Features2=0x4ff8ebbf   AMD Features=0x2c100800   AMD Features2=0x101   Structured Extended Features=0x2294e287   Structured Extended Features2=0x40400004   Structured Extended Features3=0xac000400   XSAVE Features=0xf   IA32_ARCH_CAPS=0xc6a   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr   TSC: P-state invariant, performance statistics real memory  = 8589934592 (8192 MB) avail memory = 7801671680 (7440 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: WARNING: L1 data cache covers fewer APIC IDs than a core (0 < 1) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" random: unblocking device. ioapic0 irqs 0-119 Launching APs: 3 2 1 random: entropy device external interface kbd1 at kbdmux0 efirtc0: efirtc0: registered as a time-of-day clock, resolution 1.000000s smbios0: at iomem 0x69f6d000-0x69f6d01e smbios0: Version: 3.2, BCD Revision: 3.2 aesni0: acpi0: unknown: I/O range not supported cpu0: on acpi0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x77 on acpi0 atrtc0: Warning: Couldn't map I/O. atrtc0: registered as a time-of-day clock, resolution 1.000000s Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed00000-0xfed003ff irq 8 on acpi0 Timecounter "HPET" frequency 19200000 Hz quality 950 Event timer "HPET" frequency 19200000 Hz quality 550 Event timer "HPET1" frequency 19200000 Hz quality 440 Event timer "HPET2" frequency 19200000 Hz quality 440 Event timer "HPET3" frequency 19200000 Hz quality 440 Event timer "HPET4" frequency 19200000 Hz quality 440 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xf000-0xf03f mem 0xa0000000-0xa0ffffff,0x90000000-0x9fffffff at device 2.0 on pci0 vgapci0: Boot video device hdac0: mem 0xa1310000-0xa1313fff,0xa1000000-0xa10fffff irq 25 at device 14.0 on pci0 pci0: at device 15.0 (no driver attached) ahci0: port 0xf090-0xf097,0xf080-0xf083,0xf060-0xf07f mem 0xa1314000-0xa1315fff,0xa131a000-0xa131a0ff,0xa1319000-0xa13197ff at device 18.0 on pci0 ahci0: AHCI v1.31 with 2 6Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 pcib1: at device 19.0 on pci0 pci1: on pcib1 rtsx0: <2.1g Realtek RTS5229 PCIe SD Card Reader> mem 0xa1200000-0xa1200fff at device 0.0 on pci1 rtsx0: No card is detected pcib2: at device 19.2 on pci0 pci2: on pcib2 re0: port 0xe000-0xe0ff mem 0xa1104000-0xa1104fff,0xa1100000-0xa1103fff at device 0.0 on pci2 re0: Using 1 MSI-X message re0: ASPM disabled re0: Chip rev. 0x54000000 re0: MAC rev. 0x00100000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Using defaults for TSO: 65518/35/2048 re0: Ethernet address: xx:xx:xx re0: netmap queues/slots: TX 1/256, RX 1/256 xhci0: mem 0xa1300000-0xa130ffff irq 17 at device 21.0 on pci0 xhci0: 32 bytes context size, 64-bit DMA usbus0 on xhci0 usbus0: 5.0Gbps Super Speed USB v3.0 sdhci_pci0: mem 0xa1318000-0xa1318fff,0xa1317000-0xa1317fff irq 39 at device 28.0 on pci0 sdhci_pci0: 1 slot(s) allocated mmc0: on sdhci_pci0 isab0: at device 31.0 on pci0 isa0: on isab0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbdc0: non-PNP ISA device will be removed from GENERIC in FreeBSD 14. uart0: at port 0x3f8 irq 4 flags 0x10 on isa0 uart0: non-PNP ISA device will be removed from GENERIC in FreeBSD 14. est0: on cpu0 Timecounter "TSC" frequency 1497600051 Hz quality 1000 Timecounters tick every 1.000 msec ZFS filesystem version: 5 ZFS storage pool version: features support (5000) hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 33 and 25 on hdaa0 pcm1: at nid 27 on hdaa0 pcm2: at nid 30 on hdaa0 hdacc1: at cad 2 on hdac0 hdaa1: at nid 1 on hdacc1 pcm3: at nid 3 on hdaa1 ugen0.1: at usbus0 uhub0 on usbus0 uhub0: on usbus0 mmc0: No compatible cards found on bus ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ACS-4 ATA SATA 3.x device ada0: Serial Number 200312A004C2 ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) ada0: Command Queueing enabled ada0: 238475MB (488397168 512 byte sectors) Trying to mount root from zfs:zroot/ROOT/default []... uhub0: 16 ports with 16 removable, self powered Root mount waiting for: usbus0 ugen0.2: at usbus0 ugen0.3: at usbus0 ukbd0 on uhub0 ukbd0: on usbus0 kbd2 at ukbd0 drmn0: on vgapci0 vgapci0: child drmn0 requested pci_enable_io vgapci0: child drmn0 requested pci_enable_io [drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-19). [drm] Got stolen memory base 0x7c000000, size 0x4000000 drmn0: [drm] couldn't get memory information drmn0: [drm] Applying Increase DDI Disabled quirk drmn0: successfully loaded firmware image 'i915/glk_dmc_ver1_04.bin' drmn0: [drm] Finished loading DMC firmware i915/glk_dmc_ver1_04.bin (v1.4) sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)! [drm] Initialized i915 1.6.0 20200917 for drmn0 on minor 0 VT: Replacing driver "efifb" with new "fb". start FB_INFO: type=11 height=1080 width=1920 depth=32 pbase=0x90000000 vbase=0xfffff80090000000 name=drmn0 flags=0x0 stride=7680 bpp=32 end FB_INFO acpi_wmi0: on acpi0 acpi_wmi0: Embedded MOF found ACPI: \134AMW0.WQBA: 1 arguments were passed to a non-method ACPI object (Buffer) (20201113/nsarguments-361) ichsmb0: port 0xf040-0xf05f mem 0xa1316000-0xa13160ff at device 31.1 on pci0 smbus0: on ichsmb0 lo0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP ums0 on uhub0 ums0: on usbus0 ums0: 3 buttons and [XYZ] coordinates ID=0 uhid0 on uhub0 uhid0: on usbus0 device_attach: uhid0 attach returned 12 uhid0 on uhub0 uhid0: on usbus0 uhid1 on uhub0 uhid1: on usbus0 device_attach: uhid1 attach returned 12 Security policy loaded: MAC/ntpd (mac_ntpd) 10.03.2023 23:12, Dmitrii Postolov пишет: > FreeBSD 13.2-RC1 FPS in screensaver drops after hours > > Hi all! Sorry for my bad English... > > I have access to several computers running FreeBSD 13.2-RC1 and Intel > (U)HD Graphics. For example, it is an Intel NUC7PJYH (Intel J5005) and > an Acer Revo Box RN86 (Intel Core i5-9400T). Additionally, I can > experiment with Intel NUC5PPYH (Intel N3700) and Acer Aspire XC-895 > (Intel Core i5-10400) if needed. > > I am using Xfce 4.18, drm-510-kmod video driver (installed from pkg or > built from ports). Xfce uses xscreensaver and Ant Inspect screensaver > with FPS counter and CPU Load counter enabled. > > Normally the FPS value is FPS 40 and CPU Load 15%, but if the > screensaver has been running for several hours the FPS can drop to > about FPS 18. The CPU Load value also increases. > > All serious applications were terminated before the screensaver was > turned on. > > Powerd is on by default on these computers, I can try to turn it off. > > I have not noticed this problem in previous releases of FreeBSD. > > Could this situation indicate a problem with FreeBSD's graphics > subsystem? > > P.S. FreeBSD 13.2-RC2 will be available soon and I will do more > detailed experiments with it, and bring stats and FPS screen shots. > > From nobody Mon Mar 13 10:01:37 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PZsd466V4z3xTnS for ; Mon, 13 Mar 2023 10:01:44 +0000 (UTC) (envelope-from dpostolov@yandex.ru) Received: from forward502a.mail.yandex.net (forward502a.mail.yandex.net [IPv6:2a02:6b8:c0e:500:1:45:d181:d502]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PZsd30Shhz3JSr for ; Mon, 13 Mar 2023 10:01:42 +0000 (UTC) (envelope-from dpostolov@yandex.ru) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yandex.ru header.s=mail header.b=tIzZMvzC; spf=pass (mx1.freebsd.org: domain of dpostolov@yandex.ru designates 2a02:6b8:c0e:500:1:45:d181:d502 as permitted sender) smtp.mailfrom=dpostolov@yandex.ru; dmarc=pass (policy=none) header.from=yandex.ru Received: from vla1-19b50e1e87d6.qloud-c.yandex.net (vla1-19b50e1e87d6.qloud-c.yandex.net [IPv6:2a02:6b8:c0d:3e8b:0:640:19b5:e1e]) by forward502a.mail.yandex.net (Yandex) with ESMTP id D94FF5EA31 for ; Mon, 13 Mar 2023 13:01:38 +0300 (MSK) Received: by vla1-19b50e1e87d6.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id b1eNumgcAa61-dJHMQaye; Mon, 13 Mar 2023 13:01:38 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1678701698; bh=794bZs2J1dOyC06h+ZEoqgSWWlC9Rc75rUsgxd7DEC4=; h=In-Reply-To:From:Date:References:To:Subject:Message-ID; b=tIzZMvzCjTBESV0Xh1kdNalnegZYXAFLb+ury6IAVrdzCeDVIvk3MwC+RGshyLOcC mYCdkicvyLaaJNIFv9sUvTbmijd+bILDBLYTyrBh08kA25hAVmiImsx3luPYu5Us5g H6s0dP52Z0kKmXBHtEKCGAKD0GOqljMrd+1MiWco= Message-ID: Date: Mon, 13 Mar 2023 15:01:37 +0500 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [Probably SOLVED] FreeBSD 13.2-RC2 FPS in screensaver drops after hours To: stable@freebsd.org References: Content-Language: en-US From: Dmitrii Postolov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.998]; NEURAL_HAM_SHORT(-0.99)[-0.992]; DMARC_POLICY_ALLOW(-0.50)[yandex.ru,none]; R_SPF_ALLOW(-0.20)[+ip6:2a02:6b8:c00::/40]; R_DKIM_ALLOW(-0.20)[yandex.ru:s=mail]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[stable@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[yandex.ru]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:208722, ipnet:2a02:6b8::/32, country:FI]; DKIM_TRACE(0.00)[yandex.ru:+]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_FROM(0.00)[yandex.ru]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; DWL_DNSWL_NONE(0.00)[yandex.ru:dkim] X-Rspamd-Queue-Id: 4PZsd30Shhz3JSr X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Hi to all! [Probably SOLVED]. With the setting in /etc/rc.conf 'powerd_enable="NONE"' the problem does not occur in FreeBSD 13.2-RC2. 12.03.2023 09:31, Dmitrii Postolov пишет: > Hi to all! Sorry for my bad English... > > Intel NUC7PJYH (Intel J5005 Intel UHD Graphics 605) > > The problem persists in FreeBSD 13.2-RC2. > > FPS40: https://disk.yandex.ru/i/0cYL4oSDi1vAtQ > FPS18: https://disk.yandex.ru/i/qYSVdda2YPnOaQ > > dmitrii@nuc7:~ % pkg info drm-510-kmod > drm-510-kmod-5.10.163_2 > Name           : drm-510-kmod > Version        : 5.10.163_2 > > dmitrii@nuc7:~ % pkg info gpu-firmware-intel-kmod-geminilake > gpu-firmware-intel-kmod-geminilake-20230210_1 > Name           : gpu-firmware-intel-kmod-geminilake > Version        : 20230210_1 > > dmesg FreeBSD-13.2-RC2 > > Copyright (c) 1992-2021 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >     The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 13.2-RC2 releng/13.2-n254580-5a905d8219bb GENERIC amd64 > FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git > llvmorg-14.0.5-0-gc12386ae247c) > VT(efifb): resolution 1920x1080 > CPU: Intel(R) Pentium(R) Silver J5005 CPU @ 1.50GHz (1497.60-MHz > K8-class CPU) >   Origin="GenuineIntel"  Id=0x706a1  Family=0x6  Model=0x7a Stepping=1 > Features=0xbfebfbff > > Features2=0x4ff8ebbf > >   AMD Features=0x2c100800 >   AMD Features2=0x101 >   Structured Extended > Features=0x2294e287 >   Structured Extended Features2=0x40400004 >   Structured Extended > Features3=0xac000400 >   XSAVE Features=0xf >   IA32_ARCH_CAPS=0xc6a >   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr >   TSC: P-state invariant, performance statistics > real memory  = 8589934592 (8192 MB) > avail memory = 7801671680 (7440 MB) > Event timer "LAPIC" quality 600 > ACPI APIC Table: > WARNING: L1 data cache covers fewer APIC IDs than a core (0 < 1) > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > FreeBSD/SMP: 1 package(s) x 4 core(s) > random: registering fast source Intel Secure Key RNG > random: fast provider: "Intel Secure Key RNG" > random: unblocking device. > ioapic0 irqs 0-119 > Launching APs: 3 2 1 > random: entropy device external interface > kbd1 at kbdmux0 > efirtc0: > efirtc0: registered as a time-of-day clock, resolution 1.000000s > smbios0: at iomem 0x69f6d000-0x69f6d01e > smbios0: Version: 3.2, BCD Revision: 3.2 > aesni0: > acpi0: > unknown: I/O range not supported > cpu0: on acpi0 > attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > atrtc0: port 0x70-0x77 on acpi0 > atrtc0: Warning: Couldn't map I/O. > atrtc0: registered as a time-of-day clock, resolution 1.000000s > Event timer "RTC" frequency 32768 Hz quality 0 > hpet0: iomem 0xfed00000-0xfed003ff irq 8 > on acpi0 > Timecounter "HPET" frequency 19200000 Hz quality 950 > Event timer "HPET" frequency 19200000 Hz quality 550 > Event timer "HPET1" frequency 19200000 Hz quality 440 > Event timer "HPET2" frequency 19200000 Hz quality 440 > Event timer "HPET3" frequency 19200000 Hz quality 440 > Event timer "HPET4" frequency 19200000 Hz quality 440 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > acpi_ec0: port 0x62,0x66 on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > vgapci0: port 0xf000-0xf03f mem > 0xa0000000-0xa0ffffff,0x90000000-0x9fffffff at device 2.0 on pci0 > vgapci0: Boot video device > hdac0: mem > 0xa1310000-0xa1313fff,0xa1000000-0xa10fffff irq 25 at device 14.0 on pci0 > pci0: at device 15.0 (no driver attached) > ahci0: port > 0xf090-0xf097,0xf080-0xf083,0xf060-0xf07f mem > 0xa1314000-0xa1315fff,0xa131a000-0xa131a0ff,0xa1319000-0xa13197ff at > device 18.0 on pci0 > ahci0: AHCI v1.31 with 2 6Gbps ports, Port Multiplier supported > ahcich0: at channel 0 on ahci0 > ahcich1: at channel 1 on ahci0 > pcib1: at device 19.0 on pci0 > pci1: on pcib1 > rtsx0: <2.1g Realtek RTS5229 PCIe SD Card Reader> mem > 0xa1200000-0xa1200fff at device 0.0 on pci1 > rtsx0: No card is detected > pcib2: at device 19.2 on pci0 > pci2: on pcib2 > re0: port > 0xe000-0xe0ff mem 0xa1104000-0xa1104fff,0xa1100000-0xa1103fff at > device 0.0 on pci2 > re0: Using 1 MSI-X message > re0: ASPM disabled > re0: Chip rev. 0x54000000 > re0: MAC rev. 0x00100000 > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, > 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, > auto, auto-flow > re0: Using defaults for TSO: 65518/35/2048 > re0: Ethernet address: xx:xx:xx > re0: netmap queues/slots: TX 1/256, RX 1/256 > xhci0: mem > 0xa1300000-0xa130ffff irq 17 at device 21.0 on pci0 > xhci0: 32 bytes context size, 64-bit DMA > usbus0 on xhci0 > usbus0: 5.0Gbps Super Speed USB v3.0 > sdhci_pci0: mem > 0xa1318000-0xa1318fff,0xa1317000-0xa1317fff irq 39 at device 28.0 on pci0 > sdhci_pci0: 1 slot(s) allocated > mmc0: on sdhci_pci0 > isab0: at device 31.0 on pci0 > isa0: on isab0 > acpi_button0: on acpi0 > acpi_button1: on acpi0 > acpi_tz0: on acpi0 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbdc0: non-PNP ISA device will be removed from GENERIC in FreeBSD 14. > uart0: at port 0x3f8 irq 4 > flags 0x10 on isa0 > uart0: non-PNP ISA device will be removed from GENERIC in FreeBSD 14. > est0: on cpu0 > Timecounter "TSC" frequency 1497600051 Hz quality 1000 > Timecounters tick every 1.000 msec > ZFS filesystem version: 5 > ZFS storage pool version: features support (5000) > hdacc0: at cad 0 on hdac0 > hdaa0: at nid 1 on hdacc0 > pcm0: at nid 33 and 25 on hdaa0 > pcm1: at nid 27 on hdaa0 > pcm2: at nid 30 on hdaa0 > hdacc1: at cad 2 on hdac0 > hdaa1: at nid 1 on hdacc1 > pcm3: at nid 3 on hdaa1 > ugen0.1: at usbus0 > uhub0 on usbus0 > uhub0: on usbus0 > mmc0: No compatible cards found on bus > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ACS-4 ATA SATA 3.x device > ada0: Serial Number 200312A004C2 > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) > ada0: Command Queueing enabled > ada0: 238475MB (488397168 512 byte sectors) > Trying to mount root from zfs:zroot/ROOT/default []... > uhub0: 16 ports with 16 removable, self powered > Root mount waiting for: usbus0 > ugen0.2: at usbus0 > ugen0.3: at usbus0 > ukbd0 on uhub0 > ukbd0: > on usbus0 > kbd2 at ukbd0 > drmn0: on vgapci0 > vgapci0: child drmn0 requested pci_enable_io > vgapci0: child drmn0 requested pci_enable_io > [drm] Unable to create a private tmpfs mount, hugepage support will be > disabled(-19). > [drm] Got stolen memory base 0x7c000000, size 0x4000000 > drmn0: [drm] couldn't get memory information > drmn0: [drm] Applying Increase DDI Disabled quirk > drmn0: successfully loaded firmware image 'i915/glk_dmc_ver1_04.bin' > drmn0: [drm] Finished loading DMC firmware i915/glk_dmc_ver1_04.bin > (v1.4) > sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)! > [drm] Initialized i915 1.6.0 20200917 for drmn0 on minor 0 > VT: Replacing driver "efifb" with new "fb". > start FB_INFO: > type=11 height=1080 width=1920 depth=32 > pbase=0x90000000 vbase=0xfffff80090000000 > name=drmn0 flags=0x0 stride=7680 bpp=32 > end FB_INFO > acpi_wmi0: on acpi0 > acpi_wmi0: Embedded MOF found > ACPI: \134AMW0.WQBA: 1 arguments were passed to a non-method ACPI > object (Buffer) (20201113/nsarguments-361) > ichsmb0: port 0xf040-0xf05f mem > 0xa1316000-0xa13160ff at device 31.1 on pci0 > smbus0: on ichsmb0 > lo0: link state changed to UP > re0: link state changed to DOWN > re0: link state changed to UP > ums0 on uhub0 > ums0: 1> on usbus0 > ums0: 3 buttons and [XYZ] coordinates ID=0 > uhid0 on uhub0 > uhid0: 1> on usbus0 > device_attach: uhid0 attach returned 12 > uhid0 on uhub0 > uhid0: > on usbus0 > uhid1 on uhub0 > uhid1: 1> on usbus0 > device_attach: uhid1 attach returned 12 > Security policy loaded: MAC/ntpd (mac_ntpd) > > 10.03.2023 23:12, Dmitrii Postolov пишет: >> FreeBSD 13.2-RC1 FPS in screensaver drops after hours >> >> Hi all! Sorry for my bad English... >> >> I have access to several computers running FreeBSD 13.2-RC1 and Intel >> (U)HD Graphics. For example, it is an Intel NUC7PJYH (Intel J5005) >> and an Acer Revo Box RN86 (Intel Core i5-9400T). Additionally, I can >> experiment with Intel NUC5PPYH (Intel N3700) and Acer Aspire XC-895 >> (Intel Core i5-10400) if needed. >> >> I am using Xfce 4.18, drm-510-kmod video driver (installed from pkg >> or built from ports). Xfce uses xscreensaver and Ant Inspect >> screensaver with FPS counter and CPU Load counter enabled. >> >> Normally the FPS value is FPS 40 and CPU Load 15%, but if the >> screensaver has been running for several hours the FPS can drop to >> about FPS 18. The CPU Load value also increases. >> >> All serious applications were terminated before the screensaver was >> turned on. >> >> Powerd is on by default on these computers, I can try to turn it off. >> >> I have not noticed this problem in previous releases of FreeBSD. >> >> Could this situation indicate a problem with FreeBSD's graphics >> subsystem? >> >> P.S. FreeBSD 13.2-RC2 will be available soon and I will do more >> detailed experiments with it, and bring stats and FPS screen shots. >> >> > From nobody Thu Mar 16 07:50:45 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PcfbZ354Yz3yWK8 for ; Thu, 16 Mar 2023 07:51:38 +0000 (UTC) (envelope-from eivinde@terraplane.org) Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:3006::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PcfbX5Zf6z3tLx for ; Thu, 16 Mar 2023 07:51:36 +0000 (UTC) (envelope-from eivinde@terraplane.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=terraplane.org header.s=ds202212 header.b=kQgXaz3D; spf=pass (mx1.freebsd.org: domain of eivinde@terraplane.org designates 2a01:5b40:0:3006::1 as permitted sender) smtp.mailfrom=eivinde@terraplane.org; dmarc=pass (policy=quarantine) header.from=terraplane.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=terraplane.org; s=ds202212; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Subject:To:From:Date:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ghybFBN/EXJ+ORyNADfS8lv94LqZsVbyU/RzLOrcY80=; b=kQgXaz3DtIMRKtHnOtEy07nITF Q+pMGPeGvACaLfm0FKmbYYFPYe07Lg2JRAbPVDmWr1YBdOtwGaizVYceg4SZU6mYSmj11mHKAoApH om+I5fTPYzgSHfquRQvAK8l9vdiTDLgRFIoPdWAzGTlm7pX4bXTLSYQw5VLWRKGXHB32JNZ52vvlK WExGxUrtAdRI7THBajcfqkwg+oSaDhjznf6fh98uyvX+Tw1e3AgCWweO5WmHUKz4Yf2jioi07RYcX XynPdF9mDgWIfI9BdTgzL3KIeXlHLldAnze43P9rswtM7vw8DyAcuMFoPs6ZPPL7rsECizcPNdUDE lOddTaKw==; Received: from ti0027q160-0721.bb.online.no ([109.189.136.216]:24067 helo=elg.hjerdalen.lokalnett) by smtp.domeneshop.no with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1pciOT-005riZ-Nb for freebsd-stable@freebsd.org; Thu, 16 Mar 2023 08:51:26 +0100 Date: Thu, 16 Mar 2023 08:50:45 +0100 From: Eivind Nicolay Evensen To: freebsd-stable@freebsd.org Subject: Uaudio in/output ports Message-ID: <20230316085045.6b92aa5f@elg.hjerdalen.lokalnett> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[terraplane.org,quarantine]; R_SPF_ALLOW(-0.20)[+ip6:2a01:5b40:0:2000::/51]; R_DKIM_ALLOW(-0.20)[terraplane.org:s=ds202212]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:12996, ipnet:2a01:5b40::/48, country:NO]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[terraplane.org:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4PcfbX5Zf6z3tLx X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Is there something I can do so that for example on this: ugen1.2: at usbus1 uaudio0 on uhub0 uaudio0: on uaudio0: Play[0]: 192000 Hz, 4 ch, 24-bit S-LE PCM format, 2x8ms buffer. uaudio0: Play[0]: 176400 Hz, 4 ch, 24-bit S-LE PCM format, 2x8ms buffer. uaudio0: Play[0]: 96000 Hz, 4 ch, 24-bit S-LE PCM format, 2x8ms buffer. uaudio0: Play[0]: 88200 Hz, 4 ch, 24-bit S-LE PCM format, 2x8ms buffer. uaudio0: Play[0]: 48000 Hz, 4 ch, 24-bit S-LE PCM format, 2x8ms buffer. uaudio0: Play[0]: 44100 Hz, 4 ch, 24-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record[0]: 192000 Hz, 6 ch, 24-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record[0]: 176400 Hz, 6 ch, 24-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record[0]: 96000 Hz, 6 ch, 24-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record[0]: 88200 Hz, 6 ch, 24-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record[0]: 48000 Hz, 6 ch, 24-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record[0]: 44100 Hz, 6 ch, 24-bit S-LE PCM format, 2x8ms buffer. uaudio0: MIDI sequencer. pcm4: on uaudio0 I can select the specific in/output ports I want, rather than recording the left channel always gives me input 1,3,5 while right gives 2,4,6? Ideally I'd like to make use of the second output pair separately as well. Regards -- Eivind Nicolay Evensen From nobody Thu Mar 16 20:44:13 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PczlG5Xtlz3yZGT for ; Thu, 16 Mar 2023 20:44:26 +0000 (UTC) (envelope-from nagy.attila@gmail.com) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PczlG03KLz4GWw for ; Thu, 16 Mar 2023 20:44:26 +0000 (UTC) (envelope-from nagy.attila@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=RL4dd1x8; spf=pass (mx1.freebsd.org: domain of nagy.attila@gmail.com designates 2607:f8b0:4864:20::32c as permitted sender) smtp.mailfrom=nagy.attila@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ot1-x32c.google.com with SMTP id p11-20020a9d454b000000b0069d8eb419f9so1291228oti.4 for ; Thu, 16 Mar 2023 13:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678999465; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=L6sSJTChXkljB+f8oT2y0Eo7z71aedQmYU4OWRkOqPQ=; b=RL4dd1x8Gefyi4z/mUubmZVD9VS4RtXpFxQLFB9T4PbETsuoFlxQGmTZ4/tOjeAczS loLmGHyJw+r9LgFQvbesnea3VLoHo+0Va7oBfHEN/ezDV3z3rWLOOuC8U+LuzORy0WX3 hZaLZfMp8n7ts5uTq0rGJRLH3hYcX3Lkj/iZ6BKXu9uXgnjYr7Di6yA++k52OBfnPmTa EQzqZqpL6LqPn0lsvng3keWGWlmyS8nxsR4rs3dYlcqfn0xhpQGh2rkTQJb8jkhJ/P/J dYSjDWg9ig3UfI699Cg6li/tKwiA6wq4n5qrSpWAyQVlaJKDMjTuxd7ENJ4CxFW1Baq3 FJtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678999465; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=L6sSJTChXkljB+f8oT2y0Eo7z71aedQmYU4OWRkOqPQ=; b=u6+qfMHvdgeVLVtEq4fFpt7ED0Pxrek+6e4sAjJJIQl+fhCFVv5ehygIxLrSeEqUIU Q55deuIR2nEurgRCNa72mB+J1iLMK2vlAyNCGkvJuJiE7WQ15unSPnHj/gPavvyDH+fQ fZ3m029EHOXLe+TZAdUJ7c7s18igwnDthAH3sxl6zB6F8MsXs58CB0Qza2aMyQCKi/eG wjP7ri/ItQHp+3Vlz0kye8bs3luZyXmZJrQj0EO/byKgK4Q55jyYcNzlJBosACAYDwJw wlH5S3rfoXluNji992Mcb1cK//6Z7O6nnQdY33ZRJIxMpkdoFEK/0kI8Z/lwQRzSe2bb jRRg== X-Gm-Message-State: AO0yUKXvxRQpF9C0Agf1neaXk/eZaZf1vCp9ASlzymQiY5ilgjSwAavI grYL1FhwBqc7+T4G37l5UmL+1FdjkPOScmoE4nLlJXicqUY= X-Google-Smtp-Source: AK7set+TyX4Me7mWuE94GqQSarNUX9PD/wRe161BEIelbKKiLY9aASBv/MTeYL+wgT2I4LuRt2JrPY52QfyBIBrhoqU= X-Received: by 2002:a9d:6e9a:0:b0:694:7e05:e240 with SMTP id a26-20020a9d6e9a000000b006947e05e240mr321845otr.1.1678999464777; Thu, 16 Mar 2023 13:44:24 -0700 (PDT) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Attila Nagy Date: Thu, 16 Mar 2023 21:44:13 +0100 Message-ID: Subject: Fwd: Kernel DHCP unpredictable/fails (PXE boot), userspace DHCP works just fine To: freebsd-stable@freebsd.org Content-Type: multipart/alternative; boundary="000000000000ad1af605f70a864c" X-Spamd-Result: default: False [-1.73 / 15.00]; URI_COUNT_ODD(1.00)[31]; NEURAL_HAM_SHORT(-0.97)[-0.969]; NEURAL_HAM_LONG(-0.96)[-0.964]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_SPAM_MEDIUM(0.20)[0.199]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::32c:from]; ARC_NA(0.00)[]; TAGGED_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_NONE(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4PczlG03KLz4GWw X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N --000000000000ad1af605f70a864c Content-Type: text/plain; charset="UTF-8" Hi, As this is super annoying, I'm willing to pay a $500 bounty for solving this issue (whomever is first, however I don't anticipate a big competition :) Having an invoice would be best, but I'm willing to accept individuals as well). I can't give remote access, but can run debug builds with serial console. stable/13 branch. I have a bunch of netbooted machines, one set in a cluster is older (HP DL80 G9, 2x8C, Intel I350 -igb- NICs), the other set is newer (HP XL225n G10, AMD EPYC2x16C, BCM57412 -bnxt- NICs). All of these boot from the network, which is basically: - get IP and options with DHCP with the help of the NIC's PXE stack - get the loader and kernel, start it - do another round of DHCP from the kernel (bootp_subr.c) - mount the root via NFS and let everything work as usual The problem is that the newer machines take an indefinite time to boot. The older ones (with igb NIC) work reliably, they always boot fast. The process of getting an IP address via DHCP (bootpc_call from bootp_subr.c) either succeeds normally (in a few seconds), or takes a lot of time. Common (measured) times to boot range from 10s of minutes to anywhere between a few hours (1-6). Sometimes it just gets stuck and couldn't get past bootpc_call (getting the DHCP lease). What I've already tried: - we have a redundant set of DHCP servers which offer static leases (so there are two DHCPOFFERs), so I tried to turn off one of them, nothing has changed - tried to disable SMP, the effect is the same - tried to see whether it's a network issue. The NIC's PXE stack always gets the lease quickly and booting FreeBSD from an ISO and issuing dhclient on the same interface is also fast. After the machines have booted, there are no network issues, they work reliably (since more than a year for 20+ machines, so not just a few hours) This issue wasn't so bad previously (only a few mins to tens of minutes delay), but recently it got pretty unbearable, even making some machines unbootable for days... First I thought it might be a packet loss (or more exactly packet delivery from the DHCP server to the receiving socket), either in the network or in the NIC/kernel itself, so I placed a few random printfs into bootp_subr.c and udp_usrreq.c. After spending some time trying to understand the problem it feels like a race condition in bootpc_call, but I don't know the code well enough to effectively verify that. Here are the modified bootp_subr.c and udp_usrreq.c: https://gist.githubusercontent.com/bra-fsn/128ae9a3bbc0dbdbb2f6f4b3e2c5157a/raw/a8ade8af252f618c84a46da2452d557ebc5078ac/bootp_subr.c https://gist.github.com/bra-fsn/128ae9a3bbc0dbdbb2f6f4b3e2c5157a/raw/a8ade8af252f618c84a46da2452d557ebc5078ac/udp_usrreq.c (modified from stable/13 branch from a few weeks earlier) This is the output with the always working DL80 (igb) machine: https://gist.github.com/bra-fsn/128ae9a3bbc0dbdbb2f6f4b3e2c5157a/raw/a8ade8af252f618c84a46da2452d557ebc5078ac/DL80%2520igb%2520good.txt This is the console output from a working boot for the XL225n (bnxt) machine: https://gist.github.com/bra-fsn/128ae9a3bbc0dbdbb2f6f4b3e2c5157a/raw/a8ade8af252f618c84a46da2452d557ebc5078ac/XL225n%2520bnxt%2520good.txt as you can see, it's much slower than the DL80 (which also isn't that fast...) And this one is a longer output, without success to that point (2 minutes without completing the DHCP flow): https://gist.github.com/bra-fsn/128ae9a3bbc0dbdbb2f6f4b3e2c5157a/raw / a8ade8af252f618c84a46da2452d557ebc5078ac/XL225n%2520bnxt%2520long.txt For the latter, here's an excerpt from the DHCP log: https://gist.githubusercontent.com/bra-fsn/128ae9a3bbc0dbdbb2f6f4b3e2c5157a/raw/a8ade8af252f618c84a46da2452d557ebc5078ac/dhcp_log.txt It seems the DHCP state always gets reset to IF_DHCP_UNRESOLVED even if there's answers from the DHCP server. Here's another, longer console log, which succeeded after spending 236 seconds in the loop: https://gist.github.com/bra-fsn/128ae9a3bbc0dbdbb2f6f4b3e2c5157a/raw/a77f52f5e83c699b38a7c2d3acdc52d26ceeba71/XL225n%2520bnxt%2520long%2520good.txt Any ideas about this? --000000000000ad1af605f70a864c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

As this is super annoying, I'm willing to pay a $500 bounty fo= r solving this issue (whomever is first, however I don't anticipate a b= ig competition :) Having an invoice would be best, but I'm willing to a= ccept individuals as well).
I can't give remote access, but c= an run debug builds with serial console. stable/13 branch.
I have a bunch of netbooted machines, one set in a cluster is = older (HP DL80 G9, 2x8C, Intel I350 -igb- NICs), the other set is newer (HP= XL225n G10, AMD EPYC2x16C, BCM57412 -bnxt- NICs).
All of these b= oot from the network, which is basically:
- get IP and options wi= th DHCP with the help of the NIC's PXE stack
- get the loader= and kernel, start it
- do another round of DHCP from the kernel = (bootp_subr.c)
- mount the root via NFS and let everything work a= s usual

The problem is that the newer machines tak= e an indefinite time to boot. The older ones (with igb NIC) work reliably, = they always boot fast.
The process of getting an IP address v= ia DHCP (bootpc_call from bootp_subr.c) either succeeds normally (in a few = seconds), or takes a lot of time.
Common (measured) times to boot= range from 10s of minutes to anywhere between a few hours (1-6).
Sometimes it just gets stuck and couldn't get past bootpc_call (gettin= g the DHCP lease).

What I've already tried:
- we have a redundant set of DHCP servers which offer static leases= (so there are two DHCPOFFERs), so I tried to turn off one of them, nothing= has changed
- tried to disable SMP, the effect is the same
- tried to see whether it's a network issue. The NIC's= PXE stack always gets the lease quickly and booting FreeBSD from an ISO an= d issuing dhclient on the same interface is also fast. After the machines h= ave booted, there are no network issues, they work reliably (since more tha= n a year for 20+ machines, so not just a few hours)

This issue wasn't so bad previously (only a few mins to tens of m= inutes delay), but recently it got pretty unbearable, even making some mach= ines unbootable for days...

First I thought it mig= ht be a packet loss (or more exactly packet delivery from the DHCP server t= o the receiving socket), either in the network or in the NIC/kernel itself,= so I placed a few random printfs into bootp_subr.c and udp_usrreq.c.
=

After spending some time trying to understand the probl= em it feels like a race condition in
bootpc_call, but I don&= #39;t know the code well enough to effectively verify that.
<= br>
Here are the modified bootp_subr.c and udp_usrreq.c:
https://gist.githubusercontent.com/bra-fsn/128ae9a3bbc0dbd= bb2f6f4b3e2c5157a/raw/a8ade8af252f618c84a46da2452d557ebc5078ac/bootp_subr.c=
=
(modified from stable/13 branch from a few weeks earlier)

This is the output with the always working DL80 (igb) mach= ine:

This is the console output fr= om a working boot for the XL225n (bnxt) machine:
https://gist.github.com/bra-fsn/128ae9a3bbc0dbdbb2f6f4b3e2c5157a/raw/a8a= de8af252f618c84a46da2452d557ebc5078ac/XL225n%2520bnxt%2520good.txt
as you can see, it's much slower than the DL80 (which also isn= 9;t that fast...)

And this one is a longer output,= without success to that point (2 minutes without completing the DHCP flow)= :
=

For the latter, here's an excerpt from the DHCP log= :

It seems the DHCP state always g= ets reset to IF_DHCP_UNRESOLVED even if there's answers from the DHCP s= erver.

Here's another, longer console log,= which succeeded after spending 236 seconds in the loop:

Any ideas about this?

--000000000000ad1af605f70a864c-- From nobody Thu Mar 16 21:14:25 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Pd0QD5dpvz3ybnx for ; Thu, 16 Mar 2023 21:14:44 +0000 (UTC) (envelope-from yvesguerin@yahoo.ca) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Pd0QB6R6Dz4KJr for ; Thu, 16 Mar 2023 21:14:42 +0000 (UTC) (envelope-from yvesguerin@yahoo.ca) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.ca header.s=s2048 header.b=lVAxIjHy; spf=pass (mx1.freebsd.org: domain of yvesguerin@yahoo.ca designates 98.137.65.147 as permitted sender) smtp.mailfrom=yvesguerin@yahoo.ca; dmarc=pass (policy=reject) header.from=yahoo.ca DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s2048; t=1679001280; bh=qrHtO9YOk8HWB/fSr9UsEg0IRQkzKlHOmL7US7coS84=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=lVAxIjHyAkxU/fXxDF1/lP5iFMGP/iSH62Onm517/dD7hwl9sKY1I47raYmGe0DE5B/rL9biZXmrfalM9F2/i7e7i6DQMGgkrE3iQiNPuPvntmDFOo24K4n+zgW7GFbgaISD9q6MZjb4sx4RAz5Z15/rIJfNvyGRQpbLuKGhN9Wl8IixHr1lwxdg2O9rq4ZFPdAhuBS6vFgva5WzHzIWXTUFbQAfYbcH6ONTmVFvDhjWdccU12GEjO3TU0vw/L0MYumpUxBKudSZIQa+IEw1LrFjbzVwO7qGdXIQcn1ZnPQlN2RI2KV8MKUykMDmjl4LHd1x3vRRtAOEb/l6ee+kxQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1679001280; bh=QKsl/5zu+Pze3tIcTSkQ/PtkZy1CJ2jmYZVzr7E+YNJ=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=RTTs1eGE40EBnCxtqXLX8O2G9v6z9lFKKNYoQuIWCp72uf6oNbEzWLLVD2DwRU1OY37xdsLnVNJeQOPL9g3kF9MqgAQUWFBSIRHWTpP1L80bbeTKXNI0Z8vfwis1kOltXtCirR71ejc/eH2Qf7KCTNWswkjKLKyjdRb1hHiWKVFSYGru6QibCChote4OLLvGnoOxL8NpWF4B54gn9E6XwjH/CB9oShMPzkQIkjwlJHHxPnyRlsoPgmPLyRqw5rHzGDWZIg8ugHvGN1+HntKP8fp/w6yHJ4FV66Yawg+p2HtTWQTUKyL3fxlzZeF00+vaG4I+1x/rq2EQzrm3UX9uKg== X-YMail-OSG: gzRtlt0VM1lLVGZqnSvDaHvoC2E6c4u8YLoeCNyHNEzQqEVZJQrW9djfljF9Hbx 0HcCEBfO0pUrDMW6LXx5MMROlYhvzU3.l.nMk9MySAp_aTMSJH2xFrq02n8wwmOvL.g65z086JZB 1LhBRvlPENHPPlQJSQ6kiTPESsrA9DabUauQ3rWk1q6nWCury299BsEh8SK0azpUU42jabwS2jsi QOY2R7EwLFOR2Uju0H1pVrQuoVt3CqAIfSAHADEOaVtpnsJrmvlwg8bmdn_E14j2GqgfjG2lzFBt .1rGgVJ975ZL_WnAJguuh5ISUuhM6N84SFGSTnEc0UHAVD0H0v5JtO9Dng_MM7Qsiy_Y3BB9kYUo Pxtml_qVYN4e7_CsVpol1Gdu5hd5f1tjl4ewnHwXQOqjVgZEugFWnE1n8j7S7OLbMlfzxEo_KLKk HUUM0R_4fPKlQ8tx8SkfHX1d_Vpt1tExF1CQ3LgMTvCouggIjQkF6JQSdRTKjwnmeGnUIkiIoGtQ ZogijwFFs..izgRqBIRZkbaqWVN8i6giV3oqx5zeEjqP3.tGzYxy2VTunlZV9qha47YaYtMPdy25 g0lTv009zxGL47h4PuPl.Bzs1dI9s1F1n3eAUHP1V7MFsA2_oSN0LTWHikaDrF4YFDZA3h2.DbBi bCha5miaNcEq2IiZ7lBQnGfQItce9UtXyrv0AcImjT6sg8A1jj.fG8QTcTpv9MOOqY7C3lm2NaNV 5gpIoM6Q6rzzByOqHYrMwHA9ia5Hx42G0UySX_5szG7OgcIzm0w27IEK89fEqAz7fRV4zQbMhVPt RcvdVqv4xV7qLa5tHKp9V9ALguW3qvOpWSuTUPnz6SnVL5Nkeodv_oQugQqdDw9aYMKxHcYZJukb HZJRaUUhmeXa3bzTc3JChndFkLpYR48eM6CP0wnFQQEnV.QnqZYeets4l68khFY7ATFUefAuVZ5W jLjswez46nyIBqqWqxdayP0OmtctM6j3R69Bx4i8CuMptg7S8m8oyWXsr6IP0U3LiZ6lOcIffKpV XnLGdHpjqS7hW2ZyncqVMA7qn9hyFaW4Olmdzm_LkPogX9B3hVa9ZPCTo7usaMeSadRPxwj.jnuY auyJzgS2pJvJg9NNJNHLery6dXtxqfT6BaaDSyGkyLUUxDApH_MkXOEpXd4u7FRCh0v0qHiuUV6B ETEGpC.JkzC1aZZTewtGNPGg8z6Gl1.JPtsjizLQ.FJWWSThhrIZAokVaxdbcIZFpR_Dk2U2xrsE kGTllNf0ZWNjFV1PVT3CGJzVHlaFAsXgCGn6acW.YUs1qxAqRqhNgZtiwd30f2pv6wrbk1kxKmst hLeD7DkbYmGUdTJLgrJq2Q35RzGp1OJgOkpnZnvr4ZzsojybkjsQX34gtl1LbSfpED2b5iuu_gq2 4O.s0s0usL06Si.jt6byUlAPvH.U2tzbs0PeEesOyAeaVEuQQdMJKLEuvR44tnKdXPsLgPOnuMEq 94lCeTHp2eKE_ofXTaZpF2Lv766LMBldR1NBZ1ENxSA3YhAec44iKxI4J41dQKrwfDV4Nx8VhZGt ALOqHM3noERlP1duemAwFc2SH2inME3JlWD7RwPY04SDt.ghHN.oLNghEYb127Zbgrn_cyrr.Eln GOnIdq7A8by._vh5qoc93Hrn0mN70C.iGYWJ1HTLWx7hPEprNqOVA10Vsbr25sGwCHIJBnrLy.Ar DoDLXt2YrBVkjPwTCs2HkO28q3exjxQJjMQHJCTG2b90fU6UTxn.wCuxr.gwyWSLGS69e8LoOIvI 49SSLxEGaEv7H7hV69R7CvfNk9vmXDaBs_8k_.nT8UMQiTdtRMCgvzJUA1hMdVcid57DDwKEgg_u H5bp5lTuh4by1G.6cqCpI3KOdQnie.GeoENhBGhdPTDWlHRrAPdXJN4pzFwNPmA5GmSAcZ1j6x5W OMKGmmLzMwQN1VdtiNQeU5H9uzqyfsk_iYcMPrjwheAB3.ZXhO_dmgr1bVWk7OVbv9Rbrxf6Ml39 CO7WMgKymIy2_xyg8kKgMXVMoPPg7F46fcYTQ396t7T2y.vu7Z0W37SK2d6rhmhF4S1HgzSpOCR. G5QBEB1q.tzyy433q5r0yoAKprnn8jS9hHwyAALZaX9AQTz7CEsY5iaiBWKSTM4OdiOy.r1Q7Zz9 .yOLE9Q.8vJarv25HynYBDJIMeHqAuGfWBJbhlLqAO40GFq4tDYHZF9yjMPX1pyS1XBHO5WSllhA gcDvwOnFmLoXAHgIgiS4ogyNMFh9a4E8q6mFxllUwlJ2mqIXWCrHIM8C3Ll75sWBO X-Sonic-MF: X-Sonic-ID: 133a61de-c0d4-48af-83d7-158a5353ad0d Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Thu, 16 Mar 2023 21:14:40 +0000 Date: Thu, 16 Mar 2023 21:14:25 +0000 (UTC) From: =?UTF-8?Q?Yves_Gu=C3=A9rin?= Reply-To: =?UTF-8?Q?Yves_Gu=C3=A9rin?= To: "freebsd-stable@freebsd.org" , Attila Nagy Message-ID: <132303943.191443.1679001265318@mail.yahoo.com> In-Reply-To: References: Subject: Re: Kernel DHCP unpredictable/fails (PXE boot), userspace DHCP works just fine List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_191442_1545221852.1679001265315" X-Mailer: WebService/1.1.21311 YMailNorrin X-Spamd-Result: default: False [0.50 / 15.00]; NEURAL_SPAM_MEDIUM(0.87)[0.865]; DMARC_POLICY_ALLOW(-0.50)[yahoo.ca,reject]; NEURAL_SPAM_SHORT(0.35)[0.352]; NEURAL_SPAM_LONG(0.28)[0.284]; R_DKIM_ALLOW(-0.20)[yahoo.ca:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_HAS_DN(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; TAGGED_RCPT(0.00)[]; HAS_REPLYTO(0.00)[yvesguerin@yahoo.ca]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FREEMAIL_REPLYTO(0.00)[yahoo.ca]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_FROM(0.00)[yahoo.ca]; DKIM_TRACE(0.00)[yahoo.ca:+]; TO_DN_SOME(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_TO(0.00)[freebsd.org,gmail.com]; FREEMAIL_ENVFROM(0.00)[yahoo.ca]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4Pd0QB6R6Dz4KJr X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N ------=_Part_191442_1545221852.1679001265315 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Attila, May be I will add some noise to your thread, sorry in advance, I am just a = sysadmin and I faced the same problem with one of my old hp g7 the network = card was broken (malfunctionning) , sometime it works and sometime not when= I used pxe and dhcpd (take to much time to answer to the dhcp so the mothe= rboard decided to reboot, etc. (infinite loop)).=C2=A0 The card works perfe= ctly when it's setup by an OS. May be it's a stupid question or two: do you check the network cable ?=C2= =A0 (I faced some defective cables and it ruin my day...) in the same way w= hat about the hub/router attached to this server (configuration, etc.), Do = you switched a good one by a bad one ? (same network cable, hub/router, etc= .) I spend too much nights in the lab... Regards,=20 Yves Guerin=20 Le jeudi 16 mars 2023 =C3=A0 16:44:49 UTC=E2=88=924, Attila Nagy a =C3=A9crit : =20 =20 Hi, As this is super annoying, I'm willing to pay a $500 bounty for solving thi= s issue (whomever is first, however I don't anticipate a big competition :)= Having an invoice would be best, but I'm willing to accept individuals as = well).I can't give remote access, but can run debug builds with serial cons= ole. stable/13 branch. I have a bunch of netbooted machines, one set in a cluster is older (HP DL8= 0 G9, 2x8C, Intel I350 -igb- NICs), the other set is newer (HP XL225n G10, = AMD EPYC2x16C, BCM57412 -bnxt- NICs).All of these boot from the network, wh= ich is basically:- get IP and options with DHCP with the help of the NIC's = PXE stack- get the loader and kernel, start it- do another round of DHCP fr= om the kernel (bootp_subr.c)- mount the root via NFS and let everything wor= k as usual The problem is that the newer machines take an indefinite time to boot. The= older ones (with igb NIC) work reliably, they always boot fast. The process of getting an IP address via DHCP (bootpc_call from bootp_subr.= c) either succeeds normally (in a few seconds), or takes a lot of time.Comm= on (measured) times to boot range from 10s of minutes to anywhere between a= few hours (1-6).Sometimes it just gets stuck and couldn't get past bootpc_= call (getting the DHCP lease). What I've already tried:- we have a redundant set of DHCP servers which off= er static leases (so there are two DHCPOFFERs), so I tried to turn off one = of them, nothing has changed - tried to disable SMP, the effect is the same - tried to see whether it's a network issue. The NIC's PXE stack always get= s the lease quickly and booting FreeBSD from an ISO and issuing dhclient on= the same interface is also fast. After the machines have booted, there are= no network issues, they work reliably (since more than a year for 20+ mach= ines, so not just a few hours) This issue wasn't so bad previously (only a few mins to tens of minutes del= ay), but recently it got pretty unbearable, even making some machines unboo= table for days... First I thought it might be a packet loss (or more exactly packet delivery = from the DHCP server to the receiving socket), either in the network or in = the NIC/kernel itself, so I placed a few random printfs into bootp_subr.c a= nd udp_usrreq.c. After spending some time trying to understand the problem it feels like a r= ace condition in=20 bootpc_call, but I don't know the code well enough to effectively verify th= at. Here are the modified bootp_subr.c and udp_usrreq.c:https://gist.githubuser= content.com/bra-fsn/128ae9a3bbc0dbdbb2f6f4b3e2c5157a/raw/a8ade8af252f618c84= a46da2452d557ebc5078ac/bootp_subr.chttps://gist.github.com/bra-fsn/128ae9a3= bbc0dbdbb2f6f4b3e2c5157a/raw/a8ade8af252f618c84a46da2452d557ebc5078ac/udp_u= srreq.c(modified from stable/13 branch from a few weeks earlier) This is the output with the always working DL80 (igb) machine:https://gist.= github.com/bra-fsn/128ae9a3bbc0dbdbb2f6f4b3e2c5157a/raw/a8ade8af252f618c84a= 46da2452d557ebc5078ac/DL80%2520igb%2520good.txt This is the console output from a working boot for the XL225n (bnxt) machin= e:https://gist.github.com/bra-fsn/128ae9a3bbc0dbdbb2f6f4b3e2c5157a/raw/a8ad= e8af252f618c84a46da2452d557ebc5078ac/XL225n%2520bnxt%2520good.txtas you can= see, it's much slower than the DL80 (which also isn't that fast...) And this one is a longer output, without success to that point (2 minutes w= ithout completing the DHCP flow):https://gist.github.com/bra-fsn/128ae9a3bb= c0dbdbb2f6f4b3e2c5157a/raw/a8ade8af252f618c84a46da2452d557ebc5078ac/XL225n%= 2520bnxt%2520long.txt For the latter, here's an excerpt from the DHCP log: https://gist.githubusercontent.com/bra-fsn/128ae9a3bbc0dbdbb2f6f4b3e2c5157a= /raw/a8ade8af252f618c84a46da2452d557ebc5078ac/dhcp_log.txt It seems the DHCP state always gets reset to IF_DHCP_UNRESOLVED even if the= re's answers from the DHCP server. Here's another, longer console log, which succeeded after spending 236 seco= nds in the loop: https://gist.github.com/bra-fsn/128ae9a3bbc0dbdbb2f6f4b3e2c5157a/raw/a77f52= f5e83c699b38a7c2d3acdc52d26ceeba71/XL225n%2520bnxt%2520long%2520good.txt Any ideas about this? =20 ------=_Part_191442_1545221852.1679001265315 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Attila,

May be I will add some noise to your thread, sorry in advance, I am ju= st a sysadmin and I faced the same problem with one of my old hp g7 the net= work card was broken (malfunctionning) , sometime it works and sometime not= when I used pxe and dhcpd (take to much time to answer to the dhcp so the = motherboard decided to reboot, etc. (infinite loop)).  The card works = perfectly when it's setup by an OS.

May be it's a stupid = question or two: do you check the network cable ?  (I faced some defec= tive cables and it ruin my day...) in the same way what about the hub/route= r attached to this server (configuration, etc.), Do you switched a good one= by a bad one ? (same network cable, hub/router, etc.)

I = spend too much nights in the lab...

Regards,

Yves Guerin


=20
=20
Le jeudi 16 mars 2023 =C3=A0 16:44:49 UTC=E2=88=924, At= tila Nagy <nagy.attila@gmail.com> a =C3=A9crit :


Hi,

As thi= s is super annoying, I'm willing to pay a $500 bounty for solving this issu= e (whomever is first, however I don't anticipate a big competition :) Havin= g an invoice would be best, but I'm willing to accept individuals as well).=
I can't give remote access, but can run debug builds with serial= console. stable/13 branch.

I have a bunch of = netbooted machines, one set in a cluster is older (HP DL80 G9, 2x8C, Intel = I350 -igb- NICs), the other set is newer (HP XL225n G10, AMD EPYC2x16C, BCM= 57412 -bnxt- NICs).
All of these boot from the network, which is = basically:
- get IP and options with DHCP with the help of the NI= C's PXE stack
- get the loader and kernel, start it
- d= o another round of DHCP from the kernel (bootp_subr.c)
- mount th= e root via NFS and let everything work as usual

Th= e problem is that the newer machines take an indefinite time to boot. The o= lder ones (with igb NIC) work reliably, they always boot fast.
The process of getting an IP address via DHCP (bootpc_call from bootp_sub= r.c) either succeeds normally (in a few seconds), or takes a lot of time.
Common (measured) times to boot range from 10s of minutes to anywh= ere between a few hours (1-6).
Sometimes it just gets stuck and c= ouldn't get past bootpc_call (getting the DHCP lease).

=
What I've already tried:
- we have a redundant set of DHCP s= ervers which offer static leases (so there are two DHCPOFFERs), so I tried = to turn off one of them, nothing has changed
- tried to disab= le SMP, the effect is the same
- tried to see whether it's a = network issue. The NIC's PXE stack always gets the lease quickly and bootin= g FreeBSD from an ISO and issuing dhclient on the same interface is also fa= st. After the machines have booted, there are no network issues, they work = reliably (since more than a year for 20+ machines, so not just a few hours)=

This issue wasn't so bad previously (only a f= ew mins to tens of minutes delay), but recently it got pretty unbearable, e= ven making some machines unbootable for days...

Fi= rst I thought it might be a packet loss (or more exactly packet delivery fr= om the DHCP server to the receiving socket), either in the network or in th= e NIC/kernel itself, so I placed a few random printfs into bootp_subr.c and= udp_usrreq.c.

After spending some time trying to = understand the problem it feels like a race condition in
boo= tpc_call, but I don't know the code well enough to effectively verify that.=

Here are the modified bootp_subr.c and udp_u= srreq.c:
(modified from stable/13 branch from a few weeks earli= er)

This is the output with the always working= DL80 (igb) machine:
https://gist.github.com/bra-fsn/128ae9a3bbc0dbdbb2f6f4b3e2c5157a/r= aw/a8ade8af252f618c84a46da2452d557ebc5078ac/DL80%2520igb%2520good.txt

This is the console output from a working boot for = the XL225n (bnxt) machine:
as you can see, it's much slower than the DL80 (which = also isn't that fast...)

And this one is a longer = output, without success to that point (2 minutes without completing the DHC= P flow):

For the latt= er, here's an excerpt from the DHCP log:

It seems the DHCP state always = gets reset to IF_DHCP_UNRESOLVED even if there's answers from the DHCP serv= er.

Here's another, longer console log, which = succeeded after spending 236 seconds in the loop:

Any ideas about this?

------=_Part_191442_1545221852.1679001265315-- From nobody Thu Mar 16 21:26:40 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Pd0hF4499z3ycg8 for ; Thu, 16 Mar 2023 21:26:53 +0000 (UTC) (envelope-from nagy.attila@gmail.com) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Pd0hF2MD4z4Lt4 for ; Thu, 16 Mar 2023 21:26:53 +0000 (UTC) (envelope-from nagy.attila@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ua1-x930.google.com with SMTP id g23so2102662uak.7 for ; Thu, 16 Mar 2023 14:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679002012; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7m33QQQjpkNurVcvNdQvwPevvLQ9mxpuq3hRCVIu1As=; b=llZqoeSYYYoi80ITLAjDwoDiqbSDgVINip0iVSGKJpOzgwtCF6mGyq1kCJq1Bs/aP4 +YvsKY01lBvBw3FmkCVazlHEdRVQS/Foh9TRktLb5uLoAi4ocweFm8rWwoSS4oSoQOiG vFgyiG3HyHpJHueaoUm8gb5BHe3fMBipzVW4ZwSqICQ0YZ6rrhadlbI6Z/GEnht73Y7n 3JRVmVvWH0Hh2pKuumpRaTnccws3gHgz7n+YVetzTn2GwCylisW8PrQkIn7IKLBU64O3 mQdiTSnTBuBv2hHJBAFGGXhReIiJiX3HYb0YwxmFqOVGa8DcgBFUhG2UxIiWfuwc7nBS O3zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679002012; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7m33QQQjpkNurVcvNdQvwPevvLQ9mxpuq3hRCVIu1As=; b=A1N2uSrVz9MhJh3OMosfZb/Xui5dsYWrLc/m7VWQqMPfcI0HWSlLRFtdCOpxqcaW3T ptoRWTQ2SbjjjIWKOL96u7nntWt9GvBK/O7AuJhpUMRX8aZoJt8OeTLefF0J4I/1wbAz jqAUEqBNopB/404iSei5mQLzgWA5iOQtwgKth1v4swHByc89NU673jbwBPaZLPDSiLrR L3/oARm8NKI2dGlIBs13DnCPxlJkn6Yk4dvmpbLJEyE76w0LaD+47tvFk+pSF7H9aeqG Z1m3+1aKzPtWssvokgoz26DJ2yNkiC6LLJo2WU0ahgkfoMAyEPJtxEe2jlRxTje2+7Fy MkbA== X-Gm-Message-State: AO0yUKXo0tbI2hkreOaoBk/LSEkYxhS0IJrRTgblBwKhYE3HsclRVqas VGk0pwkOJk/UURUpt9uNLipwu0TuGWF22k1jqbc= X-Google-Smtp-Source: AK7set+ghw/dNzYhPzTc+nJyJfFU7SGa6/iLvojas3AaaT7fMLdbtZ/PK0V3F+rZP4qFDqI1CDgDV/RZqiSCW5uS2wA= X-Received: by 2002:ab0:4a12:0:b0:68d:6360:77b with SMTP id q18-20020ab04a12000000b0068d6360077bmr29269338uae.1.1679002012016; Thu, 16 Mar 2023 14:26:52 -0700 (PDT) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: <132303943.191443.1679001265318@mail.yahoo.com> In-Reply-To: <132303943.191443.1679001265318@mail.yahoo.com> From: Attila Nagy Date: Thu, 16 Mar 2023 22:26:40 +0100 Message-ID: Subject: Re: Kernel DHCP unpredictable/fails (PXE boot), userspace DHCP works just fine To: =?UTF-8?B?WXZlcyBHdcOpcmlu?= Cc: "freebsd-stable@freebsd.org" Content-Type: multipart/alternative; boundary="00000000000080e78305f70b1ed9" X-Rspamd-Queue-Id: 4Pd0hF2MD4z4Lt4 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --00000000000080e78305f70b1ed9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey, Sure. We're talking about 30 machines, all behave the same (either bad or good). I'm pretty sure it's not a cabling issue. :) Yves Gu=C3=A9rin ezt =C3=ADrta (id=C5=91pont: 2023. m= =C3=A1rc. 16., Cs, 22:14): > Dear Attila, > > May be I will add some noise to your thread, sorry in advance, I am just = a > sysadmin and I faced the same problem with one of my old hp g7 the networ= k > card was broken (malfunctionning) , sometime it works and sometime not wh= en > I used pxe and dhcpd (take to much time to answer to the dhcp so the > motherboard decided to reboot, etc. (infinite loop)). The card works > perfectly when it's setup by an OS. > > May be it's a stupid question or two: do you check the network cable ? (= I > faced some defective cables and it ruin my day...) in the same way what > about the hub/router attached to this server (configuration, etc.), Do yo= u > switched a good one by a bad one ? (same network cable, hub/router, etc.) > > I spend too much nights in the lab... > > Regards, > > Yves Guerin > > > Le jeudi 16 mars 2023 =C3=A0 16:44:49 UTC=E2=88=924, Attila Nagy > a =C3=A9crit : > > > Hi, > > As this is super annoying, I'm willing to pay a $500 bounty for solving > this issue (whomever is first, however I don't anticipate a big competiti= on > :) Having an invoice would be best, but I'm willing to accept individuals > as well). > I can't give remote access, but can run debug builds with serial console. > stable/13 branch. > > I have a bunch of netbooted machines, one set in a cluster is older (HP > DL80 G9, 2x8C, Intel I350 -igb- NICs), the other set is newer (HP XL225n > G10, AMD EPYC2x16C, BCM57412 -bnxt- NICs). > All of these boot from the network, which is basically: > - get IP and options with DHCP with the help of the NIC's PXE stack > - get the loader and kernel, start it > - do another round of DHCP from the kernel (bootp_subr.c) > - mount the root via NFS and let everything work as usual > > The problem is that the newer machines take an indefinite time to boot. > The older ones (with igb NIC) work reliably, they always boot fast. > The process of getting an IP address via DHCP (bootpc_call from > bootp_subr.c) either succeeds normally (in a few seconds), or takes a lot > of time. > Common (measured) times to boot range from 10s of minutes to anywhere > between a few hours (1-6). > Sometimes it just gets stuck and couldn't get past bootpc_call (getting > the DHCP lease). > > What I've already tried: > - we have a redundant set of DHCP servers which offer static leases (so > there are two DHCPOFFERs), so I tried to turn off one of them, nothing ha= s > changed > - tried to disable SMP, the effect is the same > - tried to see whether it's a network issue. The NIC's PXE stack always > gets the lease quickly and booting FreeBSD from an ISO and issuing dhclie= nt > on the same interface is also fast. After the machines have booted, there > are no network issues, they work reliably (since more than a year for 20+ > machines, so not just a few hours) > > This issue wasn't so bad previously (only a few mins to tens of minutes > delay), but recently it got pretty unbearable, even making some machines > unbootable for days... > > First I thought it might be a packet loss (or more exactly packet deliver= y > from the DHCP server to the receiving socket), either in the network or i= n > the NIC/kernel itself, so I placed a few random printfs into bootp_subr.c > and udp_usrreq.c. > > After spending some time trying to understand the problem it feels like a > race condition in > bootpc_call, but I don't know the code well enough to effectively verify > that. > > Here are the modified bootp_subr.c and udp_usrreq.c: > > https://gist.githubusercontent.com/bra-fsn/128ae9a3bbc0dbdbb2f6f4b3e2c515= 7a/raw/a8ade8af252f618c84a46da2452d557ebc5078ac/bootp_subr.c > > https://gist.github.com/bra-fsn/128ae9a3bbc0dbdbb2f6f4b3e2c5157a/raw/a8ad= e8af252f618c84a46da2452d557ebc5078ac/udp_usrreq.c > (modified from stable/13 branch from a few weeks earlier) > > This is the output with the always working DL80 (igb) machine: > > https://gist.github.com/bra-fsn/128ae9a3bbc0dbdbb2f6f4b3e2c5157a/raw/a8ad= e8af252f618c84a46da2452d557ebc5078ac/DL80%2520igb%2520good.txt > > This is the console output from a working boot for the XL225n (bnxt) > machine: > > https://gist.github.com/bra-fsn/128ae9a3bbc0dbdbb2f6f4b3e2c5157a/raw/a8ad= e8af252f618c84a46da2452d557ebc5078ac/XL225n%2520bnxt%2520good.txt > as you can see, it's much slower than the DL80 (which also isn't that > fast...) > > And this one is a longer output, without success to that point (2 minutes > without completing the DHCP flow): > https://gist.github.com/bra-fsn/128ae9a3bbc0dbdbb2f6f4b3e2c5157a/raw > > / > > a8ade8af252f618c84a46da2452d557ebc5078ac/XL225n%2520bnxt%2520long.txt > > > For the latter, here's an excerpt from the DHCP log: > > https://gist.githubusercontent.com/bra-fsn/128ae9a3bbc0dbdbb2f6f4b3e2c515= 7a/raw/a8ade8af252f618c84a46da2452d557ebc5078ac/dhcp_log.txt > > It seems the DHCP state always gets reset to IF_DHCP_UNRESOLVED even if > there's answers from the DHCP server. > > Here's another, longer console log, which succeeded after spending 236 > seconds in the loop: > > https://gist.github.com/bra-fsn/128ae9a3bbc0dbdbb2f6f4b3e2c5157a/raw/a77f= 52f5e83c699b38a7c2d3acdc52d26ceeba71/XL225n%2520bnxt%2520long%2520good.txt > > Any ideas about this? > > --00000000000080e78305f70b1ed9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey,

Sure. We're talking= about 30 machines, all behave the same (either bad or good). I'm prett= y sure it's not a cabling issue. :)

Yves Gu=C3=A9rin <yvesguerin@yahoo.ca> ezt =C3=ADrta= (id=C5=91pont: 2023. m=C3=A1rc. 16., Cs, 22:14):
Dear = Attila,

May be I will add = some noise to your thread, sorry in advance, I am just a sysadmin and I fac= ed the same problem with one of my old hp g7 the network card was broken (m= alfunctionning) , sometime it works and sometime not when I used pxe and dh= cpd (take to much time to answer to the dhcp so the motherboard decided to = reboot, etc. (infinite loop)).=C2=A0 The card works perfectly when it's= setup by an OS.

May be it= 's a stupid question or two: do you check the network cable ?=C2=A0 (I = faced some defective cables and it ruin my day...) in the same way what abo= ut the hub/router attached to this server (configuration, etc.), Do you swi= tched a good one by a bad one ? (same network cable, hub/router, etc.)

I spend too much nights in the= lab...

Regards,
<= /div>

Yves Guerin


=20
=20
Le jeudi 16 mars 2023 =C3=A0 16:44:49 UTC=E2=88=924, At= tila Nagy <na= gy.attila@gmail.com> a =C3=A9crit :


Hi,

As this is super ann= oying, I'm willing to pay a $500 bounty for solving this issue (whomeve= r is first, however I don't anticipate a big competition :) Having an i= nvoice would be best, but I'm willing to accept individuals as well).
I can't give remote access, but can run debug builds with seri= al console. stable/13 branch.

I have a bunch o= f netbooted machines, one set in a cluster is older (HP DL80 G9, 2x8C, Inte= l I350 -igb- NICs), the other set is newer (HP XL225n G10, AMD EPYC2x16C, B= CM57412 -bnxt- NICs).
All of these boot from the network, which i= s basically:
- get IP and options with DHCP with the help of the = NIC's PXE stack
- get the loader and kernel, start it
- do another round of DHCP from the kernel (bootp_subr.c)
- mo= unt the root via NFS and let everything work as usual

<= div>The problem is that the newer machines take an indefinite time to boot.= The older ones (with igb NIC) work reliably, they always boot fast.
The process of getting an IP address via DHCP (bootpc_call from boo= tp_subr.c) either succeeds normally (in a few seconds), or takes a lot of t= ime.
Common (measured) times to boot range from 10s of minutes to= anywhere between a few hours (1-6).
Sometimes it just gets stuck= and couldn't get past bootpc_call (getting the DHCP lease).
=
What I've already tried:
- we have a redundant= set of DHCP servers which offer static leases (so there are two DHCPOFFERs= ), so I tried to turn off one of them, nothing has changed
- = tried to disable SMP, the effect is the same
- tried to see w= hether it's a network issue. The NIC's PXE stack always gets the le= ase quickly and booting FreeBSD from an ISO and issuing dhclient on the sam= e interface is also fast. After the machines have booted, there are no netw= ork issues, they work reliably (since more than a year for 20+ machines, so= not just a few hours)

This issue wasn't s= o bad previously (only a few mins to tens of minutes delay), but recently i= t got pretty unbearable, even making some machines unbootable for days...

First I thought it might be a packet loss (or more = exactly packet delivery from the DHCP server to the receiving socket), eith= er in the network or in the NIC/kernel itself, so I placed a few random pri= ntfs into bootp_subr.c and udp_usrreq.c.

After spe= nding some time trying to understand the problem it feels like a race condi= tion in
bootpc_call, but I don't know the code well enou= gh to effectively verify that.

Here are the mo= dified bootp_subr.c and udp_usrreq.c:
(modified from stable/13 = branch from a few weeks earlier)

This is the o= utput with the always working DL80 (igb) machine:

This is the console ou= tput from a working boot for the XL225n (bnxt) machine:
as you can see, it's = much slower than the DL80 (which also isn't that fast...)
And this one is a longer output, without success to that point = (2 minutes without completing the DHCP flow):
https://gist.github.com/bra-fsn/128ae9= a3bbc0dbdbb2f6f4b3e2c5157a/raw/a8ade8af252f618c84a46da2452d557ebc5078ac/XL225n%2520bnxt%2520long.txt<= /div>

For the latter, here's an excerpt from the DHC= P log:

<= /div>
It seems the DHCP state always gets reset to IF_DHCP_UNRESOLVED e= ven if there's answers from the DHCP server.

Here's another, longer console log, which succeeded after spending 2= 36 seconds in the loop:

Any ideas about this= ?

--00000000000080e78305f70b1ed9-- From nobody Thu Mar 16 22:01:32 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Pd1SZ5Zr9z3yf4N for ; Thu, 16 Mar 2023 22:01:50 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Pd1SZ0yH2z4PRp for ; Thu, 16 Mar 2023 22:01:50 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=UMNzbSVJ; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::635 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pl1-x635.google.com with SMTP id o11so3308024ple.1 for ; Thu, 16 Mar 2023 15:01:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679004109; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=JRfdLNWoSfwFe7qZJ+xblvimo6Y81Ys5EkrB8yU+TIU=; b=UMNzbSVJYGjFDd/NpTJW0qMgACDPQdvFAOeVXK4sX17Ka/I0241XmVqunQLS3euBIb 0KHg/QVk80z1MXj880zTzj2SyMzi68eOw2rR3ctZogV+jZs3lwHuRdJqHuv9rcgucxz6 LWZCufFamQ8Ls9CUg+PD4bwFnu1BN0631rWHj94JWoXVWzab7O9S3oWjrtGSqdcuPxJ+ kez/71LiJxmkWdp12XhMso1P4TZw2jQEEeOieCFdAlLFah79qRRL4EaNrLQL4ZjZ34UW Pv0E8xxf+yvFKhZKWQXKrBsKHcGFmmb+tEFfgaEIesgEBmxsAxR3ERW5bU0Jg576dy/+ JITw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679004109; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JRfdLNWoSfwFe7qZJ+xblvimo6Y81Ys5EkrB8yU+TIU=; b=R8pXsYGIFUm8ieFu7cpuJ+ehi2fNFBIWSJ1+sDnOp+t4hNZrpJnaEQ7J8IGjamliSX kH/OazbpWNm7ifxD9izUk9m8gsElG3UiXxCv2k9l6DoUU/4ES69lrEIPNMdy1pGDQFp+ qq8BNoUExhP/Wh1Ut5MRu8HQoZqLTuNi/MCplEqI6DcapUKzRxJnh+aHOJLl8cyB2W6j 5guuDs+KiNqbf9TE+FgCCLSD3Un54jf39yir46qUHdaiEcziuF7wsyXrotfBqR96MFNt CwEfUNHio8ZZe2MOKaNnC0YN+ZL1A8EXXANz3270vphvOL4H7JChHEJDla6NCuRJX5Mj CWEg== X-Gm-Message-State: AO0yUKVLspl68ZEROWAbUl/FuZjk45lvDXHqXEOZ7tKiHqNSKBJgKnJu vcUMnV7sjdWHEN770ZJYMyEzknV8MMjyrKw3/YKPz+mg0A== X-Google-Smtp-Source: AK7set+WUKPDPHWczCLJ7hw739fd4y+CEB4yi9VWA5gZ05vaGClgHmqY2kieIz+YitHZG++6K5dMNC2AVwMsYyMzkmA= X-Received: by 2002:a17:902:ecc7:b0:19f:3cc1:e3b9 with SMTP id a7-20020a170902ecc700b0019f3cc1e3b9mr2306864plh.4.1679004108588; Thu, 16 Mar 2023 15:01:48 -0700 (PDT) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Rick Macklem Date: Thu, 16 Mar 2023 15:01:32 -0700 Message-ID: Subject: Re: Kernel DHCP unpredictable/fails (PXE boot), userspace DHCP works just fine To: Attila Nagy Cc: freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-3.70 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.996]; NEURAL_HAM_SHORT(-0.87)[-0.869]; NEURAL_HAM_MEDIUM(-0.83)[-0.832]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TAGGED_RCPT(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::635:from]; ARC_NA(0.00)[]; TAGGED_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROMTLD(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[] X-Rspamd-Queue-Id: 4Pd1SZ0yH2z4PRp X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Thu, Mar 16, 2023 at 1:44=E2=80=AFPM Attila Nagy = wrote: > > Hi, > > As this is super annoying, I'm willing to pay a $500 bounty for solving t= his issue (whomever is first, however I don't anticipate a big competition = :) Having an invoice would be best, but I'm willing to accept individuals a= s well). > I can't give remote access, but can run debug builds with serial console.= stable/13 branch. > > I have a bunch of netbooted machines, one set in a cluster is older (HP D= L80 G9, 2x8C, Intel I350 -igb- NICs), the other set is newer (HP XL225n G10= , AMD EPYC2x16C, BCM57412 -bnxt- NICs). > All of these boot from the network, which is basically: > - get IP and options with DHCP with the help of the NIC's PXE stack > - get the loader and kernel, start it > - do another round of DHCP from the kernel (bootp_subr.c) > - mount the root via NFS and let everything work as usual > > The problem is that the newer machines take an indefinite time to boot. T= he older ones (with igb NIC) work reliably, they always boot fast. Haven't you at least partially answered the question yourself here? In other words, it sounds like there is an issue with the NIC driver for the newer chip. (If you can replace the NIC with one with a different chip, I'd try that.) A possible workaround would be to switch to using "options NFS_ROOT" instea= d of "BOOTP_NFSROOT". This way of doing diskless NFS depends on pexboot loading the FreeBSD boot loader and then it sets enough environment variables so that a kernel built with "options NFS_ROOT" and no "options BOOTP_NFSROOT" will boot. Yes, both approaches should work, but if one doesn't, ... rick > The process of getting an IP address via DHCP (bootpc_call from bootp_sub= r.c) either succeeds normally (in a few seconds), or takes a lot of time. > Common (measured) times to boot range from 10s of minutes to anywhere bet= ween a few hours (1-6). > Sometimes it just gets stuck and couldn't get past bootpc_call (getting t= he DHCP lease). > > What I've already tried: > - we have a redundant set of DHCP servers which offer static leases (so t= here are two DHCPOFFERs), so I tried to turn off one of them, nothing has c= hanged > - tried to disable SMP, the effect is the same > - tried to see whether it's a network issue. The NIC's PXE stack always g= ets the lease quickly and booting FreeBSD from an ISO and issuing dhclient = on the same interface is also fast. After the machines have booted, there a= re no network issues, they work reliably (since more than a year for 20+ ma= chines, so not just a few hours) > > This issue wasn't so bad previously (only a few mins to tens of minutes d= elay), but recently it got pretty unbearable, even making some machines unb= ootable for days... > > First I thought it might be a packet loss (or more exactly packet deliver= y from the DHCP server to the receiving socket), either in the network or i= n the NIC/kernel itself, so I placed a few random printfs into bootp_subr.c= and udp_usrreq.c. > > After spending some time trying to understand the problem it feels like a= race condition in > bootpc_call, but I don't know the code well enough to effectively verify = that. > > Here are the modified bootp_subr.c and udp_usrreq.c: > https://gist.githubusercontent.com/bra-fsn/128ae9a3bbc0dbdbb2f6f4b3e2c515= 7a/raw/a8ade8af252f618c84a46da2452d557ebc5078ac/bootp_subr.c > https://gist.github.com/bra-fsn/128ae9a3bbc0dbdbb2f6f4b3e2c5157a/raw/a8ad= e8af252f618c84a46da2452d557ebc5078ac/udp_usrreq.c > (modified from stable/13 branch from a few weeks earlier) > > This is the output with the always working DL80 (igb) machine: > https://gist.github.com/bra-fsn/128ae9a3bbc0dbdbb2f6f4b3e2c5157a/raw/a8ad= e8af252f618c84a46da2452d557ebc5078ac/DL80%2520igb%2520good.txt > > This is the console output from a working boot for the XL225n (bnxt) mach= ine: > https://gist.github.com/bra-fsn/128ae9a3bbc0dbdbb2f6f4b3e2c5157a/raw/a8ad= e8af252f618c84a46da2452d557ebc5078ac/XL225n%2520bnxt%2520good.txt > as you can see, it's much slower than the DL80 (which also isn't that fas= t...) > > And this one is a longer output, without success to that point (2 minutes= without completing the DHCP flow): > https://gist.github.com/bra-fsn/128ae9a3bbc0dbdbb2f6f4b3e2c5157a/raw/a8ad= e8af252f618c84a46da2452d557ebc5078ac/XL225n%2520bnxt%2520long.txt > > For the latter, here's an excerpt from the DHCP log: > https://gist.githubusercontent.com/bra-fsn/128ae9a3bbc0dbdbb2f6f4b3e2c515= 7a/raw/a8ade8af252f618c84a46da2452d557ebc5078ac/dhcp_log.txt > > It seems the DHCP state always gets reset to IF_DHCP_UNRESOLVED even if t= here's answers from the DHCP server. > > Here's another, longer console log, which succeeded after spending 236 se= conds in the loop: > https://gist.github.com/bra-fsn/128ae9a3bbc0dbdbb2f6f4b3e2c5157a/raw/a77f= 52f5e83c699b38a7c2d3acdc52d26ceeba71/XL225n%2520bnxt%2520long%2520good.txt > > Any ideas about this? > From nobody Thu Mar 16 22:11:27 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Pd1gr197Mz3yfrv for ; Thu, 16 Mar 2023 22:11:36 +0000 (UTC) (envelope-from juraj@lutter.sk) Received: from ns2.wilbury.net (ns2.wilbury.net [IPv6:2a01:b200:0:1:f816:3eff:fecd:13e6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "svc.wilbury.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Pd1gp4Q6Dz4RLd for ; Thu, 16 Mar 2023 22:11:34 +0000 (UTC) (envelope-from juraj@lutter.sk) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of juraj@lutter.sk designates 2a01:b200:0:1:f816:3eff:fecd:13e6 as permitted sender) smtp.mailfrom=juraj@lutter.sk; dmarc=none Received: from smtpclient.apple (gw-upc.owhome.net [188.167.168.254]) (Authenticated sender: juraj@lutter.sk) by svc.wilbury.net (Postfix) with ESMTPSA id 6281645CE8B; Thu, 16 Mar 2023 23:11:28 +0100 (CET) From: Juraj Lutter Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_FCEC1CDC-5E9B-4FCD-86AC-91B88AF5B8CD" List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.2\)) Subject: Re: Kernel DHCP unpredictable/fails (PXE boot), userspace DHCP works just fine Date: Thu, 16 Mar 2023 23:11:27 +0100 In-Reply-To: Cc: Attila Nagy , freebsd-stable@freebsd.org To: Rick Macklem References: X-Mailer: Apple Mail (2.3696.120.41.1.2) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HTML_MESSAGE autolearn=ham autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on ns2.wilbury.net X-Spamd-Result: default: False [-2.80 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:b200:0:1:f816:3eff:fecd:13e6]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; ASN(0.00)[asn:44185, ipnet:2a01:b200::/32, country:SK]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_DKIM_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[lutter.sk]; TAGGED_RCPT(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4Pd1gp4Q6Dz4RLd X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_FCEC1CDC-5E9B-4FCD-86AC-91B88AF5B8CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 16 Mar 2023, at 23:01, Rick Macklem wrote: > Haven't you at least partially answered the question yourself here? > In other words, it sounds like there is an issue with the NIC driver > for the newer chip. (If you can replace the NIC with one with > a different chip, I'd try that.) >=20 There are more PRs open for bnxt(4) driver, with no obvious solutions. My personal experience with bnxt(4) is also very ambigous. otis =E2=80=94 Juraj Lutter otis@FreeBSD.org --Apple-Mail=_FCEC1CDC-5E9B-4FCD-86AC-91B88AF5B8CD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 16 Mar 2023, at 23:01, Rick Macklem <rick.macklem@gmail.com> wrote:
Haven't you at least partially answered the question yourself = here?
In other words, it sounds like there is an issue with the NIC = driver
for the newer chip. (If you can replace the NIC with one = with
a different chip, I'd try that.)


There are more PRs open for bnxt(4) driver, with no = obvious solutions.
My personal experience with bnxt(4) is = also very ambigous.

otis



=E2=80=94
Juraj = Lutter

= --Apple-Mail=_FCEC1CDC-5E9B-4FCD-86AC-91B88AF5B8CD-- From nobody Thu Mar 16 22:55:55 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Pd2gL4XFSz3yjWl for ; Thu, 16 Mar 2023 22:56:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Pd2gK05Xyz4WGr for ; Thu, 16 Mar 2023 22:56:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=CKOw7MDd; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1679007370; bh=G5pSUKZMs/AelGlWhI9jXEfCGrRTufH++WWiN5Im5wg=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=CKOw7MDdpICyWzIp+NbRc3mO033SvIDucgACaivdg9wCZTUPmHj1RM9IbdmYIsDy9La5/SlObX5RHD3nNrEWimb1hdqhS16gQl1LND89m8OguXGoVrH6a0cp2uX+OisQIyQ2V410FeiYnDd4Z4amtJpLuPBfTd2MFQx7FTtF1lbVZfgF74JKyZgoUom/Nh8lLj2+gyQwzJWWgkT6meIIfys2sJ46VlacFmdaWIvn33smu4caOD8JtUBRCvGxnnieOrC9yOh0faX0V3oBqUtEAcM9zWMMoN5ELJHN1/zoclcff/AX+zofuiQtydnHYBXnR8ML5xN5zHpQI05WxNWUhw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1679007370; bh=CvSXUSUTbVXguwUyYF6QMXs338V3wyLbW1gshjLBVdq=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=uRo/KZs4UQeHCVPtClQkQSXrQ9aWCbbhFM244DH/oYhtniJCOEaLgQsZf145dxANzO1vdywnLB3CXp7E6mM5XGiHpWt/erCtB6ci8TG4w7wxHy6qbcgRGZTeW2x34Lpcg3JD3gD+BoeYCygLp+oN2DHorSFdoStgBl0D3qoYg2MF+jrM5Ru6wlTxCpziQ0epkB1Ei4goYmpyHmrTHtfR/XHhMtKsUBSZPG1YpMNXOWlbLf7IGiZGVshA+AnC66oDUMZ+krpd/+BRD8bPCwLUALBOPdr/ZWvo9TmJfwcsg+Wi18S91VCsy7cWLsJMhFJ9esKuKGaCXOt5Bwqfv0rKtA== X-YMail-OSG: H4CgcTUVM1lTSEiNBdKTPDvqWT49H5bnTvrDPv3RyAfWCbuDD8LF4yxsjo6qSG5 uBVffO7BILmldpD6JAhxx5_fIS7IRXEbjbPD_cSFMkmRwfFjCdxEmsqRTvx1g7gROic9Ml8G1hNh 9ajhMJdMaJEmaDezMP_XYy0PcNMQydM8MH8NcQEQlD6ScJ4hVkdUhgFJCqtZexFcZ6t9QoF5P3yO jK2jrKMav.alTewzxghN87VPkhu7a_sGrN4cPokBekbJJORKpofWKxeFCp6hGavpd12i2vg_Hhjn zsiLy6Xt3u9___u0xTMpu4zSvkeQQ3hkVVRgbG9AhN6tjhcLcOEvywKWsVSB.4ZAIJHXg6YVzTC5 zO9iquxsLRAPu1Qf_WHONxrlrIjeqQqMDwkyPzjkkAdmHrDs5vzkU.lB4HZizqxiSd9afRYnrp5h QYhxWnNULpGicyNmWAiRvqnrzi.G0v6amiP_5TvplLF4cGGb_Yvd6XigIHnf9vItsnsbgQZoLTh7 c1m1oCQgEVyWnQe1Y_aJOlvaotzgOdJnLcuphdMNNIT5kB0ChmzzQ1hG_OWKTZMLMW9mJjNPxqgE .7m2QFkoEhuI2MmqXrnPrFeEZT5MkSNxBuGSsgKog332WaZjUbt8x3U44VnrTgpBDSe8eauWj270 toT7YUrxDtOT4Djb_CJFb2KemRfmpmxXrENQwLVtMhTPnV.C4AFJCUn2U_ibgzo9IPE7b.hH7Tck LaCaEYoDj_eS9RSQcsKt5FnD2h2XAMO6_GIwepGARBWYqoW.FwVAYPudTivOzoBrqJYPLu62HLjr iS3UOJxi9aGSEjSzSEOvuiFERl_JM.6PBVqLFx36Bujt4seuVCCN3i7ZfVBFNwPSBEg073pgCd0y Zqgk_qjRxWK.TSJluNr8_PqLdli1WLhxbfw.FYPesL8mP.QkrQJUfcIIcO8mniNrZuJ73cM0zURl TmfjQN5ethNSrYTybwpZHwzJ.0dvrsh92tBFfpkpgmAhK5tYR9PW9ht6UTPTlalefVwLtRAy04o7 cQkJi8K_lplxd3ilIafnkpwXtoKsAoNcO9KcVI7cjCZ21YKtvm_45zQjPLk9UhUCidPhXZ83NZ5X 80cMNHAOi.QdzKH4mq2zIIfStqPH23LKb5qjqeOQN4xQ1PLb5dGEB87ki4qJzqovlRoyhZkHezYV snzBFQxHD90UVGPQv518P6SSICgsDX3YjPL_qf2mD4eVoW8HpeZ7_h6rcT018Q_VNwaSeQ6T_Lvr j8G7d1IJsPXfvtjMAu9rsm7k.skbpDcICm8.IJ4qah_IiPKRBRHUqNHGV2hGEXKW1wJXD2_BhC08 uztVBVf7OhjT9flZ4i8orsfRhJpNR7zsh4Sb3LK0RSp1w4GE.LdPwGNb3dHgln0HyLMx5f94HJvK PKvLY_JUJ6phd86DB_MkqRL_vHFwDExMuOswM_rLakuEezd6B1x9MONzS0JF7dVzLGIaqheypl7u S0WwqJC_SB9difHVR_LJSE52C_3s3f7ciUwudkd.C.eesrzYXZFlIqCa5I8lkGtq5vanC827nbRj kX4aiN56n1ycwvKWGGDD2d2MPmpkiuDmqhMX0O6LjimXggRioo4lB2NPScUdhjbip18n7Y41atE3 T9baZpqt.S3kX92povv8owABsGaNLuRyie0zYXBVW8_l4C7mwVZvjYVW7QwSdBM3z6IMcK5kC7nv ZL0UWmmONQogDrOFWefzf3ZzKtxzf38EWNXWEQto..9M1.jhqqbOAwSAVBas6Jb0wrCwzZbBJ_5n Yd.feKv_kEconF5u6LZNIT.GW6zL9dRrbM7IcKOwkfEMMT8xz2ldhz0KOo3daJyyFQEZ4.UPZav8 6YcsmOc3eBBNAddwQwT6.n3OuirEo_mu.L7fEAzJLDJ8zQNS_l6_JPyRrg0tYrI8Yo2ZHNvDAjvW yukpVI3zsdObIFr_ds_GojtXgjraH9dB3HHa10gbEnVw.wlCALMUUxoQhPM9nRI059alGQzLwg_8 Vrpm1lbWjUbcsn5Hk0pYeowwx_zI6ltdhqH9oB3852SJ8WZAwls7i3zVN4CVTNZ6HqcjNJrBHxfY UvqF4a995N.104VOxyg4NfILzr9sDwl44GJVx2OW7VDs2dE6VZW0PmluL7oYmNZ4wi6el4p.69.0 vMQBJAzDe4TFqQKcmAIAZ2rriEHkbjWl6nQaN7ll3DoAyaT31UzEav95wF3HVHmhp2eoxP_zITG0 2ZbrehHiX9LUNEUWDN4LshfYYP3dEA8UZMJ05S.CejnuWqXpFFGh.WufexgStzW2wj6kap7bb14R wUSwuRkTx X-Sonic-MF: X-Sonic-ID: 70231a56-773f-4ebd-8435-9ab9be72a9a1 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Thu, 16 Mar 2023 22:56:10 +0000 Received: by hermes--production-gq1-6cf7749bc8-lvvtt (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ecc01a7860eb2b3c09070a2e8581ccf6; Thu, 16 Mar 2023 22:56:06 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: I just updated to main-n261544-cee09bda03c8 based (via source) and now /etc/machine-id and /var/db/machine-id disagree ; more Message-Id: Date: Thu, 16 Mar 2023 15:55:55 -0700 Cc: cperciva@freebsd.org To: Current FreeBSD , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3731.400.51.1.1) References: X-Spamd-Result: default: False [-3.41 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.91)[-0.912]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.206:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.206:from] X-Rspamd-Queue-Id: 4Pd2gK05Xyz4WGr X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N # cat /etc/hostid /etc/machine-id /var/db/machine-id a4f7fbeb-f668-11de-b280-ebb65474e619 a4f7fbebf66811deb280ebb65474e619 7227cd89727a462186e3ba680d0ee142 (I'll not be keeping these values for the example system.) # ls -Tld /etc/hostid /etc/machine-id /var/db/machine-id -rw-r--r-- 1 root wheel 37 Dec 31 16:00:18 2009 /etc/hostid -rw-r--r-- 1 root wheel 33 Mar 16 15:16:18 2023 /etc/machine-id -r--r--r-- 1 root wheel 33 Mar 3 23:03:25 2023 /var/db/machine-id I observed the delete-old-files deleting /etc/machine-id during the upgrade. It did nothing with /var/db/machine-id . Also, modern hostid generation was switched to random to avoid an exposure. But the update kept the old hostid and propogated it (not "-"s) into /etc/machine-id . So /etc/machine-id now has the same exposure. Later I'll see if stable/13 also got such behavior for its upgrade. I've not been dealing with releng/13.2 but upgrades from releng/13.1 and before likely have the same questions for what the handling should be vs. what it might actually be. Different ways of upgrading might not be in agreement, for all I know. === Mark Millard marklmi at yahoo.com From nobody Thu Mar 16 23:27:53 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Pd3N84ZtKz3ykwk for ; Thu, 16 Mar 2023 23:28:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Pd3N764Hcz4cLj for ; Thu, 16 Mar 2023 23:28:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=NkMYAbMn; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1679009286; bh=/QAB/PyN8v2d1VMT80GYGj8XW++FWCryxjod8iLljPg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=NkMYAbMnaebV8Q0WPNRuL0KLMQcfkOMTfyFS85i/MyfgZkD80HJnCdzL/W3E9uyJU/HxErKOUsxK1yQvDmmcPgMmuuDSrzuJ2lhswzR8/I/zNhCi+cQgLO739MAf1Q6JOTbAmHBTsZf6IcAwkJPTbx3Ecuh2FBqCHB5bNwOMR9kUwKf1yJBRpDqg5oz5M/W6z67A8rJjXTc83RQrebCAzkyrSRdLGzbf2TaDaMPxgbO9iRBV472YqWjUownE3+DBhdOMsZK3ki0zoYXaxudYvTVjFQzcmkm1ZEXqZtsQNfeI3dMlVjs/h2Ge0LG8kSBdZA36OnikPOaZraYNQmhLXg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1679009286; bh=hkrxJsBOHGPHFA2xXSzDAz9hC6ZajBCV/BdjbYe5GUV=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=hoWRHLJI43QX3E7iqnZeKdHZ6EkKDkqXWMekBfBH+k5aDfXxu83v3z9ngbE4bucufpHxQuDO35H8FhGgINK0oN+49wgDu0mcwO2XjXxohK7l5mTybGa5ssAYU15h8Fpv8k0htwQ1MeDVF/UtxvEBKmHrKbjUANMGfL2j2iLg/WuTQBYbbj634tPa9cc736T4m6Up9G6o+W+V6k7E3zuBul3Ae37dJGhQDTgpnmhpkw3l8uKXqTS9YrmgEseKg52ZmHEZ3GGoaFzxy37osZs5J8br4J9bFdjYA2YzML55CTCvMHFjmpdwMeinynePvocpoPlONrcMsetncA64/DY6XA== X-YMail-OSG: sgSccPAVM1lFvHgMHzHOKAIB4W8j0ORiaqkkVnEwEDbhZjiRt4pniwxSy_vfShh 2o8SoImGHEmbmrQKDd78Qb3mbWo7yFkoD6iq9nIz1CyjFgtOQDjytp.kx1MK90li_9t8JY2yIyhQ F39jEksrdU7Dy0bEriuud4q1uGSbl3c5XXz2iQn2m.NQN_SNufATIJAvpdVLZxoOoRwgquu8_40q 28LMT1rFtb6B4HlC6uXWeZb7mOx9gzCyo.4Sruq6uJFrk0EMWi2tIQoTX56OB_Z5FWflhGT6m8kq NgyfGWkzd1pSsdFGa_N1UFefetkbU9o.gzQralRFt0vZ8luq4SFbfWAXxa3W955KXT.YW9ZDp1cL JFTEqmj5wPhzA68qb2DGnWn8wsZ4XbhvZzKorKHM39h1XAZX_lEy1WB6RleDiDZM6Nh6ETSEeCsG H2BYhyvHapBGpRrnokX5LabP_6hSjp5V2yyH1HoG2O3Xzme2M6UTIouGazM2t2T1f2CQRtLLjcPX 3fWRuekQX57kKgLikhGPD82bSnyI2tVn14_dSX6wE8bCUh.AMqpHoeSARxNOGJMMCI92xndyn2XX depnNIZ3peaX.6GhPOfBTkDiSbhHCfW7RQEe46ojP5vLg.fX4Jr9dBWjttSVIUdkpDD3fa2vD2Qy pjxXIH6wmLzH8uGu.ZOEl_f.yTFpaupoc2Qi9oJR4j7z0jJGce6GL._q6X6TYLGbbD.2UKj.H2Dm MdY5xn7AhxMjVbWR_vhjX85j7jM0bSAld0eFW4kzJt1BY6GgJh65dWBJxvCjGvT6WE56at.ancLp GlQ_L1rDyzQxMV9V.VBttkfT81gBEqtS5sSp_1_jHWtjSb_dvvJhe3u0p.VVp8bEe0WoGED3UBTW M.wIEoTvrNeo_bCIaP7p7G4KJoTBfXutgz1uuF26Q55zIlQnWxWT8xZCD8olNnymexykkOFJAdqW 6fAerSVVzn5ARKoLZ6z98R2hTepe_NvcWg9RL869SfMu0blKozeNVak2fJhqUAWVPbK0rVj9I186 vUIHDnBP6fqV56yYpEMQQeZj_gkDdtyWdY.heeZ7FCbc46RZ1vs2JdUbO_D5j286T2.ZJQGlxaGU 8Yxfi9tomYFwYgeGW79vJqoSbzaA81KBnqqruaTwHNkL_s2ue2Rc4afdHpb5WzANS2PRsBJZQ2Ci GykAZDuQX3BNBYgltX8HdNFnxu40EwjqIP.P62EcnTw_OVSMtl9rXJbbiJN58dTj_JvWiDvxkUNe bfoGiu8feStGl0yIt3yBPJrLKoi2ec4ILUbH7PxAfcCMpLcJDrAAJgOhcxkVI22w7PidUf14iBtw i41Y_dvXIraRe64W75KTCbpmc37YlnauzP1P9VgSEFeB5CvsIIqO8RwXkPoNuXi30TQLSMXn6TDk iCHg7w5PYg61v6nZbK4GorIhkOANpe.rgb1iuUiEtTQ_yK7MEQTfOOMBnJRGuutaZlZNDvHtNGU7 Sagep9NNM6nDtTDor6AXgX.ag.OKZfhqn_pu3iNzTPrOuLFZ2IvmrXqHUZY9mf9_1VWFNjRb69ta rB2e.6ZYdjoiN3CKkUQpY1UrOZDgvteKXHrmszTJ1pV9sdYJR80nBZug3a4Opk4v6llfcSznMpq6 CmxhQDIlJR7WoxkzOfaaNqokK_MlmaKNxELjHIzxfjw5NBGHcLP.ecZaYPNZ4pTCSKhRZqxBvr0A z_dCFvEjk3GZW.Rh7sFiMdpR_6Nk5aZF6ca6E7xyR.AUKTkATu1X2QrTeodj7r1cZK9CNeeCjEGu RP7h9sivOBVdTsd6KuFKgPWggqFZeiIZE79DSfwc61ePlZd1pCr7w3p8cpIdtWe1zy0WOxAlUtKb NSQIMrLp9m.htJNNs4V2PyMWmEidhsOQ8zln1c.pA8QzdFia6680nr13L3MdhsugfMUahfywkPS5 LnULHWEFfeUCPhTC0wR_YXuqAD4CykqO3IvZavRKP_BMD78kun9JokAF1ZjutoWUXomLo6q9wKN8 hSSxUYu4.yEqpZj9lI9yYweozGBARiCspE9iieoxbQOhe1CEKZmtMSnOysfDB27ZVKbgQ2gLGfAW hrkij8hL9uJoPiaNtR7BUua_qM9vXdCZ3brrhq.lmNCwm0cJrf9ekWfXusjiG2pEQE_eG94DJ.Vr UfLWCZaXCsDOsrcv2JjAMA4TUEQCjmU8rs5Nqiu7Q7aV.nBgOUqlf8.GiLiSJv0qyU2b1MAQkE.H LfFDvs8bE1XY66ZW79XbRwf5Qw8.TtHOjkybrQe4Gv0IkTcXIIe5HzN5n.1ZVn03rYwAWmPCgpSf VTpHTZBOn X-Sonic-MF: X-Sonic-ID: 8d9aef6e-8c04-403a-b20e-c73ae2c74b1c Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Thu, 16 Mar 2023 23:28:06 +0000 Received: by hermes--production-ne1-759c9b8c64-v6wcd (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID dc68c932865eb8e87ef0eacf1ad78a7a; Thu, 16 Mar 2023 23:28:04 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: I just updated to main-n261544-cee09bda03c8 based (via source) and now /etc/machine-id and /var/db/machine-id disagree ; more From: Mark Millard In-Reply-To: Date: Thu, 16 Mar 2023 16:27:53 -0700 Cc: cperciva@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: To: Current FreeBSD , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-3.31 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.81)[-0.814]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.206:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.206:from] X-Rspamd-Queue-Id: 4Pd3N764Hcz4cLj X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Mar 16, 2023, at 15:55, Mark Millard wrote: > # cat /etc/hostid /etc/machine-id /var/db/machine-id > a4f7fbeb-f668-11de-b280-ebb65474e619 > a4f7fbebf66811deb280ebb65474e619 > 7227cd89727a462186e3ba680d0ee142 > > (I'll not be keeping these values for the example system.) > > # ls -Tld /etc/hostid /etc/machine-id /var/db/machine-id > -rw-r--r-- 1 root wheel 37 Dec 31 16:00:18 2009 /etc/hostid > -rw-r--r-- 1 root wheel 33 Mar 16 15:16:18 2023 /etc/machine-id > -r--r--r-- 1 root wheel 33 Mar 3 23:03:25 2023 /var/db/machine-id > > I observed the delete-old-files deleting > /etc/machine-id during the upgrade. It did > nothing with /var/db/machine-id . > > Also, modern hostid generation was switched to > random to avoid an exposure. But the update kept > the old hostid and propogated it (not "-"s) into > /etc/machine-id . So /etc/machine-id now has the > same exposure. > > Later I'll see if stable/13 also got such behavior > for its upgrade. > > I've not been dealing with releng/13.2 but upgrades > from releng/13.1 and before likely have the same > questions for what the handling should be vs. what it > might actually be. Different ways of upgrading might > not be in agreement, for all I know. > stable/13 was updated to be stable/13-n254805-4e4e299b0950 based. It got the same type of results. (I'll not list the actual id's for this context.) # ls -Tld /etc/hostid /etc/machine-id /var/db/machine-id -rw-r--r-- 1 root wheel 37 Jul 5 20:08:03 2022 /etc/hostid -rw-r--r-- 1 root wheel 33 Mar 16 13:32:49 2023 /etc/machine-id -r--r--r-- 1 root wheel 33 Mar 3 23:07:55 2023 /var/db/machine-id (I'm not sure of the intent on the permissions.) === Mark Millard marklmi at yahoo.com From nobody Thu Mar 16 23:48:40 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Pd3qt3bgXz3ym9Z for ; Thu, 16 Mar 2023 23:48:42 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from mail.tarsnap.com (mail.tarsnap.com [54.86.246.204]) by mx1.freebsd.org (Postfix) with SMTP id 4Pd3qt1KyHz3FNv for ; Thu, 16 Mar 2023 23:48:42 +0000 (UTC) (envelope-from cperciva@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: (qmail 68679 invoked from network); 16 Mar 2023 23:48:41 -0000 Received: from unknown (HELO dell7390.daemonology.net) (127.0.0.1) by mail.tarsnap.com with SMTP; 16 Mar 2023 23:48:41 -0000 Received: (qmail 88592 invoked from network); 16 Mar 2023 23:48:40 -0000 Received: from unknown (HELO ?127.0.0.1?) (127.0.0.1) by localhost with SMTP; 16 Mar 2023 23:48:40 -0000 Message-ID: <2cf7d953-2493-9673-5ea3-fba22c694015@freebsd.org> Date: Thu, 16 Mar 2023 16:48:40 -0700 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: I just updated to main-n261544-cee09bda03c8 based (via source) and now /etc/machine-id and /var/db/machine-id disagree ; more Content-Language: en-US To: Mark Millard , Current FreeBSD , FreeBSD-STABLE Mailing List References: Cc: Baptiste Daroussin , Tijl Coosemans From: Colin Percival In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Pd3qt1KyHz3FNv X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:14618, ipnet:54.86.0.0/16, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N I think the current situation should be sorted out aside from potential issues for people who upgraded to a "broken" version before updating to the latest code -- CCing bapt and tijl just in case since they're more familiar with this than I am. Colin Percival On 3/16/23 15:55, Mark Millard wrote: > > # cat /etc/hostid /etc/machine-id /var/db/machine-id > a4f7fbeb-f668-11de-b280-ebb65474e619 > a4f7fbebf66811deb280ebb65474e619 > 7227cd89727a462186e3ba680d0ee142 > > (I'll not be keeping these values for the example system.) > > # ls -Tld /etc/hostid /etc/machine-id /var/db/machine-id > -rw-r--r-- 1 root wheel 37 Dec 31 16:00:18 2009 /etc/hostid > -rw-r--r-- 1 root wheel 33 Mar 16 15:16:18 2023 /etc/machine-id > -r--r--r-- 1 root wheel 33 Mar 3 23:03:25 2023 /var/db/machine-id > > I observed the delete-old-files deleting > /etc/machine-id during the upgrade. It did > nothing with /var/db/machine-id . > > Also, modern hostid generation was switched to > random to avoid an exposure. But the update kept > the old hostid and propogated it (not "-"s) into > /etc/machine-id . So /etc/machine-id now has the > same exposure. > > Later I'll see if stable/13 also got such behavior > for its upgrade. > > I've not been dealing with releng/13.2 but upgrades > from releng/13.1 and before likely have the same > questions for what the handling should be vs. what it > might actually be. Different ways of upgrading might > not be in agreement, for all I know. > > === > Mark Millard > marklmi at yahoo.com > > -- Colin Percival FreeBSD Deputy Release Engineer & EC2 platform maintainer Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From nobody Fri Mar 17 00:27:53 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Pd4jN47cZz3ypBN for ; Fri, 17 Mar 2023 00:28:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Pd4jN0gZgz3LFt for ; Fri, 17 Mar 2023 00:28:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1679012886; bh=piYhL+d90/MbK5yZyifAXR7ZvSFcwB1l2ihWEXU63PE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Ig8Cazf4XuuIa04+nks8LXfWKoRMEKyExCo5Zmf8cYIOjEYCJKMDonS4hRa9PYcReTviNVUb/TVFxBQ1GwV58vMczH1BQLLvzhuP98DQvfXo9RkZYtzEmoypZpTDubDGcGD6z4tkDCQ2g56MW3e6/yB3sVxD4y0qc0EtStTz1dUhYLZKc9F5tpK70fqNR+Y2Eco6jRinF/Bq2YIq/h5/eGCpkPWnt4Sf+vebHD4pXdIqo6/QeYt42tw5rmagkJPFzXIHsjbUzZgTyPqGoS5CpFzQOPRKT+TM3EhZL3WwI2RUrKiJAJ9nMcdPTeBBmwUWiziQoS+vE1H3zJKnZat+uw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1679012886; bh=tlR21I+Bho90EsZ5S/nJqF/fOtETj8BZj4FIeHrObxH=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=m7Pa/DJAWZ6cANlH5JwtK80K7mBceRVLL3o3Cqk2A5n5VqznP0RnmVj96nwhA/nU+FfkOr9KQ4wLxuuf/dZaafBgmWuOEhBhqwuF+amdAt+hf2YtMutjcErnMqq6TJqg2x5KE8VsPvrUT/tbEHLs9I5Opwsbdj0+T/jOJAdQOI1joejUdQcZKYVHhlAYl4/BxAtfrxcFCd33S7vLHoC4J6QppmNOUq68ZD6WtCS8sCVYrkf/w6MxMfAADHYucy+SmcGio9eF6KWGtdIuntr/2/jlmuG2lc15/82Gr0aAtqhKvwgJRP5W6uRHgCXLm6OF+1x3daMrHviOItJqwVxHgw== X-YMail-OSG: m33vXCIVM1ney3nDRTVh316MfXSsE.fhhNlA1yGdl7IAh0gj_eyZ4TMABrAPQD8 k47iXtAziNTuL_AXGeENEEU0w3eW6.eTv33vrv7TZAzCLc5P9J0VmxJgEc.UyZIKGRvfL5ifntM3 mp8Cg9m18WWpk9eRql8UcNEQLgJ6fHRSmgarKrgswFwblOteY3xCA9_ojxclbDDTx7v7E_IOhqbl p9wnRvqWCoZFojprWY4DwLTtSh8xX_QKV24r05K7QYBmkLmdsMnjQHsWH8FYVIzJrZE5IA2r71Eh 8Ofjkrc6SEDQ8xWFuQuVdDlnp_3X_Iww7.Wh7gMXlZK18obebkUjhtEWljEm3Hma5v0LMCs2IMSo h35i7U1LhcRL3QN1WDpv1pQaDmSVGaRcM5vdlgrG7eCWvA76eyHtBp83VQNdKgT7SzDzot43VZrt CgemXixSf2NOrwVdmHogAe80_leTd_6pQrjrJ5aAMCM1GW2oZf8LMSXbMluyfymwePqU_Nsovk_e 5BjzgdRpSPWdO4zoRT3lgkfmI6Li7NGeFcCrtTU6I6.36BNf9.uKng5O6BfA8eOHM1Il4b8sCF8g ocNaTCZj.CKp4l2gv55eCV28Xm4UJiDwmDXITCTaICTJjTpJEk_BNr.nwQFgyrBT9URoWsycxxIB MFJlWFSQeQmA2dCl._XIVCmY0DTkE0zwv4ThHAOwQdVFEEv5t8MwmJsr6X_CZaLR11OPZAB0wXhc o.b2J3jeAiM36zDqzxrnpKWNX4rFvS2be0Ih2NVw.pCONG.u0_zs3.rNPcwJ2bY.4MHLPdunAb7j wQSWSKEQ6nByC3kUpM32W7jkCg.twrExIKaHURRO8.lK6FIgun1c6opjI9mjRT4CkWe3HFte5CGY GqsFI2HqBX6eiHZnbwCIsiRf4E4zHG0TXSbnbMsHSXwuKI.QbI_kf3PSRUwwgicbu9dKvy7HI91Y WpzKHjB3NSwQCnutlON9gWgQWkryGEaL4cvQC.CwP12zh3TtzaR2DDL3xZA0tC5sQVuLi1HK0QZS bFN36mJkUBL_Sfzo79PPrGlE9.G2AinxU0T9RPnpQ5RnvGKF_f35aSUzAjrdxIlvAgheR.GOh6uW HquB8u05PvYgilpzZeDTBX5bnOPYPnOUM9tC0tf3VkEK1mKfEl9Nw6DJ.e0Dpf5xCsG_oe188fey 5._2Eou_fXd6elNHGDY0hljOZKTx2CzhDqbo6SabZvGvtZTphXh1vi0mQXAyC0eNXpYYCzLy.5CH zWMyn7NH9V701obMH._kSlbweSOVazAniZndFMGkUuvsBTxd7y2.bnCV4y2NKJjatKJDRzLRm4su l6bZUu22zN9e7fSJH5rTHDgt4WrvfoLMJV9VifRJGtdxymdWI2G7nHzN1oNhnGZ_ge2ocC3FqiD4 rMmFPxzM9sAT.72uClNpruDJzMwd8luM.3jC1enpaOp5ExTydEhPnuMP9Isvlswf3J6NcKIhl2KY Y53APM7GXVdkCw_xMN0xO5fmWX5kkN6yOBbcmAMXJvJx9CgGh3nck_LWBE3nuaeEblraWXo5F4UY edMNMMp48O6zrLLg9YQk8iNDwDoGPQ1Il6e5jMhYyY.kWjWu.A328gNwGfBs4mpmtjXwqVrULKT4 esrt.ziW8_4hHYDE_lg5it5CcvZhkttoLJCuL3QmQ6v8gpg4p9wjR6rApGsAKIkfzvw.ch48IYNU Bo_3IIWHfgbSsEzGcuikhbEvTYJZ6xYxFfPeJ.r8WmPf_E3KVHV2L8jrUZMii26v_zhihF4.48Pk KziMgyqRW6Js0HDxPwiQoYFF17zzPmBGT7a1uFfj0HTAkcco90MPSJnRSCdpspLAn_fNQYMfjLYW FooMuzHa.3_4GrtN8g6IHVceG1hiN87vD.gEtl2urx_mdCzsSFx8MGITkkqRzOlpgHOEI433vY1g rAdcBhZxms4uMtZaCi5LzgZAbkiUbHFjrpDGdK1D5lXQXggOxrQXd8bL7f8FM19.uTEaIR_ySU6v UBvi2Stu_r5QQO_rEnMP66aQ5Jl0v_FEW9ECHwONm6aVHAxmrX5DiRKzz.f_VNp6KisTBIbLBpWy 2HxoXmdeMHPd0jkbU0Ize28yZ4MjBySfUzmL2qc0NjX6yprQYbA5a2Ci5_EzS89hZFKc2GNvnVHN kflEnbnRfBMRTf8uU0zgEWylcoDkCVbDp6VV78M5vPq7e0wmhO2CVYQBGOLWH9c4LPqTAlLZlAg. M4fsDvYLja.k7t11UN2PnMAbDrWWEEP94g1Omp_JbZ.U9vg7mvEG1o7RRP8jO7f11fYilNcMaf6f khw-- X-Sonic-MF: X-Sonic-ID: 91ec91cb-8c24-4d32-b30e-896760568027 Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Fri, 17 Mar 2023 00:28:06 +0000 Received: by hermes--production-ne1-759c9b8c64-5jgz9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 015961d27d546f8396118beb16f695d9; Fri, 17 Mar 2023 00:28:04 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: I just updated to main-n261544-cee09bda03c8 based (via source) and now /etc/machine-id and /var/db/machine-id disagree ; more From: Mark Millard In-Reply-To: <2cf7d953-2493-9673-5ea3-fba22c694015@freebsd.org> Date: Thu, 16 Mar 2023 17:27:53 -0700 Cc: Current FreeBSD , FreeBSD-STABLE Mailing List , Baptiste Daroussin , Tijl Coosemans Content-Transfer-Encoding: quoted-printable Message-Id: References: <2cf7d953-2493-9673-5ea3-fba22c694015@freebsd.org> To: Colin Percival X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4Pd4jN0gZgz3LFt X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Mar 16, 2023, at 16:48, Colin Percival wrote: > I think the current situation should be sorted out aside from = potential issues > for people who upgraded to a "broken" version before updating to the = latest > code -- CCing bapt and tijl just in case since they're more familiar = with this > than I am. A question may be if past dbus port related activity might have established a /var/db/machine-id independent of the recent FreeBSD activity. That might not be able to be classified as a "broken version": Before upgrade: /etc/hostid (old style) /var/db/machine-id (via port) After binary or source upgrade to releng/13.2 . . . ? For other source(!) upgrades: Similarly but to a stable/13 (jumping over the middle)? Similarly but to a main [so: 14] (jumping over the middle)? To some extent the "broken" context is somewhat analogous other possible prior history sequences with /var/db/machine-id and /etc/hostid ( but not /etc/machine-id ). > Colin Percival >=20 > On 3/16/23 15:55, Mark Millard wrote: >> # cat /etc/hostid /etc/machine-id /var/db/machine-id >> a4f7fbeb-f668-11de-b280-ebb65474e619 >> a4f7fbebf66811deb280ebb65474e619 >> 7227cd89727a462186e3ba680d0ee142 >> (I'll not be keeping these values for the example system.) >> # ls -Tld /etc/hostid /etc/machine-id /var/db/machine-id >> -rw-r--r-- 1 root wheel 37 Dec 31 16:00:18 2009 /etc/hostid >> -rw-r--r-- 1 root wheel 33 Mar 16 15:16:18 2023 /etc/machine-id >> -r--r--r-- 1 root wheel 33 Mar 3 23:03:25 2023 /var/db/machine-id >> I observed the delete-old-files deleting >> /etc/machine-id during the upgrade. It did >> nothing with /var/db/machine-id . >> Also, modern hostid generation was switched to >> random to avoid an exposure. But the update kept >> the old hostid and propogated it (not "-"s) into >> /etc/machine-id . So /etc/machine-id now has the >> same exposure. >> Later I'll see if stable/13 also got such behavior >> for its upgrade. >> I've not been dealing with releng/13.2 but upgrades >> from releng/13.1 and before likely have the same >> questions for what the handling should be vs. what it >> might actually be. Different ways of upgrading might >> not be in agreement, for all I know. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Mar 17 00:59:25 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Pd5Pq2VYdz3yr9b for ; Fri, 17 Mar 2023 00:59:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Pd5Pn6mK6z3PW7 for ; Fri, 17 Mar 2023 00:59:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=HiKLEuGu; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1679014780; bh=fyTlqinA3BUgBz2T2wVJkMJ04fJPvzhJhX1gA1Go5kU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=HiKLEuGuTmurEUf7BDK6yJ9lSKFQWxAgv9iuTvG/i2F+WJx3m5hgmqZrbn9pYZtkb5vLGRGjbxUHQLKRW244i7kPxWfEReHQncecxR1to5L2xfbqN3OzMEaJF2wo39miPdYbpji+kJGnpVtDHfDC8ktAw5Ztk3DtygVpKJNmylE46f4R1SD4lAV+77e9l/Mm4itpgTgyKbmchJPGXK2XbG7dNxWoQSmj7+UvKyruzlwlcK2cRraxLnd+xQyK0NVPV0OEPsblLyxHJfwtcjA5pqRNEpBhEDHZFb16B0c83BcPWmfz0giNS6R70nUteACCR0mUifHWqmOEBaJh42kRvg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1679014780; bh=Ib3g76pG2c+lCB2uEBu64N6EzZ9F4tqkL+RFcJXMqTT=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=P2D27RAPNFcQyjJ6wp8sLrTDeGDR/2tdraAHQ1DhLNODZ6wWIBBcK6D3iLJY3geFfAbz1+s9WQXSKV10FuMUXeZrKsBj1UqyGvKoTCX++ZaL2cp4wJooOX69iISlSpJW4Jaehj424Z7oEbaRDhrAtuDOcaDAyljMRJLbAdJqUmUI4N3lbMI2WzYy45X0lOsRpe73zRFYN3wbSiZSylsqNMTI6RbjISrvs2yjd9jwTlub+KU+Fg4WFd8A2tHAbfyxEKRJO1J6kHT6I4MNE8h8zX1mKqYQKxNy9r28v/xrmyf8ps97+mdFf2emhFA56xg7haPiSJXw/e7FncRNGzVQFA== X-YMail-OSG: sxlzNNEVM1mszCGQO4ZWrkL4BYAT7F_YcZS95QxKvBi7Oazbtd3JJvgD7IAlSFd tvLnaESYejYqT4SYKmCVn_LG4e75n_TqW4UcooWxVM6VvQhKEF4IBSAKv5.XQxiJdeQinN.HWTQm 4ZJVPynadNUlIdp7FEIgkRd_dFbikM8MaPja4dMSP49Oe6pq5vRC7QgagebVLmmrYBew0_WkQviN LK2DHWJZDKSPH8CmWjQ0QWk1b21xqXqZqLa4sTX9Jy6_rLFRyoXjiJ8LttTuTYS5wC43ngqb6Prx Z4JdiCaRN_L_ClzBIR0MgEUDk2rbjnSyaybc6FuCl13aiI2q_Z4Pd00uGZ59_yCUQQefoBYIbFNn Le.DaMze3BOPGcVyS3XfkTRInkIXwhHhF5oBUvo_OmCCSk8BoHBezLyjy0Yb5MyWcnHGrmIa7eLB I0tSoMzaq8FY.HSaQBmr014CJYPvi4u6QT9n.S3K_dY05NVI.ZM25wDoId1fnkSjhBs6wDAwZsHH pkMHPSeHiciWJOdBrCKn33DyKa2cx73EaT0Wjbf.e84WEWtx5dP4cR_7YN3QP6_g561XNrULgH8o MnCMDotfkfzC2HAjnkpyg_6GeoGAn92m6GcdOTO8_.Eo9yrTI8ojRYA4huVvVcQhKsBXf8rUH4k0 k3ctN5FbZhup0WKWzJuTFiekR5Okax3_HUlvn8xDdA0ER6vuI00.SHaTvUZ0w94qx2zAzRjuT4nO 91mqa1.Zb7YdzeaMxgCGWA1Y4GI0cEO6GZ5ockFsMFten45Y2Tjc1UkVwFwO2Mg3l0e8JjGKfu_X 9PysXwACAtcV5RT0DhLRZGW2OSNDPSEayrC3sbCq3Jsn4XNzHGrvGuMSHc3Ci86sBEXouyadRp_G 816Ilh8fcX46y.1uQeLj70s6vwv19KCSkdQb3GeQB4BZZpsis_7sPrn5jHgVW93i6DIZ1WYtoE_O 3nF3o2XQ4.j2atJOUmIPegomfS9KglvNatBBZPZEP1JlxEmiJc5p46PC0PY1GAfSV6WmBdL_xIFy HgdA.mG20WKZy_ZceR3O97hnXGhLJzmOUBb8Fodcfp9dpciOt2Od4G.wnqlajYyT2X4WxOVTZJGC 96HuPzf08mUNMrW_LSskvfxi7XH0avogKtWgr4fk26dUE_6XiwqLa0fzO2Actar0.0vCKXGQfKHa 0dFNyIz0RiKdJhMPdjnPkjFlDSQ3t9Une_NRXMCVQfG4EhtXti.OxG1K3RfgyNvZiA.3x9fd_Iim fO2AIOF7rHoCS30SM3gE6MfMY0NfqSxCmuwKS1JkvhiQ4c3_s3vNRsLTNStTlOfVxLu2ucnlX50v yBKFqa3uRcvizWjf.aK2suZp2nITULCFtE6fEKxE44qfk1rYE8Wr4UpEKDbLXxgwTB4Zq1Bnv3ya uXeUK542iuBmJlpOrau.qFKAfCTzCSdEnT8sz5xjj8RgkIwP_KMeOxWO_1tuxeL6rKdyTHgoxngI ysyvyA3bBHCSrzCqjQCYhXFu3JSXX1fDxH7aRIf.xlh9NRLLBm7E7rMUHdH8qZU6J2ZIfdH8JBes I1TE9_aWbpc4sZLMuYEVnKM59hhzHOv_6ew0GZdYrvotanl5QKX.VbZ9Iyao030Rde3lS9BrKds. ZI._r2NtkPPSsed1pdm_ygvklwi1FU.aDUdlykZDqnu3cRtFTwuiG5govkcYWG7hy8QpcXG5.43E __6FsXvcsYx6jg.J4oe4oG5gEl06VKuQypr8HLxTgGT5.Q37xhWamQUrshND9s7d6ZAmlnMznyPx J0YOaTXCMBEgePXubLMHHz7igD1Q.lIZ0RUCioQA8TwFUXgcmMA.xLwxKfjdHYt02Oy63dzHRMFt rXC6unmr.wpFr2ZoUWJeeC8AYnqcx9KJ9oSAhzxP26vOv06J3uBwI0vvjUFBtSNeLv.fzmqbpHuh XvZ6MlKAbtk2lGzLpS5g05xN2QIVs_CXiu.CUM8DOjkpCxdewFlu5tWxrfaPlOBeD0QcZrqTfjNt ICTbfYfrbJzYJ59.8SiZAqI79PzsPZ4O8O3BKS0pLrclPU8fSJfQXO9izCo6EYtD0NvJ9er0ST_q RMkzBE0YxFi8TrkNl9kd4nvZjXPUv2mnuOf6GYci9sJBXXbYYfDT4xBt0__P237ikhJG7kcY8F.O 2y.SunfSEFcHnV.9Tmz.tewRKII6E.qeJLjXwy7z55fxFDyGCsc5aqI42i.OF4XZWPzdskHlD7G8 hfX1ICUXuED_PRHSPBqtV_XPwOkQZ3VySk7kQ8l.Hn2fOAAfQwpx_I8Wi1EbpjrBZwexA_WA1m7s 0XA-- X-Sonic-MF: X-Sonic-ID: d42dcdfd-0cc5-410e-a7f9-85202cf6d92a Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Fri, 17 Mar 2023 00:59:40 +0000 Received: by hermes--production-gq1-6cf7749bc8-bcgkq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 6f83934e1f1ae2d5d0f808b7db30d3c4; Fri, 17 Mar 2023 00:59:35 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: I just updated to main-n261544-cee09bda03c8 based (via source) and now /etc/machine-id and /var/db/machine-id disagree ; more From: Mark Millard In-Reply-To: Date: Thu, 16 Mar 2023 17:59:25 -0700 Cc: Current FreeBSD , FreeBSD-STABLE Mailing List , Baptiste Daroussin , Tijl Coosemans Content-Transfer-Encoding: quoted-printable Message-Id: <8DCCBDC3-3E00-48DD-A501-AC89448E8FDB@yahoo.com> References: <2cf7d953-2493-9673-5ea3-fba22c694015@freebsd.org> To: Colin Percival X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-3.31 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.81)[-0.813]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_FIVE(0.00)[5]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from] X-Rspamd-Queue-Id: 4Pd5Pn6mK6z3PW7 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Mar 16, 2023, at 17:27, Mark Millard wrote: > On Mar 16, 2023, at 16:48, Colin Percival = wrote: >=20 >> I think the current situation should be sorted out aside from = potential issues >> for people who upgraded to a "broken" version before updating to the = latest >> code -- CCing bapt and tijl just in case since they're more familiar = with this >> than I am. >=20 > A question may be if past dbus port related activity might > have established a /var/db/machine-id independent of the > recent FreeBSD activity. That might not be able to be > classified as a "broken version": >=20 > Before upgrade: > /etc/hostid (old style) > /var/db/machine-id (via port) Looks like var/db/machine-id is not a dbus default place: # find /var -name machine-id -print | more # dbus-uuidgen --ensure # find /var -name machine-id -print | more /var/lib/dbus/machine-id So the path in my analogy may not be the right one for overall question. > After binary or source upgrade to releng/13.2 . . . ? >=20 > For other source(!) upgrades: > Similarly but to a stable/13 (jumping over the middle)? > Similarly but to a main [so: 14] (jumping over the middle)? >=20 > To some extent the "broken" context is > somewhat analogous other possible prior > history sequences with /var/db/machine-id > and /etc/hostid ( but not /etc/machine-id ). >=20 >> Colin Percival >>=20 >> On 3/16/23 15:55, Mark Millard wrote: >>> # cat /etc/hostid /etc/machine-id /var/db/machine-id >>> a4f7fbeb-f668-11de-b280-ebb65474e619 >>> a4f7fbebf66811deb280ebb65474e619 >>> 7227cd89727a462186e3ba680d0ee142 >>> (I'll not be keeping these values for the example system.) >>> # ls -Tld /etc/hostid /etc/machine-id /var/db/machine-id >>> -rw-r--r-- 1 root wheel 37 Dec 31 16:00:18 2009 /etc/hostid >>> -rw-r--r-- 1 root wheel 33 Mar 16 15:16:18 2023 /etc/machine-id >>> -r--r--r-- 1 root wheel 33 Mar 3 23:03:25 2023 = /var/db/machine-id >>> I observed the delete-old-files deleting >>> /etc/machine-id during the upgrade. The above is wrong: it was etcupdate activity, not delete-old-files activity, that did the delete ("D") and did nothing with /var/???/machine-id . >>> It did >>> nothing with /var/db/machine-id . >>> Also, modern hostid generation was switched to >>> random to avoid an exposure. But the update kept >>> the old hostid and propogated it (not "-"s) into >>> /etc/machine-id . So /etc/machine-id now has the >>> same exposure. >>> Later I'll see if stable/13 also got such behavior >>> for its upgrade. >>> I've not been dealing with releng/13.2 but upgrades >>> from releng/13.1 and before likely have the same >>> questions for what the handling should be vs. what it >>> might actually be. Different ways of upgrading might >>> not be in agreement, for all I know. >=20 It might just be that there should be notes someplace about checking and possibly fixing the various machine-id related file relationships, especially if "dbus-uuidgen --ensure" (default path) was part of the prior context. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Mar 17 06:23:59 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PdDc83bZfz409Km for ; Fri, 17 Mar 2023 06:24:08 +0000 (UTC) (envelope-from leo@marco.de) Received: from mail.marco.de (mail.marco.de [192.54.39.130]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PdDc734RSz45h8 for ; Fri, 17 Mar 2023 06:24:07 +0000 (UTC) (envelope-from leo@marco.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=marco.de header.s=20201218 header.b=YEN5FBSt; spf=pass (mx1.freebsd.org: domain of leo@marco.de designates 192.54.39.130 as permitted sender) smtp.mailfrom=leo@marco.de; dmarc=none Received: from mailbox.marco.de (mailbox [10.0.0.4]) by mail.marco.de (Postfix) with ESMTP id 90162700037 for ; Fri, 17 Mar 2023 07:24:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marco.de; s=20201218; t=1679034240; bh=RFL3JrrXS9nb2uKoBmW6YZZoreL3xEVx5MlHqNu2LAs=; h=Date:Subject:To:References:From:In-Reply-To; b=YEN5FBSteDSEifZC+CFegWXYCUv1wbXRKTgpz8qGdmCF8i1RwQ+PfAl+n8nAPT1tq zjhkXc1tayULqvS9q89YQyS953n8+XK99oDyxh/UcI5+m/SDEcp5UNF5nZORAFnNFM xeLTSYU6pfg2nigMQkasL0zqbAivoOmG45I7uQ+KXVWu3rS+PfFFbCrbh4ThYqp8oZ A96abpfxRMYxK91+GRhYxWkLAETWghCoNz8+fwqVXUnQf6DD2Cg6HWA0O8Ex5SeY6P mgby8Bfs1pEs9lberl19pJVCkhu/Tc7ziYx5lE8DVLdIgeuHw+p5X6b//WWBgk4LFF 7am+UnSY8UDZw== Received: from [10.1.1.28] (rhea.dachau.marco.de [10.1.1.28]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: leo) by mailbox.marco.de (Postfix) with ESMTPSA for ; Fri, 17 Mar 2023 07:24:00 +0100 (CET) Message-ID: <0b95a502-eea0-46cc-5d0d-ec6e861ad51f@marco.de> Date: Fri, 17 Mar 2023 07:23:59 +0100 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: Fwd: Kernel DHCP unpredictable/fails (PXE boot), userspace DHCP works just fine Content-Language: en-US To: stable@freebsd.org References: From: Matthias Pfaller In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050308070205070808020400" X-Spamd-Result: default: False [-5.60 / 15.00]; SIGNED_SMIME(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+a:mail.marco.de]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_DKIM_ALLOW(-0.20)[marco.de:s=20201218]; DMARC_NA(0.00)[marco.de]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[marco.de:+]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[stable@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:3320, ipnet:192.54.39.0/24, country:DE]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; HAS_ATTACHMENT(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PdDc734RSz45h8 X-Spamd-Bar: ----- X-ThisMailContainsUnwantedMimeParts: N This is a cryptographically signed message in MIME format. --------------ms050308070205070808020400 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2023-03-16 21:44, Attila Nagy wrote: > Hi, > > As this is super annoying, I'm willing to pay a $500 bounty for solving this issue > (whomever is first, however I don't anticipate a big competition :) Having an invoice > would be best, but I'm willing to accept individuals as well). > I can't give remote access, but can run debug builds with serial console. stable/13 > branch. > > I have a bunch of netbooted machines, one set in a cluster is older (HP DL80 G9, > 2x8C, Intel I350 -igb- NICs), the other set is newer (HP XL225n G10, AMD EPYC2x16C, > BCM57412 -bnxt- NICs). > All of these boot from the network, which is basically: > - get IP and options with DHCP with the help of the NIC's PXE stack > - get the loader and kernel, start it > - do another round of DHCP from the kernel (bootp_subr.c) > - mount the root via NFS and let everything work as usual > > The problem is that the newer machines take an indefinite time to boot. The older > ones (with igb NIC) work reliably, they always boot fast. > The process of getting an IP address via DHCP (bootpc_call from bootp_subr.c) either > succeeds normally (in a few seconds), or takes a lot of time. > Common (measured) times to boot range from 10s of minutes to anywhere between a few > hours (1-6). > Sometimes it just gets stuck and couldn't get past bootpc_call (getting the DHCP lease). Do you have STP/RSTP enabled on the switch ports? When the link goes down when switching from firmware mode to kernel mode, the port will go back to blocking. When the dhcp requests don't make it to the dhcp server because of this and the link goes down and up again while retrying (don't know if this happens) you will get the same problem on the next try. As a simple test you could put a dumb unmanaged switch between your core network and the server. best regards, Matthias --------------ms050308070205070808020400 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DUcwggXSMIIDuqADAgECAhANWkFd0y31u4EWJee/nuAQMA0GCSqGSIb3DQEBCwUAMIGBMQsw CQYDVQQGEwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRy bzEXMBUGA1UECgwOQWN0YWxpcyBTLnAuQS4xLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIENBIEczMB4XDTIyMDkxNTExMTMzMFoXDTIzMDkxNTExMTMzMFowFzEV MBMGA1UEAwwMbGVvQG1hcmNvLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 71j1E3kubCJTUdz1VzJWgEaIsPUuiYmtoW7wz/0KRrbhBe3NFeDMjdgpDkzXip1W7Hvr9V+X pGql/HoZw680Rn3X9h3KbUULKVEsvrBm274J/5RCoTMYC9gAr9rQUgfbvKB2/U3k1cgfNP0N dhkC/5TboL/1pMJx8QUQ5ejD7/ki6trZggHXDPDmrdXU0ft6LUYydIQ4I8r3LQWRt4R45Bzo Bjmt/RANN48JeMOt99juX3T5Xuyv5nmEkLzSssqJjhJf4aXLjYPSTTB3N8LVlmcTINUUe9Rg zCth7MBQq+07weyZfk64w7VrejHiGgDqv6ix+Z1BRj/wVXWhUzgVtQIDAQABo4IBrTCCAakw DAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBS+l6mqhL+AvxBTfQky+eEuMhvPdzB+BggrBgEF BQcBAQRyMHAwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jYWNlcnQuYWN0YWxpcy5pdC9jZXJ0cy9h Y3RhbGlzLWF1dGNsaWczMDEGCCsGAQUFBzABhiVodHRwOi8vb2NzcDA5LmFjdGFsaXMuaXQv VkEvQVVUSENMLUczMBcGA1UdEQQQMA6BDGxlb0BtYXJjby5kZTBHBgNVHSAEQDA+MDwGBiuB HwEYATAyMDAGCCsGAQUFBwIBFiRodHRwczovL3d3dy5hY3RhbGlzLml0L2FyZWEtZG93bmxv YWQwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEgGA1UdHwRBMD8wPaA7oDmGN2h0 dHA6Ly9jcmwwOS5hY3RhbGlzLml0L1JlcG9zaXRvcnkvQVVUSENMLUczL2dldExhc3RDUkww HQYDVR0OBBYEFLxHW6QtOnvcSExiAJzldApYeUwAMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG 9w0BAQsFAAOCAgEAoXEsDkG5o4HzHnR5O5NKL9BfWAGpuWTx3BJlFYEFLMLzhREMc3Y88MaK /oXPtMc4JxZ3Dkbt7C63frcU+AeGqLgR8zVD5/15YdqFTTKuVlewShPnYUz/mCW9T5H/efgn bBA4taQ+hMH0sbqqijmMFqElOdwPIeCncfZ6uMfCU8rUq1Dna0J8DG1R8hTsIcy74+/MrNli mQEXOqMo0r40VRbbmTj5RaWwGz6rZ8iFAHynZWwtnxtT15coTSaCyRGnO1uRIUQ8cX+Jeq8r Fjb6rx3Lg9WzsLahUhzW4JkWGxOjGFqvF+ypVh2sSHM3Ih1Wl1pGjB9dV2PLOiPVmzTKbrsp 6nWdnCKwvwVAmj4goid3clANWYtg16Z3zdwGFBnKw7kAWrtxqHQPuRgZUcsVz8l6Y2CdBUM0 prKR+kRBKA6pnfStCvzZ1j0rp+wIz+xLLXKZfE+Ovh7075uo5j55nAg6cnaI0GY6TnT/72wN 4XCf7TJ9CGRSfUZPtzL2Z9Tq0qB14CJ8QcDxKy06j30KQrXnec4XNKsGFd2IpaPJ+arZBANV jJVDH/IS6jO48jcZSkTtlRk9CcrFYwGVaRgp1DLrJGixPQeKdW3evV5OCwDDtkmcOhtP/Jlj 1DMU9/M70HHIx1P3GsM5EwnX9a9oSiI4ODpgzO746ZYA8q0vAOUwggdtMIIFVaADAgECAhAX ED7ePYoctcoGUZPnykNrMA0GCSqGSIb3DQEBCwUAMGsxCzAJBgNVBAYTAklUMQ4wDAYDVQQH DAVNaWxhbjEjMCEGA1UECgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxJzAlBgNVBAMM HkFjdGFsaXMgQXV0aGVudGljYXRpb24gUm9vdCBDQTAeFw0yMDA3MDYwODQ1NDdaFw0zMDA5 MjIxMTIyMDJaMIGBMQswCQYDVQQGEwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQ UG9udGUgU2FuIFBpZXRybzEXMBUGA1UECgwOQWN0YWxpcyBTLnAuQS4xLDAqBgNVBAMMI0Fj dGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIENBIEczMIICIjANBgkqhkiG9w0BAQEFAAOC Ag8AMIICCgKCAgEA7eaHlqHBpLbtwkJV9z8PDyJgXxPgpkOIhkmReRwbLxpQD9xGAe72ujqG zFFh78QPgAhxKVqtGHzYeq0VJVCzhnCKRBbVX+JwIhL3ULYhUAZrViUp952qDB6qTL5sGeJS 9F69VPSR5k6pFNw7mHDTTt0voWFg2aVkG3khomzVXoieJGOiQ4dH76paCtQbLkt59joAKz2B nwGLQ4wr09nfumJt5AKx2YxHK2XgSPslVZ4z8G00gimsfA7UtjT/wiekY6Z0b7ksLrEcvODn cHQe9VSrNRA149SE3AlkWaZM/joVei/GYfj9K5jkiReinR4mqM353FEceLOeBhSTURpMdQ5w sXLi9DSTGBuNv4aw2Dozb/qBlkhGTvwk92mi0jAecE22Sn3A9UfrU2p1w/uRs+TIteQ0xO0B /J2mY2caqocsS9SsriIGlQ8b0LT0o6Ob07KGtPa5/lIvMmx572Dv2v+vDiECByxm1Hdgjp8J tE4mdyYP6GBscJyT71NZw1zXHnFkyCbxReag9qaSR9x4CVVXj1BDmNROCqd5NAfIXUXYTFeZ /jukQigkxXGWhEhfLBC4Ha6pwizz9fq1+wwPKcWaF9P/SZOuBDrG30MiyCZa66G9mEtF5ZLu h4rGfKqxy4Z5Mxecuzt+MZmrSKfKGeXOeED/iuX5Z02M1o7iMS8CAwEAAaOCAfQwggHwMA8G A1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUUtiIOsifeGbtifN7OHCUyQICNtAwQQYIKwYB BQUHAQEENTAzMDEGCCsGAQUFBzABhiVodHRwOi8vb2NzcDA1LmFjdGFsaXMuaXQvVkEvQVVU SC1ST09UMEUGA1UdIAQ+MDwwOgYEVR0gADAyMDAGCCsGAQUFBwIBFiRodHRwczovL3d3dy5h Y3RhbGlzLml0L2FyZWEtZG93bmxvYWQwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIHjBgNVHR8EgdswgdgwgZaggZOggZCGgY1sZGFwOi8vbGRhcDA1LmFjdGFsaXMuaXQvY24l M2RBY3RhbGlzJTIwQXV0aGVudGljYXRpb24lMjBSb290JTIwQ0EsbyUzZEFjdGFsaXMlMjBT LnAuQS4lMmYwMzM1ODUyMDk2NyxjJTNkSVQ/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdDti aW5hcnkwPaA7oDmGN2h0dHA6Ly9jcmwwNS5hY3RhbGlzLml0L1JlcG9zaXRvcnkvQVVUSC1S T09UL2dldExhc3RDUkwwHQYDVR0OBBYEFL6XqaqEv4C/EFN9CTL54S4yG893MA4GA1UdDwEB /wQEAwIBBjANBgkqhkiG9w0BAQsFAAOCAgEAJpvnG1kNdLMSA+nnVfeEgIXNQsM7YRxXx6bm Et9IIrFlH1qYKeNw4NV8xtop91Rle168wghmYeCTP10FqfuKMZsleNkI8/b3PBkZLIKOl9p2 Dmz2Gc0I3WvcMbAgd/IuBtx998PJX/bBb5dMZuGV2drNmxfz3ar6ytGYLxedfjKCD55Yv8CQ cN6e9sW5OUm9TJ3kjt7Wdvd1hcw5s+7bhlND38rWFJBuzump5xqm1NSOggOkFSlKnhSz6HUj gwBaid6Ypig9L1/TLrkmtEIpx+wpIj7WTA9JqcMMyLJ0rN6jjpetLSGUDk3NCOpQntSy4a8+ 0O+SepzS/Tec1cGdSN6Ni2/A7ewQNd1Rbmb2SM2qVBlfN0e6ZklWo9QYpNZyf0d/d3upsKab E9eNCg1S4eDnp8sJqdlaQQ7hI/UYCAgDtLIm7/J9+/S2zuwEWtJMPcvaYIBczdjwF9uW+8NJ /Zu/JKb98971uua7OsJexPFRBzX7/PnJ2/NXcTdwudShJc/pd9c3IRU7qw+RxRKchIczv3zE uQJMHkSSM8KM8TbOzi/0v0lU6SSyS9bpGdZZxx19Hd8Qs0cv+R6nyt7ohttizwefkYzQ6Gzw IwM9gSjH5Bf/r9Kc5/JqqpKKUGicxAGy2zKYEGB0Qo761MccIyclBW9mfuNFDbTBeDEyu80x ggPzMIID7wIBATCBljCBgTELMAkGA1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNV BAcMEFBvbnRlIFNhbiBQaWV0cm8xFzAVBgNVBAoMDkFjdGFsaXMgUy5wLkEuMSwwKgYDVQQD DCNBY3RhbGlzIENsaWVudCBBdXRoZW50aWNhdGlvbiBDQSBHMwIQDVpBXdMt9buBFiXnv57g EDANBglghkgBZQMEAgEFAKCCAi0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMjMwMzE3MDYyMzU5WjAvBgkqhkiG9w0BCQQxIgQgeaYL85LDkxtCjGFA0GTb hkj2E1XarLl0AzPFJXgYwHAwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBpwYJKwYBBAGCNxAEMYGZMIGWMIGBMQswCQYDVQQGEwJJ VDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEXMBUGA1UE CgwOQWN0YWxpcyBTLnAuQS4xLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIENBIEczAhANWkFd0y31u4EWJee/nuAQMIGpBgsqhkiG9w0BCRACCzGBmaCBljCBgTEL MAkGA1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0 cm8xFzAVBgNVBAoMDkFjdGFsaXMgUy5wLkEuMSwwKgYDVQQDDCNBY3RhbGlzIENsaWVudCBB dXRoZW50aWNhdGlvbiBDQSBHMwIQDVpBXdMt9buBFiXnv57gEDANBgkqhkiG9w0BAQEFAASC AQC7j8ol7ePpu9fD1ZCPmuJT8unrBicrAbBoKXGvKH6aRpDVQPD/rL2Y73XsaMvPMxW2ydoh Wmvns3iCWQm/Kjj6EqyyDcDeqEQ37yRPdiUaT3/qyqK3vnk4UPIo9XARX+LWmpQVX1XjJuj1 YAJXuRazd4Aq5uMxzT12qtjqvFwi1G7T3B6EF2GBA8HLzTYrrJA2T907dQc88tQ+h13HpBhU Bq1YXktmhr7pX/AYWO1qIWWCA4/jW2pW1ZqiNJ0ndK5OOi8oNEBkd1ARGJsPIOgBnZml3LO2 por/cwVxg01OfiXNjxYGRa7QxhDNjohhA8YWdfT+CI954kU8PFEitPxEAAAAAAAA --------------ms050308070205070808020400-- From nobody Fri Mar 17 13:47:21 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PdQS01pBTz3yP5Y for ; Fri, 17 Mar 2023 13:47:44 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PdQRy5m0rz3wb1 for ; Fri, 17 Mar 2023 13:47:42 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b="3P5gFC9/"; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il; dmarc=pass (policy=none) header.from=huji.ac.il DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:Date:Message-Id:Subject:Mime-Version:Content-Type:From; bh=2XxHicsbsJdnQVlp3HQVYOCK5xnI3SBsxLbtmDmbbp8=; b=3P5gFC9/KXyVnyw58iAxGoSa/Ra+3Q1dbCQdUrMYupiKiG1duL9ngoxuuxNzEziZGN9XCG7RT/pI984/JPNUduc0Ud5G2rU7vGXB03MewTfn0Exifzd9wTlxQGl2GisOGHPHvxEw6KKBOXhA1FuwJSjxE7Qh8E5hkka23qrb2afOolzwa8WG/1FHAEpfDn7HkwcwrYzIR82vscDVggokiCzcbVPmI+nrsHAuuT64GI8VUH2fJgi1RlAei+0C5NjhSpeZhcMyO3v1wxqMQ71tf6UTc7YyIkGMvqZVITOmHuJcbgAULhQ6Zfc1i7CUXCFY4IiKkqP3xuoW7aQrYvvoTg==; Received: from imac.bk.cs.huji.ac.il ([132.65.179.42] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1pdAQe-000I7d-0j for freebsd-stable@freebsd.org; Fri, 17 Mar 2023 15:47:32 +0200 From: Daniel Braniss Content-Type: multipart/alternative; boundary="Apple-Mail=_0B9EC67B-92CB-427A-9193-EE3496331ED0" List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: uname -a has changed? Message-Id: Date: Fri, 17 Mar 2023 15:47:21 +0200 To: FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Spamd-Result: default: False [-2.30 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/15, country:IL]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[danny]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PdQRy5m0rz3wb1 X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_0B9EC67B-92CB-427A-9193-EE3496331ED0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii im running latest 13.2-stable and just realized that uname -a is missing = some info, like version, date, source 13.1: hms-00# uname -a FreeBSD hms-00 13.1-STABLE FreeBSD 13.1-STABLE #10 huji-13-f44f97837: = Fri May 6 10:37:35 IDT 2022 = danny@hms-00:/home/obj/hms-00/h/rnd/git/stable/13/amd64.amd64/sys/HUJI = amd64 13.2: pe-44# uname -a FreeBSD pe-44 13.2-STABLE FreeBSD 13.2-STABLE huji-13-e0ed1dd5d2 HUJI = amd64 did I miss something? cheers, danny --Apple-Mail=_0B9EC67B-92CB-427A-9193-EE3496331ED0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii im running = latest 13.2-stable and just realized that uname -a is missing some info, = like version, date, source

13.1:
hms-00# uname -a
FreeBSD hms-00 13.1-STABLE FreeBSD 13.1-STABLE #10 = huji-13-f44f97837: Fri May  6 10:37:35 IDT 2022 =     danny@hms-00:/home/obj/hms-00/h/rnd/git/stable/13/= amd64.amd64/sys/HUJI amd64

13.2:
pe-44# uname -a
FreeBSD pe-44 13.2-STABLE FreeBSD 13.2-STABLE huji-13-e0ed1dd5d2 = HUJI amd64

did I = miss something?

cheers,
= danny

= --Apple-Mail=_0B9EC67B-92CB-427A-9193-EE3496331ED0-- From nobody Fri Mar 17 14:01:43 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PdQmV6GDhz3yPdw for ; Fri, 17 Mar 2023 14:02:02 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PdQmV35qQz40Zt for ; Fri, 17 Mar 2023 14:02:02 +0000 (UTC) (envelope-from david@catwhisker.org) Authentication-Results: mx1.freebsd.org; none Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.17.1/8.15.2) with ESMTP id 32HE1hWQ099297; Fri, 17 Mar 2023 14:01:43 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.17.1/8.17.1/Submit) id 32HE1hWF099296; Fri, 17 Mar 2023 07:01:43 -0700 (PDT) (envelope-from david) Date: Fri, 17 Mar 2023 07:01:43 -0700 From: David Wolfskill To: Daniel Braniss Cc: FreeBSD-STABLE Mailing List Subject: Re: uname -a has changed? Message-ID: Reply-To: stable@freebsd.org Mail-Followup-To: stable@freebsd.org, Daniel Braniss , FreeBSD-STABLE Mailing List References: List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oJWVSgEyx/hHObUJ" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4PdQmV35qQz40Zt X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --oJWVSgEyx/hHObUJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 17, 2023 at 03:47:21PM +0200, Daniel Braniss wrote: > im running latest 13.2-stable and just realized that uname -a is missing = some info, like version, date, source >=20 > 13.1: > hms-00# uname -a > FreeBSD hms-00 13.1-STABLE FreeBSD 13.1-STABLE #10 huji-13-f44f97837: Fri= May 6 10:37:35 IDT 2022 danny@hms-00:/home/obj/hms-00/h/rnd/git/stabl= e/13/amd64.amd64/sys/HUJI amd64 >=20 > 13.2: > pe-44# uname -a > FreeBSD pe-44 13.2-STABLE FreeBSD 13.2-STABLE huji-13-e0ed1dd5d2 HUJI amd= 64 >=20 > did I miss something? By default (IIRC), stable/* builds support "reproducible builds." The output of "uname -a" from a reproducible build lacks artifcacts that are specific to that particular build; rather, it should be identical to a build done from a different machine (using the same sources -- and of the same architecture). To restore the information (for future builds), append WITHOUT_REPRODUCIBLE_BUILD=3Dyes to /etc/src.conf. (For further details, see src.conf(5); look for "WITH_REPRODUCIBLE_BUILD".) Peace, david --=20 David H. Wolfskill david@catwhisker.org Casualties: Boston Massacre: 11; 06 Jan 2021 Capitol insurrection: >140 See https://www.catwhisker.org/~david/publickey.gpg for my public key. --oJWVSgEyx/hHObUJ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSr0Kzv+UJRY3wfOii0+6PfV4Ix1AUCZBRyx18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0QUJE MEFDRUZGOTQyNTE2MzdDMUYzQTI4QjRGQkEzREY1NzgyMzFENAAKCRC0+6PfV4Ix 1DW7AQCZ4vYG1dT3mRxHxHZSm0Kouqkmz3ukWe2b3FPT6CukjAEA8pGMRKv4577Y liZXYg2nRCE6am4NBX0I6lM3IDzUXgM= =CF8H -----END PGP SIGNATURE----- --oJWVSgEyx/hHObUJ-- From nobody Fri Mar 17 14:07:10 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PdQtg10BSz3yPr0; Fri, 17 Mar 2023 14:07:23 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PdQtf6phRz41mv; Fri, 17 Mar 2023 14:07:22 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=mpPDxTpuJTA0mBeDmvR8vhTtvKmMMVudv3rIGTGLxr8=; b=2TKXfVCUtr9Ixtm9UkZXLh9UAKW77E2aCuxsetFcgVSHgFbSzkdAJXiauYUY/nWx1anGGKWFakvT3z6qpVT+iUelquDSS1klEU2C45VxWKJBwy5YeXRvlV5s9IbUUR29zdSiyLsraC10U8xVFUVWgptyB4ItOZEI3aXiK9Ynpn6PJGQQRZ010nrFYD2pShvFrzTSWyaCo1z0wFUqozhhZxax/PSI7tiB2QDPfcjZWZMd8qQ0irV1ybqng+fCCXhxo3fbNvZCAP41qI/5OM6fEneZL0zMuWlyb/XCqHLDjqcUJo2/FhyNpJUnAvVHV7tMlyoAVGa2pbaBluMIGTHscQ==; Received: from imac.bk.cs.huji.ac.il ([132.65.179.42] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1pdAjo-000Iuz-R7; Fri, 17 Mar 2023 16:07:20 +0200 Content-Type: text/plain; charset=us-ascii List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: uname -a has changed? From: Daniel Braniss In-Reply-To: Date: Fri, 17 Mar 2023 16:07:10 +0200 Cc: FreeBSD-STABLE Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <8A58142E-8195-40EF-B5B8-3E33E0790BBD@cs.huji.ac.il> References: To: stable@freebsd.org X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Rspamd-Queue-Id: 4PdQtf6phRz41mv X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/15, country:IL] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N > On 17 Mar 2023, at 16:01, David Wolfskill = wrote: >=20 > On Fri, Mar 17, 2023 at 03:47:21PM +0200, Daniel Braniss wrote: >> im running latest 13.2-stable and just realized that uname -a is = missing some info, like version, date, source >>=20 >> 13.1: >> hms-00# uname -a >> FreeBSD hms-00 13.1-STABLE FreeBSD 13.1-STABLE #10 huji-13-f44f97837: = Fri May 6 10:37:35 IDT 2022 = danny@hms-00:/home/obj/hms-00/h/rnd/git/stable/13/amd64.amd64/sys/HUJI = amd64 >>=20 >> 13.2: >> pe-44# uname -a >> FreeBSD pe-44 13.2-STABLE FreeBSD 13.2-STABLE huji-13-e0ed1dd5d2 HUJI = amd64 >>=20 >> did I miss something? >=20 > By default (IIRC), stable/* builds support "reproducible builds." >=20 > The output of "uname -a" from a reproducible build lacks artifcacts = that > are specific to that particular build; rather, it should be identical = to > a build done from a different machine (using the same sources -- and = of > the same architecture). >=20 > To restore the information (for future builds), append >=20 > WITHOUT_REPRODUCIBLE_BUILD=3Dyes >=20 > to /etc/src.conf. >=20 > (For further details, see src.conf(5); look for > "WITH_REPRODUCIBLE_BUILD".) >=20 will try right away, thanks, danny > Peace, > david > --=20 > David H. Wolfskill david@catwhisker.org > Casualties: Boston Massacre: 11; 06 Jan 2021 Capitol insurrection: = >140 >=20 > See https://www.catwhisker.org/~david/publickey.gpg for my public key. From nobody Fri Mar 17 14:07:10 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PdQtg10BSz3yPr0; Fri, 17 Mar 2023 14:07:23 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PdQtf6phRz41mv; Fri, 17 Mar 2023 14:07:22 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=mpPDxTpuJTA0mBeDmvR8vhTtvKmMMVudv3rIGTGLxr8=; b=2TKXfVCUtr9Ixtm9UkZXLh9UAKW77E2aCuxsetFcgVSHgFbSzkdAJXiauYUY/nWx1anGGKWFakvT3z6qpVT+iUelquDSS1klEU2C45VxWKJBwy5YeXRvlV5s9IbUUR29zdSiyLsraC10U8xVFUVWgptyB4ItOZEI3aXiK9Ynpn6PJGQQRZ010nrFYD2pShvFrzTSWyaCo1z0wFUqozhhZxax/PSI7tiB2QDPfcjZWZMd8qQ0irV1ybqng+fCCXhxo3fbNvZCAP41qI/5OM6fEneZL0zMuWlyb/XCqHLDjqcUJo2/FhyNpJUnAvVHV7tMlyoAVGa2pbaBluMIGTHscQ==; Received: from imac.bk.cs.huji.ac.il ([132.65.179.42] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1pdAjo-000Iuz-R7; Fri, 17 Mar 2023 16:07:20 +0200 Content-Type: text/plain; charset=us-ascii List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: uname -a has changed? From: Daniel Braniss In-Reply-To: Date: Fri, 17 Mar 2023 16:07:10 +0200 Cc: FreeBSD-STABLE Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <8A58142E-8195-40EF-B5B8-3E33E0790BBD@cs.huji.ac.il> References: To: stable@freebsd.org X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Rspamd-Queue-Id: 4PdQtf6phRz41mv X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/15, country:IL] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N > On 17 Mar 2023, at 16:01, David Wolfskill = wrote: >=20 > On Fri, Mar 17, 2023 at 03:47:21PM +0200, Daniel Braniss wrote: >> im running latest 13.2-stable and just realized that uname -a is = missing some info, like version, date, source >>=20 >> 13.1: >> hms-00# uname -a >> FreeBSD hms-00 13.1-STABLE FreeBSD 13.1-STABLE #10 huji-13-f44f97837: = Fri May 6 10:37:35 IDT 2022 = danny@hms-00:/home/obj/hms-00/h/rnd/git/stable/13/amd64.amd64/sys/HUJI = amd64 >>=20 >> 13.2: >> pe-44# uname -a >> FreeBSD pe-44 13.2-STABLE FreeBSD 13.2-STABLE huji-13-e0ed1dd5d2 HUJI = amd64 >>=20 >> did I miss something? >=20 > By default (IIRC), stable/* builds support "reproducible builds." >=20 > The output of "uname -a" from a reproducible build lacks artifcacts = that > are specific to that particular build; rather, it should be identical = to > a build done from a different machine (using the same sources -- and = of > the same architecture). >=20 > To restore the information (for future builds), append >=20 > WITHOUT_REPRODUCIBLE_BUILD=3Dyes >=20 > to /etc/src.conf. >=20 > (For further details, see src.conf(5); look for > "WITH_REPRODUCIBLE_BUILD".) >=20 will try right away, thanks, danny > Peace, > david > --=20 > David H. Wolfskill david@catwhisker.org > Casualties: Boston Massacre: 11; 06 Jan 2021 Capitol insurrection: = >140 >=20 > See https://www.catwhisker.org/~david/publickey.gpg for my public key. From nobody Fri Mar 17 17:15:47 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PdW476L3Xz3ybjM; Fri, 17 Mar 2023 17:15:51 +0000 (UTC) (envelope-from tijl@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PdW475ktGz4LY2; Fri, 17 Mar 2023 17:15:51 +0000 (UTC) (envelope-from tijl@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1679073351; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IKBcKNvQb8Dd2AueR4yCp6kHiqtCJ+ECJEVh32EbF84=; b=Mb/iXXHrTbqfnAgt+sK4YpvV3JTqjU/nvdA3nVj+XpfHUEiHqdYe8O1W71MzwxDkuOPFhe EgExR2+ulMOXFgGSavlfeipWWgx/meYdaA8V5S3x6V7sXaZkYUYo+btJskxG9PTLnVRuPY PdstgzjNbT7l9durxFemwMdzpBvNzoZqqRlyPdqqjYa3DDtF31F5luVE/URgDurx4w5CLE SYtYUGeUzu5zjBNGaYgi6jdl0Zv8vm7aZ9gvsbgMcz2YRCODkx/MDqGhyCLRNR4Uyo+Joy JN4qXRx3Ew+JlC2WJe456klvyNdkAwQ+ZMyNCN9DbGGy+PfRCTyFDIAvonk49g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1679073351; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IKBcKNvQb8Dd2AueR4yCp6kHiqtCJ+ECJEVh32EbF84=; b=t0PD6ah9xvS+TAngxo7Al0FZ4dpkQVKHR/76Ysjnr5pCgCkBRNdYj89KzgQzCqTJwPc+3f q/1aRpiU6v/qWVR4gD2ymjaAFPibzgesFKWdCL2Al4x2BpXkwKHy0A5ACw3vCAiIyq/2RU jIuw4XBpHKGer3HWn2tX3uxFgI2saZ/QYPbw9k224/GICZ+5GnDsJfbsUbeZLCqaRqmkjF MZ1pqFM/BfWJ8BEmO51rlz6a+eDdHMVnPoN0IdSYcv43wzb6AtCBEgkA6F+lOAWfSs5ayz 6RitqA+17TRDJb88S35Pqm9BR9wx/9Q4NxkK5fc6lW2gndFADqgj8/b2IciT2A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1679073351; a=rsa-sha256; cv=none; b=Bg+ckZDyhKemup2H4VC8qlk9SH92SnNStnlqAgbp1yYl9d/JDNyg4v+a3wVDrlOLQPNVBF 4h3PCq4NQH66hU7VOhpLGQlsUdFgnoq2trkhrtCvoCrAHuz7+AwUCR8WUZnoM8h7u4Nu6X ATuj1yBSOGg7rVbjHsz+x7a2YP4rgjlLusKklco5M6miMKdmMuH21tUkofF3T7w/PLrp++ yiq4lbcgi6EczN6SxcmUjsGBnDBhwB0hgbnvEpmplwkzj5yIdM+5zpP29r1JghnSS9TENk sDsfOvRYIGezFWCpF5rO5CI9QtXGB47l8OOlPkdiuAr1QLB7AUc+qEIWnLvBpg== Received: from hal.tijl.coosemans.org (unknown [IPv6:2a02:a03f:894b:4700:750a:4519:2272:b3dd]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: tijl) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PdW466fqzz15jp; Fri, 17 Mar 2023 17:15:50 +0000 (UTC) (envelope-from tijl@FreeBSD.org) Date: Fri, 17 Mar 2023 18:15:47 +0100 From: =?UTF-8?B?VMSzbA==?= Coosemans To: Colin Percival Cc: Mark Millard , Current FreeBSD , FreeBSD-STABLE Mailing List , Baptiste Daroussin Subject: Re: I just updated to main-n261544-cee09bda03c8 based (via source) and now /etc/machine-id and /var/db/machine-id disagree ; more Message-ID: <20230317181547.4d75e897@hal.tijl.coosemans.org> In-Reply-To: <2cf7d953-2493-9673-5ea3-fba22c694015@freebsd.org> References: <2cf7d953-2493-9673-5ea3-fba22c694015@freebsd.org> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N On Thu, 16 Mar 2023 16:48:40 -0700 Colin Percival wrote: > I think the current situation should be sorted out aside from potential issues > for people who upgraded to a "broken" version before updating to the latest > code -- CCing bapt and tijl just in case since they're more familiar with this > than I am. > > Colin Percival > > On 3/16/23 15:55, Mark Millard wrote: >> # cat /etc/hostid /etc/machine-id /var/db/machine-id >> a4f7fbeb-f668-11de-b280-ebb65474e619 >> a4f7fbebf66811deb280ebb65474e619 >> 7227cd89727a462186e3ba680d0ee142 >> >> (I'll not be keeping these values for the example system.) >> >> # ls -Tld /etc/hostid /etc/machine-id /var/db/machine-id >> -rw-r--r-- 1 root wheel 37 Dec 31 16:00:18 2009 /etc/hostid >> -rw-r--r-- 1 root wheel 33 Mar 16 15:16:18 2023 /etc/machine-id >> -r--r--r-- 1 root wheel 33 Mar 3 23:03:25 2023 /var/db/machine-id >> >> I observed the delete-old-files deleting >> /etc/machine-id during the upgrade. It did >> nothing with /var/db/machine-id . delete-old deletes /etc/rc.d/machine-id, etcupdate deletes /etc/machine-id. I suppose delete-old could also delete /var/db/machine-id but the file is harmless so I don't think this is important for 13.2. >> Also, modern hostid generation was switched to >> random to avoid an exposure. But the update kept >> the old hostid and propogated it (not "-"s) into >> /etc/machine-id . So /etc/machine-id now has the >> same exposure. These files are meant to remain constant across reboots, so the update process cannot change an existing /etc/hostid. For example, it is used by NFS servers to restore state when a client crashes and reboots. If nothing relies on the old ID you can generate a new one by running "uuidgen -r > /etc/hostid" and rebooting the machine. >> Later I'll see if stable/13 also got such behavior >> for its upgrade. >> >> I've not been dealing with releng/13.2 but upgrades >> from releng/13.1 and before likely have the same >> questions for what the handling should be vs. what it >> might actually be. Different ways of upgrading might >> not be in agreement, for all I know. From nobody Fri Mar 17 18:56:46 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PdYJw4dZgz3yj2R for ; Fri, 17 Mar 2023 18:57:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PdYJw1Ld0z3K1F for ; Fri, 17 Mar 2023 18:57:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1679079421; bh=r8CxFguHZ9CHYS0KdEN20aG+U2LGbhe1RZpV575/ii4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=XNadx6MO2HEluYjNLD4LpYdJXo5iO0946bnuVzoYA0EB4m4OfnqsgLbZ48HZv1RJnpqyUqp4y9qAQKp0fZrcF8iYoS917URAmoFUm9OhMzdBOgaYOT7Gi0AVHZqIRQLzJ5suaiA3lywTo6SXI4Gub/XEZI3hx0hW4WIeTQ8r4M8mP21uLcF9n2PFhqDGBltWIvRz5L8SsRmrQhQAbdPjH2Mqyx+yiQgc+W49iH+jGe7gAto7mfE+4rL4KYbiuPen17SMHzEsa8/a0sy3apJyZd4v1ykpk85XfAc3DoayOsP8+hlVgg355ZsHE+nWnc2aTM4uqMbSqS3nQbyMNvxu1w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1679079421; bh=/EuwzEka+DgB/MGyzE6lH0FWWCLhEnVmQgUqEVAToFC=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=QG/k05+RnMbmsCuQnnJkjRPNVWY5zy+4FpZWKalwzgUkiWeEq5Gb1ix+02g8HP+p9i2eR6SGQoseZm1vjLT6KoXiAt/uIshRTs3LyE20J3b+OIY4hw6dIy+BPndMT6rIfrH6RmHjhUte3QQPTLsIDb70z0Z90Pk2HSL5EchRTu6Iv/Yws9oBo26QrWwubR2mMvcdKLgGhrePED/kJFg8CIp0IlsrwDQulbH427EJDQBG90nJdR1lKjwjiitsEIrWHXx1MTa2Rtqqed8lH5ByBcn1lO71SBwx8BsPJKhuKL8ktE6Zb6SezGKS7gFoAuAdIFp6Hx7hYe25PlMnz7Wnew== X-YMail-OSG: LT1dWt8VM1lMPXeTWQuKFknnWoUXGM8zPtEtj0FdFs1Lrx_IU8O_Uamt7JlzsdF zxHhkdIoKtpsXMMMzjeWu00va5nYNOwe1NpffuKfYgqV2kk0VT7pZ8632d2voYNNi.AfpmMUNiTN gnDLNnM0c.2h6O.CV2.7S4rHLxdXwFVcdh6DP2zWzMakB794tdNe8Pgg2sBQkA8y2cnW3Un7jjdm bYj.Ka9TAxad2z4ONBYM2AieBnjgh5T4TplzGXHzbg0IWHe6iSxlLb8FFEPkGoF1I2OT6Ur_8UAu ujJbJAFYzHWBpiIpsvwVJFg0I4xD48NkLnT3xtaLgIjp1nY17A78xBhqJM0xltgwozPgJjbDQqZm v6HUyw2y0c4bPoZsJtAsQuG_7KqZ1xL92f8bxqRbmYhLtCDClRkEOte_.pLx3I2Umx4NOA3BcL2k fl7KUCltrq1iwuPWEECaPFaaClfiE2_zDUsZVxHT8L2s7MXXDHgBB_7KcIO9o3NTfiP8JDK_qFQx 1jzF8YiD0MCeflN5QX4o7lQqLGTt0.MRm4xenLXaahvjBkysBEA4sAUfN2VqvgyYIts67xcIK3mp caYhE9qXsHqtRKV6ePOAqrAOfGjURngK_DL_3k4CFwTTgPZOSDIl0o2K4sDs0br5kzBgSuvI3art l2NKfS8KSe0LQ3SQ.7hjg1_GXayFiBZwF6ZjN7ctWyndW3Lf90nA9jIfDgK0WfbQEzIq2ucBt2rn Frg6A6CxpP6r8ghrxIdiilmUxy_F9iMGINLwrI6xgDRJwL_LPON2n58mZYLseTUQzPvD.tCzsu.6 G6mVfbMReltYWN21IWWuS0VRf7i.UJcX_40NVmd6oFwKa1f9Rpv5Gqsf800ohe9Ea0HbP1o8EUe7 uqnMP0OLxEVk6aKIlka5fVCkMBfx.QlrYnYvwXUXZ1qsK.OHe0eCy5FnbYEZeEWkB_58P4E2TBiz .91KFanc52pQgI7zFoy.gSFz7R3xq.oFPouOTE_Y7fp42PRWZj1xqtHmfX17POjQJqbY4RyALX90 sU3msvyhJZhQBZ5SaAmngR.xvcNZnyMN5ZT0jwJdhN2tzMgh0JK7EeJPvBDIJohRlFxucdMan6fg oJbdWlpofCi_YgxVeZGyc_gRYHXOviVXipJoHxJAtLBnPGA4eLV9kMN5PfhOykiy2BED3wLZAo2s grn0_xoTbujozsk5OORuTzuneVIY_3pCoKOQ.S13nIBTCbzUy22QqGz__LKS4hR3z5SBEzVZowhw 63AMsnfy3LsSzeW7KzM_GiMtI.EslqOb0qF7lS7WbftM2tqcMaC4Z_Ec1O9WJTnv4r0r.kk2zq3I U7hRH6jo0OqHDKo2nwSgPlUZ09Y12nkD.jvBK_HrcNeD_H0t8KRcrAf1leZI2C9oaYOFmtJ1oqbI BC7n.y0i1gC0HFiXxXcWNUYAqWIn7gWC9MjwCK3Eg.ZLTLsm8_VxEzi1ifPuMHflKgNwlpZxGPrm qGmEQ_pmbaTEAMP4jNh.KK7do3KARtFWb.8kU8gN6UzdD1k_8z.vQHmdUl91LPEP3O8bRLpk6mqQ 7JkSfQak6jmAHL.ExDsb0X0k7zlN5QvYZOetb4s2ASeEB6TtttvQV7MIuostcA34JjRQhiFIwjid kWFP4Cgl.EzpZxzLo03lCvc8YCzyHv9WDw6d1AuMcBDXMTQGaaEZbwNW_o5iOJ_g_IFhLt1j70w_ Tna6qiMovvPhUOwX_yjpEzQxHdLFa8x9pE6vpRDoerFybThRFAD1Z_Yhmph1AGtZc3vbfahMPf5t cI3rKgdPLcfGN542xmI.Ikm7ZJhzEzCr9VealoW77nNlgHxvs3PVwyKEN2oCdVex0BuYilTp3.vU 74ZqANYt7Ns2hJlJCD_6ca.3BYq5_B0CKxet9AdV_GKqDXhHbXdPYFdLTmReogi5TAcR6iWbE2FL 3ghXm3liZVQrfRrlY.oi9l89N6aqOYoB5TdIizp9HoFlAMaK98IjA_FbER7X6Mj6w0Xhf2ak9SM0 nKLbJ_cuOlvkgGFFNqSv1C0ryfg3rb6wyjWK2bhI64N6veSj_j.YzamPaJB4iQy5HvYj_Zp2BTVw VBt2q3.HpME56VJ7RptE5Xv88OgvDliX7X2O98x2KjTCZzob8MuSNscqHRCKZKnqbjLadnJQZFLr udTILsNaqTh8UyTIsw9Y_P4T7EFgmGtvYui045sYWUyJvyLptigMDNr_lYupeDEnmRXMM7LWeqA6 TF96aOId0ue8xdkyEDbBqj_MjbAihlX.Apf.OYlaWiAq81QFXafCS.Idp08AyXt9Bb1y3igwuo0V TakpY X-Sonic-MF: X-Sonic-ID: 5889bb56-193c-4e98-a2d7-cdd5250b9806 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Fri, 17 Mar 2023 18:57:01 +0000 Received: by hermes--production-gq1-6cf7749bc8-q7lrl (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1a416eca30d07b07c3a19c24d1763da5; Fri, 17 Mar 2023 18:56:57 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: I just updated to main-n261544-cee09bda03c8 based (via source) and now /etc/machine-id and /var/db/machine-id disagree ; more From: Mark Millard In-Reply-To: <20230317181547.4d75e897@hal.tijl.coosemans.org> Date: Fri, 17 Mar 2023 11:56:46 -0700 Cc: Colin Percival , Current FreeBSD , FreeBSD-STABLE Mailing List , Baptiste Daroussin Content-Transfer-Encoding: quoted-printable Message-Id: References: <2cf7d953-2493-9673-5ea3-fba22c694015@freebsd.org> <20230317181547.4d75e897@hal.tijl.coosemans.org> To: =?utf-8?Q?T=C4=B3l_Coosemans?= X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PdYJw1Ld0z3K1F X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Mar 17, 2023, at 10:15, T=C4=B3l Coosemans wrote: > On Thu, 16 Mar 2023 16:48:40 -0700 Colin Percival = wrote: >> I think the current situation should be sorted out aside from = potential issues >> for people who upgraded to a "broken" version before updating to the = latest >> code -- CCing bapt and tijl just in case since they're more familiar = with this >> than I am. >>=20 >> Colin Percival >>=20 >> On 3/16/23 15:55, Mark Millard wrote: >>> # cat /etc/hostid /etc/machine-id /var/db/machine-id >>> a4f7fbeb-f668-11de-b280-ebb65474e619 >>> a4f7fbebf66811deb280ebb65474e619 >>> 7227cd89727a462186e3ba680d0ee142 >>>=20 >>> (I'll not be keeping these values for the example system.) >>>=20 >>> # ls -Tld /etc/hostid /etc/machine-id /var/db/machine-id >>> -rw-r--r-- 1 root wheel 37 Dec 31 16:00:18 2009 /etc/hostid >>> -rw-r--r-- 1 root wheel 33 Mar 16 15:16:18 2023 /etc/machine-id >>> -r--r--r-- 1 root wheel 33 Mar 3 23:03:25 2023 = /var/db/machine-id >>>=20 >>> I observed the delete-old-files deleting >>> /etc/machine-id during the upgrade. It did >>> nothing with /var/db/machine-id . >=20 > delete-old deletes /etc/rc.d/machine-id, etcupdate deletes > /etc/machine-id. I suppose delete-old could also delete > /var/db/machine-id but the file is harmless so I don't think this is > important for 13.2. Good to know. I'll remove the /var/db/machine-id that hte machines happen to have around. >>> Also, modern hostid generation was switched to >>> random to avoid an exposure. But the update kept >>> the old hostid and propogated it (not "-"s) into >>> /etc/machine-id . So /etc/machine-id now has the >>> same exposure. >=20 > These files are meant to remain constant across reboots, so the update > process cannot change an existing /etc/hostid. For example, it is = used > by NFS servers to restore state when a client crashes and reboots. Good to know. Absent man page(s) describing the princples for handling the hostid and machine-id file(s) (and why), what to report vs. not was unclear. So, for example, historical hostid value takes default precedence over potential adjustment to be random-based instead. That was not obvious to me prior to the explanation. I'm not aware of any place to find that in the man pages or other documentation. > If nothing relies on the old ID you can generate a new one by running > "uuidgen -r > /etc/hostid" and rebooting the machine. Yea, in my context, it appears that I can freely update the files. >>> Later I'll see if stable/13 also got such behavior >>> for its upgrade. >>>=20 >>> I've not been dealing with releng/13.2 but upgrades >>> from releng/13.1 and before likely have the same >>> questions for what the handling should be vs. what it >>> might actually be. Different ways of upgrading might >>> not be in agreement, for all I know. Thanks for the notes. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Mar 17 20:05:55 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PdZrd0L6Nz3ymsW for ; Fri, 17 Mar 2023 20:06:09 +0000 (UTC) (envelope-from nagy.attila@gmail.com) Received: from mail-oo1-xc36.google.com (mail-oo1-xc36.google.com [IPv6:2607:f8b0:4864:20::c36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PdZrc37yGz3RGf for ; Fri, 17 Mar 2023 20:06:08 +0000 (UTC) (envelope-from nagy.attila@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=L1jp1T0j; spf=pass (mx1.freebsd.org: domain of nagy.attila@gmail.com designates 2607:f8b0:4864:20::c36 as permitted sender) smtp.mailfrom=nagy.attila@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-oo1-xc36.google.com with SMTP id o26-20020a4ad49a000000b0053964a84b0fso316645oos.7 for ; Fri, 17 Mar 2023 13:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679083567; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RCBjse+dKvK/4FnPwUplDzTesXJ+qbqM8yGRFP+ZclE=; b=L1jp1T0jt3INj/7vUkr5RGDjQUo3JjM/A5ioK11UkU2uQOxJ5LhDdZpzZIu41B1ewD KicMBa6LWN8F5ymgJNAtzj4dbyyek3RhggOGtuC/wcpqCIH4dG3znFWUkFU5KtUpVqkM jturTVHya3l8QfpxKv4X0xubFDqyyyCrKslooSowjQbRsRDIJdbp5JqZCedS+cN97dor T8uclAO6amn5Va75Ry7I+259P7v3sW16MB+z1XwAgCTHgeBsUvdYAcuOuMEryNXOi7eO adWyqvBKi5kfhIfA4lkyZa6WpMsNlHFFpOHhpggHpGt1rn1S5hDWSzvm3nijDmn1GzIu i4lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679083567; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=RCBjse+dKvK/4FnPwUplDzTesXJ+qbqM8yGRFP+ZclE=; b=y+xsHimV8pkWOf6Lgb//pq4jOnpH9zslP3hePaeMrK4gjKcQbKGg25UJhOVaPqeVHy Vk0pON9ySNUO59ucBhkWEg0PgwgSrS3EK215ae6A1sPyvnga6iFo7Qq8YHlbBHPSFQbu mjtgXvNvi4RaASegRgav8gAXXA1PZRkDKHI6BHUWO6drEjVopc/RDUh2dyC22/j+nqfp YzoQBg/g3Xi+FwR5SaIRvtxPgjjqwaHO6bzB3+TWD7hek2cIUw55v2EdkT6tHIXLtrme 9nmrXFqzIT7JIa1BMI1b+8hxQoBfZhqzfCkb7UUWiUMNn/wny3l5Y5/blWGoKJw59OZc k4PQ== X-Gm-Message-State: AO0yUKWllh5zJN0Mt+waJx8T8Tds9wPhVhSzNBKIRogY7YktFyVQpLaL gGHuOYHVP4y0LKB7sXDG/dCvG5zbPERG3HHneD63SYYhhrc= X-Google-Smtp-Source: AK7set+PmOlqgStU/jgpfMUh+kVXbNx+97qPrNk1ijjoJd2oGH9URVyKXfJVnGT16CnzvSegyXqA+aQQp9e+Wbkglos= X-Received: by 2002:a4a:bd08:0:b0:52e:17e2:7d4c with SMTP id n8-20020a4abd08000000b0052e17e27d4cmr446390oop.1.1679083567201; Fri, 17 Mar 2023 13:06:07 -0700 (PDT) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Attila Nagy Date: Fri, 17 Mar 2023 21:05:55 +0100 Message-ID: Subject: Re: Kernel DHCP unpredictable/fails (PXE boot), userspace DHCP works just fine To: Rick Macklem Cc: freebsd-stable@freebsd.org Content-Type: multipart/alternative; boundary="00000000000092443d05f71e1bce" X-Spamd-Result: default: False [-3.24 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.24)[-0.240]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_HAS_DN(0.00)[]; TAGGED_RCPT(0.00)[]; TO_DN_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::c36:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROMTLD(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TAGGED_FROM(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4PdZrc37yGz3RGf X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N --00000000000092443d05f71e1bce Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Rick Macklem ezt =C3=ADrta (id=C5=91pont: 2023. m= =C3=A1rc. 16., Cs, 23:01): > On Thu, Mar 16, 2023 at 1:44=E2=80=AFPM Attila Nagy wrote: > > > > The problem is that the newer machines take an indefinite time to boot. > The older ones (with igb NIC) work reliably, they always boot fast. > Haven't you at least partially answered the question yourself here? > In other words, it sounds like there is an issue with the NIC driver > for the newer chip. (If you can replace the NIC with one with > a different chip, I'd try that.) > Yes, this driver is quite bad and has a lot of flaws, but after the OS boots, it works fine otherwise. I can't change the NIC. :( > > A possible workaround would be to switch to using "options NFS_ROOT" > instead of > "BOOTP_NFSROOT". This way of doing diskless NFS depends on pexboot > loading the FreeBSD boot loader and then it sets enough environment > variables so that a kernel built with "options NFS_ROOT" and no > "options BOOTP_NFSROOT" > will boot. > > Oh, I long forgot this option, thanks for bringing it up! Yes, it skips that code and the DHCP query along with it and works wonderfully, the machine boots fast. For me this confirms that the problem lies in the bootp_subr.c DHCP code (at least something works bad with this NIC, I guess it might be a timing issue). I had to dig out of my memory why we don't use that, but the first boot helped me to get those memories back: bootp_subr.c gets option 134 from the DHCP response and loads it into kern.bootp_cookie, which is then used by /etc/rc.initdiskless to set up the class, which we depend on. Well, it's possible to work that around ("encoding" the class in the NFS root path), but that's not the same (we have different initdiskless "classes" with the same NFS root paths). I'm not sure if pxeboot could get that information from the PXE stack, but I guess even if it has access to the DHCP reply, nobody is interested in modifying it to actually pass option 134 through to kern.bootp_cookie if it wasn't implemented in the last many years. :) --00000000000092443d05f71e1bce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Rick Macklem <rick.mack= lem@gmail.com> ezt =C3=ADrta (id=C5=91pont: 2023. m=C3=A1rc. 16., Cs= , 23:01):
On Thu= , Mar 16, 2023 at 1:44=E2=80=AFPM Attila Nagy <nagy.attila@gmail.com> wrote:
>
> The problem is that the newer machines take an indefinite time to boot= . The older ones (with igb NIC) work reliably, they always boot fast.
Haven't you at least partially answered the question yourself here?
In other words, it sounds like there is an issue with the NIC driver
for the newer chip. (If you can replace the NIC with one with
a different chip, I'd try that.)
Yes, this driver = is quite bad and has a lot of flaws, but after the OS boots, it works fine = otherwise.
I can't change the NIC. :(
=C2= =A0

A possible workaround would be to switch to using "options NFS_ROOT&qu= ot; instead of
"BOOTP_NFSROOT".=C2=A0 This way of doing diskless NFS depends on = pexboot
loading the FreeBSD boot loader and then it sets enough environment
variables so that a kernel built with "options NFS_ROOT" and no "options BOOTP_NFSROOT"
will boot.

Oh, I long forgot this option, thanks for bringing it= up!
Yes, it skips that code and the DHCP query along with it and= works wonderfully, the machine boots fast.
For me this confi= rms that the problem lies in the bootp_subr.c DHCP code (at least something= works bad with this NIC, I guess it might be a timing issue).
I had to dig out of my memory why we don't use that, but t= he first boot helped me to get those memories back:
bootp_subr.c = gets option 134 from the DHCP response and loads it into kern.bootp_cookie,= which is then used by /etc/rc.initdiskless to set up the class, which we d= epend on.
Well, it's possible to work that around ("enco= ding" the class in the NFS root path), but that's not the same (we= have different initdiskless "classes" with the same NFS root pat= hs).

I'm not sure if pxeboot could get that in= formation from the PXE stack, but I guess even if it has access to the DHCP= reply, nobody is interested in modifying it to actually pass option 134 th= rough to kern.bootp_cookie if it wasn't implemented in the last many ye= ars. :)

--00000000000092443d05f71e1bce-- From nobody Fri Mar 17 20:09:08 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PdZwJ5hwCz3ymw0 for ; Fri, 17 Mar 2023 20:09:20 +0000 (UTC) (envelope-from nagy.attila@gmail.com) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PdZwJ2vN2z3hnX for ; Fri, 17 Mar 2023 20:09:20 +0000 (UTC) (envelope-from nagy.attila@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oi1-x234.google.com with SMTP id y184so4644721oiy.8 for ; Fri, 17 Mar 2023 13:09:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679083759; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=jSfpQOGops8Uykbp7GBFLhlIce4IvWMl+iIrS6l/X4k=; b=eHAQFK9Ej+JhVJw9L4nOweVb/5Jcl5KPtri796Qt94hI95ZM65zNGT9b3zxS4E1fbg t39h58T8XF9lc826BA5QKuWjhKfYQhpcknG813NLhbfw7Tdhtr4y8yc59WvWV6MtGrD4 vEjs6PBwKAA2xdfOWQ6lu2/YLJOZ9nb7OJBWf5jAmJbSE5T+nZd1SXxh+2r9WeMCu+9R t21SxnUS26wl+yl8XgqJ7EwCygSBrHSs5NXIbQfyeY5qs2mRK6zKGdidDCwWt6YI4vnH viV5f/K8iNlpv3rdbvdMPXOofcH7N6RbiGur8M0HI1/ZzJ0QuXAwu/yfrqH0sWG9y1X0 R0kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679083759; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=jSfpQOGops8Uykbp7GBFLhlIce4IvWMl+iIrS6l/X4k=; b=B1e08l0Ak/XpvGSYAmZVb2peJ6PCh5HwVpb516MOE8FSfMUCSo8hXGG98V7nD008OG +M/j31eSOl+qFx7BNbLh+M+KCRsEPl2wJ6xcMhv0412kKmVSPNRUImYImN2lJSx3BDiA k13CJObcgyVVB9WXlcKxqKllLajQhzcMZzuox67iifv13a1jVHoFYI2H6AQDCd7xu3Wo T5KFCmvS1ZhOdnPjQph6/apbyN1/vFlslT0P9XPvrVcebFLRX0HuF2ezeIsMi3riJztT 8PCQFn/ucUojQUCO1kg3A6USxKsXDo1qBlnk85ZER8b4CwffkRnjn7Rf4ZhomeO9Da3A pNiw== X-Gm-Message-State: AO0yUKUYuCfP9y5QM5l7NIClgozuvS9UrFWqASu2T9+pK/SmGqCxrCA5 VoXAPNbdHiBG008Rug9rpAbIEEyIbh+yp1Y4pHM= X-Google-Smtp-Source: AK7set+BmO0wuRAhh5RRf6ndBhjB63d285PgloHdbvwbJHRU66usPI9LClfrtyChb4LuAxSypDeH8VjHikGIu231Vks= X-Received: by 2002:a05:6808:88:b0:384:a13:952a with SMTP id s8-20020a056808008800b003840a13952amr3565221oic.11.1679083759188; Fri, 17 Mar 2023 13:09:19 -0700 (PDT) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Attila Nagy Date: Fri, 17 Mar 2023 21:09:08 +0100 Message-ID: Subject: Re: Kernel DHCP unpredictable/fails (PXE boot), userspace DHCP works just fine To: Juraj Lutter Cc: Rick Macklem , freebsd-stable@freebsd.org Content-Type: multipart/alternative; boundary="00000000000003c0d905f71e2795" X-Rspamd-Queue-Id: 4PdZwJ2vN2z3hnX X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_RCPT(0.00)[]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --00000000000003c0d905f71e2795 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Juraj Lutter ezt =C3=ADrta (id=C5=91pont: 2023. m=C3=A1rc= . 16., Cs, 23:11): > > > On 16 Mar 2023, at 23:01, Rick Macklem wrote: > Haven't you at least partially answered the question yourself here? > In other words, it sounds like there is an issue with the NIC driver > for the newer chip. (If you can replace the NIC with one with > a different chip, I'd try that.) > > > There are more PRs open for bnxt(4) driver, with no obvious solutions. > My personal experience with bnxt(4) is also very ambigous. > > In my last 26 years with FreeBSD, having a Broadcom NIC in my machine has never been a good thing. :( But I still think the problem here lies in bootp_subr. --00000000000003c0d905f71e2795 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
--00000000000003c0d905f71e2795-- From nobody Fri Mar 17 20:16:17 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Pdb4Y2xWMz3ynZm for ; Fri, 17 Mar 2023 20:16:29 +0000 (UTC) (envelope-from nagy.attila@gmail.com) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Pdb4X6qQ1z3jyQ for ; Fri, 17 Mar 2023 20:16:28 +0000 (UTC) (envelope-from nagy.attila@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oi1-x22c.google.com with SMTP id s41so4643185oiw.13 for ; Fri, 17 Mar 2023 13:16:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679084188; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=WHmwdMVtZCKM+HEKSSj9HvLG3Dd0wzmQFV9QGsRjEO4=; b=Qh9pgGSKstCwPI23n1ZBNqvPz1zSJq3DRYNH9ErX8NfH38H2wqEfvok8rx4PiflAiI 6lHeliQypj+IO2bhU8Cq4FIhUo5rjT/fHTM51slvfw8aaTey70+gV6GdXT9OTfpLnK8z FVgUTWqndzMpRQ6u6OxwOd4bukmwP/UOkq5ZDvqCPI4jFtOn+Yn1ZrfI3a7Gemlk1Cri cTSFUNkc2o9J4lRvcL3FpziK4B0/zhF9BcRgKtsmo3or2MpK0AGyNRxjZSw0RSDk/QpZ yuH8/xpZ1bXG3IzUTjeXyo/6DJmdE9kr2oeAkZsKYIWh44sxQ7Wb/8D28SpTcNM0Fvax pWaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679084188; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WHmwdMVtZCKM+HEKSSj9HvLG3Dd0wzmQFV9QGsRjEO4=; b=69uaWPGQ2EOnr0iMbeKb4dJD1rDZSd7Gek6K+eYyY1dLIOlqQ3+btpdMT5ii7yKHeO AY3f2621QJt3RfP8c+Azk2cFiOvVN7SPKskrztADBrS4cYeQnNvt5NFG3HCOunZgBuci 9K6NdeKw7CCjogOPEc3X9wzwZ0YKmSWXcZGX3iJJzStlY2dlO63CNkkq/fomLgEGSUig fAnsM0VdK/IaUEwB5JTLkHsa5Vqit/5kuYoULcv6SUi+ooYwZqjTGaNTaROEMcy7NdQT Y/5h9QSvr3jOX/Lyx0uJyLYjSHarz1xApxAMPa68ZWy0rOXlHj1RsdihTyysv92Ap1Cg dQtw== X-Gm-Message-State: AO0yUKW7TfeOIYdRv9FKbd4UAMjp2L4jNwUbXKzM+2nBz0VjWI19IBt4 m0qEROxkmdm90/9cRFr3VSnDYhqh1pbj0t0JEKweIh91 X-Google-Smtp-Source: AK7set8bDJQpaiYokya2KdJNBrh5Voi08H4n9L4SGgFjrVat3gmiEHj4XIKcdh/w2U9E8+pmJsvDJ/UawsY/tpEyOGM= X-Received: by 2002:aca:1717:0:b0:386:9718:cfeb with SMTP id j23-20020aca1717000000b003869718cfebmr3765983oii.11.1679084188084; Fri, 17 Mar 2023 13:16:28 -0700 (PDT) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: <0b95a502-eea0-46cc-5d0d-ec6e861ad51f@marco.de> In-Reply-To: <0b95a502-eea0-46cc-5d0d-ec6e861ad51f@marco.de> From: Attila Nagy Date: Fri, 17 Mar 2023 21:16:17 +0100 Message-ID: Subject: Re: Fwd: Kernel DHCP unpredictable/fails (PXE boot), userspace DHCP works just fine To: Matthias Pfaller Cc: stable@freebsd.org Content-Type: multipart/alternative; boundary="000000000000942f1205f71e4052" X-Rspamd-Queue-Id: 4Pdb4X6qQ1z3jyQ X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000942f1205f71e4052 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Matthias Pfaller ezt =C3=ADrta (id=C5=91pont: 2023. m=C3=A1r= c. 17., P, 7:24): > > Do you have STP/RSTP enabled on the switch ports? When the link goes down > when > switching from firmware mode to kernel mode, the port will go back to > blocking. When > the dhcp requests don't make it to the dhcp server because of this and th= e > link goes > down and up again while retrying (don't know if this happens) you will ge= t > the same > problem on the next try. As a simple test you could put a dumb unmanaged > switch > between your core network and the server. > Thanks for the idea, but I don't think this might be the case. I can see the UDP datagrams coming into the kernel (replies to DHCP messages). --000000000000942f1205f71e4052 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Matthias Pfaller <leo@marco.de> ezt =C3=ADrta (id=C5=91pont: 2023. m=C3=A1rc. 17., P, 7:24):

Do you have STP/RSTP enabled on the switch ports? When the link goes down w= hen
switching from firmware mode to kernel mode, the port will go back to block= ing. When
the dhcp requests don't make it to the dhcp server because of this and = the link goes
down and up again while retrying (don't know if this happens) you will = get the same
problem on the next try. As a simple test you could put a dumb unmanaged sw= itch
between your core network and the server.
Thanks for t= he idea, but I don't think this might be the case.
I can see = the UDP datagrams coming into the kernel (replies to DHCP messages).
--000000000000942f1205f71e4052-- From nobody Sat Mar 18 01:24:39 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PdjwY2pyZz405f8 for ; Sat, 18 Mar 2023 01:25:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PdjwX0sXLz4CvF for ; Sat, 18 Mar 2023 01:25:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=HIoknEis; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1679102697; bh=Z3oxsTBisPpsq1Anfa77aw0dBL6p2sqAgoonQ2DEUEI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=HIoknEisGFBmgHU+fMfVezP/xu+/Z2iluyCGx3G+V1twTXZ/0dlCU8lxxpjGB2N3M+6vKhtieqInNoiLKLwEeM9iCm99jz3MezE92fjSXZ9i5OPC4tFCVXJVkNYUWv7x2ydla3IEe2C99iXh3hoHGSf0TSCeyh4zQIT7c6YfSRkNXBTYn0fDaQVuIxEsXsFb6JbU6qvG9DF6OUPbgU3Jy221OGqpzXq/6+hEAdJ0FsV4NqLiOpP54d2OggWkpPEcEx80kqF8s7n7KWg5YsmZRY2pF60t6AjLBLUFT8DKK3Et/Ni6bt3YX1bqvgsnxtKpNWRcYcjBBx++ep7ULVll1Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1679102697; bh=62NdlwPQl7ge3uHjUBJ0xI3DnBdISXG2OcBVAM6DWXy=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=hgAgQGGyzh6yLBa/ZVLYJWDtO21o+2H6MnaORJVHs17XNiG/MolmhyxmImdAai6J7m46hHtP0adouXgNBRZ7Mg52x30SHF34HCiyE4Y7cF4w9cPnXViPikda1J/Zk2fOg4MGO4WjWvpWXNUvjKgFFgubl9Sxe04u9f5N+p4wLM3pbemUZBTXNmYxGR5NXZJTqM66pJdK3t0fKjI87gGEEwLOU93M5XUX5oF81cs0ODS0sWwE/wVlQ+FkWQ5hIKJhpvKBwqC6ciLNQ3R0ZQ64fyO4wMvLQR7IdX01FpPWvsFqrCVdKzaxGkdmB0c6Z+VpGLJwDamhS7fC20fqnxo8ww== X-YMail-OSG: sf5tJM4VM1k7.QJrAj32i4rw2gQpZuNY2HEdxQMpBF070LxIWQRO6kjyNG5laVt Lv8jXKk2vzmADXGwiyAReoTK6EnIdt3DeA32ENngom3PwFtsBfj49HpoQDKX98pL.ckCGeXTJroh adtmG1Zs9CO36olb1SzsywLfJU6W9IVUJRm4TF6Uo_C4V3NV0OUf7U7L6.gBPI9jcEzLmM8445m2 D6hhIwzrllk8a1.uCf98qQlNLVZcnxREy482lPsl1CDkbH32jP9iG.eyisCNpg9Ihmxg012wKwHw k42oDCMmXRGAfm1nffwsV.lkflio4bDd03hmOu1pR7tBlKX56NyVyFc2pK1T3DtJyacxUAfKpp7Z 1KVUYMeboNK6jKEVY1OEJuFy1ntciwjCO9CYhEx3YXDF1ZmZjpkAE9XRYYfEcP8rmNnGvUtUl9U3 tn4pjA.QPI_8fpjL5tJjFz6fMQgwt49A.rXhNyh5GuEJiNPX2hXmjsUeDaPOChI58E64bU_3INn. 7Cikbwxc0dDQs9jBeDUmfHPUcz96f9lShRfSpBbnOZjxEDEN63diA7jPMVD3YUvBrSkWMJeOBtlg uBisg88eSVraINATImE0tcUt3nG5Y7jmK55DSp9DzF8Eblw3tDF2fsJBQVlJITAEc6yXiBmTrPH3 G4W.7BZk1OYwpfWIa_3.qymSI2UVZ5pbV2qrgflk_k41CrmYoAOI3fMebYpNyfnZPrypphgVgo1U sIn0vb4aTttqLaZLFjdxXVHN3E7uzL6_LAn6YJ9X3vUybswL5Md8oTHGctnmlgplshMf80D22JhD NWt2fOYYHiAQsPj6HUDMXmU.0Pb7hoYJuK3Ge2dvnUhziiM10kS0kiRJyN2hqhTz8jR29kueWMJq 7PbqOYrKhJkY76EzWFJHf88pxbD9L9TDSCsHqbunQEXIfeGPKEiOrW2Ov77F6fB4FdxVmjE9Gcv0 ejE5xtObY5mNuoIg7wkI.19LxwGxG9noitgeNfbixnFo1N2ilP961zCHaShKbJzCcsttJvfFzYct 3.J9_o8HOSiosefHk15X52QmYIWXkKL6Irp07MqFHgtSqO955hyUm4kA0nFsVQeogi2rS0RymsMV lpEUuJqggbvx0TTkz0490Xq0kcx0.bZrGQX29RfQdDvxNQbdpRg2rWa_xu9DXOpJHNF8ifdyIlwd GTfGC9Vb.M08.YN2TSkUJtgqkwtHkV7tstbOW2onczg3ALLZL5UuRnOtv2kUmvaqjTt.ZB16dt_O HC9n56QIVQCLfZPZ1u4QgvHew3NNapdM31Z4oJwSKMi.QBWlOCAI8ZG0R0T4EmxzAa6nID.SyUX9 JUNStzvWzmp3LA79WDNJ8MMivKSNwTq6O9l.iEAu3ES67qHThAE2kw8qUkLJLJwnvEwcy1vQ9qly l1vmlXvKIHN5bakq33dMgBUPlVui2uXL26d7mvMjfMON68JVb08KPEmPZYW7VTLBqxBLWbyAwUdq 19QK2Vj_hfOgGS8BgNA.7WJI9SywdJMBADBZQzX_BAb7c3urxX8adzD_vwh9yo0GmxqY3zzsb3p4 rJK2rPdI9gr7eQjeJE2oGn4ZIJeH9F1hkFFHNCjQj_mX7Lk.PMA6jhE6Vo4aPi6ShvTnIWDapexj KqWnPHeexgBd85cKaw_t5iUjSnaUFbTx4V5oHLGp0qIdbjaPJNPfwwC0yoQRbpdSxPqV3FbYw2lg jB7hyTHs0VMUhZXWKmBCdp.b7RVuoM_K9xTmtGGKvN.kEX5jdlFtsuKBKiRqOFz7lMkDehaGlCqC vhXc2prRffL4PCkZGfqV8aTBFby7rx8Bj0oxwR7TC.cuWatsqHfkJkiL34Cw172BWVQQexV85SKc 0qyRv1A1NPIRcp.PwaL8kTELgx7D.VsAj2C0Wfx97mzmQiCfEoIBaVG6AJ99tWOzF2OuNBNuDebr KS0WzXb8MzSfCMzpFCzGuIw3cqEJle2oJD1gb6pn_LeBDmq0ajF7S.b069mqlv0gtlGpGl0Nqq66 cr8Txyh1sciqjdOtQGQ.WgmmqVOQKxssI.k9st_YSzYjwtYfYg9B5VTawBWwjkWudQDAYWbazcnx 4wqtXbuuyByMghiVHLAtvoF.K9bHI.OLfimDLk9B7tBsAYfdpK.dDUNk77Ki.SmS2V7ueGvYPSyI 4WhweImJHl732JtGG2ubJ.X3AU_t84bCGKCkOteK88O9odkckozrX.fcM7siV4EtrY.tVXWrCJMP .hy4pPy7DaXLcygiygJWqj3CUGEa.yAWZMBa4Z.Lguhmxpff3SrydjyFR9G8Mxej.DHpf429db9c _Uw-- X-Sonic-MF: X-Sonic-ID: 79c13ad1-2184-4dfe-9a3f-ad2fefc630b0 Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sat, 18 Mar 2023 01:24:57 +0000 Received: by hermes--production-ne1-759c9b8c64-gbrwf (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 32082728079a61947ced984b6bf8633d; Sat, 18 Mar 2023 01:24:51 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: I just updated to main-n261544-cee09bda03c8 based (via source) and now /etc/machine-id and /var/db/machine-id disagree ; more From: Mark Millard In-Reply-To: Date: Fri, 17 Mar 2023 18:24:39 -0700 Cc: =?utf-8?Q?T=C4=B3l_Coosemans?= , Current FreeBSD , FreeBSD-STABLE Mailing List , Baptiste Daroussin Content-Transfer-Encoding: quoted-printable Message-Id: References: <2cf7d953-2493-9673-5ea3-fba22c694015@freebsd.org> <20230317181547.4d75e897@hal.tijl.coosemans.org> To: Colin Percival X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-3.47 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.970]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_FIVE(0.00)[5]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from] X-Rspamd-Queue-Id: 4PdjwX0sXLz4CvF X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N The 13.1-RELEASE (snapshot) to 13.2-RC3 freebsd-update's upgrade sequence did not go well relative to my being prompted to do the right thing to establish /etc/machine-id . After the last reboot (kernel upgrade, presumably) it had me continue with. . . # /usr/sbin/freebsd-update install src component not installed, skipped ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Installing updates... install: ///var/db/etcupdate/current/etc/rc.d/growfs_fstab: No such file = or directory install: ///var/db/etcupdate/current/etc/rc.d/var_run: No such file or = directory install: ///var/db/etcupdate/current/etc/rc.d/zpoolreguid: No such file = or directory Scanning //usr/share/certs/blacklisted for certificates... Scanning //usr/share/certs/trusted for certificates... rmdir: ///usr/tests/usr.bin/timeout: Directory not empty done. root@generic:~ # cat /etc/hostid /etc/mach* cat: No match. It did not indicate the need for another reboot to end up with a /etc/machine-id file. I tried "shutdown -r now" anyway. It did establish an /etc/machine-id file during the reboot: # ls -Tld /etc/hostid /etc/machine-id=20 -rw-r--r-- 1 root wheel 37 May 12 08:46:21 2022 /etc/hostid -rw-r--r-- 1 root wheel 33 May 13 09:46:56 2022 /etc/machine-id So the basic implementation is operational but just lacks an indication of the need to reboot again. The date/time is because it is a RPi4B context (no time of its own) and time is not automatically being established via ntp, apparently. (I did not make such adjustments to the snapshot before starting the upgrade.) I do not know if any of the "install: ///var/db/etcupdate/ . . . " lines or the rmdir line are important. It earlier indicated 5708 patches were fetched and that 377 files were as well. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Mar 18 02:04:23 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PdkpL3BS3z408GT for ; Sat, 18 Mar 2023 02:04:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.gq1.yahoo.com (sonic314-21.consmr.mail.gq1.yahoo.com [98.137.69.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PdkpK2Mdmz4JpX for ; Sat, 18 Mar 2023 02:04:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=N7r9A6g7; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1679105079; bh=rgVZfZ1cqBfWES+/1T2rCsyD0ybkKRaamzJWKGiwVZE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=N7r9A6g7ZMVsWSl26i54PGveZoUvT/yNDl1O+qTmcZEMeKETt0PiCEMctzfNbbSgMW5Qz3j4fw5bS7CxJX11guRBvzsdjD+xZnypgetu0u5Ce4D4VCNrpYBR4eA92KetGivQLjvCVJs4o6SwUMBw/SE3Y3a1TLXJu78nJGdIawBPJkbI5kowXWqmXBK2ME2T9SKUhAKszjMf39ShtKaABmuuam+tr4lFc4rHgK4ramRLmHLq4dtyIkvRYvQqp8OYkYNRGzDJ95OHF5kjyNAreZ9SAqR77ltaFcPtgWh+nsF3/L7GH1Q62Uf7RBuVhStEkyYYxd0iWv2eaRx7NADHPw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1679105079; bh=9nMhICiEPRpixFqUWi5rVpJJcaluK/aHUqS4NQGq8pD=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=DQlapYOIymccwsZv5TXett9dnN907pPOXDV9rZpZsWrD1Y5VtGIkirEBzZ9BDVP+LvePd/7Ppne5LlomjcKUytjCoPuPX2XQODH/6XXVgKSIZQMJ307TOKqFYgIuUzBRzAnanZ6M4clcr5XTM6c/1YFzNoYscarnxnbDdHMGLBJn3Ei2D+I5GstOCPQu5qNwAOs4jKuOvqym2oJAjx1IzNwEiZPkLNOXbqWK2ooWLFBHo7Rp3rs2dSe3D1LHeMnIALkSWn6oLxmlfzpljJ5hWW6dnMppbrEiochJW42BadHfUiSUR6O3RJ0tokhPUV9q7obs8noV53r3U37O/Su8yA== X-YMail-OSG: LZYSSUsVM1ldaVwL0s3km5KCMk7jWUPlgJeTFqnuXZOOuHICOYKlW5VQEsYAyY8 7d3wgMZMf95Sw4k8l.69nadxxrQvvRnX3ERGCXLFqH6TnNa8WARIxbrSGlE6tdXilAXGNpjeMl7W IBmSIdAJCnLUmUod6MRmyemU76ZDHNxi0XSV5MtLLLzAeHKviEj7pO5bnA3A4bg1wo83U9yfiHYf PD3n2.U5DyeRz7zSyaqAHtQJdHgi9kgxbkmrmatmMSvPNMRgPwSC5EdoXUJcmcH8yqmj4VAAtfjv M6EG813QHSpOTjvVUxlMCoC_8G2Hb4p_CW8ey_lVuUL1whF3cAIgP.nZHEMcY8r1hGQH.gW5GTzG DhM8Ic4BnQ2UBFvFydGNS2.N6EAEK1QlBDSVuc_djVsJ13hh46tWRdWlBYEye8x7KxYrYx.MF_XZ 9dNSnoHDbdb4PK780KfmdJGNayYRn4xK2OvrytaAw4Oi5dDuZtNbbhb3INTyuS3CfVuAfznd7W3x dwrb28pmioikaHiplbt3DuEtTgG5_D2liJTBrTb38CFcQdKOBq7E43tUHghyXfgCLDMZ5mBUNrU7 qbYNRZWJK5nXbQJ64XdU30SoN4wZUSNn0gqINPvkVZh949mI4zG3TMvS3pZ588Xeh_RIX3__g6Rq 746._PETsgVhHaxNdcwQuom5gdZK.N_lUR7CW1UNUX4LdvtvaKrKOt8XflzSMVQfcnH0S9hWTbK4 72kAHCyowRts_jyWHHHdbCq1cCXawPYKGv_IZaV_amgI2aNglQ50DfpiJ6BgqczjLWHByxn0y1Al lhg9RfcFJeNBQPEQOCNcU.8iK3sN6BElIgxYYFi_aT.SBriUplaG_8CKgIu8lpVqowrO9PodCVvV fiHNdhqAFlrs6hGNxhCIjXVGYR.CBmD0Wkmp9GPxjUwKchCFu7DX1xDxzSf_P1EvO4RSEEHINy3j oobmh6Gfoq0nPeb0gHYh0IPesXN4.P8ajWLYL062BbY1O1V0jvvHZX6Jl3RjzbdFqluiYm980LO7 GrPkRxPoY71dKZaUb2VjzC0GMZ6.bIOoC6EshPzLdwIB2ni9.lMcepYpFRn0_WHcLAqjdGG3b.yV 82aDqaPwdDnM2bQoMl.EBUJ5.wMFVFqIKK1x92_Ov2NdrNfzC0__9_dVuLPn9N57_p.KrbXYpBov aa3vpXS8I.ypXIPPrw_9i.vKqRgSrEwH0dK79vFV.I2VZvhPvD_V1wLwdcE1oNh_y01oEW483MdR RnGqhaNVRMt7MEisXHeQFxPPplwminN6DqFLEnchAQgvyVF5sDnRQeCcKL0QLfSGcou967djWLk5 u__47mkmWW.wZ1TLHCzinrBQR7r4Izg3r3XdijwvkJ0qRGcLWGN.JchPARp6vnzi5vSNTX_.UIWS nasx29wqtpfE5rdvFRTnqxZBdFb81OWyGDu59icBsLPxkccheIwnXLEuiqRJ0nA3sMK2ek3slY6l PSF6FAclT5RJztQH1EesCBl7aYk.XHRCWOHk.SDptuSfRhFSJ0rn7zZdjVY6ON4rV2JUFDFZOaI1 x8RN_bYCiH4ejHmpSZpv.9w9JQ7CVesqi7Vhh9ZwMDHZMeiHYazxVT_MyG950KwMU2_8fyQmgERc rqKf6refkRmFa14XuW4W1LzMxTVQN5RWCZLMA831UVod_8F4H9wCRlUYyEK5Eg_vy.fILiw659gq HZo7kTzIdb7Emv0KQENEcQh0X_2P2KXt2_XHob1Eblm_x2ouCC63QXLHPuySvt9Z4SYxeoP.3wtD DYwOdCcOiMFBP.0vfGF_9aUEBKSzx9WOKfwRPwkDFq6OHWv7bd_.f..BA54BpXkwnmYY.m4YsB8v dgqoPud3NN86wK0GkcFnghUwuMvtcH2SM9pkFvscvwJ1j3UHbiZ4wEawuTQBXGsF7JTgIsb0X.60 8nPJlzaamzCvpv0ILilDkxYaWPRq6Az84E17G3sDe0xNY5OZGY_duhLPvW1bnOgoze5g8Xp3oZRi AbjdWe47nssrwplmlFIoqbvAGNl_nMUZH0gLpSMVGxFCX_U3A.wMIN6U33t3use626rJu9ZcmhJG h9TET2Rx8AGyO832Fm2Rb.80hMWq72WyzDHmT5Co2qWutuN.mKkpQU2SU8hoMzOwI8UM6svO_SSK MCEIzOyKs6W3oF8SNxYud_OLBpjaWT9Ui2hDLiIvIjog34QXItiTw2goEtwGcBw.NyVilEtR9ANE mEqI2edtk8yJ19udVzmrB6SmyP.NkKDKUqw6rkDrOgMu5oAQlvVladegfXxiccmFve7mya5upApq 8xo4- X-Sonic-MF: X-Sonic-ID: eebe58e9-65e3-4e4c-988e-79f00d7fc4c1 Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 18 Mar 2023 02:04:39 +0000 Received: by hermes--production-bf1-777648578f-277mr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 315132da0532cee6617be1d4d38e000d; Sat, 18 Mar 2023 02:04:35 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: I just updated to main-n261544-cee09bda03c8 based (via source) and now /etc/machine-id and /var/db/machine-id disagree ; more From: Mark Millard In-Reply-To: Date: Fri, 17 Mar 2023 19:04:23 -0700 Cc: =?utf-8?Q?T=C4=B3l_Coosemans?= , Current FreeBSD , FreeBSD-STABLE Mailing List , Baptiste Daroussin Content-Transfer-Encoding: quoted-printable Message-Id: <91950753-BDE0-45D5-B0B9-42782BD75C47@yahoo.com> References: <2cf7d953-2493-9673-5ea3-fba22c694015@freebsd.org> <20230317181547.4d75e897@hal.tijl.coosemans.org> To: Colin Percival X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-3.45 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.95)[-0.952]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.84:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_FIVE(0.00)[5]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.84:from] X-Rspamd-Queue-Id: 4PdkpK2Mdmz4JpX X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Mar 17, 2023, at 18:24, Mark Millard wrote: > The 13.1-RELEASE (snapshot) to 13.2-RC3 freebsd-update's > upgrade sequence did not go well relative to my being > prompted to do the right thing to establish /etc/machine-id . > After the last reboot (kernel upgrade, presumably) it had me > continue with. . . >=20 > # /usr/sbin/freebsd-update install > src component not installed, skipped > ZFS filesystem version: 5 > ZFS storage pool version: features support (5000) > Installing updates... > install: ///var/db/etcupdate/current/etc/rc.d/growfs_fstab: No such = file or directory > install: ///var/db/etcupdate/current/etc/rc.d/var_run: No such file or = directory > install: ///var/db/etcupdate/current/etc/rc.d/zpoolreguid: No such = file or directory > Scanning //usr/share/certs/blacklisted for certificates... > Scanning //usr/share/certs/trusted for certificates... > rmdir: ///usr/tests/usr.bin/timeout: Directory not empty > done. > root@generic:~ # cat /etc/hostid /etc/mach* > cat: No match. >=20 > It did not indicate the need for another reboot to > end up with a /etc/machine-id file. >=20 > I tried "shutdown -r now" anyway. It did establish > an /etc/machine-id file during the reboot: >=20 > # ls -Tld /etc/hostid /etc/machine-id=20 > -rw-r--r-- 1 root wheel 37 May 12 08:46:21 2022 /etc/hostid > -rw-r--r-- 1 root wheel 33 May 13 09:46:56 2022 /etc/machine-id >=20 > So the basic implementation is operational but just > lacks an indication of the need to reboot again. >=20 > The date/time is because it is a RPi4B context (no > time of its own) and time is not automatically being > established via ntp, apparently. (I did not make such > adjustments to the snapshot before starting the > upgrade.) >=20 > I do not know if any of the "install: ///var/db/etcupdate/ . . . " > lines or the rmdir line are important. >=20 > It earlier indicated 5708 patches were fetched and that 377 > files were as well. Using the likes of: = http://ftp3.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.2/FreeBSD-13.2-= RC3-arm64-aarch64-RPI.img.xz directly seems to produce installations with a constant: kenv -q smbios.system.uuid 30303031-3030-3030-3265-373238346338 that ends up being what is used for /etc/hostid . It looks like this traces back to the U-Boot involvement in the boot sequence: # kenv | grep smbios hint.smbios.0.mem=3D"0x39c2b000" smbios.bios.reldate=3D"10/01/2022" smbios.bios.revision=3D"22.10" smbios.bios.vendor=3D"U-Boot" smbios.bios.version=3D"2022.10" smbios.chassis.maker=3D"Unknown" smbios.chassis.type=3D"Desktop" smbios.planar.maker=3D"Unknown" smbios.planar.product=3D"Unknown Product" smbios.socket.enabled=3D"1" smbios.system.maker=3D"Unknown" smbios.system.product=3D"Unknown Product" smbios.system.serial=3D"REDACTED" smbios.system.uuid=3D"30303031-3030-3030-3265-373238346338" smbios.version=3D"3.0" =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Mar 18 03:52:28 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PdnC04zbYz40Fwb for ; Sat, 18 Mar 2023 03:52:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.gq1.yahoo.com (sonic314-21.consmr.mail.gq1.yahoo.com [98.137.69.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PdnBz3R7kz4TH5 for ; Sat, 18 Mar 2023 03:52:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=DP0fBKdA; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1679111561; bh=cIEZvKx1Zb04OZdhA7xhX09MqY5185ehFJZRJLnH3i8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=DP0fBKdAxtGXTTt/Jp2yF71G+ZioEU6pU9C/ssFNXL6wCcR0dyMW3fqWJTZMVUhotDZgmvlZTeaCoZJ7QlyzCs2BvvW1vVJNZ4eshCtJKoqAIVqYWXodsU/nbbPoUR/U/gSVs1q6p667DBfmKq+v2z4ZQZ6GW9obqU4woWFD8DcmAu/AXkZGue0L7HdMMpXjZ7gZns7cHsAMot1EPKh/NoFlCTFX6Ib06SlYwmsIoZ4NhMx4V+TRCjak6DwdZRx0MfAIPxX/hFc4/XGAdZLwZeYsdhn1PVhyRcIQj4sUq8fskViCv3eW1bpBnzuUFmqgZMpnxt8s/0izQeVBac2YPw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1679111561; bh=THZMHUUiH9Ais+Sb7cr40wiMyHbmCrp8aPzIlKoDmtr=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Fh8Wr3oIP5uGUGLTJTisIIa8pVUPtMdRLlsrUblt/v+jQdaliD0YdT0b0G282/RIS4k6NaXBeFQ/8CpH/pTBc4HMv5dNJC2XA36LyBDQt1GW0tnidM7YhWAPWTDUgR6CzWYyO/h0xYNXZV5Rfj/sd8qfiVI7OTyqvsAgBbBn3ZM8vFTejN/hp7ilk+ZbPao/Kyi7xgjO6VS3MUYT+oneOZ+4QxIjdYozpVrRl3+TwzAAfoO6fjJyfDS8bhc3BmcwbAbmZs3ce5ePaoCmm3hyJ1heebchxgfZz9yl/WoOv6imgUtwl8cPjhojMXX8znlF0w2PHKwLq9/a9v6BrYEz0Q== X-YMail-OSG: aZNQXloVM1kSYdgD.ZQECRuvb_AC6SLS_z7FfHU1onCVtkvtl3EPJQf0Gj.mZ3J 97qR3FaDvNia3kiH9_sN4aWFofPv56rhNYAYM47Qbs7chINZdD0Xl9Ylygs0qsSqt802RvqLe45u SxCUB3Z2YHxHcTCA98LYZUpIy.6lixPvohjnG_wWCmv_QBBL..MoRHkf.i5EpsrgYxvXB3apw7u6 PWJqOfZNUwIJ8bcG_BZ_f4FyGPmdZX2dFoDaR9rnH1Pf4cmP_73Ioxvinbj7aYPpVOCcHFUcZTzC ploMzibPjVyanDgrAH7Z_yUi4Muay_4TjPk_CHiMetwVtm.WJm7ZMz9nIXAPGqTIMdWnNLagLjuG lgOJRbFW3EsbhHXPBIpErDqZ.yEWb6XHoPY0tuGnDRGIUAvbkeqh_EaD57.5RJJrhXW23ntzjYxS Qx_PpwR7ClqPNqPyeQ3h_Wsu04tZEu9tgZyQ5xeyepqaoD_GK90d6d5DPZZ5xTBLr.4BmUSSQUOD 9xYd6M0g3B_itQ0mMUSGoZK7j.0qWm_zOvyJ3OQTQ0A7SurA71ZVhGGF4xMQR45ZTt6UDKT.JEpY wqs8_3d4Y5OioCrC.2I8ZG9GJXkoxngIy2whOwAOpdsldVJHMGbZnzGqKK3V6U44AZrX2pqhOAep p52Yvi9LgCrQZA37skwwrM_Hxag7TOglPVey6EVCcpEdZja29ut1vRF06r5vJ6lgcVXF2ofaW_2X 8LVZsk7hCatdWyAFCuXI8jEXx5Uwf1pcxS0zuRLkEBQnVP9Ik7p2EJ2VlxyJG1sXlX3xxSWpLiDE dYDkGsi27owkdEBF7cVAZliBKJOQaTC1s8kCfBo5s_hksBbmCy69.SYZO7XmsijHsF5YJ16F3Twl 4dIPvjyr3gEYA1s4KffAv0ys7PtvEs6rEL4S2SBa1YmzJEK.Do8aBEuo7YzLbL12bU7mUBoDq0I6 fypVSGWuAd1tqudL7IC1n1QFyi79_getG5aOwi7s4XbL9rlJdrVhQrq79qKWymW0027WlkBiphw2 FSSdtCDYDtBipFBFWSmc6vq4t9jN_ryuXXcuelbf1uCRSesqMhbckn33nVWy0j1jrXy6lbiV34wo oBb9J.DevAPRhFPBfRGmwQOawINsmojDmJfhwouV0yfn5KPCggaQHMvcvMVEyaHVOymczk6TxxvS SrnM0VDp.cq3ky5QjkK3gSmscmLTxmYjmDHdXeMgGF3BYBH64bX8rECoDwJQRMxw_DcDcIQSGYyh 0uz.FQa71Z9TVJY0yhLvkfuGEzHwdk.odWkgTeBqDhk0zzadcpXAmp8KAo2tlqaAcWz2NFirH6WF oxA5xMpBxGF_vra2TqcaalMepIiCBhSswl9siE8Om6os3b.ehMd5GAWRlN2U3sT1MM52qbsufZUv 1VMbk.mpyRV0wria65KW7obeqgurSOBiwXZm6bfa3Rc6l3dH7XC1hua23X1483LJYORVu_mHvubC qdb9MUtBPSeDibVch4oAsTR9tGS3UMuqkiUkyUbBowMC4DWRw7nZaHJIWH_FR8VbIdjs.8s7n2dJ pQ5H9zvNTSzF27kGmSQdehBGXPe1iBZ.QS3974IV9k7XBDVfZWDVfoM0pb9OmBrPolanrkcYz0Oz _3A_cN15lt8WULTZvBVuqAGu72fcOPaJDax34efoIz0uMJtcD3bJmM.OUEGssjHE9JkD650snVuy CJXmiSm9pPyr1_WkvEu2vtMBMojgrVagAc3nLiJMlBpbr3jL_.ijpbEGVpiSoJxSrP5VML6xwAxp nZSYV_k15hsW65ExEn8r8OBjsJzgdL9FMAj9wLJqCul34FJ6p9S56AN6JNuPxZlKhTMCBQG45bdj ZBUJG5EsLmCBjIquk3rTd2qgpX4wTrlmwx09t8LErFIh7gMAz6UotELKQr8n0Z3vLf.2x3NOXixe fmRTNMZwdM38DMLmNWSEmnNSs68cY2y2YFh052D3oxhmG7zgJzaS.NOK9WS2v7q2eZP0Bu7hO6se iUu_gIRuoxyd7BV7fZv5oH_FmiB.T8RS_nwwvtGdwDdiv1.hrdJ2pCSjI1jFB_vMy5OPyMlYCcZr hPmKXcxWuLGpiQL8aUP4ILoktHJB2MgEvEWFjyIPfysQu2lKDbnp0.e_ci6OzYlL5eCgkWLoSq2p eaLhxtm7pNUpfAGOoz.btbXQie0UZYU6mc_pIJI3i3Zc51A.lq.25i6dKwpPK3ORUCvo4xdptVH. VOyBBpEBzBwy8vAi5lW87qca0fxl5LN0sEaqmnIck6fxrAFHiiwl2l7cG1jlxrto.OLjDbNiQUhS 50qntyg-- X-Sonic-MF: X-Sonic-ID: b9706546-0634-4824-81d0-8acc40b90c34 Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 18 Mar 2023 03:52:41 +0000 Received: by hermes--production-gq1-6cf7749bc8-q7lrl (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c4d4a0b53802a9e6b26d5014239f83c2; Sat, 18 Mar 2023 03:52:38 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: I just updated to main-n261544-cee09bda03c8 based (via source) and now /etc/machine-id and /var/db/machine-id disagree ; more From: Mark Millard In-Reply-To: <91950753-BDE0-45D5-B0B9-42782BD75C47@yahoo.com> Date: Fri, 17 Mar 2023 20:52:28 -0700 Cc: =?utf-8?Q?T=C4=B3l_Coosemans?= , Current FreeBSD , FreeBSD-STABLE Mailing List , Baptiste Daroussin Content-Transfer-Encoding: quoted-printable Message-Id: References: <2cf7d953-2493-9673-5ea3-fba22c694015@freebsd.org> <20230317181547.4d75e897@hal.tijl.coosemans.org> <91950753-BDE0-45D5-B0B9-42782BD75C47@yahoo.com> To: Colin Percival X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-3.44 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.94)[-0.944]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.84:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_FIVE(0.00)[5]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.84:from] X-Rspamd-Queue-Id: 4PdnBz3R7kz4TH5 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Mar 17, 2023, at 19:04, Mark Millard wrote: > On Mar 17, 2023, at 18:24, Mark Millard wrote: >=20 >> The 13.1-RELEASE (snapshot) to 13.2-RC3 freebsd-update's >> upgrade sequence did not go well relative to my being >> prompted to do the right thing to establish /etc/machine-id . >> After the last reboot (kernel upgrade, presumably) it had me >> continue with. . . >>=20 >> # /usr/sbin/freebsd-update install >> src component not installed, skipped >> ZFS filesystem version: 5 >> ZFS storage pool version: features support (5000) >> Installing updates... >> install: ///var/db/etcupdate/current/etc/rc.d/growfs_fstab: No such = file or directory >> install: ///var/db/etcupdate/current/etc/rc.d/var_run: No such file = or directory >> install: ///var/db/etcupdate/current/etc/rc.d/zpoolreguid: No such = file or directory >> Scanning //usr/share/certs/blacklisted for certificates... >> Scanning //usr/share/certs/trusted for certificates... >> rmdir: ///usr/tests/usr.bin/timeout: Directory not empty >> done. >> root@generic:~ # cat /etc/hostid /etc/mach* >> cat: No match. >>=20 >> It did not indicate the need for another reboot to >> end up with a /etc/machine-id file. >>=20 >> I tried "shutdown -r now" anyway. It did establish >> an /etc/machine-id file during the reboot: >>=20 >> # ls -Tld /etc/hostid /etc/machine-id=20 >> -rw-r--r-- 1 root wheel 37 May 12 08:46:21 2022 /etc/hostid >> -rw-r--r-- 1 root wheel 33 May 13 09:46:56 2022 /etc/machine-id >>=20 >> So the basic implementation is operational but just >> lacks an indication of the need to reboot again. >>=20 >> The date/time is because it is a RPi4B context (no >> time of its own) and time is not automatically being >> established via ntp, apparently. (I did not make such >> adjustments to the snapshot before starting the >> upgrade.) >>=20 >> I do not know if any of the "install: ///var/db/etcupdate/ . . . " >> lines or the rmdir line are important. >>=20 >> It earlier indicated 5708 patches were fetched and that 377 >> files were as well. >=20 > Using the likes of: >=20 > = http://ftp3.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.2/FreeBSD-13.2-= RC3-arm64-aarch64-RPI.img.xz >=20 > directly seems to produce installations with a constant: >=20 > kenv -q smbios.system.uuid > 30303031-3030-3030-3265-373238346338 >=20 > that ends up being what is used for /etc/hostid . >=20 > It looks like this traces back to the U-Boot > involvement in the boot sequence: >=20 > # kenv | grep smbios > hint.smbios.0.mem=3D"0x39c2b000" > smbios.bios.reldate=3D"10/01/2022" > smbios.bios.revision=3D"22.10" > smbios.bios.vendor=3D"U-Boot" > smbios.bios.version=3D"2022.10" > smbios.chassis.maker=3D"Unknown" > smbios.chassis.type=3D"Desktop" > smbios.planar.maker=3D"Unknown" > smbios.planar.product=3D"Unknown Product" > smbios.socket.enabled=3D"1" > smbios.system.maker=3D"Unknown" > smbios.system.product=3D"Unknown Product" > smbios.system.serial=3D"REDACTED" > smbios.system.uuid=3D"30303031-3030-3030-3265-373238346338" > smbios.version=3D"3.0" >=20 Looks like if U-Boot ends up with a system serial number, it uses that as the basis for the system uuid: https://github.com/u-boot/u-boot/blob/master/lib/smbios.c char *serial_str =3D env_get("serial#"); . . . if (serial_str) { t->serial_number =3D smbios_add_string(ctx, serial_str); strncpy((char *)t->uuid, serial_str, sizeof(t->uuid)); } else { t->serial_number =3D smbios_add_prop(ctx, "serial"); } For example (some byte reordering also involved someplace): smbios.system.serial=3D"100000002e7284c8" smbios.system.uuid=3D"30303031-3030-3030-3265-373238346338" # 0 0 0 1- 0 0- 0 0- 2 e- 7 2 8 4 c 8 This explains my seeing the same uuid from 13.1-RELEASE installation as I later saw from an independent 13.2-RC3 installation (not upgrade): I reused the same RPi4B. All media produced on the same RPi4B will get the same hostid and machine-id files by default, given how U-Boot works and that smbios.system.uuid "wins" when present. This may all be fine. But it still leaves me expecting that there should be man page(s) covering these hostid and machine-id files and how they should be handled to match the usages to which they are put, such as the nfs use that was referenced. A note/reminder to look up that material could also be relevant. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Mar 18 09:55:49 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PdxGG5ksBz3yNbD for ; Sat, 18 Mar 2023 09:56:06 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PdxGD4R0dz3rly for ; Sat, 18 Mar 2023 09:56:04 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=WkDYtdO4; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il; dmarc=pass (policy=none) header.from=huji.ac.il DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type:Message-Id:From; bh=slwsP0d7DFpXIlPByBbNPJcsRqccYiN+Hqn5V/Bq0rM=; b=WkDYtdO41XGKAW7yLqDlwCnSOSCyQnKxoW6smuj50HZWZm5wq8bOThG7tsmXEhcJqy6V0R8zAuR1LPityKrYVinmayg84HLZT6ao5yLCWBGrLQC4ygCcS9DEFWtyL156EwWT2uarv51CGlrbXz3phoIZaCYCywEGHpVivVqUggtbNtVEu/VsjNWqs/Ie4MWWqsSb1AMZBA6CqOLtwCRKQfpPV57JYlUWlyuourKgheqiOXzSjpZUMyKCtMMX86UyosoIrpmTsJSu4gIZh6frTP8bMqqmGYYJKYxXebGSPjHd0jX8D98L+Z/0omVOoVC4UwBvEESYUkyRBMEWgfln5Q==; Received: from imac.bk.cs.huji.ac.il ([132.65.179.42] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1pdTI7-000Id0-Aw; Sat, 18 Mar 2023 11:55:59 +0200 From: Daniel Braniss Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_09293E36-95E4-4BC4-ACE0-1BE2793A1AAF" List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: Kernel DHCP unpredictable/fails (PXE boot), userspace DHCP works just fine Date: Sat, 18 Mar 2023 11:55:49 +0200 In-Reply-To: Cc: Matthias Pfaller , stable@freebsd.org To: Attila Nagy References: <0b95a502-eea0-46cc-5d0d-ec6e861ad51f@marco.de> X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Spamd-Result: default: False [-3.29 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.991]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ASN(0.00)[asn:378, ipnet:132.64.0.0/15, country:IL]; MLMMJ_DEST(0.00)[stable@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; R_SPF_NA(0.00)[no SPF record]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FREEFALL_USER(0.00)[danny]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; FROM_HAS_DN(0.00)[]; TAGGED_RCPT(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PdxGD4R0dz3rly X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_09293E36-95E4-4BC4-ACE0-1BE2793A1AAF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 17 Mar 2023, at 22:16, Attila Nagy wrote: >=20 > Matthias Pfaller > ezt =C3=ADrta = (id=C5=91pont: 2023. m=C3=A1rc. 17., P, 7:24): >>=20 >> Do you have STP/RSTP enabled on the switch ports? When the link goes = down when=20 >> switching from firmware mode to kernel mode, the port will go back to = blocking. When=20 >> the dhcp requests don't make it to the dhcp server because of this = and the link goes=20 >> down and up again while retrying (don't know if this happens) you = will get the same=20 >> problem on the next try. As a simple test you could put a dumb = unmanaged switch=20 >> between your core network and the server. > Thanks for the idea, but I don't think this might be the case. > I can see the UDP datagrams coming into the kernel (replies to DHCP = messages). take look at src/stand/libsa/bootp.c, there is a compile option that = allows many more options to be transferred via dhcp =E2=80=A6=20 BTW, where possible I=E2=80=99m moving to uefi, since pxeboot is = failing with file to large =E2=80=A6 another issue i have with pxeboot,=20 older versions work - better - , some are terribly slow, and some just hang. danny --Apple-Mail=_09293E36-95E4-4BC4-ACE0-1BE2793A1AAF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 17 = Mar 2023, at 22:16, Attila Nagy <nagy.attila@gmail.com> = wrote:

Matthias Pfaller <leo@marco.de> ezt =C3=ADrta = (id=C5=91pont: 2023. m=C3=A1rc. 17., P, 7:24):

Do you have STP/RSTP enabled on the switch ports? When the link goes = down when
switching from firmware mode to kernel mode, the port will go back to = blocking. When
the dhcp requests don't make it to the dhcp server because of this and = the link goes
down and up again while retrying (don't know if this happens) you will = get the same
problem on the next try. As a simple test you could put a dumb unmanaged = switch
between your core network and the server.
Thanks = for the idea, but I don't think this might be the case.
I can = see the UDP datagrams coming into the kernel (replies to DHCP = messages).

take look at src/stand/libsa/bootp.c, = there is a compile option that allows many
more options to be = transferred via dhcp =E2=80=A6 

BTW, where = possible I=E2=80=99m moving  to uefi, since pxeboot is failing with = file to large =E2=80=A6

another issue i have = with pxeboot, 
older versions work - better - , some are = terribly slow,
and some just = hang.

danny

= --Apple-Mail=_09293E36-95E4-4BC4-ACE0-1BE2793A1AAF-- From nobody Sat Mar 18 14:55:09 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Pf3vT1pCLz3yfn1 for ; Sat, 18 Mar 2023 14:55:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Pf3vT06Cnz4KRy for ; Sat, 18 Mar 2023 14:55:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52a.google.com with SMTP id w9so31065179edc.3 for ; Sat, 18 Mar 2023 07:55:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; t=1679151315; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=yfAlfxqUZTi6nvTIytuVUfE1700OhzxwkGYFPzEP85k=; b=1Fd9H2ceVYku+Aqn0TeXbvEI8DrwNBuqH9LcqoUyQ/sAZgVLhLv3T3Qf4CYJ4wiNX8 iqAVcYs4vllc8UxF99tHDec3vn6kZd45tIm+lPVmVX2UdrPdj2IAVhoWEQYXIR9ubNQ9 wmH91uc3tk4RGWjyLqfuGqexZrJ0X0V8XffXjI+jIs0ZjdndC1HIBkSBWec1PLGxZN// WDjHs3qPI7PgNrAgLFyne7jNZknMTgHfvyLBnHIXc4l+OFeDTo0a09X/ivqPgbLi78MO ymV15eavE1R2bmKc3Uj5uTGXXBMCFcCLl4F5AmZE2RP8U7HfuYgf5hczg4mPkIrG5Rj8 S3Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679151315; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yfAlfxqUZTi6nvTIytuVUfE1700OhzxwkGYFPzEP85k=; b=3RVo7HhmnYu5TLQ99rvPCI4xmmUYuYS1ZhYtsccd8RDEV3rppe4zjayK5ZikRODr6A 2a5le+qUxQvx6rOJJgElSLwDBMHdOc5GKmBzuM/eaflzk2Cc+ZKKK5x2LkZHrml5X51l Qv10mXSMYfbH85ugSD5va7fccnxf/qWu687TuPtCZ+Q5p/YAhJQBn5d+7BwFAH0RaHEp mROw0O5ppdnPE8uIYeCr3yIGp1zgqNHAfdhPQNvXf513tdqtwja8Wc7CrCOKtFA/7QfI SK3iTx+tq7Aw/HPSMCsSrvVht5Mpn02yIHSr1qyn1+N5/yy8mXAXUM8wikFlkDHRXl8e B2Zg== X-Gm-Message-State: AO0yUKUEYVR/Ki25aFvFvOORqhZvyRh+hlEJxyCOb4fpK2cpPzlG+JVL fnqH6aGkl3K17vkKY2lyXlWYpOOaI9pRlFPL/3PKkw== X-Google-Smtp-Source: AK7set9zzpmQWxmdGexFY6r4txeOUDYKK7zcunbWt179ldAz1/RuWpEbGl3xFnjIlKQPexEUfaXK4FggxcS1t9WriOg= X-Received: by 2002:a17:906:9c96:b0:931:f8b1:4472 with SMTP id fj22-20020a1709069c9600b00931f8b14472mr1323838ejc.2.1679151315550; Sat, 18 Mar 2023 07:55:15 -0700 (PDT) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: <2cf7d953-2493-9673-5ea3-fba22c694015@freebsd.org> <20230317181547.4d75e897@hal.tijl.coosemans.org> <91950753-BDE0-45D5-B0B9-42782BD75C47@yahoo.com> In-Reply-To: From: Warner Losh Date: Sat, 18 Mar 2023 08:55:09 -0600 Message-ID: Subject: Re: I just updated to main-n261544-cee09bda03c8 based (via source) and now /etc/machine-id and /var/db/machine-id disagree ; more To: Mark Millard Cc: Colin Percival , =?UTF-8?Q?T=C4=B3l_Coosemans?= , Current FreeBSD , FreeBSD-STABLE Mailing List , Baptiste Daroussin Content-Type: multipart/alternative; boundary="000000000000b01d9e05f72de1ef" X-Rspamd-Queue-Id: 4Pf3vT06Cnz4KRy X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000b01d9e05f72de1ef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 17, 2023 at 9:53=E2=80=AFPM Mark Millard wr= ote: > This may all be fine. But it still leaves me expecting > that there should be man page(s) covering these hostid > and machine-id files and how they should be handled to > match the usages to which they are put, such as the nfs > use that was referenced. A note/reminder to look up > that material could also be relevant. > It would be great if we could document this. I too recently ran into a mismatch. If you load the /etc/hostid so that the code in jail0_init picks it up and sets the host uuid, then /etc/rc.d/hostid, enabled by default, will come along and see there's no smbios.system.uuid and generate a new uuid and smack that bad-boy into the kern.hostuuid sysctl unconditionally. It was easy enough for me to work around this by setting smbios.system.uuid in the boot env that I was booting from, though. Nothing to do with the upgrade, just that we have multiple mechanisms to specify this stuff, and the code we use today is somewhat less than robust to cover all the cases that should be supported, but wind up being buggy. Warner --000000000000b01d9e05f72de1ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Mar 17, 2023 at 9:53=E2=80=AF= PM Mark Millard <marklmi@yahoo.com<= /a>> wrote:
This may all be fine. But it still leaves me expecting
that there should be man page(s) covering these hostid
and machine-id files and how they should be handled to
match the usages to which they are put, such as the nfs
use that was referenced. A note/reminder to look up
that material could also be relevant.


=
Nothing to do with the upgrade, just that we have
multiple m= echanisms to specify this stuff, and the code
we use today is som= ewhat less than robust to cover all
the cases that should be supp= orted, but wind up being
buggy.

Warner
--000000000000b01d9e05f72de1ef-- From nobody Sat Mar 18 19:34:37 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PfB621WTbz3ywX4 for ; Sat, 18 Mar 2023 19:34:50 +0000 (UTC) (envelope-from nagy.attila@gmail.com) Received: from mail-oa1-x2e.google.com (mail-oa1-x2e.google.com [IPv6:2001:4860:4864:20::2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PfB615MJfz3kms for ; Sat, 18 Mar 2023 19:34:49 +0000 (UTC) (envelope-from nagy.attila@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oa1-x2e.google.com with SMTP id 586e51a60fabf-17997ccf711so9289663fac.0 for ; Sat, 18 Mar 2023 12:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679168088; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=umR7rs7rqKQouVLgo7F9NUvj+vj8BkZ/Zi/O8lxxjM4=; b=BGoIjrszM71sDL3Ay0Z+inDNPVi4m92nraYHftt/XWyhJodftvVAP+x1tmRK3HduPG WJi+0r3aqEkyt6Iz2TbuPB+sof0Stfp1rdMyh+utUqaigHqzldgigv/h9lnUnIt3FxKy 6KzqzcmpC6Lkbg/00fuqKyiruApPfGsqMmSwYc3k6rzKudh9vsNkaGsmYNPnFSUTeZMF ORNz4EjT9M2WFq0sjJogai9IhkdYpCoeM17dgIU/WQta0zPN4OCbra+xCZ27CPWFCP6I pqerLYFJwZ7cGIFfoyHl1xh3tI5OuNcVpNV3DoA9NZmlepplKe+xJeJi69Cv+Xoy/CQi Z+Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679168088; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=umR7rs7rqKQouVLgo7F9NUvj+vj8BkZ/Zi/O8lxxjM4=; b=Hdup4F0kD0Rk+tgKHB4HNiNOL5iEQFWflwdftNI3e+2PFn+LTahZPeVNjECC65vj1W bzUIxmBmgfK+gRTP/BlocWCkefnBc8uvhodjp0fjobAqtg47AbZe0fOP19mUfl7HjcvJ Q7mbw8eo0N1ksFwwsUZCmxwTzf0CN1ekEiVd/oTFlyiVvu84xtz7d5FIeWFtDnurHMDS wPCZqGybDBYcwIPdVckE/qmsV+S7e35gJwGutqRYlIwBc/5+DXf+6sbIOw+Us02dKf2p mZWpva+IZ4hATDGEpKFwfp43j7XwhzhwSlfr6BmAAFTCGBpZGoYV27qI6gSjNrHg3c71 avgg== X-Gm-Message-State: AO0yUKWoL0RxjkMh1irBvgba3X7sanlq2T/m/yDoO1D6ku4/oFXbkjsw 7cRG6fd79mAfNfvIyC2lIoqkSOnJoTsojVbQe/A= X-Google-Smtp-Source: AK7set+LcpraY3+T1/RDe5MKXTiH4NVDjfVz35zuG1aEDskgMhFEg/fIXM0oUN6Erqtcs9PbhP1UGLVI7Puj6e57kJw= X-Received: by 2002:a05:6871:8689:b0:17b:1895:a637 with SMTP id ta9-20020a056871868900b0017b1895a637mr838943oab.11.1679168088211; Sat, 18 Mar 2023 12:34:48 -0700 (PDT) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: <0b95a502-eea0-46cc-5d0d-ec6e861ad51f@marco.de> In-Reply-To: From: Attila Nagy Date: Sat, 18 Mar 2023 20:34:37 +0100 Message-ID: Subject: Re: Kernel DHCP unpredictable/fails (PXE boot), userspace DHCP works just fine To: Daniel Braniss Cc: stable@freebsd.org Content-Type: multipart/alternative; boundary="0000000000006a845605f731c9f3" X-Rspamd-Queue-Id: 4PfB615MJfz3kms X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --0000000000006a845605f731c9f3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Daniel Braniss ezt =C3=ADrta (id=C5=91pont: 2023. m= =C3=A1rc. 18., Szo, 10:56): > take look at src/stand/libsa/bootp.c, there is a compile option that > allows many > more options to be transferred via dhcp =E2=80=A6 > Without the kernel BOOTP/DHCP, this (doing the DHCP from userspace, from /etc/rc.d/dhclient) is somewhat late for rc.initdiskless to pick them up, no? I mean how would you use that to have the same support for classes in rc.initdiskless? > > BTW, where possible I=E2=80=99m moving to uefi, since pxeboot is failing= with > file to large =E2=80=A6 > Does that make any changes here? rc.initdiskless is called very early in the boot process and kern.bootp_cookie won't exist (there wouldn't be a hostname either I think, which I also rely on with the in-kernel DHCP). --0000000000006a845605f731c9f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
Daniel Braniss <danny@cs.huji.ac.il> ezt =C3=ADrta (id=C5=91pon= t: 2023. m=C3=A1rc. 18., Szo, 10:56):
take look at src/stand/libsa/bootp.c, there is a= compile option that allows many
more options to be transferred via dhc= p =E2=80=A6=C2=A0
Without the kernel BOOTP/DHC= P, this (doing the DHCP from userspace, from /etc/rc.d/dhclient) is somewha= t late for rc.initdiskless to pick them up, no?
I mean how would = you use that to have the same support for classes in rc.initdiskless?
=C2=A0
=

BTW, where possible I=E2=80=99m moving =C2=A0to ue= fi, since pxeboot is failing with file to large =E2=80=A6
Does that make any changes here? rc.initdiskless is called very= early in the boot process and kern.bootp_cookie won't exist (there wou= ldn't be a hostname either I think, which I also rely on with the in-ke= rnel DHCP).
--0000000000006a845605f731c9f3-- From nobody Sat Mar 18 20:05:17 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PfBnY55N3z3yxxW for ; Sat, 18 Mar 2023 20:05:37 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PfBnX2XP6z3nbq for ; Sat, 18 Mar 2023 20:05:36 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b="3r/DUEeG"; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il; dmarc=pass (policy=none) header.from=huji.ac.il DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type:Message-Id:From; bh=pimeDM0sTzKrhLx86g+bDRqSSWdDRyipIbkgbqsOu9M=; b=3r/DUEeGCC6GNWD8jTNT/irUXbQcc3O4HMPKYk4IvWEJdsnWGqPUG53mlaGusiciBMioIqBPmPwXuxeTM9HCLisijoXmd12k4kisJoH156Fs/2bUmdBHJMcGIvK7TLRXHFPJe6tWN2wAFUlReYAdZFot50h0yRJ568YiqwJhYcxOJUk9W4vVDpuMlAzV6C3u0jNU10pTuLZYG7AFtTDZolqJTMtXb8mXDG5Gfht1MZxvo4sdaVx0Ffcu8XWyINlnbxqlc5fLJXpWOpnCih5oWBsPN+7Mi6/Sj89fdI/UdgL6G16EDCq4n/tyZHA7Bu4FKS6ienDRavbT20OIHZ/RRw==; Received: from imac.bk.cs.huji.ac.il ([132.65.179.42] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1pdcnv-0009TJ-O1; Sat, 18 Mar 2023 22:05:27 +0200 From: Daniel Braniss Message-Id: <41594155-7AED-4265-82FB-89B388BD40D8@cs.huji.ac.il> Content-Type: multipart/alternative; boundary="Apple-Mail=_B59C8C85-F873-4C93-8C93-7892145251D2" List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: Kernel DHCP unpredictable/fails (PXE boot), userspace DHCP works just fine Date: Sat, 18 Mar 2023 22:05:17 +0200 In-Reply-To: Cc: stable@freebsd.org To: Attila Nagy References: <0b95a502-eea0-46cc-5d0d-ec6e861ad51f@marco.de> X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ASN(0.00)[asn:378, ipnet:132.64.0.0/15, country:IL]; MLMMJ_DEST(0.00)[stable@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; R_SPF_NA(0.00)[no SPF record]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; FREEFALL_USER(0.00)[danny]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TAGGED_RCPT(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PfBnX2XP6z3nbq X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_B59C8C85-F873-4C93-8C93-7892145251D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 18 Mar 2023, at 21:34, Attila Nagy wrote: >=20 >=20 >=20 > Daniel Braniss > ezt = =C3=ADrta (id=C5=91pont: 2023. m=C3=A1rc. 18., Szo, 10:56): >> take look at src/stand/libsa/bootp.c, there is a compile option that = allows many >> more options to be transferred via dhcp =E2=80=A6=20 > Without the kernel BOOTP/DHCP, this (doing the DHCP from userspace, = from /etc/rc.d/dhclient) is somewhat late for rc.initdiskless to pick = them up, no? > I mean how would you use that to have the same support for classes in = rc.initdiskless? > =20 >>=20 >> BTW, where possible I=E2=80=99m moving to uefi, since pxeboot is = failing with file to large =E2=80=A6 > Does that make any changes here? rc.initdiskless is called very early = in the boot process and kern.bootp_cookie won't exist (there wouldn't be = a hostname either I think, which I also rely on with the in-kernel = DHCP). i made the changes to bootp ages ago, but as far as I remember you can = get as kenv variables much stuff, including hostname, which rc.initdiskless can use. I=E2=80=99m= using a slightly modified rc.initdiskless btw. it=E2=80=99s a bit late now, but i=E2=80=99ll try and refresh my memory = tomorrow. danny --Apple-Mail=_B59C8C85-F873-4C93-8C93-7892145251D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 18 = Mar 2023, at 21:34, Attila Nagy <nagy.attila@gmail.com> = wrote:



Daniel Braniss <danny@cs.huji.ac.il> ezt = =C3=ADrta (id=C5=91pont: 2023. m=C3=A1rc. 18., Szo, = 10:56):
take look at = src/stand/libsa/bootp.c, there is a compile option that allows = many
more options to be transferred via dhcp = =E2=80=A6 
Without the kernel = BOOTP/DHCP, this (doing the DHCP from userspace, from = /etc/rc.d/dhclient) is somewhat late for rc.initdiskless to pick them = up, no?
I mean how would you use that to have the same support = for classes in = rc.initdiskless?
 

BTW, = where possible I=E2=80=99m moving  to uefi, since pxeboot is = failing with file to large =E2=80=A6
Does = that make any changes here? rc.initdiskless is called very early in the = boot process and kern.bootp_cookie won't exist (there wouldn't be a = hostname either I think, which I also rely on with the in-kernel = DHCP).

i made the changes to bootp ages ago, = but as far as I remember you can get as kenv variables
much = stuff, including hostname, which rc.initdiskless can use. I=E2=80=99m = using a slightly modified rc.initdiskless btw.
it=E2=80=99s a = bit late now, but i=E2=80=99ll try and refresh my memory = tomorrow.
danny

= --Apple-Mail=_B59C8C85-F873-4C93-8C93-7892145251D2-- From eugen@grosbein.net Sat Mar 18 20:08:02 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PfBrb19Hgz3yySk for ; Sat, 18 Mar 2023 20:08:15 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PfBrZ2YNWz3pyD for ; Sat, 18 Mar 2023 20:08:14 +0000 (UTC) (envelope-from eugen@grosbein.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=grosbein.net (policy=none) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.17.1/8.17.1) with ESMTPS id 32IK84Z9091894 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 18 Mar 2023 20:08:05 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: nagy.attila@gmail.com Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 32IK83ZM042573 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Sun, 19 Mar 2023 03:08:03 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Fwd: Kernel DHCP unpredictable/fails (PXE boot), userspace DHCP works just fine To: Attila Nagy , freebsd-stable@freebsd.org References: From: Eugene Grosbein Message-ID: Date: Sun, 19 Mar 2023 03:08:02 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.6 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on hz.grosbein.net X-Spamd-Result: default: False [-1.95 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_FAIL(1.00)[-all]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.95)[-0.952]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[grosbein.net : No valid SPF, No valid DKIM,none]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[eugen]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TAGGED_RCPT(0.00)[]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4PfBrZ2YNWz3pyD X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N 17.03.2023 3:44, Attila Nagy wrote: > Hi, > > As this is super annoying, I'm willing to pay a $500 bounty for solving this issue (whomever is first, however I don't anticipate a big competition :) Having an invoice would be best, but I'm willing to accept individuals as well). > I can't give remote access, but can run debug builds with serial console. stable/13 branch. > > I have a bunch of netbooted machines, one set in a cluster is older (HP DL80 G9, 2x8C, Intel I350 -igb- NICs), the other set is newer (HP XL225n G10, AMD EPYC2x16C, BCM57412 -bnxt- NICs). > All of these boot from the network, which is basically: > - get IP and options with DHCP with the help of the NIC's PXE stack > - get the loader and kernel, start it > - do another round of DHCP from the kernel (bootp_subr.c) > - mount the root via NFS and let everything work as usual > > The problem is that the newer machines take an indefinite time to boot. The older ones (with igb NIC) work reliably, they always boot fast. > The process of getting an IP address via DHCP (bootpc_call from bootp_subr.c) either succeeds normally (in a few seconds), or takes a lot of time. > Common (measured) times to boot range from 10s of minutes to anywhere between a few hours (1-6). > Sometimes it just gets stuck and couldn't get past bootpc_call (getting the DHCP lease). > > What I've already tried: > - we have a redundant set of DHCP servers which offer static leases (so there are two DHCPOFFERs), so I tried to turn off one of them, nothing has changed > - tried to disable SMP, the effect is the same > - tried to see whether it's a network issue. The NIC's PXE stack always gets the lease quickly and booting FreeBSD from an ISO and issuing dhclient on the same interface is also fast. After the machines have booted, there are no network issues, they work reliably (since more than a year for 20+ machines, so not just a few hours) > > This issue wasn't so bad previously (only a few mins to tens of minutes delay), but recently it got pretty unbearable, even making some machines unbootable for days... > > First I thought it might be a packet loss (or more exactly packet delivery from the DHCP server to the receiving socket), either in the network or in the NIC/kernel itself, so I placed a few random printfs into bootp_subr.c and udp_usrreq.c. > > After spending some time trying to understand the problem it feels like a race condition in > bootpc_call, but I don't know the code well enough to effectively verify that. For me, it looks like timekeeping problem. Please show output of: sysctl kern.timecounter kern.eventtimer After it booted to single- or multi-user mode. Also, show verbose boot log (bootverbose). Sometimes UEFI/BIOS SETUP has some settings for ACPI/HPET timers (enable/disable), did you try "playing" with such options? Note that there is loader tunnable kern.timecounter.hardware="HPET" that can be used to force some timecounter source for kernel using loader.conf or device.hints, any way that puts it to kenv; kenv/device.hints may be compiled into custom kernel binary even. From nobody Sat Mar 18 20:51:11 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PfCp809cPz401Cn; Sat, 18 Mar 2023 20:51:12 +0000 (UTC) (envelope-from cperciva@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PfCp76xkgz3vGD; Sat, 18 Mar 2023 20:51:11 +0000 (UTC) (envelope-from cperciva@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1679172671; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc; bh=/ZN4bVYOI6dxvDljVbwPN1AdZpOVRwejGHxNWdzfrGQ=; b=yK0HqQQtRgRMlrlma84rW+nWTQj/zxLMkM/G/NhlKmnpuybCrpesy3jy1C6VQ8Q98JlRg3 u42I/mn+u9JffYnvnlgIA3ULuP+gsqg5tdMhlv1rwS75rxcWs0BfK8pOlMEw6cZwgv4nRs +c3aOPwaceYizcFSWyoYntHUGGPBcBerwppoQoyB0h+DsG+bJUkDZvuFtfZoJEfGo1cMVu YV4SxYqUpcjvSJ1RwPOWK7mT83XhwXQbWSmyV0TawxOoR88wgy9Q0cE44fiD3d9312SRr1 K+Wxg8GsgB4/T14JMs72INVSGvzN6X20+F/nefxGTOqlqJe+zrky+6f5eMI5gw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1679172671; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc; bh=/ZN4bVYOI6dxvDljVbwPN1AdZpOVRwejGHxNWdzfrGQ=; b=yQpKIWGoJwnjoKsbjY38xblJOlX8ASdp27h2t4A6bvQw17IJTPraou1EBgHOPKgeK9+iRe I78yCepm5bUkLIEVb6NTNVx2MDh/j3J+uEvI0xo2Om4XH19c1+8yL1q+nDi/V1o25WH3QC dsdTsVYlC8a996ZLtgoRUZdDU63NnGUbDpY1FEGx6OOctknzRksPw3+TY9OGgcXmZ4bOov olEKL66P0VMnvfguABjHLNekMmMkOzrx9I4r06GaLdNmLP2a8hiZSWZ0+g9N0JMsR/vLEd GQFHUP3+fn+LI8d3NKldUYGGfzdBOV0gWfpTapUFCjAIGaMQQhpvNly8gy3+HA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1679172671; a=rsa-sha256; cv=none; b=l8IzqnlhXFvpbetJ9yFf00Gjf+WGbYvxMcOS67bzx2arfMFNYHe8UJH90QoSUkoKZb3NF3 FUopeoPT/QOCPOjcwVk7UYidQW/WqIw0yoUFxxWCm9MjCJkJ4QxcUZMHRdklDawfVFmFRp EDjFWGENNzzoIHHaA4Z9n89+xfMo0McQrdOz0M4ST3n7drg2NVUrh4ECMY7bWWJciaVIjt GK96emiyRzkzODPpLwFeX0gz8Ng1+rxTZzhDye+o+Bo9vCCtpNc3qIjDBtewpPbaOW5ikI Z3jAQFprMjSPmadPc6Ek0HDtyehqIEFCIsd1cFsmYGPo/HDhzae0BuFOXDYgmQ== Received: by freefall.freebsd.org (Postfix, from userid 1002) id DB5221C595; Sat, 18 Mar 2023 20:51:11 +0000 (UTC) To: freebsd-snapshots@FreeBSD.org, freebsd-stable@FreeBSD.org Cc: FreeBSD Release Engineering Team Reply-To: FreeBSD Release Engineering Team Subject: FreeBSD 13.2-RC3 Now Available Message-Id: <20230318205111.DB5221C595@freefall.freebsd.org> Date: Sat, 18 Mar 2023 20:51:11 +0000 (UTC) From: Colin Percival X-ThisMailContainsUnwantedMimeParts: N List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The third RC build of the 13.2-RELEASE release cycle is now available. Installation images are available for: o 13.2-RC3 amd64 GENERIC o 13.2-RC3 i386 GENERIC o 13.2-RC3 powerpc GENERIC o 13.2-RC3 powerpc64 GENERIC64 o 13.2-RC3 powerpc64le GENERIC64LE o 13.2-RC3 powerpcspe MPC85XXSPE o 13.2-RC3 armv6 RPI-B o 13.2-RC3 armv7 GENERICSD o 13.2-RC3 aarch64 GENERIC o 13.2-RC3 aarch64 RPI o 13.2-RC3 aarch64 PINE64 o 13.2-RC3 aarch64 PINE64-LTS o 13.2-RC3 aarch64 PINEBOOK o 13.2-RC3 aarch64 ROCK64 o 13.2-RC3 aarch64 ROCKPRO64 o 13.2-RC3 riscv64 GENERIC o 13.2-RC3 riscv64 GENERICSD Note regarding arm SD card images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root. It is strongly recommended to change the password for both users after gaining access to the system. Installer images and memory stick images are available here: https://download.freebsd.org/releases/ISO-IMAGES/13.2/ The image checksums follow at the end of this e-mail. If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use Git to do a source based update of an existing system, use the "releng/13.2" branch. A summary of changes since 13.2-RC2 includes: o OpenSSH updated to 9.3p1. o A major performance fix to makefs for msdos filesystems. o Changes to how host/machine IDs are generated. A list of changes since 13.1 is available in the releng/13.2 release notes: https://www.freebsd.org/releases/13.2R/relnotes/ === Virtual Machine Disk Images === VM disk images are available for the amd64, i386, and aarch64 architectures. Disk images may be downloaded from the following URL (or any of the FreeBSD download mirrors): https://download.freebsd.org/releases/VM-IMAGES/13.2-RC3/ BASIC-CI images can be found at: https://download.freebsd.org/releases/CI-IMAGES/13.2-RC3/ The partition layout is: ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 135 MB and 165 MB respectively (amd64/i386), decompressing to a 21 GB sparse image. Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI loader file is needed for qemu-system-aarch64 to be able to boot the virtual machine images. See this page for more information: https://wiki.freebsd.org/arm64/QEMU To boot the VM image, run: % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \ -bios QEMU_EFI.fd -serial telnet::4444,server -nographic \ -drive if=none,file=VMDISK,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -device virtio-net-device,netdev=net0 \ -netdev user,id=net0 Be sure to replace "VMDISK" with the path to the virtual machine image. === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: ap-south-2 region: ami-0131a35facd31e2b6 ap-south-1 region: ami-00ff638d4ff7b7aa5 eu-south-1 region: ami-0fddd48ec085e0eee eu-south-2 region: ami-0caa64d56e6abde5e me-central-1 region: ami-075c75df3f6f445d6 ca-central-1 region: ami-01935c2b64c640e4b eu-central-1 region: ami-0e11b18443d818e3b eu-central-2 region: ami-0fbecccb98e3abdd6 us-west-1 region: ami-08b93f81b0e418077 us-west-2 region: ami-020b3285ee1552b95 af-south-1 region: ami-0e167b2bd2bd6d083 eu-north-1 region: ami-08a7c8d83ae79b127 eu-west-3 region: ami-07e1c36a55c5809de eu-west-2 region: ami-025bba53d2570b640 eu-west-1 region: ami-0751127930b5733e3 ap-northeast-3 region: ami-08cbc7a3b87f6ba3f ap-northeast-2 region: ami-04db704a054c1f701 me-south-1 region: ami-083f2d92231279523 ap-northeast-1 region: ami-0ca775a15fecc5d84 sa-east-1 region: ami-051df4112708fa2bd ap-east-1 region: ami-0e6b886bc7177b242 ap-southeast-1 region: ami-04e828c469b764fd6 ap-southeast-2 region: ami-0afc4676e8fe2658e ap-southeast-3 region: ami-02b834f6bc3f162f5 us-east-1 region: ami-010705f6d17b66934 us-east-2 region: ami-01558ce48fdadecde These AMI IDs can be retrieved from the Systems Manager Parameter Store in each region using the keys: /aws/service/freebsd/amd64/base/ufs/13.2/RC3 FreeBSD/aarch64 EC2 AMIs are available in the following regions: ap-south-2 region: ami-00114e8df2b540e90 ap-south-1 region: ami-0b783642a9e232660 eu-south-1 region: ami-07d33c9fdc93d8a3b eu-south-2 region: ami-0e2179a87f55b74a1 me-central-1 region: ami-0da7f4ff610629f35 ca-central-1 region: ami-0edf1e667a9ce74f5 eu-central-1 region: ami-09ebbcf7a4b681f73 eu-central-2 region: ami-04c88f73c913dd832 us-west-1 region: ami-0623cd79de15807c8 us-west-2 region: ami-0a746737f2bad72d0 af-south-1 region: ami-0c554c72dd2203b1c eu-north-1 region: ami-001c2f4eab883a82e eu-west-3 region: ami-05fbd63e5db974448 eu-west-2 region: ami-02c10243fc90d5054 eu-west-1 region: ami-0ffff811c6a908f70 ap-northeast-3 region: ami-068ec1eddbfc5caf2 ap-northeast-2 region: ami-05e6b0664100905c3 me-south-1 region: ami-05b218d656d9a007a ap-northeast-1 region: ami-03b482842cf217c53 sa-east-1 region: ami-0c666fe8dea5b2b3b ap-east-1 region: ami-01b4d33b92ed76d8e ap-southeast-1 region: ami-028e9f455c4250b6a ap-southeast-2 region: ami-0f2e305005fc79ded ap-southeast-3 region: ami-0b9236acf50ab952d us-east-1 region: ami-0e51221cfcaa66c5d us-east-2 region: ami-0f6c130463cbd2e70 These AMI IDs can be retrieved from the Systems Manager Parameter Store in each region using the keys: /aws/service/freebsd/arm64/base/ufs/13.2/RC3 === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site for the VMWare Desktop and VirtualBox providers, and can be installed by running: % vagrant init freebsd/FreeBSD-13.2-RC3 % vagrant up === Upgrading === The freebsd-update(8) utility supports binary upgrades of amd64, i386, and aarch64 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 13.2-RC3 During this process, freebsd-update(8) may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install It is recommended to rebuild and install all applications if possible, especially if upgrading from an earlier FreeBSD release, for example, FreeBSD 12.x. Alternatively, the user can install misc/compat12x and other compatibility libraries, afterwards the system must be rebooted into the new userland: # shutdown -r now Finally, after rebooting, freebsd-update needs to be run again to remove stale files: # freebsd-update install == ISO CHECKSUMS == o 13.2-RC3 amd64 GENERIC: SHA512 (FreeBSD-13.2-RC3-amd64-bootonly.iso) = 7f4bc32ed177bc85dc4f4a52bffeee12e86ccf9b09a4263683fa16e954813005535e6772b1afa2a6bba6cfb6599992981c11a0d1a32ee156bfa075cc05c6c487 SHA512 (FreeBSD-13.2-RC3-amd64-bootonly.iso.xz) = 8effb1d4ec8d9b6d2949ac4d486c999c046321db1b7e38122e810efeda1d84541af1b6533dc665349853c8e2391b78c4beab5414f755be9d63dc19828d2dc5d5 SHA512 (FreeBSD-13.2-RC3-amd64-disc1.iso) = 204d9a464c96f4d72c135acff85736cebeac4bb26e37672e89ef5977c2faecba2002a40444313d9328c6133955cbdd951cb0446267db32184ad6a5db40c1cd64 SHA512 (FreeBSD-13.2-RC3-amd64-disc1.iso.xz) = f147e8c94b02adf953849dde68cb33696b697435d734e446ccd88a44feb2efd9d0b677929ff3399d013966780c24f496c2b4ac11031f3d6126c92f7742e0db09 SHA512 (FreeBSD-13.2-RC3-amd64-dvd1.iso) = 3743548c50729af8c65d78103941926c1340c0b6056a67a1035a94d532f64a882a69c868063c1584e42523abf52f8d5959736e3f86911be3e264b2c402502ec9 SHA512 (FreeBSD-13.2-RC3-amd64-dvd1.iso.xz) = 6541f018166e4e1b97e1643838fa63de7bc9c829bc910b9d0b7dddcd1ed23de0e732bd75cd2f22a4d27966e5436a207eb6865d06cfb9d01a2710c5229380a89b SHA512 (FreeBSD-13.2-RC3-amd64-memstick.img) = 81bf78b3b8429e481128b71242d32ecc3df1ecae7bfe570a27c8b8d43355ab0a30042250700cf517164520bb35b60d41eea1d5d2f1bdb28b112ddcf934b0636e SHA512 (FreeBSD-13.2-RC3-amd64-memstick.img.xz) = e0f15fb59490ca1065561a335be17024799de81364f20301bc31f35beb56df3998705f558e16c51930850b62fe74de619c650083bebe3b999ea7731676a12d53 SHA512 (FreeBSD-13.2-RC3-amd64-mini-memstick.img) = d5622c8f89ab210f9144c714a3aadbe8790f7056d42c3cc65e308dc52571544e3ea6cb4c69786de180297be14f586f4be39e1acbbc068916c5033f520a957c06 SHA512 (FreeBSD-13.2-RC3-amd64-mini-memstick.img.xz) = a9b346a5ca93ca84ce39d64cd9a69a5443ae9719cc24929056a3121ac80eb701814f824ca4e94eb8bcc9f89341267a7978fd449e8e7349add1cc5d4503b4ee13 SHA256 (FreeBSD-13.2-RC3-amd64-bootonly.iso) = 55107db4a889175f84edad3d669fadf85f45296ebd7b198e3481f77fe8b14b07 SHA256 (FreeBSD-13.2-RC3-amd64-bootonly.iso.xz) = 4620a2f803fe30a7cd187d00cc722585bb52a4a417e6ea10d470241c78caadbc SHA256 (FreeBSD-13.2-RC3-amd64-disc1.iso) = a5e28fff4a1f13ef03b05f1437372d07cc4248788998663ae6f599791497fdae SHA256 (FreeBSD-13.2-RC3-amd64-disc1.iso.xz) = 7d381b79bc5ef1d8d54b62084be51bc2177b339934286a925b70498a89a99bf8 SHA256 (FreeBSD-13.2-RC3-amd64-dvd1.iso) = a4023a86134cf6717566667b2313f9b2140441f9a6b27d6ad63a469a627620e6 SHA256 (FreeBSD-13.2-RC3-amd64-dvd1.iso.xz) = ba370ed435349c904b966b19da0b690fe7515d550a7ce887b72a4487c822f1d0 SHA256 (FreeBSD-13.2-RC3-amd64-memstick.img) = 3309851a0adebcd5af75eb08bc71887da0851f35c23ba25757be29f9a67f77bd SHA256 (FreeBSD-13.2-RC3-amd64-memstick.img.xz) = c788d63856a42d0dc29ba6b7ef83cde4007fb6cde96fd13080708969c71525f4 SHA256 (FreeBSD-13.2-RC3-amd64-mini-memstick.img) = 489c99ce230f1d58742225048c647f8da132800ded0fe7396090fdfefb14f639 SHA256 (FreeBSD-13.2-RC3-amd64-mini-memstick.img.xz) = feb93491b205ccc8a958477c55e798bc95823408b1d533560cca18afa7290b60 o 13.2-RC3 i386 GENERIC: SHA512 (FreeBSD-13.2-RC3-i386-bootonly.iso) = d498565ea3ef2dd74d88900f90ea7458e52a4092a913fb3ff7b89685c692eb9d85867a1a5323881de8d2c218789631afc9b137b1be5c49554302b33a8803fe2b SHA512 (FreeBSD-13.2-RC3-i386-bootonly.iso.xz) = 8689e6353302c72a972c21f57d5b69cbc05e7a446625825d6a7f21edbbfdbdefcf759eba91f298fb3586abaee0522e1ade3d2ff7b7730812a807b7e81ba94bc5 SHA512 (FreeBSD-13.2-RC3-i386-disc1.iso) = 5e0d40cdf5e1c65bdd994faeb871722440aab051f65d55c50b1e85135e6adae43342dd9df407caa9f3a099c803579315dd491df5209de405e959a7ff37e4335a SHA512 (FreeBSD-13.2-RC3-i386-disc1.iso.xz) = 5f18ddb0d68b0c91438081257a293037596cf473552b64ef9ac821ac63ac371c54a89d54e73c93d88a1aa7174f6a9cb49ea11d14700c7ae1a2c6a8edb57ebae7 SHA512 (FreeBSD-13.2-RC3-i386-dvd1.iso) = 4147c10468fe17d365173183ecb0d23b616d3c18d4da5f4e649234542adb68e5b21d443ae397d62b587f41f57edc56b4261aceb489126a8c7ae5a016963462c4 SHA512 (FreeBSD-13.2-RC3-i386-dvd1.iso.xz) = 91f6722be47ed005577d382aa79f2ef64a4113b3a851c987aeedeb2eac8a14a7531d4c65583744e4dd688d768aa0f99d3738f54fb524fcb9aa440dfa484d5ee8 SHA512 (FreeBSD-13.2-RC3-i386-memstick.img) = cc306b2d7467890e44de28c0b5d24db4153897c92027340ec472e9327c620211d330a981e1711839cddc06285abd271ff5106445cc69d7c63d3edb263ab1b433 SHA512 (FreeBSD-13.2-RC3-i386-memstick.img.xz) = d744e8245cd350d6fce4a2668e69841f64ba8c4569900bab4c607c57e17a5cd1ea03b88c1d1d00ba4ec250948502749e30147f60d80db75b859067f7a45e86d3 SHA512 (FreeBSD-13.2-RC3-i386-mini-memstick.img) = 20b3605c9b48b6c47952a20b0d582364f8b2b5e0d2fb9a931e41b1e134599375c24777328e7044f42310fd5aa2fc27dcfea21e1e926ef84672620fed456d5ab5 SHA512 (FreeBSD-13.2-RC3-i386-mini-memstick.img.xz) = 66b78e66428a457a26a33970482d8ec237234f9293f9bb45a493464c08fab31dc0b3e6d46da4127ff25d776c437e7aac1382c0359ee3448113286b5ee6bec1c3 SHA256 (FreeBSD-13.2-RC3-i386-bootonly.iso) = eee43bec46b843649118c910493cd3c3d230e3e6b523aa38bfd97ea7d0ba35ce SHA256 (FreeBSD-13.2-RC3-i386-bootonly.iso.xz) = cd0c68badd77fecc33a75d40adb9094d2017d95af654cb3c39d1e0308b1c3a09 SHA256 (FreeBSD-13.2-RC3-i386-disc1.iso) = 5954f4edecc57f08dd458e07422479cb5e83e783b8171c90b5010bed80419798 SHA256 (FreeBSD-13.2-RC3-i386-disc1.iso.xz) = 43767a820ab00c92720687535485d008ee4ac5690a1d52879620c77ece7a0eb3 SHA256 (FreeBSD-13.2-RC3-i386-dvd1.iso) = 219da09228a6f3d6643942ff90951e5a0c0d487bc6782df43e7226405e6a5c0f SHA256 (FreeBSD-13.2-RC3-i386-dvd1.iso.xz) = d3e931f64c42115bd5948210481ff27b8332d96c253ddabdf4e074ee95a78cc0 SHA256 (FreeBSD-13.2-RC3-i386-memstick.img) = 9c0cea23b4d6fe2f5827be6c847d29d82455f348dd54dbe1e6d40a1bef3e47cf SHA256 (FreeBSD-13.2-RC3-i386-memstick.img.xz) = d8dc7b37d332f2eed8bb02ce2d45f51139b47f81a99d9df281cf7bdb091c5a36 SHA256 (FreeBSD-13.2-RC3-i386-mini-memstick.img) = 1e2688aeb9400f9b0585f922f03db78ced491228c2eacd761722185a392f230e SHA256 (FreeBSD-13.2-RC3-i386-mini-memstick.img.xz) = e3c370cb06f713d4a67c2e3080fc741d0d7cc253002ed4a33c749308a7b56691 o 13.2-RC3 powerpc GENERIC: SHA512 (FreeBSD-13.2-RC3-powerpc-bootonly.iso) = 1b9de9386191b238f878a4934dda3904e6fecd4ce3f6268a8a3614ae3ce54f3c42cfed1232d6742d1f4d28e5889b3f3e50e17dcd031d9a92fb55a21f34f5c358 SHA512 (FreeBSD-13.2-RC3-powerpc-bootonly.iso.xz) = ebe4b1661264d26610bb46c933f06dfb5c330f796773a481f3a061f5bb421fe597bd28840bf9574ff2162184b16b258b3c90bcbfb08f4996e4eaa16dd68c995e SHA512 (FreeBSD-13.2-RC3-powerpc-disc1.iso) = be68dd7e3f38d3285482914d32c85a3f7eac1d3c2462fc44694f26b6fd45d94f53d2e46a275fbb8efc352fbc928e8b8fcb1a0ac34e12b07ca11d2cd1483a45cf SHA512 (FreeBSD-13.2-RC3-powerpc-disc1.iso.xz) = 8171cbd0ad2250294f4fef0103bbdfcc31ca9156d3d01127187d3faae0641a6402c3e7260304b45c98b7a60837b0fe13674794de47676ff32222ba347c7f943c SHA512 (FreeBSD-13.2-RC3-powerpc-dvd1.iso) = e8c1726d85447f7d92212b52e96b32c70fcf4a8088b27f9b88bd40c54174009fa2bf39ccbe96e521e6c7b1b2e3db2280069af3347267a5e417303d6bc7edd5cf SHA512 (FreeBSD-13.2-RC3-powerpc-dvd1.iso.xz) = 65da779116f691182e7e6644e3823fb2b8cb632174fe8b40eead9c8b7c55f3ce3745923d3d36ac8cede93d78fd4197d3fd717b7e7681cdc5b4b595d880508e05 SHA256 (FreeBSD-13.2-RC3-powerpc-bootonly.iso) = a68e079dcab06435d1bdbeeb31b7639aeb7d7547a6017d83d937f36c0712c342 SHA256 (FreeBSD-13.2-RC3-powerpc-bootonly.iso.xz) = 815477420bc29ac77c580eae00f506d3c2538d36c67407fad294cae91dbed3bd SHA256 (FreeBSD-13.2-RC3-powerpc-disc1.iso) = a10ae7566ff41400ddab8f4f3cb7efecf385ef090533a9785f16da8beeca050d SHA256 (FreeBSD-13.2-RC3-powerpc-disc1.iso.xz) = 10ef44813707021230b407011243ea62097d4668df1acd3d75bd6fce53cd0243 SHA256 (FreeBSD-13.2-RC3-powerpc-dvd1.iso) = 2c3071fb2a91cf7248da3194657a74f43a1db7125ab2776d4efdf2c3e0ad226d SHA256 (FreeBSD-13.2-RC3-powerpc-dvd1.iso.xz) = 1579da8db6f4f09f58b40c15d0a7638d3e2973ca5b6965390e7a32daad192408 o 13.2-RC3 powerpc64 GENERIC64: SHA512 (FreeBSD-13.2-RC3-powerpc-powerpc64-bootonly.iso) = d95750e8486e9db4355164a1bd24e3d1b2234e3696c01297006dee939a5b035a8d6061c3801dc60c5dfd36dd746391b730da63c496e76c39a96d605d785a3739 SHA512 (FreeBSD-13.2-RC3-powerpc-powerpc64-bootonly.iso.xz) = 3bfab4c96dec4a103ee43209178165833a74b993211beff2c4ec87cb097c8abce3ee723a354ddc9229d4eac181550992b8f9311b12c2fb047962117d876173df SHA512 (FreeBSD-13.2-RC3-powerpc-powerpc64-disc1.iso) = 307a25db7e9adf7891ff3d8f5daea7d0a3f4d4beb3f82367452b3b59b1d35cf2ed8959c137aeff4393cdc9decc66521c71f190f34d435dd700e2c6460e16c65a SHA512 (FreeBSD-13.2-RC3-powerpc-powerpc64-disc1.iso.xz) = 1e537c2d12f23564a4a9058bf54b3d7e5ae1d629d8cdf90a3c40648acf194be0e1f9c3ce84d6ee0e6b36f2166fbdfb9cbe6e045064f9278489a9cec84ae51e3d SHA512 (FreeBSD-13.2-RC3-powerpc-powerpc64-dvd1.iso) = ad4b4e7e4a23fac9c2870a187e1267c56b25b553e12a349d3262aceb2ac457ce70835ee13f8d6ad0644d0e05618fe920a0d924e4dbaea32dd9874f4a894a353e SHA512 (FreeBSD-13.2-RC3-powerpc-powerpc64-dvd1.iso.xz) = fc3844ad3dc1a66461bb66754a9237f5bdc3e677d293927d009de27dbc8bbc90243240a02c47b6d675c3d4ecf169905d82eada4e980baa16b1dfb3673e812b99 SHA256 (FreeBSD-13.2-RC3-powerpc-powerpc64-bootonly.iso) = a41842b0dffdd4f445206d0d0ecd12f0ddc7ad3bb6dc80b14923f512cf229afe SHA256 (FreeBSD-13.2-RC3-powerpc-powerpc64-bootonly.iso.xz) = e26b56bfcff80bd46701c2b7052179b0f324a53e3640bc4e141236335b83879a SHA256 (FreeBSD-13.2-RC3-powerpc-powerpc64-disc1.iso) = 9c4f29c0d81c6ab169ebaad04116948e28209174fb7e0d2ab91585ff214c0b77 SHA256 (FreeBSD-13.2-RC3-powerpc-powerpc64-disc1.iso.xz) = 348b75f25e36638c2e78e10a046c187113f0469e7a3dad33af659704f695a345 SHA256 (FreeBSD-13.2-RC3-powerpc-powerpc64-dvd1.iso) = 4be6642729313c0aa7ec1939f2533120bb75ab9ef21b20cfb130bcd25cbb552f SHA256 (FreeBSD-13.2-RC3-powerpc-powerpc64-dvd1.iso.xz) = 91a6b27bd13bd572cca2ce003603d11e8ff0ebd3c09fc1c17392344d4010de22 o 13.2-RC3 powerpc64le GENERIC64LE: SHA512 (FreeBSD-13.2-RC3-powerpc-powerpc64le-bootonly.iso) = 52a79ec8c4c34a1cf039711bde1617de8dde3fe8f047aa377648b6dda1af4ab6a093ad41198425892b3c7a27e62208e1c1407915ee513d70a901bb1c997667a2 SHA512 (FreeBSD-13.2-RC3-powerpc-powerpc64le-bootonly.iso.xz) = fb28dac863a7347c0054806ffffacce6a895d6f7063e0bae90f092669a1277c4cf2f446daeab2fa66d3321b7153be821eed318946f8a869c17aa8ce57b06ec71 SHA512 (FreeBSD-13.2-RC3-powerpc-powerpc64le-disc1.iso) = e8a592624e0b2898cb01144b740d15afe028804b67dd6575e9af1f7d62f40a5639367ac2ab288fa3d892cc3734e0d8007c6386a406c6cb771064b888b7f1a976 SHA512 (FreeBSD-13.2-RC3-powerpc-powerpc64le-disc1.iso.xz) = 8ecc71850e1403126d534b3a37d776d33f1b336c9f06412e5f67e8ce37fc6bc81c5a611f88076fddce9029cb93baf0746b05f528e5692a32cbd9ca3c11509b9a SHA512 (FreeBSD-13.2-RC3-powerpc-powerpc64le-dvd1.iso) = 95bd32f440d76cebcca2b2a2c2233eb7e18d32d4a514f0558da5a8151dbc76e062b625f1bad6e2df0f1c9850def162169bb23c58c7dfb4baf123678e5a59a1ae SHA512 (FreeBSD-13.2-RC3-powerpc-powerpc64le-dvd1.iso.xz) = abbbdcbccfa426504f2ee59f3ca2a564536fb8e6c75c6084f508eca78df555163636f7dd2950ac97ce93831b2eb6f0c4b58112b672d74edab5c5205389e9b1d5 SHA256 (FreeBSD-13.2-RC3-powerpc-powerpc64le-bootonly.iso) = a8aeb6d688b1a22c5f74c0f6ac3aae8bde711b399303052d85c703c32f5bb6ae SHA256 (FreeBSD-13.2-RC3-powerpc-powerpc64le-bootonly.iso.xz) = 6ae810ebbabad77235e0e3d5326eab02eed69193328b4458aa1170c45a3ee9b7 SHA256 (FreeBSD-13.2-RC3-powerpc-powerpc64le-disc1.iso) = 9e84e1f3eaee455ca01f5fc211b812f8a4a61d90feb7b32067161f0322aa7fe6 SHA256 (FreeBSD-13.2-RC3-powerpc-powerpc64le-disc1.iso.xz) = c1a57afe6ef585d69fcd4df58701d03f2eac31fbc70aa7d0fdcd80fb71ec1269 SHA256 (FreeBSD-13.2-RC3-powerpc-powerpc64le-dvd1.iso) = c94355898898980c40ead1709bd8d27aab3a88f32de48784bab48c6288fc430e SHA256 (FreeBSD-13.2-RC3-powerpc-powerpc64le-dvd1.iso.xz) = 783cc5c1bed5aaff8ff7a394befa5d2b40bdf4c39147ab4024c3664421e61c93 o 13.2-RC3 powerpcspe MPC85XXSPE: SHA512 (FreeBSD-13.2-RC3-powerpc-powerpcspe-bootonly.iso) = ecee3b08ce694bc44c73beadb92e5282c2909009d119a46619b7df9f67fab2b83286ef240a7d0b1b5ad4274fe4caf7e4f3abb90f7f67d59e9441350f19b3bb5e SHA512 (FreeBSD-13.2-RC3-powerpc-powerpcspe-bootonly.iso.xz) = aa1f20b84cfc8096989ad9fb0b5f264f207daa0711af36c3379a8ddd948588c84ae4e0b66c6830c205259a3dc209d54f0d508470d1d70bc6f3e849c7253156bd SHA512 (FreeBSD-13.2-RC3-powerpc-powerpcspe-disc1.iso) = 7039d954ffc404d94a8e174f1a597b952f6c9a44fbb4d95d582636cec4722db2b08b6214c8f8fd0b5e9d49afa5494468a1d9b1252b63bc1e78a45de12f20102f SHA512 (FreeBSD-13.2-RC3-powerpc-powerpcspe-disc1.iso.xz) = 90b1c82c82578dde8bd30d946e1a0f26e359e5efb11a8ec03f39cdef8e9d07989ba452e1e3421263def9979c536e828b6c182b3c0d081438f65fd421940ecb7f SHA512 (FreeBSD-13.2-RC3-powerpc-powerpcspe-dvd1.iso) = 1518c92dd9d41791aad2de519a0bd46e6b852fb54ee76b4c93d27024e23da2ba4d48819b6710fc55c93a6fd496957bda49695d4ac205185db8f03980149df4cf SHA512 (FreeBSD-13.2-RC3-powerpc-powerpcspe-dvd1.iso.xz) = c1c00de21df473a63cd3491600ed3b634793a35a654311c47afb0ddcdf378d326cc2ea4f8c4c226beb6c7defc7a513478d5d8c5f2c9b2848ad7bc6b096f0ca65 SHA256 (FreeBSD-13.2-RC3-powerpc-powerpcspe-bootonly.iso) = f7e6fb82dc032e0b5aa0cf772b4ec1d2003b6e50b9f940a3c10a875247cd2b49 SHA256 (FreeBSD-13.2-RC3-powerpc-powerpcspe-bootonly.iso.xz) = 8642dd3c5509252ea8078925c5dc61faab11c1861ddb30d1ef0ce73631d01da2 SHA256 (FreeBSD-13.2-RC3-powerpc-powerpcspe-disc1.iso) = 2198d31492d71c0e4bb197822cadc55e9a4f45ad0781e792b558ca8a7e59218a SHA256 (FreeBSD-13.2-RC3-powerpc-powerpcspe-disc1.iso.xz) = b6c1ea4fb9397b15c43091f5a5a906cd33d1c73a1e8098ed53e315b4c75e239c SHA256 (FreeBSD-13.2-RC3-powerpc-powerpcspe-dvd1.iso) = 3c797050b25c937a3108d48ecfd42f7558e41e55609d55c3c999e4237916764c SHA256 (FreeBSD-13.2-RC3-powerpc-powerpcspe-dvd1.iso.xz) = dda9749b45b763d1d60dca89ab60a592d0daa980e9d6f27966b8a93436714f89 o 13.2-RC3 armv6 RPI-B: SHA512 (FreeBSD-13.2-RC3-arm-armv6-RPI-B.img.xz) = 850a5072b495ec219f7eecdc51b39c698c7842befefa6b5e7e6307d91f4f76dd2a60c5634b211235c8d2cbc3b7a9de022c39a332ab1d8aff4f52e57945a21eb6 SHA256 (FreeBSD-13.2-RC3-arm-armv6-RPI-B.img.xz) = a3e3e108128d52cc4040ce77028f824ca012739d0b5ce73e9c5a61188450b6f9 o 13.2-RC3 armv7 GENERICSD: SHA512 (FreeBSD-13.2-RC3-arm-armv7-GENERICSD.img.xz) = b5c51bb6e61f1ad9a4b9286fcafc3a90bb84d4c440a01b5e2331569ad1049f7e94524cf116cbaf209227bc7a97253052ca9dd1269a47edb882bc684228b51abf SHA256 (FreeBSD-13.2-RC3-arm-armv7-GENERICSD.img.xz) = b98929a071613029e61ba36c1cd3c7c9f4d023deb85f4c0fc9c44e22c1ac04e1 o 13.2-RC3 aarch64 GENERIC: SHA512 (FreeBSD-13.2-RC3-arm64-aarch64-bootonly.iso) = e8d59a81b3465f7d466d763ff527e116af978997d9dc7181df133469f32883ff2964bf87d55a30245302a2c1c0086bac72bffb37addaba95e39f5936d409a24a SHA512 (FreeBSD-13.2-RC3-arm64-aarch64-bootonly.iso.xz) = 2fd06a40946274366d9ef831fe205659087b75719346481b4b40ba7c2529821d6f28f35c70523ac3a99d87a6c00d7c2047ebf6cd564750ebbcdb9ef8a7fabc16 SHA512 (FreeBSD-13.2-RC3-arm64-aarch64-disc1.iso) = 40a56eb17993cb9355c96e7f5d02396947ac5208e474b21369ec27024f923f4ed8aab68f3f8d897492bd00708381b04a6c8d92ead175065456827d0ed264f4ff SHA512 (FreeBSD-13.2-RC3-arm64-aarch64-disc1.iso.xz) = 2ebf1c3016fcfa2de504efe0b8a9b1a8c7dd45fd96b1cb6eaa96a9ae209cb1062cca69b10fa75bb68dddae8962b69fc930bd19d3c776013b48a1dcc385c3a07c SHA512 (FreeBSD-13.2-RC3-arm64-aarch64-dvd1.iso) = 083019d90b942a2d6dc6a362594c27f02e6fa9f73ab62ad6b4ad6decdeb20d74922af78a16dfb4e4408123237102f39c2d31862598ca50b4e3ed39dde379b461 SHA512 (FreeBSD-13.2-RC3-arm64-aarch64-dvd1.iso.xz) = 22de2b02d223009a4209a574244c81ed0fb050b19a5debde2c7075fb915925da854775921a0782f3764ee744fec292ac6cf679a47bbb1244ca0c28b65c2b0f3e SHA512 (FreeBSD-13.2-RC3-arm64-aarch64-memstick.img) = e4d2c9031b07236c3fb0cfc7dc8e7546f48581c7cce25d094f4078b07d276e8fc29c5426aa59a4125ab87e9711928bb80cb0fb573fd61d8eec761851baa37944 SHA512 (FreeBSD-13.2-RC3-arm64-aarch64-memstick.img.xz) = 60a5771632b8fb33a3e0f906d742e82f00c2bb0f5f64dc0625e22708fcb10183f4231d73c6dcc37371c36e680c0e503d4c58dbcf821a5bead14afd3a704dfaab SHA512 (FreeBSD-13.2-RC3-arm64-aarch64-mini-memstick.img) = 792c649fee0f726d370aca18c843a6f1a3a0d9b2fb194bf0c6f41ea7e220a3581b6f169869b8e9af611ea0e5178719b735dd69a093e75022f526520de607926b SHA512 (FreeBSD-13.2-RC3-arm64-aarch64-mini-memstick.img.xz) = 3c4d4bdbb4b889c5fe36b872042531cdd4d6c12b55b04b0d065fe414ba0f4ede130a4f5b284e74a33ce553849498b0d55ba859a0452c45c3d6164aa0ae487fda SHA256 (FreeBSD-13.2-RC3-arm64-aarch64-bootonly.iso) = 594cdca8660d070e90b7b51350bdcde27ae5127352eb011da76e0d016a752667 SHA256 (FreeBSD-13.2-RC3-arm64-aarch64-bootonly.iso.xz) = 26e4f00f5cb9f730ba6272415521b2394b13fd38af41682270dc18a36cf04227 SHA256 (FreeBSD-13.2-RC3-arm64-aarch64-disc1.iso) = c4af09ac8ee22404c5f556c7bcfd5fbb9e0fa2361685d03f1c6581a781b115e3 SHA256 (FreeBSD-13.2-RC3-arm64-aarch64-disc1.iso.xz) = 2e09db9a3232c36aca60e57ed6fb98ca71d31b06436190c05e561ed2deac1883 SHA256 (FreeBSD-13.2-RC3-arm64-aarch64-dvd1.iso) = d066a319961b28873d26c403fc7d28cbfd34450a06c9e31f595f5452bd79f6b6 SHA256 (FreeBSD-13.2-RC3-arm64-aarch64-dvd1.iso.xz) = 46a12797e0d36127860b0b7d257734d369081f14a0bd70581c345d7c9cec7520 SHA256 (FreeBSD-13.2-RC3-arm64-aarch64-memstick.img) = cbf18a0f1e754388a839020d1bf26e1f50b9345c0aa02eb652f2f0a920634ccf SHA256 (FreeBSD-13.2-RC3-arm64-aarch64-memstick.img.xz) = 1154574d4f764aac8826efe8c3f08f9f846665976995e9331e98cce05c7ddeab SHA256 (FreeBSD-13.2-RC3-arm64-aarch64-mini-memstick.img) = 28349a1b9427432a2b5fbb28cd3b242ac79cd63fd1317fb40d5bd0614e9dfd22 SHA256 (FreeBSD-13.2-RC3-arm64-aarch64-mini-memstick.img.xz) = 5600c5d64d2d18c1ef31a5bcab4bb21f1447e9e9d8dd2de251f5cef2709b1bdd o 13.2-RC3 aarch64 RPI: SHA512 (FreeBSD-13.2-RC3-arm64-aarch64-RPI.img.xz) = 09e721067fb18d8f6bd83a2304bdf27c7c2c193844a86efed0d254fc54cbf3a6eec93a9d7332395a374076f25e0e596a08c122227f12fece2948e91d7a22e85b SHA256 (FreeBSD-13.2-RC3-arm64-aarch64-RPI.img.xz) = 01a4efa877f27ae4f39a00e371b78ccf34ead38b92443f544219a3d096af847a o 13.2-RC3 aarch64 PINE64: SHA512 (FreeBSD-13.2-RC3-arm64-aarch64-PINE64.img.xz) = 55cade7a6113b528fc2abed30c7651355ab0cb0d825bcb493f37ce074df2d51b40353fcf7b45232893378af82b3394c75a7b6a53c474b41858ca39fa2adf2a65 SHA256 (FreeBSD-13.2-RC3-arm64-aarch64-PINE64.img.xz) = 10706d0f1222b5fe6ca598c8afce66b934f5e6c2e42950eacd13e06a14fc3d4b o 13.2-RC3 aarch64 PINE64-LTS: SHA512 (FreeBSD-13.2-RC3-arm64-aarch64-PINE64-LTS.img.xz) = f3275f20584e57fe26f7d8f857312a547d830c02e60c011541a3bc04eec5816d17628995aa7c8458b2156f8b999018c325fd7bae46bfc3de44df6256fab6cac5 SHA256 (FreeBSD-13.2-RC3-arm64-aarch64-PINE64-LTS.img.xz) = 04f0da8124c70d9ccf9817548b26fd79c349294c9fa854039a5076cd3e23b650 o 13.2-RC3 aarch64 PINEBOOK: SHA512 (FreeBSD-13.2-RC3-arm64-aarch64-PINEBOOK.img.xz) = ebcd9cfa7050f1648c504f5b733702216c43b17a60338d9513afbc8c9a5518059d7c5b8971dc605de6fc9c17a5222854ea7b71008eea1451d35d9cbadc349535 SHA256 (FreeBSD-13.2-RC3-arm64-aarch64-PINEBOOK.img.xz) = f5ff979bd79e8cea13909828637459d1c11cd3d8d17826ca1df8da3cea332336 o 13.2-RC3 aarch64 ROCK64: SHA512 (FreeBSD-13.2-RC3-arm64-aarch64-ROCK64.img.xz) = 7e8de7e9892ae16db5d9001b3bd64bb45733392cadd3add2cfcc5002b0e2be71458f24782906023de19bd96c5a42be69f18c07fa8c99b343b3b72ebae2784eaf SHA256 (FreeBSD-13.2-RC3-arm64-aarch64-ROCK64.img.xz) = 576129b1d787d471b92b6b3b477807281f5adf594acfd403224bbc29b19196dd o 13.2-RC3 aarch64 ROCKPRO64: SHA512 (FreeBSD-13.2-RC3-arm64-aarch64-ROCKPRO64.img.xz) = 348e8773bfa1e1c5d97adda7f0a4231ea6bfbe5252e4fa5c260298f738385d9a192c170cda1872b79276482247f78819f1f254c21f52b495996d36615544c35c SHA256 (FreeBSD-13.2-RC3-arm64-aarch64-ROCKPRO64.img.xz) = e2ff08ac99ea3e1559492ee084aa06d7d1c23ba03daec2c7e8e71c96c0f3e8c3 o 13.2-RC3 riscv64 GENERIC: SHA512 (FreeBSD-13.2-RC3-riscv-riscv64-bootonly.iso) = 868b2426d733b38e3a32c5b4fcdf85dc94f9f518b1498b0b699bcbe476dfb980fad7bc8da4761a09704300992c8013357b173d9d71ea3bc2cf83d6a433db44d0 SHA512 (FreeBSD-13.2-RC3-riscv-riscv64-bootonly.iso.xz) = e94096a2eaf3d833979cc5ddc4080b7fcb155c2338a2a5c6dc80fb1e903824fdaa365bd667ceced6a4f4eb579afe2abd102d1a4756a1059747ca22d0071a967e SHA512 (FreeBSD-13.2-RC3-riscv-riscv64-disc1.iso) = 4a2822bafaa4a2ed4a50fd94e6d8ee2c2d2b3227bafa5139277d34364b755be41e0f5e3432ff3f20f149cead8a78136f50759a130c20c160295fe0598b7a8de8 SHA512 (FreeBSD-13.2-RC3-riscv-riscv64-disc1.iso.xz) = 8187b1dc0d9e9ad5ca017d3f77924ecac9876661b3c5e40d2b9baab22d6cd15631465c980ce4caf41b6372704784a8a253ee2db6225514545f196c3ca522cf7c SHA512 (FreeBSD-13.2-RC3-riscv-riscv64-dvd1.iso) = 89d895507d8c2dc0b739c92fceeffb45dca1caaed37e5dccebf96fcf0e03f1393e1024717bf2bcf54cb75f99e64c9a6cbda027871e4129d79d6658b9f5bdda39 SHA512 (FreeBSD-13.2-RC3-riscv-riscv64-dvd1.iso.xz) = 227c04c2fab6967668aa58f6286003fee071181005c082af3ce39611d320d24a723f11c0a7a4455d8ed898fd77b3c5255962076d0aa33682b0082a4dc65bb292 SHA512 (FreeBSD-13.2-RC3-riscv-riscv64-memstick.img) = 126a6575004e746946f44a23b7133bc7340c5fa898d15feaea1ac5ccf7a0309963961c660058fa77247b57f902a26e33031c4c54ddfd1b7650f8fd2a04a0899a SHA512 (FreeBSD-13.2-RC3-riscv-riscv64-memstick.img.xz) = d3bd78e5c0322315b990d38ab18133b09d57e0be219a8748a6702bf8cf62786924c82b44fa4b2227eff01b955cc2fd5815e4f215df8c35b2878208b513f03b5d SHA512 (FreeBSD-13.2-RC3-riscv-riscv64-mini-memstick.img) = ff0fcebf1f2f9ff2e16cda2fbffbf90c7c5a784132a42a13200560355d3c5001788ce0a0e710beadee231ac852ac9afbe93919fd253442e26149580224d2a6b7 SHA512 (FreeBSD-13.2-RC3-riscv-riscv64-mini-memstick.img.xz) = 67e070ea12f274915cf6899e62f2703841a777d9fd4671305617dbb662807c8b1246a744cfc7fc2d0f19aeb4235b26a2dfafd40a63b6454eb773b41507dd8d72 SHA256 (FreeBSD-13.2-RC3-riscv-riscv64-bootonly.iso) = e98842947a97860b6a85bfe4279f7b193b024c10ed063448a5c2b54c60df76b2 SHA256 (FreeBSD-13.2-RC3-riscv-riscv64-bootonly.iso.xz) = 5f12fa3b715654e8a65edc12ebc636b685ff216a16a3014ffd5ee200e2896b90 SHA256 (FreeBSD-13.2-RC3-riscv-riscv64-disc1.iso) = c28b0924617f49f68875988a7f114fc7029c4fc1c9ff3a6801569f8f6e29f21d SHA256 (FreeBSD-13.2-RC3-riscv-riscv64-disc1.iso.xz) = 8e435fe862e1a4676e3c92811fef72fbebbdb1151db25c9511031d7ed08fd910 SHA256 (FreeBSD-13.2-RC3-riscv-riscv64-dvd1.iso) = 97bc007002721705f1f9c6e94a186c0c6a0c26f743f443759e80ac4d63b6050d SHA256 (FreeBSD-13.2-RC3-riscv-riscv64-dvd1.iso.xz) = c0de213b062029e504151333afde1038493adc8965836c3fd289c1756abce6b7 SHA256 (FreeBSD-13.2-RC3-riscv-riscv64-memstick.img) = 20f1b2ea77c56eff2a6ce41f305579f3f34d50e910ccfe80bfcac88dd132c477 SHA256 (FreeBSD-13.2-RC3-riscv-riscv64-memstick.img.xz) = afbc37e5ce3d8975656790aac6ce562b2c1dc1621d4d5a35e59f5e70fdd2d91b SHA256 (FreeBSD-13.2-RC3-riscv-riscv64-mini-memstick.img) = fa9cd5b786f92bbf88280fe2265859f0acf3bdc5ba591fb3a0960f63fd74309b SHA256 (FreeBSD-13.2-RC3-riscv-riscv64-mini-memstick.img.xz) = 5903ba6d4e5ea4022b1f9c05a0d8d349b0c8f6ebe3bb18854fcff0b660654d40 o 13.2-RC3 riscv64 GENERICSD: SHA512 (FreeBSD-13.2-RC3-riscv-riscv64-GENERICSD.img.xz) = 384c536bbf295a9ace89891b8e7f7d0e075a4b0cf1869a32190159754b303c4984cbdf9fe1906dae7fa72e2b28e37d0d38dac984fff811cd201dd8a90b9c249d SHA256 (FreeBSD-13.2-RC3-riscv-riscv64-GENERICSD.img.xz) = c7d4f6889fff14d2dc6758bde7cea323addca622efce4e0ed3f0f19021c2804a == VM IMAGE CHECKSUMS == o 13.2-RC3 amd64: SHA512 (FreeBSD-13.2-RC3-amd64.qcow2.xz) = 39eb46f0f26aa07601088ba80242815eaadb594014cc4657330773d48777ef8e4b989cdb854d46b481ec84c701fc2d36a7fde823b51833a45fae9d5025ad6310 SHA512 (FreeBSD-13.2-RC3-amd64.raw.xz) = fee50d9b2ce9b18fbf2884f8f6e86c7c6b72b35414a91559550f60151b8af1638e9733ca5a0f78e9d8be4bbb2bb92b851f8163326d9c50f0c8d01f2bcdf17b75 SHA512 (FreeBSD-13.2-RC3-amd64.vhd.xz) = 1ec5a4469ccecbbe98c6ffd076f863dee607e24fb172eac05a0f9502802522b3758a230cb4af6183b43782e077f896d77b81ccb3252ea310bdf43af8cc858791 SHA512 (FreeBSD-13.2-RC3-amd64.vmdk.xz) = 70ab6410ca9c49b1f21cf23f54572adf13132138d13fb5a100f0d9982b38d9bcc9422d3d7f6e41d5cc01819e37f1ba0fabcf7bcd6e82e9407b1918d95b8b732d SHA256 (FreeBSD-13.2-RC3-amd64.qcow2.xz) = 5e88203fa5fcb9fed17be0100505eb4fa46c890df12f6178f7104e78d0020d1f SHA256 (FreeBSD-13.2-RC3-amd64.raw.xz) = bd50c1913165107b393d7c622d803212dfc11c8146d3bdc1fad94370c00bfeae SHA256 (FreeBSD-13.2-RC3-amd64.vhd.xz) = f1359cc8b7a8e09d8b6964b4adb131ff6a3293582d8720ef92dfcaa881cfde95 SHA256 (FreeBSD-13.2-RC3-amd64.vmdk.xz) = 2406ad96c53d3b437f132ad30069c2ce14895fcda4c9071ab2bc3baceebca74b o 13.2-RC3 i386: SHA512 (FreeBSD-13.2-RC3-i386.qcow2.xz) = a39a2fe1589e4c66acd78bc59dbc88588046afade4c3c0bf4552bbf893bd8bc5cf24790e66885d138a0c1ac360b3c86441d221a6f7a054e33cc9915fab76b4a1 SHA512 (FreeBSD-13.2-RC3-i386.raw.xz) = 58f2eb7f466e639a56b1eb226e2f66730826ef51ebe90ec52d303577534540d1f8627fa5f218b6274660caf869ac6e8e444219bf796a3d802b90988cd0bfc593 SHA512 (FreeBSD-13.2-RC3-i386.vhd.xz) = c82c3a3709958f47dd4b0bc2f2e8d0761f9403418f9539511b4168eb0030cf61753787d70b9bd4ffbf437a7da6ff2f19a20859960b7be87d6d5a99a096ed60e6 SHA512 (FreeBSD-13.2-RC3-i386.vmdk.xz) = 32ae55bc032d30162a22aeb329e927ec610c6e4b8162313f105402bc06816cf502825dee6a9d28ab07657b544c2cd0dc2abd92d5aefb685d42bd86f103e5fccd SHA256 (FreeBSD-13.2-RC3-i386.qcow2.xz) = eee1f665ae353abb84579afe521112ace5f93bf301e2050c1e2558f130a6b43d SHA256 (FreeBSD-13.2-RC3-i386.raw.xz) = 794d43967310187aa45b7a3dbd10ed6626f6bd2cd2803f52def5bbaab7937574 SHA256 (FreeBSD-13.2-RC3-i386.vhd.xz) = 2e4d72f1d0d02b7fc41e398bc0b0eb7388e873a0e748d6ec9f598b8ccdb26cea SHA256 (FreeBSD-13.2-RC3-i386.vmdk.xz) = 035f786b40014c1b83b508168cd0717a4cdfa296bc2cf936ad1f02794a3fdc13 o 13.2-RC3 aarch64: SHA512 (FreeBSD-13.2-RC3-arm64-aarch64.qcow2.xz) = 5f189436e8382f4bbc8560a32718f41b32245b90fdf795b6440edf989860554dc3b767b1656bccb3b34e2056a230ca59993abe0b8f6c2f1aa183226b9ea6309d SHA512 (FreeBSD-13.2-RC3-arm64-aarch64.raw.xz) = 3941caf3f48cfd9cfc48bf43416ca89fb720a61458a1ad79b81d094cbd100e501e31231ad9b56fb08b20e6f3dc4baebdecf85dcc3347bbe12d86b7986a5f1045 SHA512 (FreeBSD-13.2-RC3-arm64-aarch64.vhd.xz) = 94d102151d285d6738db195dfe6825f0e39afa8a50ded5c3465280fcc0aa6d796454d6fdb9eeba71c7104f477a0ff1d1ce4b32fe816bae493f9a0f1174fa7d3b SHA512 (FreeBSD-13.2-RC3-arm64-aarch64.vmdk.xz) = 6ed333aac59a3876d1e62fcdd4b251fbcaf6db4c4f0ecdd977e7af095a57d2aa6fb2a456f5a28fd58777d53a142a673a8770b41780df33a76ac877cf0e36926c SHA256 (FreeBSD-13.2-RC3-arm64-aarch64.qcow2.xz) = 27a0fdb13ee39bb606098c0ca6640e1d4586fc8c4ae442cf484eab1189ad5eae SHA256 (FreeBSD-13.2-RC3-arm64-aarch64.raw.xz) = 8bc000ce6e7c06409836c25d8fcee9e8c6010140f1667db769cb5c40d5b7a569 SHA256 (FreeBSD-13.2-RC3-arm64-aarch64.vhd.xz) = 81df38ed74bd5c8980476a00393e19bcb8b6d799c62acc0d775b73ac442a497c SHA256 (FreeBSD-13.2-RC3-arm64-aarch64.vmdk.xz) = ea061d9bd3bd25b3c07126bc5e2e785ddfd9ce93ffde860fb4f39a9c154ff31f o 13.2-RC3 riscv64: SHA512 (FreeBSD-13.2-RC3-riscv-riscv64.qcow2.xz) = d8f46f850577b9099bcc1c928c0aece12f8345dd0792f4d236287c01a6b1c52e1c88978a7626f75c46075995e137e101dc269ff6796c007c21d1de78142738a1 SHA512 (FreeBSD-13.2-RC3-riscv-riscv64.raw.xz) = 746dc066fc97b2e031bd2f0587f42db9ddc999fb488cc00feefc637ff0367990b9e8b21dec22cd484c634f7834678773e38777007c488e43137e7b48a7bad5ae SHA512 (FreeBSD-13.2-RC3-riscv-riscv64.vhd.xz) = 26743cf2283a35868a4ebc1ba93f05b244f35da91bb6c2c377f5e27b197b94335cb9ecace23b2d2bcb193c5e4bb3f9dfffe347f0485c9118b547487363bd6b8c SHA512 (FreeBSD-13.2-RC3-riscv-riscv64.vmdk.xz) = 81466d9bce461dfba84ea18afdebba8af29c26ddb8cc3499c2289fff17bfaf9fe6936bf7905a8aec7899c63e1cb4c06f54a3efb14a8606487fa51383715a8eb0 SHA256 (FreeBSD-13.2-RC3-riscv-riscv64.qcow2.xz) = c63ae7d1e0a28d8b50edf190a373b0246d7ed044205a06ed06772c6c084003d4 SHA256 (FreeBSD-13.2-RC3-riscv-riscv64.raw.xz) = f23a72f2781693ab68267ae3b2fb7994739aa694a58d803a9d0647e98c00828f SHA256 (FreeBSD-13.2-RC3-riscv-riscv64.vhd.xz) = 225378273b4a89cd3eae2b9bb9e192c75a1c7d66e18dd72145e5e24fa8a8fa87 SHA256 (FreeBSD-13.2-RC3-riscv-riscv64.vmdk.xz) = 13af5b6def69ca49ee853bf93363eef42739ba5876146028b9503fc5ff13154b Love FreeBSD? Support this and future releases with a donation to the FreeBSD Foundation! https://www.freebsdfoundation.org/donate/ -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTq9Iu6fMd6MP78Dak4zsppDGpqbgUCZBYjtQAKCRA4zsppDGpq bmZXAJ0QxhU9m1lPnblUgPDlKl2Zfg1i1gCgoIvN5d7uetovZK4T4Y10K1aBAV4= =mB3i -----END PGP SIGNATURE----- From nobody Sat Mar 18 22:01:58 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PfFN31Wh3z404rM for ; Sat, 18 Mar 2023 22:02:11 +0000 (UTC) (envelope-from nagy.attila@gmail.com) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PfFN26fvMz424q for ; Sat, 18 Mar 2023 22:02:10 +0000 (UTC) (envelope-from nagy.attila@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ot1-x333.google.com with SMTP id 14-20020a9d010e000000b0069f1287f557so444618otu.0 for ; Sat, 18 Mar 2023 15:02:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679176930; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7CvfRlQ2es0N/kBSeJTpJhu0WzoyyRJXpsejh6DMGmA=; b=USQgjXKBXJUd8Ly0wRGhuccTfm0tTJvAuorXfxIEN2+BsQF21mcY9iN0Jnmw9Dh6gw 74d+64++vsEUTDNaFU0Txcfg91vZvCdyoFv0PXMWu9m25JeJ/4BI9wbQy1QYJ+D9JGia 6zj13GBvlspRIg82HC6h9z+zumVpSBZuFfy+qVIpsRgQC1wLbUOShHzZlbzEhujKfO23 P84b/nMi+1nU36tEr71V+cv8RkQHoJJT16D/Xn50xtw6BzFNtj7ylpx9EeUoAvsMiA4t xtW76XEmkhVwZTE0TX+/SfmGyg4D4C6OH+ZjgzOJIzDL63p6AJcuYyVCaqPgwJF/f8L1 jf8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679176930; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7CvfRlQ2es0N/kBSeJTpJhu0WzoyyRJXpsejh6DMGmA=; b=eCJ8wSCJSoJa5wOYNQgNKLKP6HsL1AAZIaIO69CpGsKvOQhkK+GfXTK6hnZKAD3Fvf tj+6gZ3eAc+xyfjNKos6HDeYRJAinXOCOG+RIvZ6FFlr8de+4QFOUVW0UggnLjd2iMck q/1NHYhgsZlTnwKL4T062owTjhV1RYkeVtz3TXacOpI4NdiVWM5pCkcpi8J7l7ahC03a EEgGMlmQT4ROtWoaYFUfrRsZyTRixumACxEJjftiPby9pIx8ypNPnoUMtAB7jQZ677kX n97xcHUogiUZ4AF/8hPtt6OVEvDlqiHtSm0TLRBx+lRn5UX9hLMbIueQiewD1LxGiNwt CVNA== X-Gm-Message-State: AO0yUKVLcRDTiRh9P12SZRhh7Izx34Ui/KXLQBt7InhDtPNrxn6805nf sfIYZ91t55nA0Hsg/Tdood7NRB1xXQEGK7yZzJzglPsTr5Q= X-Google-Smtp-Source: AK7set8Ly6f07VKeq+hvIGsJwx1PCM4kcotIdk5jum7FcVfV2IKZf2zEXY+v18K6i6R5YiIkO+Mz96hbNBa8ZHbPi0I= X-Received: by 2002:a05:6830:1d90:b0:69f:4a8:d9b4 with SMTP id y16-20020a0568301d9000b0069f04a8d9b4mr965693oti.1.1679176929927; Sat, 18 Mar 2023 15:02:09 -0700 (PDT) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Attila Nagy Date: Sat, 18 Mar 2023 23:01:58 +0100 Message-ID: Subject: Re: Fwd: Kernel DHCP unpredictable/fails (PXE boot), userspace DHCP works just fine To: Eugene Grosbein Cc: freebsd-stable@freebsd.org Content-Type: multipart/alternative; boundary="0000000000006c683405f733d827" X-Rspamd-Queue-Id: 4PfFN26fvMz424q X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --0000000000006c683405f733d827 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Eugene Grosbein ezt =C3=ADrta (id=C5=91pont: 2023. m= =C3=A1rc. 18., Szo, 21:08): > > For me, it looks like timekeeping problem. Please show output of: > sysctl kern.timecounter kern.eventtimer > kern.timecounter.tsc_shift: 1 kern.timecounter.smp_tsc_adjust: 0 kern.timecounter.smp_tsc: 1 kern.timecounter.invariant_tsc: 1 kern.timecounter.fast_gettime: 1 kern.timecounter.tick: 1 kern.timecounter.choice: TSC-low(1000) ACPI-fast(900) HPET(950) i8254(0) dummy(-1000000) kern.timecounter.hardware: TSC-low kern.timecounter.alloweddeviation: 5 kern.timecounter.timehands_count: 2 kern.timecounter.stepwarnings: 0 kern.timecounter.tc.TSC-low.quality: 1000 kern.timecounter.tc.TSC-low.frequency: 1397374857 kern.timecounter.tc.TSC-low.counter: 3785476192 kern.timecounter.tc.TSC-low.mask: 4294967295 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.counter: 3688926057 kern.timecounter.tc.ACPI-fast.mask: 4294967295 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.counter: 180764627 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.counter: 745 kern.timecounter.tc.i8254.mask: 65535 kern.eventtimer.choice: LAPIC(600) i8254(100) kern.eventtimer.et.i8254.quality: 100 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.i8254.flags: 1 kern.eventtimer.et.LAPIC.quality: 600 kern.eventtimer.et.LAPIC.frequency: 49906250 kern.eventtimer.et.LAPIC.flags: 7 kern.eventtimer.periodic: 0 kern.eventtimer.timer: LAPIC kern.eventtimer.idletick: 0 kern.eventtimer.singlemul: 2 Indeed, it selects TSC-low. > After it booted to single- or multi-user mode. > Also, show verbose boot log (bootverbose). > https://gist.github.com/bra-fsn/bf07136ec7987db1a7e4d2e4d899e13b (with the original kernel/settings and after changing to HPET) Sometimes UEFI/BIOS SETUP has some settings for ACPI/HPET timers > (enable/disable), > did you try "playing" with such options? > Nope, I haven't thought about that. It's enabled (default setting). --0000000000006c683405f733d827 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Eugene Grosbein <eugen@gros= bein.net> ezt =C3=ADrta (id=C5=91pont: 2023. m=C3=A1rc. 18., Szo, 21= :08):

For me, it looks like timekeeping problem. Please show output of:
sysctl kern.timecounter kern.eventtimer
kern.timecount= er.tsc_shift: 1
kern.timecounter.smp_tsc_adjust: 0
kern.timecounter.s= mp_tsc: 1
kern.timecounter.invariant_tsc: 1
kern.timecounter.fast_get= time: 1
kern.timecounter.tick: 1
kern.timecounter.choice: TSC-low(100= 0) ACPI-fast(900) HPET(950) i8254(0) dummy(-1000000)
kern.timecounter.ha= rdware: TSC-low
kern.timecounter.alloweddeviation: 5
kern.timecounter= .timehands_count: 2
kern.timecounter.stepwarnings: 0
kern.timecounter= .tc.TSC-low.quality: 1000
kern.timecounter.tc.TSC-low.frequency: 1397374= 857
kern.timecounter.tc.TSC-low.counter: 3785476192
kern.timecounter.= tc.TSC-low.mask: 4294967295
kern.timecounter.tc.ACPI-fast.quality: 900kern.timecounter.tc.ACPI-fast.frequency: 3579545
kern.timecounter.tc.A= CPI-fast.counter: 3688926057
kern.timecounter.tc.ACPI-fast.mask: 4294967= 295
kern.timecounter.tc.HPET.quality: 950
kern.timecounter.tc.HPET.fr= equency: 14318180
kern.timecounter.tc.HPET.counter: 180764627
kern.ti= mecounter.tc.HPET.mask: 4294967295
kern.timecounter.tc.i8254.quality: 0<= br>kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i825= 4.counter: 745
kern.timecounter.tc.i8254.mask: 65535
kern.eventtimer.= choice: LAPIC(600) i8254(100)
kern.eventtimer.et.i8254.quality: 100
k= ern.eventtimer.et.i8254.frequency: 1193182
kern.eventtimer.et.i8254.flag= s: 1
kern.eventtimer.et.LAPIC.quality: 600
kern.eventtimer.et.LAPIC.f= requency: 49906250
kern.eventtimer.et.LAPIC.flags: 7
kern.eventtimer.= periodic: 0
kern.eventtimer.timer: LAPIC
kern.eventtimer.idletick: 0<= br>kern.eventtimer.singlemul: 2

Indeed, it sel= ects TSC-low.


After it booted to single- or multi-user mode.
Also, show verbose boot log (bootverbose).
(with= the original kernel/settings and after changing to HPET)

Sometimes UEFI/BIOS SETUP has some settings for ACPI/HPET timers (enable/di= sable),
did you try "playing" with such options?
Nop= e, I haven't thought about that.
It's enabled (default set= ting).
--0000000000006c683405f733d827-- From eugen@grosbein.net Sat Mar 18 23:16:37 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PfH256tWTz408GR for ; Sat, 18 Mar 2023 23:16:45 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PfH241cCMz47mB for ; Sat, 18 Mar 2023 23:16:44 +0000 (UTC) (envelope-from eugen@grosbein.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=grosbein.net (policy=none) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.17.1/8.17.1) with ESMTPS id 32INGdMi093374 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 18 Mar 2023 23:16:39 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: nagy.attila@gmail.com Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 32INGcUa044626 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Sun, 19 Mar 2023 06:16:38 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Fwd: Kernel DHCP unpredictable/fails (PXE boot), userspace DHCP works just fine To: Attila Nagy References: Cc: freebsd-stable@freebsd.org From: Eugene Grosbein Message-ID: <1634f44f-cb69-ee74-5300-4a8c414850f4@grosbein.net> Date: Sun, 19 Mar 2023 06:16:37 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.6 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on hz.grosbein.net X-Spamd-Result: default: False [-1.93 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_FAIL(1.00)[-all]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.93)[-0.934]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[grosbein.net : No valid SPF, No valid DKIM,none]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[eugen]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TAGGED_RCPT(0.00)[]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4PfH241cCMz47mB X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N 19.03.2023 5:01, Attila Nagy wrote: > Sometimes UEFI/BIOS SETUP has some settings for ACPI/HPET timers (enable/disable), > did you try "playing" with such options? > > Nope, I haven't thought about that. > It's enabled (default setting). Another possible reason: DHCP packets sent from DHCP client have 1-bit flag indicating if client wants to receive an answer as unicast or broadcast UDP packet. You could try hacking source to force broadcasts and see if that changes things. This NIC's driver has previous history of bad in-chip filtering packets in transit from the wire to the host (CPU). Broadcasts should get through without a problem, nevertheless. https://www.rfc-editor.org/rfc/rfc2131#section-4.1 > A client that cannot receive unicast IP datagrams until its protocol > software has been configured with an IP address SHOULD set the > BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or > DHCPREQUEST messages that client sends. The BROADCAST bit will > provide a hint to the DHCP server and BOOTP relay agent to broadcast > any messages to the client on the client's subnet.