Re: ipv4_prefer
Lucifer wrote: > On Sun, Apr 28, 2024, 5:16 PM beaker wrote: > > > m...@goathill.org (MLH) wrote: > > > > > It appears that some of the pkgsrc distfiles now are only available > > > via ipv6 servers but how do you set ipv4_prefer mode so ipv6 attempts > > > don't prevent normal ipv4 operation? > > > > > > setting > > > ip6addrctl_policy="ipv4_prefer" > > > > > > in rc.conf doesn't change to normal ipv4 mode first as the > > > documentation (and other references) appear to claim. > > > > Try setting "ip6addrctl=YES" as well. > > > What is ip6addrctl? It's mentioned in rc.conf(5): "ip6addrctlBoolean value. Fine grain control of address and routing priorities." I *think* it's akin to having to enable cruise control before you can set a particular speed preference. -B
Re: ipv4_prefer
m...@goathill.org (MLH) wrote: > It appears that some of the pkgsrc distfiles now are only available > via ipv6 servers but how do you set ipv4_prefer mode so ipv6 attempts > don't prevent normal ipv4 operation? > > setting > ip6addrctl_policy="ipv4_prefer" > > in rc.conf doesn't change to normal ipv4 mode first as the > documentation (and other references) appear to claim. Try setting "ip6addrctl=YES" as well.
Re: cryptic pkgin SSL cert error
David Brownlee wrote: > On Tue, 23 Apr 2024 at 02:27, beaker wrote: > > I have a 9.3/i386 VM on which I recently ran > > $ sudo pkgin update ; sudo pkgin upgrade ;sudo pkgin autoremove > > > > which worked but subsequent attempts to use pkgin report the following > > error: > > > > -- > > $ sudo pkgin update > > cleaning database from > > http://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/i386/9.3/All entries... > > reading local summary... > > processing local summary... > > processing remote summary > > (https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/i386/9.3/All)... > > 3061459968:error:1416F086:SSL > > routines:tls_process_server_certificate:certificate verify > > failed:/usr/src/crypto/external/bsd/openssl/dist/ssl/statem/statem_clnt.c:1921: > > 3061459968:error:1416F086:SSL > > routines:tls_process_server_certificate:certificate verify > > failed:/usr/src/crypto/external/bsd/openssl/dist/ssl/statem/statem_clnt.c:1921: > > 3061459968:error:1416F086:SSL > > routines:tls_process_server_certificate:certificate verify > > failed:/usr/src/crypto/external/bsd/openssl/dist/ssl/statem/statem_clnt.c:1921: > > pkgin: Could not fetch > > https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/i386/9.3/All/pkg_summary.xz: > > Authentication error > > -- > > > > A work-around is to edit /usr/pkg/etc/pkgin/repositories.conf so > > it only uses http not https but I'd really rather not do that going > > forward so I'm looking for some guidance on how to fix wahatever > > is causing this SSL certificate verification error. > > > > System info: > > $ pkgin -v > > pkgin 23.8.1 (using SQLite 3.26.0) > > $ uname -a |cut -d' ' -f4-12 > > NetBSD 9.3_STABLE (GENERIC) #0: Mon Mar 25 15:54:20 UTC > > $ uname -m > > i386 > > Do you have security/mozilla-rootcerts-openssl installed? (which > should provide a full set of certs in /etc/openssl). Alternatively > what do you have in /etc/openssl > > For netbsd-10 /etc/openssl is populated by the OS, but doing that > would be a breaking change on netbsd-9, however it may be that the > latest pkgin is enforcing SSL certificates by default on netbsd-9 > which would be... unhelpful in this case Thanks, installing the mozilla-rootcerts-openssl pkg then re-editing ../pkgin/repositories.conf to use "https" worked. You're probably right about this being sort of a transitory issue mostly affecting 9.x, I just hadn't encountered it before and I've a handful of 9.x systems. Probably the forementioned rootcert pkg is already present on those. -B
cryptic pkgin SSL cert error
Hello, I have a 9.3/i386 VM on which I recently ran $ sudo pkgin update ; sudo pkgin upgrade ;sudo pkgin autoremove which worked but subsequent attempts to use pkgin report the following error: -- $ sudo pkgin update cleaning database from http://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/i386/9.3/All entries... reading local summary... processing local summary... processing remote summary (https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/i386/9.3/All)... 3061459968:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/external/bsd/openssl/dist/ssl/statem/statem_clnt.c:1921: 3061459968:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/external/bsd/openssl/dist/ssl/statem/statem_clnt.c:1921: 3061459968:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/external/bsd/openssl/dist/ssl/statem/statem_clnt.c:1921: pkgin: Could not fetch https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/i386/9.3/All/pkg_summary.xz: Authentication error -- A work-around is to edit /usr/pkg/etc/pkgin/repositories.conf so it only uses http not https but I'd really rather not do that going forward so I'm looking for some guidance on how to fix wahatever is causing this SSL certificate verification error. System info: $ pkgin -v pkgin 23.8.1 (using SQLite 3.26.0) $ uname -a |cut -d' ' -f4-12 NetBSD 9.3_STABLE (GENERIC) #0: Mon Mar 25 15:54:20 UTC $ uname -m i386
Re: would anybody use binary packages for NetBSD/i386 10?
Greg Troxel wrote: > In contemplating bulk builds and resources, I wonder if there are still > people who: > > are running NetBSD/i386 (as opposed to amd64) > > are using the binary packges from quarterly branches on ftp.netbsd.org > > are running NetBSD 10 already, or who intend to move to it soon or > after release > > If you have a system that meets the above, please either reply here (the > first few people :-) or just answer me privately. (I'd also be > interested in which category below your use is.) > > Basically, I would think about not doing bulk builds if very few want > them, relative to the effort/resources required to create them. > > > My guess is that at this point, i386 use is limited to > > a) old embedded-type systems (soekris) > b) systems that are running i386 because they were first installed many > years ago and haven't been converted to amd64 for no good reason or > for some odd special case odd reason > c) build systems to support category a/b systems, for testing or > building private binary package sets > d) retrocomputing > > and that the amount of use with ftp.n.o binary packages is extremely > small. > > As a personal example -- and I am somewhat trailing edge -- I know of > two NetBSD/i386 systems in category b (one each no good reason and one > special case odd reason), and 2 in category c. I have one system that > would be category a, replaced several years ago and powered off because > it was underpowered, that I might or might not ever power up again, and > if I did I wouldn't use ftp.n.o packages on it. > Yup, still using 32bit NetBSD. I do like the binaries but really most of the stuff I use is easy to build under pkgsrc. I would appreciate having a usable Xorg w/o having to build it. I'm in category "d" for sure.
Re: holding back pkgs from pkgin
pin wrote:
> Apparently nobody has answered your question in the mailing-list.
>
> > Is there a way to hold back packages from pkgin similar to 'apt-mark '
> > ?
>
> The short answer is no, there isn't.
>
> > The pkg in question is ../wm/dwm which I customize in pkgscr and install.
> > pkgin sees it's installed and always over-writes my custom built binary
>
> For simple things like this, there's a way to fool pkgin that I've been using
> for years.
>
> But, first one warning. Do not change the contents of pkgsrc/wm/dwm directly.
> Use wip to do this things.
>
> Copy wm/dwm to wip, do your customization and bump the version (currently
> 6.4) to a higher number.
> Build and install the package.
> Now next time you upgrade pkgin will see that the installed version of dwm is
> than the available in the binary repository and won't touch it.
>
> Hope this solves your issue.
Sorry for late reply.. Ya this is an intersting approach. I ended
up just building dwm under /usr/local since it's not too complicated
to do.
FYI: For anyone considering building dwm under /usr/local/..
In addition to correcting the X11LIB, X11INC, and FREETYPEINC paths
one needs to do at least ONE of the following for the Xlib linking:
# option 1: tweak ../dwm-4.6/config.mk
#../dwm-4.6/config.mk
..
LIBS += -Wl,-rpath=${X11LIB}
# option 2: set LD_LIBRARY_RUN
$ export LD_LIBRARY_RUN=/usr/X11R7/lib
# option 3: create /etc/ls.so.conf
#/etc/ls.so.conf
/usr/X11R7/lib
$ sudo ldconfig
Probably many already know this. I was scratching my head for a bit
until I found the reason for the lack of linking, probably because
many projects use autoconfig to probe system and set things.
holding back pkgs from pkgin
Is there a way to hold back packages from pkgin similar to 'apt-mark ' ? Didn't see anything in the manpage and when I try to use 'pkgin import pkg_list.txt' where the not-to-be-updated pkg has been removed pkgin STILL tries to update the pkg. The pkg in question is ../wm/dwm which I customize in pkgscr and install. pkgin sees it's installed and always over-writes my custom built binary...
Re: modern desktop update recommendations?
m...@goathill.org (MLH) wrote: > My ~10 yr old i3-based box needs to be updated. I can't compile > anything nontrivial without the box rebooting anymore. I think your system should be able to build most packages just fine though something like Gnome might take a while. Some packages, ie. those with lots of fonts, may run out of RAM; this can be addressed by adding a swap file (see online documentation for how to do this). I regularly build packages on an old 32 bit box with 2GB RAM usually without issue -- once I addressed an ACPI/powerd(8) quirk (see below) that would cause sudden system shutdowns during even moderate loads. If the rebooting is occuring during package building you may want to check if it's being triggered by ACPI/powerd(8) receiving faulty core temp values which eith the default powerd script initiates a system shutdown. You should see something in the logs relating to this if this is the situation. You can also monitor things during a build using envstat(8) to see if something like a temp of "255" gets reported (the case on my system). The script of interest: /etc/powerd/scripts/sensor_temperature You can either comment out the "shutdown -p.." lines of simply rename the script to something powerd(8) won't see. -J
Re: Keeping NetBSD disklabel up to date
mlel...@serpens.de (Michael van Elst) wrote: > bea...@sdf.org (beaker) writes: > > >Is it safe and sufficient to run 'mbrlabel -fw ' on NetBSD > >whenever there has been partition resizing (usually via Gpartd) > >such that the disklabel no longer reflects the current partitioning > >state? > > mbrlabel creates disklabel entries for MBR partition entries, nothing > generic. It also won't move any data. > > > >System in question is an old 32bit i386 with an MBR partition scheme > >on a SATA disc hosting several Linux partitions and one NetBSD FFS2 > >partition. Bootloader is GAG, not GRUB nor native NetBSD bootloader. > > If you only change the Linux partitions, you can use mbrlabel > (without -w) to print the necessary disklabel entries. mbrlabel > doesn't know how to delete or modify existing entries, so you need > to do that and use the mbrlabel output as a template. > > If you want to modify or even resize the NetBSD partitions, it gets > much more complicated. A save approach is to boot from an alternate > installation (Live- or Installation-CD), backup the partitions, > modify them accordingly and restore the partition content from > the backup. You may also have to reinstall the bootloader. Thanks for the reply. Basically this question arrises from a recent experience in which I was attempting to reformat an existing partition to EXT2 for use as a "Commons" since neither the NetBSD nor Linux OSes can mount eachother (one is BTRFS, the other UFS2; RW for UFS2 on Linux is supposedly supported but I couldn't get it to work). Anyway, a Linux formatted EXT2 "Commons" was unmountable by NetBSD so I too-haistily tried the same from NetBSD and corrupted the nearby BTRFS partition in the process, apparently due to the disklabel not accurately reflecting the current partitioning "map". Well, that's why backups get made.. So it sounds like mbrlabel by itself would not have been sufficient for avoiding this scenario; it's output still needs to be applied via the disklabel tool; is that correct? I'm sort of surprised as the mbrlabel(8) manpage says "mbrlabel is used to update a NetBSD disk label from the Master Boot Record (MBR) label and Extended Boot Record (EBR) label(s) found on disks that were previously used on DOS/Windows systems (or other MBR using sys tems)." Perhaps it's grammatically correct but not literally correct -- it is used to update the disklabel but doesn't actually do it itself? Regarding the GPT scheme as a possibility I'll have to get educated on that but perhaps it's the better way to go since I'm goning to have to start over with this disc anyway. I had it in my head that GPT was a 64bit only option.
Keeping NetBSD disklabel up to date
Is it safe and sufficient to run 'mbrlabel -fw ' on NetBSD whenever there has been partition resizing (usually via Gpartd) such that the disklabel no loner relects the current partitioning state? System in question is an old 32bit i386 with MBR partition scheme on sata disc hosting several Linux partitions and one NetBSD FFS2 partition. Bootloader is GAG, not GRUB or native NetBSD bootloader. If I wipe the disc and recreate a multi-boot setup is there a better partitioning scheme I could use for such an old system? I don't believe GPT is supported on the system in question.
Keeping NetBSD disklabel up to date
Is it safe and sufficient to run 'mbrlabel -fw ' on NetBSD whenever there has been partition resizing (usually via Gpartd) such that the disklabel no longer reflects the current partitioning state? System in question is an old 32bit i386 with an MBR partition scheme on a SATA disc hosting several Linux partitions and one NetBSD FFS2 partition. Bootloader is GAG, not GRUB nor native NetBSD bootloader. If I wipe the disc to recreate a multi-boot setup is there a better partitioning scheme I could use for such an old system? I don't believe GPT is supported on the system in question.
Re: Printer recommendations
So, what printers do NetBSD'ers use? I use an HPLJ 2100TN. Has a Jet Direct card so really all you need is a lpd of some sort. Can even ftp files to it. Basically any network printer will likely work for you as long as it speaks CUPS or Unix LPD.
