Re: Building old systems
On 20/04/23 10:34, Brook Milligan wrote: I am trying to build an old kernel with build.sh on a recent (9.99.108) amd64 system. However, compiling nbmake fails immediately with errors like /usr/bin/ld: buf.o:(.bss+0x0): multiple definition of `debug_file'; arch.o:(.bss+0x0): first defined here Unless I am doing something silly, it clearly is not possible for a current system to build old tools and kernels at arbitrary points in time. What is the best strategy for building old kernels to, for example, bisect the code? This problem is only going to get worse as 9.x gets older and more people use newer hosts. It occurs to me that we could fix the nbmake source code and release it as 9.4. It won't fix things for people stuck on 9.[0-3], but it's better than a poke in the eye with a sharp stick. Cheers, Lloyd
daily CVS update output
Updating src tree: P src/distrib/utils/embedded/conf/armv7.conf U src/distrib/utils/embedded/files/boot.cfg P src/games/worms/worms.c P src/sys/arch/amd64/amd64/locore.S P src/sys/arch/i386/stand/efiboot/boot.c P src/sys/arch/i386/stand/efiboot/efiboot.c P src/sys/arch/i386/stand/efiboot/efiboot.h P src/sys/arch/i386/stand/efiboot/bootia32/efibootia32.c P src/sys/arch/i386/stand/efiboot/bootia32/startprog32.S P src/sys/arch/i386/stand/efiboot/bootx64/efibootx64.c P src/sys/arch/i386/stand/efiboot/bootx64/startprog64.S P src/sys/arch/i386/stand/lib/exec.c P src/sys/netinet/ip_output.c Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 47650526 Apr 20 03:03 ls-lRA.gz
Re: Building old systems
> On Apr 19, 2023, at 5:12 PM, Havard Eidnes wrote: > > -V HOST_CFLAGS="-O -fcommon" Indeed, this (without -O) works. The key is the HOST_CFLAGS variable; I was thinking of just CFLAGS at first. Thanks a lot. Cheers, Brook
Re: Building old systems
>> It might be better to use corresponding older tools to build older >> kernels. Modern gcc switched to -fno-common by default, so if you >> want to compile an older kernel that has multiple variable definitions >> you will need to arrange for -fcommon option to be used. > > Is there any way to do that with a current system and build.sh? > Neither setting it with -V or with env works. Just glancing at build.sh from -current here, but since this is while building nbmake, it's early in the process, and it's the host's toolchain you will be using by necessity. You don't say which variable you tried setting via -V (I'm wondering a little what it is with folks who won't be concrete...). It could be that you should try with -V HOST_CFLAGS="-O -fcommon" or possibly with a variant with -V HOST_LDFLAGS=-fcommon possibly as an addition, possibly as the only "extra" setting, since IIUC the -fcommon flag influences the behaviour during linking. Regards, - Håvard
Re: Building old systems
> On Apr 19, 2023, at 4:45 PM, Valery Ushakov wrote: > > It might be better to use corresponding older tools to build older > kernels. Modern gcc switched to -fno-common by default, so if you > want to compile an older kernel that has multiple variable definitions > you will need to arrange for -fcommon option to be used. Is there any way to do that with a current system and build.sh? Neither setting it with -V or with env works. Cheers, Brook
Re: Building old systems
On Wed, Apr 19, 2023 at 16:34:19 -0600, Brook Milligan wrote: > I am trying to build an old kernel with build.sh on a recent > (9.99.108) amd64 system. However, compiling nbmake fails > immediately with errors like > > /usr/bin/ld: buf.o:(.bss+0x0): multiple definition of `debug_file'; > arch.o:(.bss+0x0): first defined here > > Unless I am doing something silly, it clearly is not possible for a > current system to build old tools and kernels at arbitrary points in > time. > > What is the best strategy for building old kernels to, for example, > bisect the code? It might be better to use corresponding older tools to build older kernels. Modern gcc switched to -fno-common by default, so if you want to compile an older kernel that has multiple variable definitions you will need to arrange for -fcommon option to be used. -uwe
Building old systems
I am trying to build an old kernel with build.sh on a recent (9.99.108) amd64 system. However, compiling nbmake fails immediately with errors like /usr/bin/ld: buf.o:(.bss+0x0): multiple definition of `debug_file'; arch.o:(.bss+0x0): first defined here Unless I am doing something silly, it clearly is not possible for a current system to build old tools and kernels at arbitrary points in time. What is the best strategy for building old kernels to, for example, bisect the code? Cheers, Brook
Re: Total sysupgrade failure - 10.99.3 -> 10.99.3, 4 days difference
On Wed, 19 Apr 2023 at 14:47, Christos Zoulas wrote: > > In article > , > Chavdar Ivanov wrote: > >On Tue, 18 Apr 2023 at 22:16, Chavdar Ivanov wrote: > >> > >> Hi, ... > >> > > Yup, that was my fault. It was broken for a few hours and you caught it > during that time. If it makes you feel any better I got bitten the same > way, but thanks for /rescue :-) No problem; -current is actually rather stable for a system in constant development. It never came to my mind in the heat of the moment that I have /rescue... although I have used it in the past; I could have restored the base set and the kernel from my saved copy of 10.99.2. Anyway, the iso from releng was good and now I am rebuilding again. The hardest thing was to remember which key activated the boot menu choice of my system... > > christos > --
Re: Total sysupgrade failure - 10.99.3 -> 10.99.3, 4 days difference
In article , Chavdar Ivanov wrote: >On Tue, 18 Apr 2023 at 22:16, Chavdar Ivanov wrote: >> >> Hi, >> >> I do my builds with sysbuild and my upgrades with sysupgrade, many >> years now, basically since these two tools were made available. I >> haven't had much problems with them so far. >> >> My previous build was from 14th of April and worked just fine. Today I >> did another one, after completing a two day pkg-rolling-replace, and >> got: >> >> 100% >|*| >> 43015 KiB8.57 MiB/s00:00 ETA >> sysupgrade: I: Extracting comp into / >> /usr/lib/libc.so.12: Undefined symbol "_libc_init" (symnum = 3700) >> sysupgrade: I: Extracting games into / >> ... >> /usr/lib/libc.so.12: Undefined symbol "_libc_init" (symnum = 3700) >> sysupgrade: I: Extracting xserver into / >> /usr/lib/libc.so.12: Undefined symbol "_libc_init" (symnum = 3700) >> sysupgrade: I: Upgrading /etc interactively >> /bin/sh: Undefined symbol "optreset" (symnum = 16) >> sysupgrade: I: Performing postinstall checks >> /bin/sh: Undefined symbol "optreset" (symnum = 16) >> /bin/sh: Undefined symbol "optreset" (symnum = 16) >> sysupgrade: E: Some postinstall(8) checks have failed >> .. >> # sh >> >>sh: Undefined symbol "optreset" (symnum = 16) >> # /sbin/zpool status >> >> /sbin/zpool: Undefined symbol "suboptarg" (symnum = 17) >> # /sbin/reboot >> >> /lib/libutil.so.7: Undefined symbol "ifm_type_descriptions" (symnum = >> 6) >> Yup, that was my fault. It was broken for a few hours and you caught it during that time. If it makes you feel any better I got bitten the same way, but thanks for /rescue :-) christos
Re: Panic on yesterday's -current amd64
On Fri, 14 Apr 2023 at 10:09, Chavdar Ivanov wrote: > > Hi, > > I got: > .. > Apr 14 00:28:34 ymir syslogd[2516]: restart > [ 19830.9541169] panic: kernel diagnostic assertion "offset < > map->dm_mapsize" failed: file > "/home/sysbuild/src/sys/arch/x86/x86/bus_dma.c", line 826 bad offset > 0x0 >= 0x0 > [ 19830.9541169] cpu0: Begin traceback... > [ 19830.9541169] vpanic() at netbsd:vpanic+0x173 > [ 19830.9541169] kern_assert() at netbsd:kern_assert+0x4b > [ 19830.9541169] bus_dmamap_sync() at netbsd:bus_dmamap_sync+0x326 > [ 19830.9541169] rge_rxeof() at netbsd:rge_rxeof+0x179 > [ 19830.9541169] rge_intr() at netbsd:rge_intr+0x16f > [ 19830.9541169] intr_biglock_wrapper() at netbsd:intr_biglock_wrapper+0x41 > [ 19830.9541169] Xhandle_ioapic_edge21() at netbsd:Xhandle_ioapic_edge21+0x75 > [ 19830.9641164] --- interrupt --- > [ 19830.9641164] x86_mwait() at netbsd:x86_mwait+0xd > [ 19830.9641164] acpicpu_cstate_idle() at netbsd:acpicpu_cstate_idle+0x19a > [ 19830.9641164] idle_loop() at netbsd:idle_loop+0x14c > [ 19830.9641164] cpu0: End traceback... > > [ 19830.9641164] dumping to dev 168,2 (offset=8, size=4189743): > [ 19830.9641164] dump [ 1.000] Copyright (c) 1996, 1997, 1998, > 1999, 2000, 2001, 2002, 2003, > ... > > rge is a 2.5gb/s network adapter: > ... > rge0 at pci7 dev 0 function 0: Realtek Semiconductor 8125 > 10/100/1G/2.5G Ethernet (rev. 0x00) > rge0: interrupting at msix5 vec 0 > rge0: Ethernet address 00:8e:25:79:05:3c > ... > which should not have been busy at the time; the system was close to > completing a full build of aarch64 -current. > > Chavdar > > -- > I am getting the same when I installed the image from releng - panic: kernel diagnostic assertion "offset < map->dm_mapsize" failed: file "/usr/src/sys/arch/x86/x86/bus_dma.c", line 826 bad offset 0x0 >= 0x0 cpu0: Begin traceback... vpanic() at netbsd:vpanic+0x173 kern_assert() at netbsd:kern_assert+0x4b bus_dmamap_sync() at netbsd:bus_dmamap_sync+0x326 rge_rxeof() at netbsd:rge_rxeof+0x179 rge_intr() at netbsd:rge_intr+0x16f intr_biglock_wrapper() at netbsd:intr_biglock_wrapper+0x41 Xhandle_ioapic_edge21() at netbsd:Xhandle_ioapic_edge21+0x75 --- interrupt --- x86_mwait() at netbsd:x86_mwait+0xd acpicpu_cstate_idle() at netbsd:acpicpu_cstate_idle+0x19a idle_loop() at netbsd:idle_loop+0x14c cpu0: End traceback... dumping to dev 168,2 (offset=8, size=4189743): # uname -a NetBSD ymir.lorien.lan 10.99.3 NetBSD 10.99.3 (GENERIC) #0: Mon Apr 17 20:37:43 UTC 2023 mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64 so it does not appear to be a problem with my own builds only. Chavdar --
Re: Total sysupgrade failure - 10.99.3 -> 10.99.3, 4 days difference
On Tue, 18 Apr 2023 at 22:16, Chavdar Ivanov wrote: > > Hi, > > I do my builds with sysbuild and my upgrades with sysupgrade, many > years now, basically since these two tools were made available. I > haven't had much problems with them so far. > > My previous build was from 14th of April and worked just fine. Today I > did another one, after completing a two day pkg-rolling-replace, and > got: > > 100% > |*| > 43015 KiB8.57 MiB/s00:00 ETA > sysupgrade: I: Extracting comp into / > /usr/lib/libc.so.12: Undefined symbol "_libc_init" (symnum = 3700) > sysupgrade: I: Extracting games into / > ... > /usr/lib/libc.so.12: Undefined symbol "_libc_init" (symnum = 3700) > sysupgrade: I: Extracting xserver into / > /usr/lib/libc.so.12: Undefined symbol "_libc_init" (symnum = 3700) > sysupgrade: I: Upgrading /etc interactively > /bin/sh: Undefined symbol "optreset" (symnum = 16) > sysupgrade: I: Performing postinstall checks > /bin/sh: Undefined symbol "optreset" (symnum = 16) > /bin/sh: Undefined symbol "optreset" (symnum = 16) > sysupgrade: E: Some postinstall(8) checks have failed > .. > # sh > >sh: Undefined symbol "optreset" (symnum = 16) > # /sbin/zpool status > > /sbin/zpool: Undefined symbol "suboptarg" (symnum = 17) > # /sbin/reboot > > /lib/libutil.so.7: Undefined symbol "ifm_type_descriptions" (symnum = > 6) > > > and basically nothing works. This was my second build of the day, the > first one failed as the destination directory still contained the > remnants of lua 5.3, so I deleted them and repeated the build, with > iso, live and install system, which completed to end. > > > Any ideas? Or should I wipe the root disk and start afresh? > > Chavdar > > -- > I was able to easily recover using the image from releng and restoring only the kernel and base; I then further tested the bad installation and indeed, the cd boot also panics, so I might have caught the update in a wrong place. I guess I should first test the newly created ISO on a virtual machine before attempting sysupgrade... --
