Re: new "compat" sets have really made sets harder to manage.
On Thu, Apr 25, 2024 at 10:43:43PM -, Christos Zoulas wrote: > Thank you. I think there should be one compat set list, not one > for each machine_arch, and only have a ad or md machine specific > file for the parts that are different. I.e. there should be a > base32/mi and a base32/shl.mi containing most of the data. I'd say even those should not exist, as the files in base/* already have all the information we need, and it is important to keep tags like compatfile and compatdebug working like they used to before the set list changes. Martin
Re: tmux-direct entry only has 8 colors
On Thu, Feb 01, 2024 at 03:13:42PM +, RVP wrote: > This looks like a bug in NetBSD. Minimal reproducer: > > ``` > $ cat tit > tit|TermInfo Test, > # if the second number is >32767, it disappears! > use=num, use=max, > # putting the bigger one first makes "promotion" happen. > # use=max, use=num, > > max|any number > INT16_MAX, > colors#32768, > > num|any num < INT16_MAX, > num#111, > > $ tic -x tit This is fallout from usr.bin/tic.c: -- revision 1.33 date: 2020-03-27 16:11:57 +0100; author: christos; state: Exp; lines: +21 -17; commitid: 2Q6C4aNTDvrFf32C; As described in tech-userlevel: - Modify the writing code to only write entries in the new format for the terminal descriptions that require it. - Store new format entries as @v3 - Store old format entries with clamped values as for backwards compatibility - Lookup first @v3 and then if that is not found. - Don't create terminfo2 anymore; old programs keep working with clamped entries, and new programs be able to use the wide fields with using the original db file. -- especially this part of process_entry: if (tic->rtype == TERMINFO_RTYPE) return process_entry(, flags | TIC_COMPAT_V1); but I don't understand how it is supposed to work. Martin
Re: Can't build evbarm
On Sat, Jan 27, 2024 at 03:33:06PM +0700, Robert Elz wrote: > Now that Christos moved the function around, that declaration in the > header is just noise, and could be removed. Yes, that would be consistent then (but isn't it against the new style rules?) Martin
Re: Can't build evbarm
On Fri, Jan 26, 2024 at 09:09:30PM +0100, Adam wrote: > Simple and elegant. No hacks involved. Because the declaration in the relevant header is already there, and the order does not matter. But the #ifdef around the declaration needs to do the right thing. No need to move things around and its like this code is compiled everwhere else where it is used. Martin
Re: Can't build evbarm
On Sat, Jan 27, 2024 at 02:49:09AM +0700, Robert Elz wrote: > | It doesn't accept implicit function declarations. > > Yes, that's fine - you do not need to explain the issue, we all > understand that --- but there's supposed to be a prototype for > the function, it isn't intended to be implicit. Robert is right, the missing prototype is a bug in the makefiles. Adam: that your clang host compiler requires a newer C standard than C99 for building tools is another bug, you can probably add something like -std=c99 to HOST_CFLAGS / HOST_CXXFLAGS to fix that. Martin
Re: Can't build evbarm
On Fri, Jan 26, 2024 at 04:42:43PM +0100, Adam wrote: > % cat /tmp/pkgsrc/obj.aarch64/tools/compat/md2.d [..] > md2.o: > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/assert.h > md2.o: /dist/src/tools/compat/md2.h > md2.o: /dist/src/tools/compat/../../include/md2.h OK, so that wasn't it. Martin
Re: Can't build evbarm
On Fri, Jan 26, 2024 at 03:03:24AM +0700, Robert Elz wrote: > Date:Thu, 25 Jan 2024 20:12:36 +0100 > From:Adam > Message-ID: > > | Correct, _LIBC_INTERNAL is not defined for tools/compat. > > I wonder what the difference is between your environment, and > a standard build on a NetBSD host. My guess is a system header (md2.h?) being found unintendly (either only on macOS or in case of NetBSD having the "right" bits in the system header). Adam, can you check the *.d file in your objdir correspoding to the failing compiler invocation and show us what system headers are mentioned there? Martin
Re: Can't build evbarm
On Thu, Jan 25, 2024 at 10:52:30AM +0100, Adam wrote: > > All builds are working again, if this still fails for you there must be > > a local problem in your setup. > > > > Martin > > My setup is cross-building NetBSD on macOS. But that doesn't explain the issues you are seeing, no host tools should be involved in that part or am I missing something? Can you start the build from scratch (remove obj and destdir upfront) and provide a bit more build output before the failure, please? Martin
Re: Can't build evbarm
On Thu, Jan 25, 2024 at 09:20:50AM +0100, Adam wrote: > Reverting lib/libc/hash/md2/md2.c to v1.7 fixes the build. All builds are working again, if this still fails for you there must be a local problem in your setup. Martin
Re: Can't build evbarm
On Sat, Jan 20, 2024 at 05:19:25PM +0700, Robert Elz wrote: > Not that particular one I didn't, didn't know about that particular > breakage, will look at it now. Oops, mixed the breakage - but thanks for fixing it now :-) Martin
Re: Can't build evbarm
On Sat, Jan 20, 2024 at 10:50:27AM +0100, Adam wrote: > NetBSD-current fails to build on aarch64. > > Please, help :) As you can see here: https://releng.NetBSD.org/cgi-bin/builds.cgi it was not only evbarm/aarch64 affected, but all builds were broken. Robert fixed it in the meantime. Martin
Re: unlink_if_ordinary undefined...
On Sun, Dec 31, 2023 at 02:19:01PM +, Chavdar Ivanov wrote: > As far as I could tell, the only place where this is defined in the system is > in > > nm /usr/libexec/lto-wrapper | grep unlink_if > 0006a842 T unlink_if_ordinary > > No idea about this, my google-fu apparently is not so strong to > suggest anything useful. It is a GNU libiberty utility function and probably should not be a dynamic symbol anywhere (but staticaly linked from -liberty). Martin
Re: Router setup
On Mon, Dec 25, 2023 at 12:58:27PM -0500, xuser wrote: > Does any one know how to setup ip forwarding on netbsd? In /etc/sysctl.conf add: net.inet.ip.forwarding=1 net.inet6.ip6.forwarding=1 Martin
Re: Mediatek 7601U wireless chip porting
On Fri, Dec 22, 2023 at 08:06:40AM +0700, Robert Elz wrote: > Date:Thu, 21 Dec 2023 20:26:29 +0100 > From:=?ISO-8859-1?Q?Fekete_Zolt=E1n?= > Message-ID: <8bc45468-b662-4615-9c61-9981bd2b1...@minux.hu> > > | Using USB would have been a good starting point from a hardware > | availability perspective. > > It probably still could be, Martin's: > > | >There are lots of others out there though... > > was in reference to his earlier: > > | >for the USB chipsets where we currently have drivers. > > and indicates that there are more USB chipsets for which we > don't currently (not even in his, and others', unreleased yet version) > have drivers. There is probably a misunderstanding. The "list" I assumed we were talking about is at https://wiki.netbsd.org/wifi_driver_state_matrix/ There are no additional drivers popping up with the new stack by itself, besides (currently) two exceptions: the mtw one that started this discussion and the Intel linux one that Phil is working on. The Atheros chipset mentioned might fall into the AR10k group (I haven't checked details yet), where FreeBSD has a driver and we can (maybe) more or less easily adapt that driver with the new stack - but besides the (then) identical wifi API we have to deal with the different USB api (and ideally adapt to the usbwifi helper library). Martin
Re: Mediatek 7601U wireless chip porting
On Thu, Dec 21, 2023 at 04:59:36PM +0100, Fekete Zoltán wrote: > Is there any usb wifi chipset left on the list without a maintainer? I could > take one for my study if I could purchase hardware for that. Might be a > win-win. I think we have everything covered for the USB chipsets where we currently have drivers. There are lots of others out there though... Martin
Re: Mediatek 7601U wireless chip porting
On Thu, Dec 21, 2023 at 07:51:07AM +0100, Fekete Zoltán wrote: > Is anybody working on the same driver? > Has anybody tried it so far? > Is there any known hard limitation which blocks the porting to NetBSD? We have patches for that chipset for the new FreeBSD based wifi stack (and I have hardware). So it will likely be supported once we merge the new stack into -current. Martin
Re: How to raise iwm0?
On Sun, Nov 19, 2023 at 02:44:04PM +0100, Lizbeth Mutterhunt, Ph.D wrote: > As axen0 fails to connect, I want to try the wlan0, but it won?t be able to > make a wlan0. I can?t find the iwm module in kernel config. Does it be named > differently (I?ve got it from FreeBSD) or is just the hardware bad. I mean > it?s unsupported, because I killed a Chromebook to an EFI machine. It?s a > Gemini Lake. wlan* is the FreeBSD name for VAP interfaces, you don't have that in NetBSD (unless you are running the wifi renovation branch). Martin
Re: weird hangs in current (ghc, gnucash)
On Wed, Nov 01, 2023 at 10:49:12AM +0100, Thomas Klausner wrote: > Should we back out ad's changes until he has time to look at them? I just did that on behalf of core. Can you test if this solves your problem? Martin
Re: Can't cross-build on macOS: clock.h
On Fri, Oct 27, 2023 at 08:49:53AM +0200, Tobias Nygren wrote: > The header being used from the tools build was an unexpected surprise > but such reasons are why those ifdef guards exist. So I think it > just just be put back the way it was. The example came from > sys/atomic.h so it shouldn't be controversial. Yes, the C standard says the types we are looking for are defined in . Martin
Re: Automated report: NetBSD-current/i386 test failure
On Fri, Oct 13, 2023 at 05:11:47PM +0300, Andreas Gustafsson wrote: > Even though some of the test failures were reported as an excessive > number of separate emails and attributed to the wrong commit, the > failures themselves are real. Indeed, on my real hardware tests the jumps are impressive: https://netbsd.org/~martin/evbearmv7hf-atf/ goes from 12 failures on 2023-10-04 to 551 failures on 2023-10-12 https://netbsd.org/~martin/evbarm-atf/ goes from 70 failures on 2023-10-06 to 242 failures on 2023-10-12 I stopped running tests untill this is solved. Martin
Re: 10.99.9 amd64 panic
On Fri, Sep 29, 2023 at 09:52:42AM +, Chavdar Ivanov wrote: > Sep 29 01:53:13 ymir /netbsd: [ 228407.9443196] 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 [..] > Sep 29 01:53:13 ymir /netbsd: [ 228407.9543802] bus_dmamap_sync() at > netbsd:bus_dmamap_sync+0x326 > Sep 29 01:53:13 ymir /netbsd: [ 228407.9543802] rge_rxeof() at > netbsd:rge_rxeof+0x179 This is a bug in the rge(4) driver (unrelated to userland resource usage by the build), maybe a race triggered more easily when the system is under heavey load. Martin
Re: heartbeat panic by heavy traffic
On Fri, Sep 15, 2023 at 12:17:58PM +0900, Masanobu SAITOH wrote: > I think it would be good to change the default behavior from > panic to something others because GENERIC kernel enables HEARTBEAT. > by default. One of idea is to print warning message at sufficient intervals. I disagree. It is very important that we fix the underlying problem instead. Without hearbeat, this behaviour is still visible (but undiagnosable). Martin
Re: NetBSD 10.0 timeline and branch status
On Wed, Sep 13, 2023 at 11:07:48PM +0200, rudolf wrote: > FWIW, the list of DRM/KMS bugs (or the list of regressions since 9) is > missing PR #57268. I have just added it (to the DRM/KMS list). Martin
Re: NetBSD 10.0 timeline and branch status
On Mon, Sep 11, 2023 at 09:37:19AM +0200, Christian Groessler wrote: > Has port-evbarm/57551 been fixed? It's not running stable on my Raspberry Pi > 3. Unfortunately not yet. Martin
Re: NetBSD 10.0 timeline and branch status
On Sun, Sep 10, 2023 at 11:56:16AM -, Michael van Elst wrote: > I hope that the library changes are completed soon and that we can quickly > rebuild 2023Q2. AFAIK they are complete now. Martin
Re: NetBSD 10.0 timeline and branch status
On Sun, Sep 10, 2023 at 11:59:33AM +0200, Havard Eidnes wrote: > With the caveat that I've not verified this myself, I *think* > this depends on how you got to where you are at the moment. If > your current up-to-date 10.0 BETA using openssl 3 was initially > installed in the pre-openssl3 era and subsequently upgraded, the > old major versions of the shared libraries should still be > installed, and you should then in theory be able to use packages > from a binary package repository from the pre-openssl3 era. > > If, on the other hand you're talking about a fresh install of a > 10.0 BETA with openssl 3, you will not be able to use binary > packages built in the pre-openssl3 era. Basically: yes. But it is slightly more complex due to the initial openssl3 changes missing several shared library bumps (what pkgsrc would call a recursive revbump) for libs using one of the openssl or heimdahl libs. The fallout from that is cryptic and depends on the pkgs you use. Martin
Re: NetBSD 10.0 timeline and branch status
On Sun, Aug 20, 2023 at 02:07:25PM +0200, Martin Husemann wrote: > The tricky pullups are done (thanks to everyone who helped with it), and > package builds are going - so now it looks like we will be able to > switch from BETA to release candidate state soonish. > > See > > https://wiki.netbsd.org/releng/netbsd-10/ ... so, as ususual, things do not work out as smooth as we hoped. We had to do some shared library version bumps to the netbsd-10 branch as a consequence of the openssl pullup. All critical changes (and especially everything that would normally not be allowed for a release branch) have happend now. Unfortunately the additional shared library changes require another round of package rebuilds from scratch. Everyond building packages against netbsd-10: please start a new round from scratch. Sorry for the bumpy ride, I hope we are really there now. The above reference wiki page has been updated, schedule had to be adjusted slightly - but fortunately we found the issues quickly and only have a minor delay now. Thanks to everyone helping and testing, looking forward to a great 10.0 release! Martin
Re: possible NFS trouble
On Thu, Aug 24, 2023 at 09:22:13AM -0400, Greg Troxel wrote: > I ran a build, and it was erroring out with IO errors, and restarting > kept having errors. I suspected NFS concurrency, and reran it with > MAKE_JOBS=1 and it seems to have gone much better. What network adapters are involved? Does ifconfig show a serious amount of errors on either client or server? In my experience network driver bugs (or crappy hardware) are the most likely cause for NFS errors under high load. Martin
Re: builds fail w/undef ref in rump tests
On Sun, Aug 20, 2023 at 12:08:01PM +, Taylor R Campbell wrote: > > /r0/build/current/tools/amd64/bin/mips64el--netbsd-gcc > > --sysroot=/r0/build/current/DEST/evbmips64-el -Wl,--warn-shared-textrel > > -pie -shared-libgcc -o t_workqueue t_workqueue.o > > -Wl,-rpath-link,/r0/build/current/DEST/evbmips64-el/lib -L=/lib -lrumpvfs > > -lrumpvfs_nofifofs -lrump -lrumpuser -lpthread -lrump > > -L/r0/build/current/obj/mips64el/tests/rump/kernspace -lkernspace-latf-c > > /r0/build/current/tools/amd64/lib/gcc/mips64el--netbsd/10.5.0/../../../../mips64el--netbsd/bin/ld: > > t_workqueue.o: in function `atfu_workqueue_wait_pause_body': > > /x/current/src/tests/rump/rumpkern/t_workqueue.c:96: undefined reference to > > `rumptest_workqueue_wait_pause' > > That's odd, can you share this ident(1) output? > > cd $OBJDIR/tests/rump > ident kernspace/workqueue.o kernspace/libkernspace.a > > The definition has been there for a couple weeks now. Is this with an update build? I think I had to clean some test obj dirs after the latest changes to workqueue (and probably forgot to note it in UPDATING) Martin
NetBSD 10.0 timeline and branch status
Hey folks, after some unusual rough days for the netbsd-10 branch last week, we now have a state that is building fine again and all tests look as expected. We also made great progress on the icky DRM/KMS issues and overal stability. The tricky pullups are done (thanks to everyone who helped with it), and package builds are going - so now it looks like we will be able to switch from BETA to release candidate state soonish. See https://wiki.netbsd.org/releng/netbsd-10/ for the current list of bad bugs we are facing and the amount we dealt with already. Quite a lot of the DRM/KMS releated ones are in feedback state and have just been pinged - hopefully more of them will be closed soonish. Realistically this is close to as good as we will get the branch for a 10.0 release - so we are now looking at a release date very early in october. Martin
Re: i386 -current build failure
On Mon, Aug 14, 2023 at 09:23:37AM +0100, Chavdar Ivanov wrote: > Hi, > ERROR: nbctfmerge: Input file adiantum_selftest.o was partially built > from C sources, but no CTF data was present Can you reproduce it after removing that .o file (or the whole kernel build directory)? This symptom often shows up when one of the ctf tools died in an earlier run. Martin
Re: 10.0_BETA w/MKNSD=yes build fails after OpenSSL update
On Sat, Aug 12, 2023 at 06:41:14AM -0500, John D. Baker wrote: > The recent mega-pull-up of heimdal, bind, and OpenSSL 3.0 to > NetBSD-10.0_BETA: > > https://mail-index.netbsd.org/source-changes/2023/08/11/msg146890.html > > breaks builds which set MKNSD=YES. Should be fixed now. Martin
Re: Why can't a WireGuard interface route packets to itself?
On Mon, Jul 31, 2023 at 11:59:12PM +0200, logothesia wrote: > route(8) for a while, and all my attempts to coax it into inserting a > route to an interface in a different subnet than the gateway's so far > have failed. route add -iface should work. > > I expect that you will need to dig deeper into WireGuard. It's quite > > possible that this is a bug in WireGuard. Or you might just have something > > misconfigured. I don't know anything about WireGuard and only a little bit > > about PPPoE. > > Oh, I probably should have shared my config to begin with, my bad- here > goes: I can reproduce your issue on my wg(4) setup, it is not specific to your setup (and I was suprised by the behaviour too). Martin
Re: i386/openssl on amd64?
On Sun, Jul 30, 2023 at 03:18:32PM +0200, Jan-Hinrich Fessel wrote: > Oh yes: > build.sh command:./build.sh -U -j 2 -M /usr/obj -O /usr/obj -R > /usr/src/releasedir.NetBSD-10.99.6-amd64 -D > /usr/obj/destdir.NetBSD-10.99.6-amd64 -X /usr/xsrc -x -V MKCOMPAT=no release > install-image > > so, that leads to the question: is MKCOMPAT=no incompatible with building a > release? > Can that be fixed by just declaring the offending directories also as compat, > like: > /usr/lib/i386/openssl/engines base-crypto-usr > compat No, the lib/i386/openssl entries should just be removed. It is a bug normally hidden by equivalent lines generated from the generic compat lib handling. Martin
Re: i386/openssl on amd64?
On Sun, Jul 30, 2023 at 10:05:15AM +0200, Jan-Hinrich Fessel wrote: > Hej there, > > tried that on several fresh installations now with src grabbed via cvs > checkout. No one else seeing this? > I am somewhat lost in how to fix this apart from modifying the source list > (md.amd64 that would be) > > because i see there: > grep openssl lists/base/md.amd64 > ./usr/lib/i386/openssl base-crypto-usr > ./usr/lib/i386/openssl/engines base-crypto-usr > ./usr/lib/i386/openssl/engines/dasync.sobase-crypto-usr > compat,pic,openssl=30 > ./usr/lib/i386/openssl/engines/devcrypto.so base-crypto-usr > compat,pic,openssl=30 > ./usr/lib/i386/openssl/engines/loader_attic.so base-crypto-usr > compat,pic,openssl=30 > ./usr/lib/i386/openssl/engines/ossltest.so base-crypto-usr > compat,pic,openssl=30 > ./usr/lib/i386/openssl/engines/padlock.so base-crypto-usr > compat,pic,openssl=30 > ./usr/lib/i386/openssl/modules base-crypto-usr > ./usr/lib/i386/openssl/modules/legacy.sobase-crypto-usr > compat,pic,openssl=30 This seem to be leftovers that should be removed, all "compat" handling for OpenSSL is done generically now (see src/etc/mtree/NetBSD.dist.compat.in) Do you build with MKCOMPAT=no or something? Martin
Re: fdisk and alignment
On Sun, Jul 09, 2023 at 08:54:56PM +0100, David Brownlee wrote: > In practice I think it would be better not to penalise current use of > "small" (120GB SSD or 64GB or or CF/USB devices) for an edge case of > older hardware I am not sure what you see as penalty here. I think two factors made the original size decisions sensible back then: - for large disks the space lost to alignment does not matter - native block sizes > 512 byte only happened for larger disks initially Overall it would be better to enforce alignment as least as large as the native block size on *any* disk - but IIRC it is quite hard to find that value in all cases. Martin
Re: fdisk and alignment
On Sun, Jul 09, 2023 at 02:52:01PM +0100, David Brownlee wrote: > Does anyone know offhand what alignment Linux/FreeBSD/OpenBSD pick for > MBR formatting? You should avoid MBR :-) I don't know other systems defaults, but sysinst uses 4k for small disks and 2m for bigger, unless you switch to single sector mode where it takes your input verbatim. Martin
Re: Remove extra unlock in dm9000 driver
On Thu, Jul 06, 2023 at 10:10:37PM -0400, Lwazi Dube wrote: > ec->ec_flags |= ETHER_F_ALLMULTI; > -ETHER_UNLOCK(ec); I fixed it slightly different, thanks for catching it! Martin
Re: tweaks needed for 10 branch
On Sat, Jul 01, 2023 at 05:47:53PM -0400, Andrew Cagney wrote: > just fyi, had to tweak this when building; to be honest I'm a bit puzzled Yes, puzzling - it is not clear what standard apple tools default to after latest updates. The easy fix is to use HOST_CFLAGS= (or is it HOST_CXXFLAGS?) to force an older standard (for that tools build). Martin
Re: Mounting NetBSD partition on voidlinux
On Thu, Jun 22, 2023 at 03:47:27PM +0200, Sagar Acharya wrote: > I need something to repair this ufs2 partition. You did not answer the partitioning questions and it is hard to follow what you are doing and seeing. You can repair it easily with NetBSD's fsck(8). You can analyze it close with dumpfs(8). But first you really need to make sure you are accessing the correct partition on the SD card. Since it is a SD card it should be easy to make a full backup of it upfront - e.g. with dd, just in case. Martin
Re: Mounting NetBSD partition on voidlinux
On Wed, Jun 21, 2023 at 08:43:45PM +0200, Sagar Acharya wrote: > $ dkctl sd0 listwedges > /dev/rsd0: no wedges configured > > What are wedges? I get sectors which are 512 bytes long on physical disk. With "dkctl sd0 addwedge " you can use arbitrary "partitions" on disk sd0 without modifying its on-card partition information, so if you have a disk from a foreign system where NetBSD does not understand the partitioning scheme but you know the block offset/size of the file system you are interested in, you can create a "partition" at runtime and mount it (w/o changing the SD). They show up as /dev/dk* and they are automatically created e.g. for GPT partitions. Martin
Re: Mounting NetBSD partition on voidlinux
On Wed, Jun 21, 2023 at 08:39:45PM +0200, Sagar Acharya wrote: > I am on a NetBSD 10 install now after sabotaging my fully good alpine due to > constraints of sd card. The memory card from which I want to retrieve data is > mounted at sd0 > > $ fsck_ffs /dev/sd0a > /dev/rsd0a[1] Floating point exception (core dumped) fsck_ffs /dev/sd0a Are you sure sd0a is the correct partition? What does the partition table look like? gpt show -a sd0 disklabel -r sd0 should show usefull hints. Martin
Re: Mounting NetBSD partition on voidlinux
On Wed, Jun 21, 2023 at 02:20:25PM +0200, Sagar Acharya wrote: > Also, linux doesn't have fsck_ffs and debian had support for ufs in ufsutils > a long time ago. > > I highly recommend that for such cases you have a small standalone source > which can be built for correcting such errors which can perhaps have > disklabel, fsck_ffs, etc. A user can use it locally! Sources are not very helpful for emergency recovery. Depending on your device (I don't know anything about the Lime2) you have various easy "binary only" recovery methods: - most popular for all machines that can boot from USB: boot a USB install image - my personal favorite: boot an install kernel for your device from u-boot via network - boot an install kernel for your device from another SD card and swap the cards after the installer starts (better only do that on ramdisk based installers where / is on the memorydisk during installation) On machines with multiple possible boot sources it is easier (and you can prepare for disaster upfront by having a spare "known good" boot setup around). For us to be able to help you more, we need to know details about your setup. Like: what boot medium are you using, what are the other available options - and maybe you can get better support on the port-arm mailing list. Martin
Re: Mounting NetBSD partition on voidlinux
On Wed, Jun 21, 2023 at 12:12:35PM +0200, Sagar Acharya wrote: > My NetBSD system has gotten corrupted. How do I mount my NetBSD partition on > voidlinux? The typical recovery doesn't involve any other OS. If your kernel works and finds the / partition you can "boot -sa" and select /rescue/init as init replacement, then fix things from there. If that doesn't work, just boot a USB installer and escape to shell, then fix whatever needs fixing. Martin
Re: Redirecting 80 to 443
On Wed, Jun 07, 2023 at 08:55:46AM +1200, Lloyd Parkes wrote: > The httpd manual page describes how to invoke Lua scripts, but these > aren't CGI scripts. The manual page also describes how to invoke CGI > scripts of course. I would try a special document root for the port 80 instance and place (as only content) a .bzabsredirect symbolic link there. Martin --8<-- [/tmp] martin@big-apple > mkdir www-port-80 [/tmp] martin@big-apple > cd www-port-80/ [/tmp/www-port-80] martin@big-apple > ln -s "https://my.server.com/; .bzabsredirect [/tmp/www-port-80] martin@big-apple > ll -a total 12 drwxr-xr-x 2 martin wheel 24 Jun 7 08:06 ./ drwxrwxrwt 10 rootwheel 288 Jun 7 08:05 ../ lrwxr-xr-x 1 martin wheel 22 Jun 7 08:06 .bzabsredirect@ -> https://my.server.com/ [/tmp/www-port-80] martin@big-apple > cd .. [/tmp] martin@big-apple > /usr/libexec/httpd www-port-80/ get / got request ``get /'' from host to port redirecting https://my.server.com/ HTTP/0.9 301 Document Moved Document Moved Document Moved This document had moved https://my.server.com/;>here
Re: -current build failure
On Sun, Jun 04, 2023 at 02:40:16PM +0200, Thomas Klausner wrote: > Hi! > > I just tried updating my -current but the build failed: > > build.sh -j 32 -x -V MKDEBUG=yes -V MKDEBUGLIB=yes -V MKLLVM=yes -V > NOGCCERROR=yes -T /usr/obj/tools.gcc -m amd64 -O /usr/obj/src.amd64 -D > /usr/obj/amd64.gcc.20230604 -R /usr/obj/amd64.gcc.20230604.release > distribution > > --- support-modules --- > g++: error: unrecognized command-line option '-stdlib=libc++' > g++: error: unrecognized command-line option '-fmodules'; did you mean > '-fmoduleinfo'? > g++: error: unrecognized command-line option '-fcxx-modules' > g++: error: unrecognized command-line option > '-fmodules-cache-path=./module.cache' > > > Any ideas how to fix this? I couldn't even compile a amd64 GENERIC kernel w/o the attached patch - CC_WNO_ADDRESS_OF_PACKED_MEMBER is undefined in kernel builds (but that hack sounds like the wrong way to fix things). Luke, what would be the correct fix? Martin Index: Makefile.amd64 === RCS file: /cvsroot/src/sys/arch/amd64/conf/Makefile.amd64,v retrieving revision 1.86 diff -u -p -r1.86 Makefile.amd64 --- Makefile.amd64 6 Jan 2023 15:35:06 - 1.86 +++ Makefile.amd64 4 Jun 2023 13:49:07 - @@ -22,6 +22,7 @@ USETOOLS?=no NEED_OWN_INSTALL_TARGET?=no NOSANITIZER= .include +.include USE_SSP?= yes
Re: LLONG_MAX not available from c++
On Fri, Mar 31, 2023 at 03:30:56PM -, Michael van Elst wrote: > There is magic involved. You mean: there are bugs - bah :-/ Martin
Re: LLONG_MAX not available from c++
On Fri, Mar 31, 2023 at 02:27:17PM -, Michael van Elst wrote: > c++ also doesn't define __STDC_VERSION__ nor _ISOC99_SOURCE. It defines the former but not the latter: > c++ -dM -E - < /dev/null | fgrep __STDC_VERSION__ #define __STDC_VERSION__ 201710L > c++ -dM -E - < /dev/null | fgrep __ISO > (at least w/o special -std= options) Martin
Re: LLONG_MAX not available from c++
On Fri, Mar 31, 2023 at 02:10:46PM +0200, Thomas Klausner wrote: > g++ in -current doesn't get this symbol when you include limits.h > (which lua does, since this is still C code) because of (from > /usr/include/machine/limits.h): > > #if defined(_ISOC99_SOURCE) || (__STDC_VERSION__ - 0) >= 199901L || \ > defined(_NETBSD_SOURCE) > #define ULLONG_MAX 0xULL /* max unsigned long long */ > #define LLONG_MAX 0x7fffLL/* max signed long long */ Which options does it pass to g++ ? For me just invoking "g++" defines __STDC_VERSION__ as 201710L, so should get the symbol: > g++ -dM -E - < /dev/null | fgrep STDC #define __STDC_UTF_16__ 1 #define __STDC_VERSION__ 201710L #define __GNUC_STDC_INLINE__ 1 #define __STDC_UTF_32__ 1 #define __STDC__ 1 #define __STDC_HOSTED__ 1 Martin
Re: DNS name resolution not working in 10beta installer?
On Fri, Feb 24, 2023 at 06:22:50PM -0500, Tom Lane wrote: > So it doesn't seem to be a problem with DNS infrastructure, but the > installer doing something wrong. You should be able to test this again easily w/o doing a real installation and gather more information by using the Utility menu/Configure network option right after sysinst starts up. When it doesn't work, please ^Z sysinst and check ifconfig output and cat /etc/resolv.conf. Did you use dhcp auto configuration or entered the settings manualy? Martin
Re: GZIP warnings when building
On Thu, Feb 16, 2023 at 06:37:36AM +1300, Lloyd Parkes wrote:
> Oh, it's used to pass the compression level though pax to gzip. That's
> explain it. Maybe we should switch to --use-compress-program="nbgzip
> -LEVEL"???
The problem is that we only have ${TOOLDIR}/nbpax, but that invokes gunzip
via $PATH and there is no ${TOOLDIR}/gunzip.
So this causes a dependency on the host gunzip, which is why the problem
does not show up when building on NetBSD.
Martin
Re: GZIP warnings when building
On Thu, Feb 16, 2023 at 06:18:54AM +1300, Lloyd Parkes wrote: > I saw this too. I think the way we select the gzip compression level (using > the GZIP environment variable) is now deprecated for some reason. I have not seen it anywhere, but I see we set GZIP=-9n for pax -z in src/distrib/sets/maketars. Martin
Re: GZIP warnings when building
On Wed, Feb 15, 2023 at 03:09:37PM +0100, Christian Groessler wrote: > Hi, > > probably known and considered not important, but I wanted to mention that > I'm getting warnings like this when building a release: Sounds like a local problem - what is in your $GZIP (and why)? Martin
Re: How to build only one part of NetBSD system
On Thu, Jan 19, 2023 at 05:33:03AM +, Thomas Mueller wrote:
> >From /usr/src/UPDATING,
>
> Recent changes:
> ^^^
>
> 20230112:
> New binutils require an updated ld.elf_so. If you are doing
> (unsupported) in-place self builds (with the -E flag to build.sh),
> make sure to have installed latest ld.elf_so before you rebuild
> userland.
>
> So how do I build /usr/src/lbexec/ld.elf_so preliminary to rebuilding the
> whole NetBSD (current)?
If you are not using something like "build.sh -E -D /" you should ignore that
entry.
> I tried going into libexec/ld.elf_so and running "make install" but that
> didn't work or even come close.
It would be something like:
cd src/libexec/ld.elf_so
${TOOLDIR}/bin/nbmake-${arch} dependall
${TOOLDIR}/bin/nbmake-${arch} install
> I don't think I could have used build.sh for just this component.
Right.
> I had two failed builds of NetBSD-current (10.99.2) before looking more
> closely at /usr/src/UPDATING.
Failed builds how? If you are using "build.sh -u" you may need to manually
clean the object dir for all instances of "binutils" (depending on when
you did the last sucessful build).
A safe way is to completely remove the object dir and build everything from
scratch.
Martin
Re: failure to build guile 2.2.7 on current with current
On Fri, Jan 13, 2023 at 06:37:50PM +0100, Martin Husemann wrote: > On Fri, Jan 13, 2023 at 07:36:53PM +0100, Riccardo Mottola wrote: > > I don't think it updatedm today is the 13th, I'd expected today or > > yesterday.. how often does releng kick it out? I thought daily > > Usually about twice a day, but currently the build is broken so "latest" > does not update. For the record: you can check the state here: https://releng.netbsd.org/cgi-bin/builds.cgi I have a patch to fix the build that is pending review (already tested and seems to work for me), so we should be "green" again soonish. Martin
Re: failure to build guile 2.2.7 on current with current
On Fri, Jan 13, 2023 at 07:36:53PM +0100, Riccardo Mottola wrote: > I don't think it updatedm today is the 13th, I'd expected today or > yesterday.. how often does releng kick it out? I thought daily Usually about twice a day, but currently the build is broken so "latest" does not update. Martin
Re: failure to build guile 2.2.7 on current with current
On Fri, Jan 13, 2023 at 02:12:49PM +0100, Riccardo Mottola wrote: > I just upgraded to 10.99.2 via sysinst. I updated pkgsrc and started > rolling-replace. You need to update (at least /libexec/ld.elf_so). Martin
Re: Very recent NetBSD-current Xorg panic
On Sun, Jan 08, 2023 at 01:15:01PM +, Chavdar Ivanov wrote: > As far as I understand it, there was a change with the dynamic loader at > this time? Yes, and after the ld.elf_so change the default linker options were adjusted, which makes testing this now a bit tricky (you can't just downgrad ld.elf_so). Martin
Re: Very recent NetBSD-current Xorg panic
On Sun, Jan 08, 2023 at 11:28:18AM +, Chavdar Ivanov wrote: > This morning I upgraded the instance to my yesterday's build - as of > 07/01/2023. Now Xorg dumps core as follows: Can you show the output of readelf -l /usr/X11R7/lib/modules/dri/i965_dri.so for the new build? It probably has 4 LOAD sections now, while the old one only had 2. Martin
Re: Difference between i915drm and i915drmkms
Side note: we are collecting all bug reports for the new DRM/KMS that should be fixed before the 10.0 release here: https://wiki.netbsd.org/releng/netbsd-10/ If you know of any other PRs that should be listed there, please let me know. Martin
Re: binutils still failing on amd64
On Mon, Jan 02, 2023 at 12:17:11PM +1100, matthew green wrote: > oh yeah - this is only going to break r/o src tree builds, which is > also something i use as much as possible. Note that the official daily builds also use this (and have been failing since new binutils have been enabled for x86). Martin
Re: -current build failure?
On Fri, Dec 30, 2022 at 01:04:46PM +, Chavdar Ivanov wrote: > Hi, > > I am getting again a failure in binutils.old, after having cleaned four days > ago the entire obj: binutils.old is the wrong directory, your build should use binutils now. You need to clean the tools/binutils obj dir. Martin
Re: tools build failure
You may need to clean the binutils objdir, as the binutils vs. binutils.old switch happened recently. Martin
Re: 10.0 BETA: How to boot using UEFI or grub
On Sun, Dec 25, 2022 at 07:03:31PM +0530, Mayuresh wrote: > However the firmware shows only Ubuntu among UEFI options. Do I need to > copy some more files so that netbsd option shows up? IIRC you have to create a "boot option" in uefi vars and store it to use a non-default path for most UEFI implementations. Ubuntu apparently does that, and makes it point at the subdir. NetBSD currently does not do it, and uses the default boot path instead (EFI/boot/bootx64.efi). We really should set up the boot option too (so the UEFI shows a proper name for the OS), but it is not trivial, especially in the case you describe where the installer is booted via BIOS your are mostly lost and can't do it at all (setting boot options happens via EFI runtime services, so you must have booted via UEFI). Martin
Re: 10_BETA: Nice QOL improvements to the installer
On Thu, Dec 22, 2022 at 08:05:02AM +0530, Mayuresh wrote: > Ok. So, it appears the -bios image has become redundant now. Or hasn't it? No, there are BIOSes out there that don't work with the hybrid bootloader. Martin
Re: Branching for netbsd-10 next week
On Sat, Dec 17, 2022 at 01:41:18AM -0500, Tom Lane wrote: > but I suppose that just reflects a branch existing in the CVS repo. Yes, and also that pullup ticket queues for -10 exist. > I don't see any sign of the branch being supported at, say, > > https://nycdn.netbsd.org/pub/NetBSD-daily/ > http://releng.netbsd.org/cgi-bin/builds.cgi It is building right now (see the second url): Currently building tag: netbsd-10 started at Sat Dec 17 04:29:51 UTC 2022 18 passed so far and when that build is done it will appear in the daily site and there will be armbsd.org images for it. Martin
Re: Branching for netbsd-10 next week
On Thu, Dec 15, 2022 at 07:59:35PM +, Thomas Mueller wrote: > I will want to update my NetBSD installation from 9.99.82 from source > and am inclined toward 10.99.1 rather than 10.0_BETA. I use "cvs up > -dP -A" to update the source on base system and pkgsrc, currently am on > native X. As your current installation is in the "bad" time window, you will have to follow Chuck's guide to safely update: https://wiki.netbsd.org/features/UFS2ea/ But most likely you will decide to no not need EAs and the easy upgrade path is to stay with FFSv2 (i.e.: not run ufs2ea-flip, but only fsck). This is the path we expect most users to take. Martin
Re: /etc/protocols generation
On Thu, Dec 15, 2022 at 08:35:42PM -0500, Jan Schaumann wrote: > This, then would speak in favor of leaving the tools > in pkgsrc. Yes, and stop there. No point in automating more - just like the web files are generated by various tools from the meta-pkgs/netbsd-www pkg, the IANA-derived files can be created by whatever tools hidden in pkgsrc. Then for an update you do: - make sure you have the proper pkg(s) installed - download the latest versions and run the import tools on them - put the results in you source tree - do a full build to verify nothing broke and finaly either - install the resulting etc files on a test machine and run local ATF tests, or - do an Anita test run with the build results to verify there are no regressions. Licenses do not matter here, as long as the commited results are properly licensed. Martin
Re: Branching for netbsd-10 next week
Just to wrap up this thread: - branch will probably happen in the next ~10h - default file system for new installations will be FFSv2 I will update docs and extend the wiki page about FFS2ea to show how to switch later, and also provide installation instructions how to select FFSv2ea right during installation (trivial to do, but better we have something to be found for later searches). Thanks to all the input provided on this list and off list! Martin
Re: Branching for netbsd-10 next week
On Sat, Dec 10, 2022 at 03:28:14PM +0100, Reinoud Zandijk wrote: > related, I think we should really iron out all installation issues that > plagued NetBSD before and were scorned on say Slashdot i.e. provide easy > install/live images with a gui installed, with optional extra variants with > say a complete xfce4 one with FF etc. and provide complete installs like the > live CD running as option in sysinst. You are free to work on that any time, but we are not going to delay the branch nor the release for any of that. Instead of (or as first step towards) a xfce4 install image I would prefer to have signed binary packages, but it seems impossible to do with the current pkgsrc infrastructure: https://wiki.netbsd.org/projects/project/Make_signed_binary_pkgs_for_NetBSD_happen/ Martin
Re: Branching for netbsd-10 next week
On Fri, Dec 09, 2022 at 10:03:46AM +0100, Matthias Petermann wrote: > compatibility. However, if I understand correctly, this only affects new > installations? If I migrate an existing NetBSD 9 to 10, nothing changes in > the file system format. I.e. as long as I do not actively initite the > migration, I can always access it with NetBSD 9. Correct. No special action is needed if you never run any current kernel on it and file systems will remain plain FFSv2 (and have EAs deactivated). > How likely is it that I > will have to access the filesystem with NetBSD 9 after a new installation of > NetBSD 10? Not very, IMHO. And in the cases you want, there is a path to convert it. As Robert pointed out, you don't need to fiddle with the not-in-tree ufs2ea-flip tool, you can just use "fsck_ffs -c" from your -current (or netbsd-10) install. Martin
Branching for netbsd-10 next week
Hey folks, after the EA changes are in current now and all tests look good, we can finally move on and branch for netbsd-10. Proposed date is next wednsday. We have quite a few things to finish before the final release, but this gets things moving - and I hope it will not take more than three months to get the release out of the door. Before the branch one final issue needs to be decided, and I would like to solicit your feedback on this: With the new EA-enabled variant of FFSv2 (see https://wiki.netbsd.org/features/UFS2ea/ for details) we have the choice to use ACLs and EAs on FFS file systems - which makes them incompatible with all prior releases and other operating systems - or to forbid them. The installer offers upto three options for FFS file systems: - FFSv1, typically only used with bootloaders that did not get FFSv2 support yet or firmware that loads the kernel directly (examples: mac68k or shark). - FFSv2, compatible with older releases but not supporting EAs/ACLs. In read-only mode partly compatible with other operating systems. - FFSv2ea, with full support for EAs and ACLs, but incompatible with all prior NetBSD releases and all other operating systems (the file system superblock has a different magic number, so will be rejected by older code). Currently the installer defaults to creating FFSv2ea file systems for new installations, so if you do intend to share a partition with older NetBSD kernels, be sure to change the filesystem type. This will require a good description in the release notes, and probably more extensions to the wiki page pointed to above. Now the question: should the default install really use this new FFS type, or should it default to plain FFSv2? The change is trivial and from my PoV both choices have serious downsides: - unaware users may install FFSv2ea file systems and later find the need to access them from older NetBSD kernels. "Downgrading" them is quite easy using the ufs2ea-flip tool mentioned in the wiki page, but it is not "plug & play". - if FFSv2ea is not the default, most new installs will create non-EA enabled file systems and - the EAs will not get much testing - packets from pkgsrc (like samba) will continue to have the corresponding options disabled by default - users will have a hard time to find the conversion options later. It is hidden in fsck_ffs(8) and quite simple: after having made sure your bootloader is up to date, boot to single user and run something like: "fsck_ffs -c ea /" So, what should be the default FFS type for new installs in netbsd-10 ? Martin
Re: HEADS UP: UFS2 extended attribute changes will be committed tomorrow
On Mon, Nov 21, 2022 at 10:10:57PM -0800, Chuck Silvers wrote: > yes, there should be a way to tell sysinst to create UFS2ea rather than UFS2 > (or vice-versa if we make UFS2ea the default in sysinst). this was on my > list of outstanding issues but I think I was thinking that Martin would > take care of it (since he's been the one doing most of the sysinst changes > for a long time now). at any rate, either Martin or I will add this. I will add it soonish. Martin
Re: Finding memory bugs automatically
On Sun, Oct 02, 2022 at 12:28:41AM +0200, Roland Illig wrote: > Hi, > > Do any of the releng builds and tests run with MALLOC_CONF=junk:true? No. > If not, why isn't there such a mode, and is there an alternative memory > allocator that can find these kinds of bugs? Using COPTS -fsanitize=address is a good way to find memory bugs, but it turns off ASLR, only works on a few architectures and causes a quite heavy performance impact. Martin
Re: How to BIOS-boot from NVMe device?
On Wed, Sep 07, 2022 at 08:37:43PM -0700, Paul Goyette wrote: > On a positive front, the BIOS seems to now recognize the NVMe as > having a UEFI OS. Trying to boot it takes me down some new path > having to do with SecureBoot, and I don't have time for that now. There is typicaly a setting in the UEFI to just disable secureboot. Martin
Re: Bad symbols in Installer menu in USB Stick Kingston Elite G2
On Sat, Aug 27, 2022 at 07:58:51PM -0700, Paul Goyette wrote: > Looks to me like there's a string that is not null-terminated, thus > we see garbage following the string/label (serial number?) which > reads ``PMAPPAMP1234'' Yes, it is a bug in the ioctl code used in the sysinst installer to get the name of the disk - I'll have a look. Martin
Re: Checksum mismatch of -HEAD and -STABLE sets on nycdn
On Wed, Aug 03, 2022 at 11:21:40PM +, RVP wrote: > Obviously, (most of) the checksums fail: > > $ printf '%s\n' *.xz | fgrep -f- SHA512 | sha1 -c > (SHA512) base.tar.xz: FAILED I can reproduce this and will file an admin ticket. A good way to get more information is to use curl like this: curl -H "Fastly-Debug:1" -D /tmp/headers --output base.tar.xz https://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/latest/amd64/binary/sets/base.tar.xz and then check /tmp/headers for more detailed informations. Background: a CDN works like a multi level key/value cache, where the URL is the key. The "latest" directory in the build outputs is a symlink to the last full build for that branch (so whenever the build cluster completes uploading a build with 0 failures, see https://releng.netbsd.org/cgi-bin/builds.cgi, the "latest" symlink is switched over to that new build. This means: all URLs below that link are now stale, so the CDN is informed about this (and supposed to react with cache misses on next access to that URLs). Something there isn't working as designed. > See also this (possibly relevant) thread: > > https://mail-index.netbsd.org/netbsd-users/2022/07/31/msg028770.html I don't think this is related, it sounds like a plain fastly operations issue. Martin
Re: namespace pollution? clone()
On Mon, Aug 01, 2022 at 05:11:53PM +0200, Thomas Klausner wrote: > I don't understand why we expose __clone() in a public header at all, > but I understand your comments to result in the attached patch. It is used in tests: /tmp/build/2022.08.01.14.34.01-i386/src/tests/lib/libc/sys/t_clone.c:123:16: error: implicit declaration of function '__clone'; did you mean 'close'? [-Werror=implicit-function-declaration] 123 | switch (pid = __clone(clone_func, stack, |^~~ |close Not sure why your test build did not catch it. Martin
Re: namespace pollution? clone()
On Mon, Aug 01, 2022 at 03:57:19PM +0200, Thomas Klausner wrote: > The attached diff survived a complete amd64-current build. Ok to commit? Looks good to me. Martin
Re: namespace pollution? clone()
On Tue, Jul 26, 2022 at 03:46:14PM +0300, Valery Ushakov wrote: > On Linux clone(2) is declared only for _GNU_SOURCE, which explains why > linux doesn't run into the name clash. I gather we should follow > suit, as that's what the apps expect. Yes, that is the right thing to do here, especially as clone(2) does only exist as a portability helper for linux code. I think we could even pull that change up to -9. Martin
Re: FYI: new X server in -current, among other X things
I have a minor (but strange) issue with the new X setup. My Radeon amdgpu does not fully work yet (strange colours, some drawing artifacts, otherwise mostly ok), so I am using vesfb and wsfb_drv (but the same effect happens with the amdgpu driver). I hadn't updated firefox before the X server update, so I'm not sure this issue is due to the X update or due to the firefox update: When I start firefox and select Help|About firefox from the menu I get a transparent "about mozilla firefox" window. It only starts drawing its content when I either move it, or click elsewhere (so it loses focus and the wm causes a frame redraw). Does anyone happen to have firefox-102.0.1nb1 installed and not yet updated the X server and Xlib? Martin
Re: savecore weirdness
On Wed, Jun 29, 2022 at 10:57:55AM +0200, Thomas Klausner wrote: > I've tried overwriting the first 100MB of the 'dp' entry in my fstab > with zeroes in the hope of getting rid of the crashdump, but that > didn't help either. How can I get rid of the crashdump so savecore > doesn't try again to write it out? savecore -c should clear it. Martin
Re: Script to create bootable arm images?
On Fri, Jun 24, 2022 at 10:41:28AM +0200, Martin Husemann wrote: > On Thu, Jun 23, 2022 at 02:17:28PM -0600, Brook Milligan wrote: > > Is there a script somewhere that is being used to create the bootable > > arm issues that are available on https://nycdn.netbsd.org/pub/arm/? If > > so, where? > > It is build by build.sh, e.g. this is the invocation for a recent earmv7hf > build run: > > ===> build.sh command:/home/source/ab/HEAD/src/build.sh -m evbarm -a > earmv7hf -B 202206240040Z -V NETBSD_OFFICIAL_RELEASE=no -D > /home/builds/ab/HEAD/evbarm-earmv7hf/202206240040Z-dest -M > /home/builds/ab/HEAD/evbarm-earmv7hf/202206240040Z-obj -R > /home/builds/ab/HEAD/evbarm-earmv7hf/202206240040Z-rlse -T > /home/builds/ab/HEAD/evbarm-earmv7hf/202206240040Z-tools -U -X > /home/source/ab/HEAD/xsrc -P -x -N2 -V TMPDIR=/tmp -V BUILD=yes -V > MAKECONF=/home/builds/etc/make.conf -V MKDEBUG=yes -j16 release install-image > > and /home/builds/etc/make.conf only has MKREPRO=yes > (mostly for historic reasons). I forgot the board specific part: for each board, you need the corresponding sysutils/u-boot pkg from pkgsrc and then use installboot (typically in its $TOOLDIR/bin/nbinstallboot variant) on the usb disk image to add that particular u-boot. Martin
Re: Script to create bootable arm images?
On Thu, Jun 23, 2022 at 02:17:28PM -0600, Brook Milligan wrote: > Is there a script somewhere that is being used to create the bootable > arm issues that are available on https://nycdn.netbsd.org/pub/arm/? If > so, where? It is build by build.sh, e.g. this is the invocation for a recent earmv7hf build run: ===> build.sh command:/home/source/ab/HEAD/src/build.sh -m evbarm -a earmv7hf -B 202206240040Z -V NETBSD_OFFICIAL_RELEASE=no -D /home/builds/ab/HEAD/evbarm-earmv7hf/202206240040Z-dest -M /home/builds/ab/HEAD/evbarm-earmv7hf/202206240040Z-obj -R /home/builds/ab/HEAD/evbarm-earmv7hf/202206240040Z-rlse -T /home/builds/ab/HEAD/evbarm-earmv7hf/202206240040Z-tools -U -X /home/source/ab/HEAD/xsrc -P -x -N2 -V TMPDIR=/tmp -V BUILD=yes -V MAKECONF=/home/builds/etc/make.conf -V MKDEBUG=yes -j16 release install-image and /home/builds/etc/make.conf only has MKREPRO=yes (mostly for historic reasons). Martin
Re: scp -r incompatibility between -current and NetBSD releases
On Sat, Jun 11, 2022 at 10:56:26AM -0400, Tom Lane wrote: > Experimenting here, it seems the only case that doesn't work is > scp -r *to* a remote directory that doesn't exist yet. Possibly > worthy of a PR. Yes, it is an upstream regression when they switched the default protocol. A NetBSD PR will not help much. Martin
Re: scp -r incompatibility between -current and NetBSD releases
On Sat, Jun 11, 2022 at 04:12:17PM +0200, Thomas Klausner wrote: > Hi! > > I cannot use 'scp -r' from -current to NetBSD 8 or NetBSD 9. scp changed to use sftp by default in a recent OpenSSH update. It seems you can use scp -O to request the legacy protocol. Martin
Re: Branching for NetBSD 10
On Sat, Jun 04, 2022 at 05:16:34AM +, Thomas Mueller wrote: > My big concern with the branch is the entropy bug, where building > many packages from pkgsrc is stopped. Yes, you are kinda right: https://wiki.netbsd.org/releng/netbsd-10/ "Waiting for Randot" as open point, although you may notice that all other entropy related subpoints have been dealt with. But again: this is not a bug, but a broken system setup - and nowadays it is pretty hard to get into that state on new installations. The installer will push you very hard to fix the setup before completing installation. Various improvements in this area have happened lately, and once your system setup is fixed (one time, and savely shutdown or rebooted w/o crash after that fix) everything will just work. But most importantly in this context: this is nothing that can delay the branch itself (only the release). The one sub item that altered libc ABI (addition of getentropy(3)) has happened. Martin
Re: Branching for NetBSD 10
On Mon, May 02, 2022 at 04:22:56PM +0200, Martin Husemann wrote: > After a bit more than two years after the first NetBSD 9 release > (9.0 happened February 14, 2020) and nearly a year after the last > (so far) netbsd-9 release (9.2 happened May 12, 2021) we are in > the final steps to prepare for the next really great release: > > We are planning to branch netbsd-10 in about a week from now. As you may have noticed, this did not happen. Those who followed the NetBSD Foundation's annual general meeting saw that we discussed a new plan that wanted to branch early two weeks ago - and that also did not happen. The major issue that came up late and that we are now trying to resolve properly before the branch (so we can document what people testing the branch need to know about it) is the handling of extended attributes on FFS file systems. See the thread about "File system corruption due to UFS2 extended attributes" on current-users and tech-kern, starting here: https://mail-index.netbsd.org/tech-kern/2022/05/24/msg028105.html We hope to have these changes landed within the next few days and will start with the branch process right after that. Sorry for yet another delay, but let's do it right. Martin P.S.: of course the *real* cause for the delay is that we are still trying very hard to find reasons to bump the -current version to 9.99.99 - only two bumps to go!
Re: Steinberg UR44 uaudio device
On Fri, Jun 03, 2022 at 10:12:44AM +0200, Eivind Nicolay Evensen wrote: > Hello. > > Is there any way to get more information to understand > what is needed to get this Steinberg UR44 to work on > NetBSD: > > [ 109,152749] uaudio0 at uhub1 port 1 configuration 1 interface 0 > [ 109,152749] uaudio0: Yamaha Corporation (0x0499) Steinberg UR44 (0x1704), > rev 2.00/2.10, addr 4 > [ 109,152749] uaudio0: autoconfiguration error: audio descriptors make no > sense, error=4 It is most likely a uaudio v2 device (not suprising for 32bit/192kHz). Unfortunately NetBSD currently does not support that audio class. It is not hard to add support, just needs someone with some time to do it ;-) Martin
Re: /dev/wsfont permissions (Was: CVS commit: src/sys/dev/wsfont)
On Tue, May 17, 2022 at 12:48:06PM +0300, Valery Ushakov wrote: > Any thoughts on this? The problematic scenario is that the system is > upgraded, new MAKEDEV is run after the upgrade to (re)create the > devices, it creates world readabile /dev/wsfont, and then an old > kernel is booted (which is kinda in the unsupported territory). That > would allow fonts to be loaded by anyone, exposing whatever bugs are > lurking in wsfont(4) to J. Random User. I guess we can live with that risk. > Does anyone have a secret devfs project that can be merged in time for > 10 by any chance? :) There is no time left to be "in time for 10"! (We are a few days past planned branch date already) Martin
Branching for NetBSD 10
After a bit more than two years after the first NetBSD 9 release (9.0 happened February 14, 2020) and nearly a year after the last (so far) netbsd-9 release (9.2 happened May 12, 2021) we are in the final steps to prepare for the next really great release: We are planning to branch netbsd-10 in about a week from now. It seems that -current is in good shape overall, and we hope to get the big blockers resolved before the release. There is a list here: http://wiki.netbsd.org/releng/netbsd-10/ The most user visible fallout preventing testing of the new beta versions is likely the DRM/KMS update and the current massive fallout on intel i915 chips, here is an excerpt of the open PRs: https://gnats.NetBSD.org/56608 https://gnats.NetBSD.org/56648 https://gnats.NetBSD.org/56672 https://gnats.NetBSD.org/56724 https://gnats.NetBSD.org/56727 https://gnats.NetBSD.org/56740 https://gnats.NetBSD.org/56761 https://gnats.NetBSD.org/56765 We hope to get this issues resolved soonish, but couldn't allow them to further delay this long overdue branch. We don't yet know how long the branch will take to the first release (NetBSD 10), but hope it will not be more than three months. [But note that all my personal estimates on NetBSD-10 have been off by years, so this might need a correction - we will see once i915 works again.] Martin
Re: NetBSD-9.99.x No Video
On Mon, Apr 25, 2022 at 10:19:13PM +, RVP wrote: > Intel integrated GPUs on laptops don't work in all cases in UEFI mode > (mine does not). I think it does work (mostly--there are a couple of issues > still remaining) in BIOS compatibility (CSM) mode. No, the failure is unrelated to BIOS vs UEFI (my machine boots via CSM and can't find any displays). Martin
Re: Installing bootx64.efi on NetBSD current?
On Sun, Apr 10, 2022 at 03:19:33PM +1200, Lloyd Parkes wrote: > My /usr/mdec contains only boot, bootxx_ffsv1, bootxx_ffsv2, bootxx_lfsv2, > gptmbr.bin, mbr, mbr_bootsel, and mbr_ext. I think I have just fixed this... Martin
Re: Installing bootx64.efi on NetBSD current?
On Sat, Apr 09, 2022 at 09:16:28AM +1200, Lloyd Parkes wrote: > I installed NetBSD current from late March by net booting netbsd-INSTALL.gz > on and amd64 system of mine. The net boot and disk boot were both done with > UEFI and sysinst correctly offered to create GPT filesystems for me. > > Even though the FAT system partition was created correctly, bootx64.efi > didn't get installed in it. The directories were there, just not the > bootable file. > > Is that supposed to happen? I don't think that's supposed to happen. First question is if the files exist in that install medium - can you netboot into that netbsd-INSTALL.gz again, go to the shell and check contents of /usr/mdec? Martin
Re: Panics from today's sources
On Sun, Apr 03, 2022 at 05:20:37PM +, John Klos wrote: > [ 56496.032711] uvm_fault(0x81908580, 0xbd134d9bc000, 2) -> e > [ 56496.032711] fatal page fault in supervisor mode > [ 56496.032711] trap type 6 code 0x2 rip 0x80c4f634 cs 0x8 rflags > 0x10202 cr2 0xbd134d9bcc90 ilevel 0 rsp 0xa604bbfebda0 > [ 56496.032711] curlwp 0xfd0d7.0327109] panic: trap > [ 56496.032711] cpu5: Begin traceback... > panic() at netbsd:panic+0x3c > [ 56496.032711] trap() at netbsd7109] uvm_pagefree() at > netbsd:uvm_pagefree+0x2d5 > [ 56496.003271] uvm_unmapace_free() at netbsd:uvmspace_free+0xe4 > [ 56496.042711] exit1()_exit+0x39 > [ 56496.042711] syscall() at netbsd:syscall+0x1f2 > cpu5: End traceback... Is that happening to specific processes? Which process is trying to exit here? I have updated three machines today and don't see anything like that so far. Martin
Re: Installation issues with 9.99.92 and 9.99.93
On Tue, Mar 01, 2022 at 06:59:46AM -0600, Robert Nestor wrote: > Any ideas? When it does not find the boot device, you should get a boot prompt like: [ 8.8237251] boot device: [ 8.8637251] root device: and when you enter a "?" there, it should give you a list, like: [ 18.6737220] use one of: dk0 dk1 dk2 dk3 dk4 dk5 dk6 re0 iwn0 wd0[a-p] wd1[a-p] Can you also show the output of dmesg when you booted 9.2 ? Recently some timing around ATA disk identification changed, maybe you have some disk that does not play well with the new code (so wd1 is missing)? Martin
Re: 9.99.93 kernel and still entropy hangs
On Mon, Feb 14, 2022 at 12:54:27PM +0100, Riccardo Mottola wrote: > [ 10879.215507] entropy: pid 6895 (python3.9) blocking due to lack of > entropy [..] > seed 0 0 ???collect, v The last line means your system did not load entropy at boot time, maybe becaus there wasn't "blessed" entropy at shutdown time - or because something went wrong. It should look like: Source Estimated bitsSamples Type Flags [..] seed256 1 ???estimate, collect, v "man entropy" shows you how to deal with in more details (search for "Adding entropy"). If you have a new enough sysinst installed, you can use that to seed the entropy pool. Just start sysinst (as root), select language (if asked for it) and then go to the config menu. Right at the end there should be a "Set up entropy" menu item. The manual way from the entropy(7) man page is quite simple. Just make sure after you did it sysctl kern.entropy.needed says 0. After "shutdown -r now" the system should come up with kern.entropy.needed being 0 again (and nothing blocking). If it doesn't, you have to find out where it goes wrong. But that is the next step... Martin
Re: Bug or no Bug?
On Thu, Feb 10, 2022 at 08:05:36AM -0800, Jason Thorpe wrote: > Honestly, I think it's probably better to disable 'spinout' by > default and have it enabled by a sysctl / option. And possibly the > spin time adjustable by sysctl, too. I like that. Martin
Re: Dell Precision 3650 issues & sysinst
On Thu, Feb 10, 2022 at 01:02:34PM +0100, Martin Husemann wrote: > Hmm, that used to work - but I may have broken it accidently when fixing > a similar issue for updates recently. I'll try to reproduce it. Yes - it was my change. Testing a fix now, thanks for noticing! Martin
Re: Re: Bug or no Bug?
The kernel lock is held too long while the graphics card is configured. I have seen that with some Nvidia cards, where I just have not been able to boot LOCKDEBUG kernels (example in PR 55185). You can patch out the kernel lock spinout code (so the kernel does not limit the KERNEL_LOCK() spin time and you then can investigate other locking issues). Maybe we should offer an official option to do that? Martin P.S.: only guessing it is the graphics card, something(tm) is taking very long while holding the kernel lock, anything called during autoconfiguration could do that - but also a few other things.
