Re: Font Path prompt in pkg_add
Changelog (just the facts - Awesome!): https://www.openbsd.org/plus71.html A search for "font" on the page shows 3 entries... On 4/28/22 12:37, Christopher Turkel wrote: > I'm on OpenBSD AMD64 7.1, fresh install > I noticed when adding fonts via pkg_add it no longer prints out "You may > wish to" after installation is finished. > > is this a bug, or a feature?
Font Path prompt in pkg_add
I'm on OpenBSD AMD64 7.1, fresh install I noticed when adding fonts via pkg_add it no longer prints out "You may wish to" after installation is finished. is this a bug, or a feature?
Re: Openbsd 7.1 installation - disk boot record
On 4/28/22 04:46, Pawel Kraszewski wrote: Well, I installed 7.0 (*not* 7.1) on my desktop (old Haswell mobo) - it rendered computer unstartable (not unbootable). Mobo hung so hard it couldn't even enter the BIOS. I think I was lucky I didn't install it on my PCIe-card NVMe... It would be shitty to need it hot-plugged to a working computer to fix. If it is of any use to anyone, I have a Haswell Gigabyte board that locks up if I use OpenBSD to set up the drive with GPT. It just shows a black screen and won't even show the vendor logo, much less let me into the BIOS or OS. This happens with both an on-board mSATA and with a standard SATA HDD or SSD. As soon as I unplug the drive, everything is fine, and I have to recreate the partition table in another system. I always figured it was a problem with the MB firmware, so I never filed a bug.
Re: Unusable resolution on a widescreen monitor during install
> On 28 Apr 2022, at 04:06, Mike Larkin wrote: > > On Wed, Apr 27, 2022 at 05:07:14PM -0400, Nick Holland wrote: >> On 4/27/22 9:15 AM, David Demelier wrote: >>> Hello, >>> >>> I have a lenovo thinkcentre machine connected to 24” LG screen (with >>> 4k resolution), the installer boots fine using UEFI but it looks like >>> efifb takes a strange “squared” resolution where bottom part of the >>> console is below the screen so I’m unable to see what I type. I’ve >>> taken a picture of what’s seen: >>> >>> http://markand.fr/static/openbsd-resolution.jpeg >>> >>> I have tried disabling inteldrm using UKC as I’ve seen on some >>> websites with somewhat similar problem but with no effect. I’ve also >>> noticed there is no wscons(cfg|ctl) utilities in the installer so I >>> was unable to blindly type commands to alter the resolution either. >>> Unfortunately, changing boot video mode using `machine video …` does >>> not change kernel resolution either. >>> >>> My only solution for now would be to boot not using UEFI but that’s >>> something I’d like to avoid if possible. >>> >>> Do you have any idea why an incorrect resolution is picked up by the >>> kernel? I’m using install71.img on USB stick FYI. >> > > Does: > > boot> machine gop (then machine gop followed by some mode number) work? Hello, I’ve been finally able to install OpenBSD accidentally, I powered on the machine without the screen on and for some reason the lenovo used a very low resolution like 640x480. That’s exactly what machine gop shown (and the only available resolution). Maybe the machine did use a degraded resolution due to absence of video signal? dunno. But now I can enjoy OpenBSD on this machine. It works perfectly. -- David
Re: clang 13 space issues with KARL
On Thu, Apr 28, 2022 at 2:00 PM Peter J. Philipp wrote: > BTW do you know any operating systems that aren't BSD, Linux that I can > continue on? Surely you'd be in the know for this. If you do not mind using msdos as a bootstrap loader, you might try colorforth. For example: https://colorforth.github.io/install.htm That said, if you are looking for a community to support that effort, you might have to build it yourself. This isn't really the right place for that. Good luck, -- Raul
Re: clang 13 space issues with KARL
On Thu, Apr 28, 2022 at 11:47:14AM -0600, Theo de Raadt wrote: > >On Thu, Apr 28, 2022 at 10:44:09AM -0600, Theo de Raadt wrote: > >> If people built properly sized machines there would be no problem. > > > >That's a little condescending don't you think? > > Not at all. > > If you don't use a tool as it was intended, you bear the consequences. > > *WE* built the tool. *WE* decided how it works. We even documented > how much resources it typically needs. When people use it > incorrectly, it is their own damn fault. *THEY* can make adjustments. > > But they cannot complain, because they did not pay and even if they > had there is no warrantee. > > There is nothing condescending about telling someone their complaints > about how something works are falling on deaf ears. I don't give a > flying damn if KARL is hurting people who don't provide their machines > with reasonable defaults. It is their own damn fault, and they can > make manual accomodations for their own (completely stupid, IMHO) > decisions. > > In this modern world is has become *impossible* to complain about > any technology which doesn't work like you want, companies who take > money don't give a damn. Here's the shocker: I will not be held > to a higher standard than that. So Peter, your attitude stinks > and your suggestion that anything I've said is "rude" rather than "real", > thgat suggestion of yours is an insult. OK, I get it you're having a bad day. I'm sorry if I was rude. BTW do you know any operating systems that aren't BSD, Linux that I can continue on? Surely you'd be in the know for this. -peter
Re: clang 13 space issues with KARL
>On Thu, Apr 28, 2022 at 10:44:09AM -0600, Theo de Raadt wrote: >> If people built properly sized machines there would be no problem. > >That's a little condescending don't you think? Not at all. If you don't use a tool as it was intended, you bear the consequences. *WE* built the tool. *WE* decided how it works. We even documented how much resources it typically needs. When people use it incorrectly, it is their own damn fault. *THEY* can make adjustments. But they cannot complain, because they did not pay and even if they had there is no warrantee. There is nothing condescending about telling someone their complaints about how something works are falling on deaf ears. I don't give a flying damn if KARL is hurting people who don't provide their machines with reasonable defaults. It is their own damn fault, and they can make manual accomodations for their own (completely stupid, IMHO) decisions. In this modern world is has become *impossible* to complain about any technology which doesn't work like you want, companies who take money don't give a damn. Here's the shocker: I will not be held to a higher standard than that. So Peter, your attitude stinks and your suggestion that anything I've said is "rude" rather than "real", thgat suggestion of yours is an insult.
Re: clang 13 space issues with KARL
On Thu, Apr 28, 2022 at 10:44:09AM -0600, Theo de Raadt wrote: > If people built properly sized machines there would be no problem. That's a little condescending don't you think? -peter
Re: clang 13 space issues with KARL
>On 2022-04-27, Nick Holland wrote: >>> What can I do to make KARL reorder_kernel use less memory without buying >>> more >>> RAM? I've turned KARL off for now but that's not a real solution and I hate >>> it. >>> >>> Is there no option in the clang 13.0.0 linker to store what it would >>> normally >>> store in memory to disk? I know it would be slow but KARL doesn't need to >>> be fast if it's backgrounded. >> >> yep. It is called "swap". You just reinvented swap. :) >> And KARL is backgrounded already. > >And that's the problem in some cases: /bin/time -l says that >reorder_kernel uses ~650MB rss on my laptop. Depending on what else you >have running (noting that daemons, which are often starting at around >the same time as reorder_kernel runs, often use more RAM during startup >than in a steady state) that can be enough to tip it over the edge. 650MB rss why is this a big deal? I think people are building tiny little machines that Linux would never run on, and then inventing complaints. If people built properly sized machines there would be no problem. Alternatively, they should grow up and go work on making the linker use less memory. I do not understand why this complaint exists. If you built a machine that cannot link a kernel, your machine is very likely Not Fit For Modern Purposes. Grow up, this is not the year 2000.
kqueue and EVFILT_USER
I'm trying to "port" an application that currently works on FreeBSD and NetBSD, but it fails to compile on OpenBSD due to lack of EVFILT_USER in kqueue. Is there any plans to add support it for OpenBSD? --- Mika T. Lindqvist / Talleo Project
Re: Openbsd 7.1 installation - disk boot record
Well, I installed 7.0 (*not* 7.1) on my desktop (old Haswell mobo) - it rendered computer unstartable (not unbootable). Mobo hung so hard it couldn't even enter the BIOS. I think I was lucky I didn't install it on my PCIe-card NVMe... It would be shitty to need it hot-plugged to a working computer to fix. I was able to do that as Michael did (unplug, boot other OS, hot-plug, wipe OpenBSD partition, fix UEFI order). And I'm pretty used to fact, that a bootable pendrive with OpenBSD installer (.fs image) renders old HP laptops (ProBooks, EliteBooks from 2-ish gen Cores era) unbootable in the very same way (hard lock, can't enter BIOS). I suppose this behavior might have some common root cause. -- Paweł Kraszewski GPG key: E030 A049 9C33 C1E9 28EA 50C9 821F DA62 0A90 D330 Tel: +48(604)777447 czw., 28 kwi 2022 o 03:37 napisał(a): > > > Hello, > > > > Today I tried to do a fresh install of openbsd 7.1. (from usb pendrive). I > > tried to do a very basic install (accepting the default - without network > > - with sets from disk) and when getting to the root disk question I used > > (W)hole disk MBR. Everything went through smoothly, however when rebooting > > the system the initial boot sequence goes into an endless loop > > (manufacture logo appearing again and again) - also cannot enter bios > > setup anymore. Had to remove the ssd, connect via usb and dd with zero the > > first mb. Tried several things i.e. changing bios options, upgrading bios > > to latest version, using uefi etc nothing worked. Always same endless boot > > loop. > > > > After some time I found a work around by installing from the 7.0 > > installation image and then upgrading to 7.1. Everything works now. > > > > Does anyone know why this might be happening? It would seem that changes > > to fdisk did change the MBR (or how it is written) which at least on my > > machine - old dell e7240 - is preventing it from booting. > > > > Any help is highly appreciated. > > > > Thanks, Michael > > > > P. S. Not sure if this is a bug and if it should be reported. > > > > Hello > > I had a similar situation with an old Dell: > > The installation of 7.1 went correctly, but when i did a reboot; the > machine said that there were not a disk! > > Then i tried to install 7.0 and the installer gave me a > point! in the > section available disk. > > Is there a form to reestablish the MBR using the installer? > > PD: > Testing i deleted the loop partition with Gparted, and added different new > mbr. Nothing changed. > > Thanks OpenBSD team I feel happy using 7.1 on 3 vms. > > Curiosity question: > 2 of my vms show UTC with # date, and 1 shows the local time; during the > installation, i marked local time Canada/Pacifi; in all of them, which i > can see with: # > date -z Canada/Pacific. > > Thanks. > > >
