Re: Unusable resolution on a widescreen monitor during install
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? -ml > The installer kernel is very limited in its abilities, and if I understand > UEFI (which I don't), the install kernel is more-or-less locked into using > what the firmware sets up. "man efifb" kinda hints that I might be right > on this. > > In short: probably not a lot you can do with the install kernel to fix > the problem. And hopefully, once installed, the "real" kernel will be fine > with your monitor. > > HOWEVER, 4k monitors and their support are interesting. I have an old HP > netbook with an AMD competitor to the Intel Atom chips which just took off > and ran with an HDMI 4k monitor, and a much more capable and newer Thinkpad > which didn't work properly at all with 4k (in both OpenBSD and Windows). > > You might want to start with a firmware upgrade for your machine in question, > see if that helps. If not, a few ideas: > > * Boot the installer, drop to shell, hit "clear" to put the cursor back at > the top of the screen and do your install, taking defaults as much as > possible to minimize dialog, and defaults for everything after the text rolls > off the bottom of the screen, and clean it up later. > > * Do a serial install (aren't I funny? As if there is a serial port on a > machine with an HDMI port! But maybe there is...Maybe I should go buy > a lottery ticket, too). > > * Try the install with a 1920x1080 or lesser resolution monitor. > > * Move the hard disk to another UEFI machine and do the install on it, then > move the disk back, hoping the other machine works better for the installer. > > Nick. >
Re: Openbsd 7.1 installation - disk boot record
> 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.
Openbsd 7.1 installation - disk boot record
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.
Re: Unusable resolution on a widescreen monitor during install
On 2022-04-27, Nick Holland wrote: > On 4/27/22 9:15 AM, David Demelier wrote: >> >> http://markand.fr/static/openbsd-resolution.jpeg > > * Do a serial install (aren't I funny? As if there is a serial port on a > machine with an HDMI port! But maybe there is...Maybe I should go buy > a lottery ticket, too). it isn't 100% clear from the photo which thinkcentre machine it is, but actually there is quite a good chance it _does_ have a serial port. > * Try the install with a 1920x1080 or lesser resolution monitor. or maybe a VGA cable to the existing monitor, if machine and monitor can do it
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.
Re: Unusable resolution on a widescreen monitor during install
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. The installer kernel is very limited in its abilities, and if I understand UEFI (which I don't), the install kernel is more-or-less locked into using what the firmware sets up. "man efifb" kinda hints that I might be right on this. In short: probably not a lot you can do with the install kernel to fix the problem. And hopefully, once installed, the "real" kernel will be fine with your monitor. HOWEVER, 4k monitors and their support are interesting. I have an old HP netbook with an AMD competitor to the Intel Atom chips which just took off and ran with an HDMI 4k monitor, and a much more capable and newer Thinkpad which didn't work properly at all with 4k (in both OpenBSD and Windows). You might want to start with a firmware upgrade for your machine in question, see if that helps. If not, a few ideas: * Boot the installer, drop to shell, hit "clear" to put the cursor back at the top of the screen and do your install, taking defaults as much as possible to minimize dialog, and defaults for everything after the text rolls off the bottom of the screen, and clean it up later. * Do a serial install (aren't I funny? As if there is a serial port on a machine with an HDMI port! But maybe there is...Maybe I should go buy a lottery ticket, too). * Try the install with a 1920x1080 or lesser resolution monitor. * Move the hard disk to another UEFI machine and do the install on it, then move the disk back, hoping the other machine works better for the installer. Nick.
Re: clang 13 space issues with KARL
On Wed, Apr 27, 2022 at 11:32:06AM -0400, Nick Holland wrote:
> On 4/25/22 1:23 PM, Peter J. Philipp wrote:
> > Hi,
> >
> > I have an openbsd amsterdam vps and KARL is using up so much RAM that it
> > causes the system to swap. I recently upgraded it to 7.1 and it's the first
> > time I had a problem with this (that I noticed). I have tried to put KARL
> > into a login.conf'ed (32 MB data limit) user but ld doesn't like that at all
> > and exits with a memory allocation failure.
> >
> > 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.
Oh goody! When I look at this VPS it has 1 GB of RAM, 1/2 of all resources
are used up by daemons (around 512 MB) and the rest is in buffer cache and
free memory. I don't care much about 45 MB being swapped out to disk really
but if I'm correct this does have a negative impact on openbsd.amsterdam and
was the reason they gave us a free RAM upgrade before.
> > I've done some homework googling and found this:
> > https://stackoverflow.com/questions/25197570/llvm-clang-compile-error-with-memory-exhausted
> >
> > in the checked solution, 1 and 2 are sorta out of the question, but
> > question is
> > whether we're using a Debug build of clang? Does anyone know off hand?
> >
> > While I'm here thinking about possible solutions it would be cool if I could
> > allocate a 128 MB vmm inside this vmm (cascaded vmm's?) with a stripped down
> > KARL building kernel and lots of swap, then it can swap all it wants to
> > while
> > linking and it leaves the system in reasonable memory without swapping in
> > the main vm. Perhaps I'm thinking in over-engineering terms here?
>
> "I have a problem with memory consumption. I know! I'll solve it adding a
> VM!"
> Now you have many problems. I really don't think this is a good idea.
>
> How tiny is this VM??? My smallest intel box currently sitting around and
1 GB RAM.
> ready to go is a 400MHz celeron with 512MB RAM, i386 platform, so I just
> fired it back up and did a few sysupgrades to bring it up to 7.1-current (ok,
> "just" isn't applicable here, I started this test yesterday). I did a reboot
You can't compare i386 to amd64 the memory footprint is a lot smaller in i386.
But I see where you're going with this: <=512 MB RAM is too low for a machine.
> and as soon as I could log back in, did so and watched top -- ld topped out
> at about 270MB. That is admittedly huge for an OS I used to do builds on
> with 128MB and run in production with 32MB but a couple releases ago, I
> found that 384MB was the minimum needed to avoid swap on boot. Doesn't look
> much worse now (granted, i386 platform. I don't know what you are running).
>
> If you are trying to run <512MB RAM, I would politely suggest reconsidering
> some life choices here. :)
Not the case here. Although I'm constantly searching for new opportunities
which affect my life choices regardless.
> Alternatively, you might want to think about other options.
> KARL is great, but even without it, I think you will find OpenBSD is still far
> more robust and secure than the systems your bank runs on, so disabling KARL
> is not fatal in my mind for otherwise fairly secure systems. If you wish to
> get overly complicated, you could disable KARL on the production machine and
> relink a kernel periodically on ANOTHER machine and put it on the prod
> machine after it is built (there's your VM. Just don't put it on an already
> resource-starved system!)
This is a good idea and I haven't thought of it. I may do this.
> Another idea might be to slip "disknice" into /etc/rc where it rebuilds the
> kernel. It is a cute little bit of code TedU@ wrote a number of years ago,
> you can find it here:
> https://marc.info/?l=openbsd-misc&m=126526614419455&w=2
> It won't stop swapping, but *may* help other tasks get some time. I've found
> it useful on disk I/O tied tasks, but never tried it with a swap-bound task.
> I have no idea how it would impact a swapping process. Might solve your
> problem, might do nothing ("doing nothing" counts as hurting when you make
> changes to system scripts).
I like your first recommendation better somehow, thanks very much though.
> Nick.
>
Best Regards,
-peter
Re: clang 13 space issues with KARL
On 4/25/22 1:23 PM, Peter J. Philipp wrote:
Hi,
I have an openbsd amsterdam vps and KARL is using up so much RAM that it
causes the system to swap. I recently upgraded it to 7.1 and it's the first
time I had a problem with this (that I noticed). I have tried to put KARL
into a login.conf'ed (32 MB data limit) user but ld doesn't like that at all
and exits with a memory allocation failure.
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.
I've done some homework googling and found this:
https://stackoverflow.com/questions/25197570/llvm-clang-compile-error-with-memory-exhausted
in the checked solution, 1 and 2 are sorta out of the question, but question is
whether we're using a Debug build of clang? Does anyone know off hand?
While I'm here thinking about possible solutions it would be cool if I could
allocate a 128 MB vmm inside this vmm (cascaded vmm's?) with a stripped down
KARL building kernel and lots of swap, then it can swap all it wants to while
linking and it leaves the system in reasonable memory without swapping in
the main vm. Perhaps I'm thinking in over-engineering terms here?
"I have a problem with memory consumption. I know! I'll solve it adding a VM!"
Now you have many problems. I really don't think this is a good idea.
How tiny is this VM??? My smallest intel box currently sitting around and
ready to go is a 400MHz celeron with 512MB RAM, i386 platform, so I just
fired it back up and did a few sysupgrades to bring it up to 7.1-current (ok,
"just" isn't applicable here, I started this test yesterday). I did a reboot
and as soon as I could log back in, did so and watched top -- ld topped out
at about 270MB. That is admittedly huge for an OS I used to do builds on
with 128MB and run in production with 32MB but a couple releases ago, I
found that 384MB was the minimum needed to avoid swap on boot. Doesn't look
much worse now (granted, i386 platform. I don't know what you are running).
If you are trying to run <512MB RAM, I would politely suggest reconsidering
some life choices here. :)
Alternatively, you might want to think about other options.
KARL is great, but even without it, I think you will find OpenBSD is still far
more robust and secure than the systems your bank runs on, so disabling KARL
is not fatal in my mind for otherwise fairly secure systems. If you wish to
get overly complicated, you could disable KARL on the production machine and
relink a kernel periodically on ANOTHER machine and put it on the prod
machine after it is built (there's your VM. Just don't put it on an already
resource-starved system!)
Another idea might be to slip "disknice" into /etc/rc where it rebuilds the
kernel. It is a cute little bit of code TedU@ wrote a number of years ago,
you can find it here:
https://marc.info/?l=openbsd-misc&m=126526614419455&w=2
It won't stop swapping, but *may* help other tasks get some time. I've found
it useful on disk I/O tied tasks, but never tried it with a swap-bound task.
I have no idea how it would impact a swapping process. Might solve your
problem, might do nothing ("doing nothing" counts as hurting when you make
changes to system scripts).
Nick.
UEFI install not booting if disk preinstalled with Fedora
Hello, During my recent experimentation with ssd and OpenBSD, I came to a point where the OpenBSD amd64 snapshot install was not able to boot from ssd installed and booted in UEFI mode. Since I was able to prior use this ssd in this configuration, I started to analyze and check more in BIOS and ssd settings. The only this different was that I was trying to install OpenBSD in UEFI mode on a ssd with Fedora already installed on it. The install went fine, but the boot was not successful having BIOS reporting 'No option to boot.' Since the BIOS settings were the same, I did: dd if=/dev/zero of=/dev/rsd1c bs=1m count=10 on that ssd ( 10 was just to be sure, after i thought 1 may not be enough), then OpenBSD went fine with install and boot in UEFI mode. Now, I'm asking: shouldn't OpenBSD install be able to fully install on a ssd no matter what the previous setting are? As for what was wrong, I didn't saved any information, but if that is really of interest I can reinstall Fedora and try after that OpenBSD install and boot, with some debug as instructed. Thanks
Unusable resolution on a widescreen monitor during install
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. -- David
Re: OpenBSD and multitasking
On Tue, Apr 26, 2022 at 01:40:46PM +0200, Stefan Hagen wrote: > Mihai Popescu wrote (2022-04-26 01:13 CEST): > > I use OpenBSD amd64 snapshots on the following dmesg hardware. > > The download rate on a browser was slow and I figured out with some > > memory mapped partition that disk transfer rate was slow. > > I can bear this since I'm not into large file transfer business. But > > here is another interesting fact: each time my disk is used by some > > file transfer, all the running applications, mostly GUI based are > > stalling - that includes mostly chromium ( even if it is not chromium > > that it does the disk data transfer). > > > > My questions are: is something incorrectly set up on my computer, > > regarding the multitasking? > > I understand disk operations are slow, but may I say that kernel is > > dragged in that slow transfer too (no DMA, no cache, etc.)? > > Does this happens to all users, but since there are more powerful > > configuration involved the delay is not so noticeable? > > Mount your file systems with the softdep flag (described in mount(8)). > This should bring HDD i/o to what you're used to on other operating > systems. This has the unfortunate side-effect that this is not quite the official configuration. softdep is somewhat supported but if you experience panics related to this, good luck getting them fixed. (I've stopped using softdep entirely on bulk machines. NFS having burps from time to time is enough to cope with)
Re: OpenBSD 7.1 and unbound 1.15.0
On 2022-04-27, Renaud Allard wrote: > This is a cryptographically signed message in MIME format. > > --ms080604030904040206090102 > Content-Type: text/plain; charset=UTF-8; format=flowed > Content-Transfer-Encoding: 8bit > > > > On 4/26/22 16:25, Renaud Allard wrote: >> >> Hello, >> >> Since I upgraded my DNS servers to 7.1 with unbound 1.15.0, I have a lot >> of issues with DNS resolution (without changing anything in the config). >> I randomly get SERVFAIL (or somethings NXDOMAIN) for a lot of names, or >> something even stranger like some addresses and SERVFAIL for others (see >> dashlane example). >> >> Examples: >> host dashlane.com >> dashlane.com has address 65.9.82.43 >> dashlane.com has address 65.9.82.13 >> dashlane.com has address 65.9.82.36 >> dashlane.com has address 65.9.82.97 >> Host dashlane.com not found: 2(SERVFAIL) >> Host dashlane.com not found: 2(SERVFAIL) >> >> >> host forum.opnsense.org >> Host forum.opnsense.org not found: 2(SERVFAIL) >> > >> use-caps-for-id: yes > > After removing the use-caps-for-id, it seems the resolver works fine. I > opened the following bug report > https://github.com/NLnetLabs/unbound/issues/670 I'm not aware of intentional changes in use-caps-for-id between the versions of Unbound in 7.0 and 7.1, it might be worth trying the old version again to rule out a coincidental change on the authoritative servers for those domains, it can happen. (there is some fallback in unbound for hosts which don't handle this, but I think it might not cope if there's differing behaviour between multiple hosts load-balanced behind a single backend IP). Maybe consider packet captures to the auth servers for some domains you've seen problems? You aren't on an ISP which might be intercepting some DNS requests are you?
