Re: Doesn't work prtsc button on Tex Shinobi keyboard
On Fri, Oct 11, 2024 at 5:48 PM Kirill A. Korinsky wrote: > > On Fri, 11 Oct 2024 19:07:03 +0200, > Pascal Stumpf wrote: > > > > On Tue, 08 Oct 2024 16:59:26 +0200, Kirill A. Korinsky wrote: > > > misc@ > > > > > > I made an assumption that I'm not the only one using Tex Shinobi's > > > keyboard, > > > and just discovered that the Prtsc button doesn't work. > > > > > > Not working means that xev doesn't register an event. When I press it, it > > > looks like I'm not pressing it. > > > > > > I was almost sure it was working a while ago, like this spring. > > > > > > Does this ring a bell for anyone? tex shinobi is a great keyboard, that replicates the old ibm 8845 ultranavs very well in a modern mechanical format. thanks for reporting this bug, and it looks like the fix will also fix special key problems other folks have run into. > > > > Yes, I can confirm this behaviour on a Keychron Q6. > > > > Here a diff which fixed Prtsc button on my keyboad. > > Index: driver/xf86-input-keyboard/src/at_scancode.c > === > RCS file: /cvs/xenocara/driver/xf86-input-keyboard/src/at_scancode.c,v > retrieving revision 1.5 > diff -u -p -r1.5 at_scancode.c > --- driver/xf86-input-keyboard/src/at_scancode.c17 Dec 2015 06:03:10 > - 1.5 > +++ driver/xf86-input-keyboard/src/at_scancode.c12 Oct 2024 00:25:40 > - > @@ -95,6 +95,7 @@ ATScancode(InputInfoPtr pInfo, int *scan > case KEY_KP_Decimal: *scanCode = KEY_Delete;break; /* curs > delete */ > case KEY_Enter: *scanCode = KEY_KP_Enter; break; /* > keypad enter */ > case KEY_LCtrl: *scanCode = KEY_RCtrl; break; /* > right ctrl */ > +case KEY_ShiftL: > case KEY_KP_Multiply: *scanCode = KEY_Print; break; /* > print */ > case KEY_Slash: *scanCode = KEY_KP_Divide; break; /* keyp > divide */ > case KEY_Alt: *scanCode = KEY_AltLang; break; /* > right alt */ > @@ -113,7 +114,6 @@ ATScancode(InputInfoPtr pInfo, int *scan > keyboards */ > case 0x01:*scanCode = KEY_R_0xF4;break; > case 0x03:*scanCode = KEY_R_0xF5;break; > -case 0x2A: > case 0x36: > return TRUE; > default: > > > -- > wbr, Kirill >
Re: Unexpected reboots after upgrading APU2 to 7.6
On 10/14/24 07:14, Ian Chilton wrote: Hi, I've got a few PCEngines APU2 boxes I use as routers at home. I updated 3x of them from 7.5 to 7.6 a few days ago. Since then, one of them has randomly spotted responding 3x times in just over 48 hours when it was stable for months previously. On opening the serial console, I see it sat at a 'dbb{0}>' prompt. Thankfully I am able to type reboot there and it comes back up fine. It's not logging anything the logs go from standard routine jobs like syslogd restarting to booting up. It's also sat doing very little - it has a PPPoE connection to a VDSL provider, a PF ruleset and is just doing standard firewalling and routing. The other 'identical' apu2 boxes I upgraded seem fine so far. Are there any known problems? - or anything I can do to troubleshoot further? Three identical machines, two behaving, one misbehaving. Looking at the OS is probably the wrong path here. Sounds like a clear hardware problem to me. My bet: power pack. I had something like that happen recently myself -- stable machine, I believe the problems started when I did an upgrade on it, it just wouldn't stay running after that. I was about to chuck it in the trash and replace it (I have plenty of others of these systems, and they were all fine), and I looked at the power pack I had on it...and realized how anemic it was. I think it was one I did a "let's see what I can get away with on these things". Replaced the power pack, it's been solid ever since. SPECULATION: The power draw during an upgrade is a lot more than the normal day-to- day power draw, due to the install kernel not having all the power management code of the production kernel. So...a borderline and already stressed power pack may just decide that's a good time to finish getting flakey. Nick.
Re: Crash when cold booting
On 10/11/24 12:26, Joe B wrote: Hello, Today i booted into openbsd and got this https://0x0.st/X6aV.jpg <https://0x0.st/X6aV.jpg> I don't know where to start and what to do.. IRC advised to file a report but i was wondering if anyone here can tell me what it is ? I rebooted and everything was working fine.. just curious to see what pepole have to say. It works much better if you type a few things from the message to get the right people's attention, THEN give them a link to the photograph. The panic message is pretty suggestive. "panic: ffs_valloc: dup alloc" ffs often means "Fast File System", the standard BSD file system. Combine that with shortly above, there is fsck activity, hinting at an "abrupt" shutdown. (hmmm. Rapid Unscheduled System Termination? RUST? Nice name overlap with the current "Will definitely replace C this time!" language, so perfect to add confusion to the computer world.) So...my guess is you got had an event causing a hard shutdown, the file systems were left in an unclean state, and the first pass of boot fsck's didn't quite catch everything. The good news is, the panic resulted in another fsck at boot, and this time, it caught whatever it puked over last time. Nick.
Re: Server inaccessible after upgrade from 7.5 to 7.6
On 10/10/24 14:14, Sebastien Marie wrote: Mark writes: Hi. I got 2 VPS, yesterday I upgraded one, from OpenBSD 7.5 to OpenBSD 7.6 (amd64), today I wanted to upgrade the remaining one, after "sysupgrade -nk" and "reboot", I cannot login to the system anymore (I manage only via SSH), Putty says: "Remote side unexpectedly closed network connection", after entering the password of my root user. I tried ssh in the Windows terminal, same thing happens. ssh server is running, login: prompt arrives. And I see that my ssh client disconnects after issuing the correct password. If the password is wrong, it attempts to ask for it again. I got no physical or console access to the server. Any idea would be much appreciated. From your description, I assume your shell is from ports (bash, zsh, ...), and that after the upgrade of base, the binary of the port (from 7.5) doesn't run on 7.6 system for some reason. So, sshd runs (it is 7.6), you connect : sshd execve the shell, and it doesn't ends well. that was my first assumption, too. You can try to connect to another user (if possible) using some base shell, or try to get a console (the getty) and logs as root (assuming the shell of root is still ksh). Might try this: ssh remotehost ksh it will probably look like it hung, but it might not be -- you are just sitting at ksh without $PS1 (or much of anything else) set. You might be able to gain control of the system sufficiently to run pkg_add -u. Here's an actual demo: $ uname -a OpenBSD fluffy3.in.nickh.org 7.5 GENERIC.MP#171 amd64 $ ssh dbu1 ksh uname -a # note lack of prompt, motd, or anything... OpenBSD dbu1.in.nickh.org 7.6 GENERIC.MP#337 amd64 # but I'm in! you can get around some of the no prompt/no motd stuff by doing "ssh ksh -li", but it's still quite weird. you know all those times when you said, "I don't need to know 'ed(1)'"? well...maybe you now need it. Warning: when I promoted myself to root, the PW echoed on the screen. So...beware of shoulder surfers. :) (and I'm sure there are fixes for all these issues, but I didn't hunt very hard) Nick.
Re: Failed re-install with bsd.rd and full disk encryption
On 10/9/24 17:06, Thomas wrote: Hello all, I have attempted to upgrade from 7.5 to 7.6 on a VPS with encryption. As /usr was too small (< 1G left), I chose to re-install and re-partition. I downloaded bsd.rd, checked it, etc. and rebooted it. Following the install steps, I was not offered the choice to encrypt, only to choose sd0 or sd1. With hindsight, I should probably have chosen sd1, re partitioned and called it a day. What I did is tried to follow the OpenBSD FAQ 14 for softraid + this guide: https://www.tumfatig.net/2020/fde-on-openbsd.amsterdam-opinionated-vm I could not detach sd1 (bioctl -d sd1) with the following error: softraid0: refusing to delete boot volume. So, I tried to erase entirely the drive, thinking that since bsd.rd was in RAM, it would forget about the previous volumes / partitions. It did not work, after using dd if=/dev/urandom of=/dev/rsd0c bs=1m, using disklabel to create sd0a showed: disklabel: DIOCWDINFO: Device busy when trying to write. I have given up (and I think that's my last question of the series) and asked for the VM to be reimaged but I wonder where that went wrong in trying to re-install with bsd.rd. Yes, bsd.rd runs from RAM, but you loaded it by unlocking the encrypted drive that became sd1. The system boots, sd1 is seen by the OS, so it can't be casually deleted, as the kernel has already become aware of it. Because of that, you can't detach the drive (I think? I haven't tried this, but I recognize the rest of your problem :) ) your dd'ing trash over sd0 worked, but the disklabels are stored in RAM, so the system wouldn't know until you rebooted. (personally, I'd suggest zeros over random data if you are just trying to free up the disk. OpenBSD won't have a problem, but I've seen lesser OSs freak out if the disk has magic bytes in magic places in the early part of the disk) For what you trying to do, after zeroing the drive, you needed to reboot using other media for bsd.rd (netboot, usb, CD, etc). Now you would have no partition tables on sd0, and thus, no sd1. For your goal -- repartitioning an established system, boot bsd.rd, then just delete and create partitions on sd1. No reason to delete sd1 itself, your encrypted drive was just fine, it was just the disklabel partitions within it you wanted to rework. Nick.
Re: Do Spectre-V4 mitigations protect VM guests?
On 10/8/24 07:50, Anders Andersson wrote: While reading the release notes for 7.6, the first change is "Implemented Spectre-V4 mitigations for arm64". There's now a number of Spectre-type flaws and mitigations, and I realize I don't know enough about them. An idle question that popped into my mind was: Does this mitigation protect vmm/vmd guests? If so/if not, does this generalize software mitigations for all Spectre exploits? I'm primarily interested in a situation where I run an up-to-date OpenBSD with this mitigation on bare metal, and then run an older OpenBSD or a linux variant in a VM. well, I'm not at all an authority on arm64, vmm or Spectre exploits, but the basic premise of your query causes me to twitch: the idea that adding a virtualization layer might be a net improvement in security. That seems mighty unlikely. Even IF a particular flaw could be mitigated by a hypervisor, probably far more likely to add new ones by stacking layers of OSs. As an excuse to "run an older" anything, no, that's just a bad idea. REALLY bad. Also remember: most security compromises are done through bad administration and buggy applications. REAL LIFE data loss or system compromise from these processor flaws is fairly rare (has it ever even happened?), It is something that should be fixed, but ... it isn't the low-hanging fruit for most systems. Unfortunately. Nick.
Re: checksums to detect/correct bit-rot
On Sun, Sep 15, 2024 at 12:22 AM Jonathan Thornburg wrote: > > Does OpenBSD support any file systems with built-in checksums to > (try to) ensure metadata and/or data integrity in the face of "bit rot" > disk (or memory/cpu/USB) errors? I'm not looking for ZFS-style storage > pools or logical volume management, "just" checksums to catch silent > metadata and/or data corruption. > > Softraid 1, 5, or 1C could in theory do this, but with a large space > overhead (a factor of 2 to detect errors, or 3 to correct errors). > And, the current (7.5) man pages don't mention any option to have each > read read all the chunks and verify that they're identical. > > And a related question: I have a pool of ~10 external USB3 backup > disks (all consumer-grade WD or Seagate 2.5" spinning rust, either > 2TB or 4TB capacity each), all currently setup with FFS2 filesystems > on top of softraid crypto (/bioctl -c C/). Each backup is to a single > disk, written with (roughly speaking) > rsync -aHESvv --delete /home/ /mnt/home/ > Each disk thus has slightly different contents depending on how > recently I did a backup to that disk, but the vast majority of the > files (those that haven't changed recently) should be identical > across disks. > > [Before anyone asks: Yes, I regularly rotate some of the disks offsite. > And yes, I regularly restore files "in anger".] > > Each backup disk somewhat more than 1e13 bits, so at an unrecoverable > bit error rate of 1e-14 or 1e-15 for consumer disks there's a non-trivial > chance of a bit error somewhere in my backup pool. > > Thinking about how to detect/correct bit-rot in these backups, it > occurs to me that I could hack up some Perl to walk the filesystem > tree on a mounted backup disk, /stat()/ and read each file, and build > a database of (pathname, inode mtime, checksum) tuples. (I could either > ignore symlinks, or checksum the result of /readlink()/.) Then given > such databases for a bunch of disks, a bit more Perl could read all > the databases, find all the files with matching pathname and inode > mtime (so that the contents should be the same, given that my usage > of /rsync/ preserves /mtime/), look for differing checksums, and for > any differences, majority-vote the checksums to identify which copy > or copies is in error. > > But before I reinvent the wheel, can anyone point me to software > which already does this? Bonus points if the software is already > in ports. perhaps you would find mtree(8) helpful. > > Thanks, > -- > -- "Jonathan Thornburg [remove -color to reply]" > >on the west coast of Canada >"The programmers outside looked from Web 2.0 firm to AI company, and from > AI company to Web 2.0 firm, and from Web 2.0 firm to AI company again; > but already it was impossible to say which was which." >-- /Ars Technica/ comment by /ubercurmudgeon/, 2024-05-09 > > >
Re: failed to install bootblocks
On 9/4/24 10:17, openbsd_fr...@mail2tor.com wrote: When installing I get failed to install bootblocks. Trying a second time using MBR it install but "default boot device missing". Any suggestions? Thank you. I suspect it is either something you have done wrong, or you have some unusual HW setup. Either way, your problem report is not useful. So...tell us exactly what you are doing, exactly what you are doing it on, and what you are doing that's different than the rest of us who aren't having this problem, and maybe we can help. It would be nice to see a dmesg, but I realize that's a little difficult on a system that won't boot. SOME important bits: BIOS vs UEFI boot OpenBSD version? HW run on? Softraid? What are you booting from? multiple disks? multibooting? Exactly what error messages are you seeing at exactly what point? Nick.
Re: Installation USB
On 8/27/24 02:18, openbsd_fr...@mail2tor.com wrote: I cannot install OpenBSD using flash usb media. The installer stops at (disk, http, nfs etc). After partioning. The install USB boots up and everythings goes well until I reach the part with the data sets. The installer cannot find usb media. This definitely works in general. So give us some more info about what you actually did and what you actually saw, maybe we can help you. But do note: the booting is managed by the system firmware until the OS loads, then the OS takes over HW support. So it is POSSIBLE (though unusual) to have incompatible hardware boot an install media just fine then fail to see a disk. But your answer to the disk/http/nfs question will be "disk". The disk will be the USB drive's 'a' partition, and it is not currently mounted. Nick.
Re: How to trim SSD?
On 8/11/24 15:44, Oliver Peter wrote: Hi! How do you guys trim your SSDs? Or shall I ask "do you trim your SSDs at all"? Does OpenBSD have similar functionality like https://man.netbsd.org/blkdiscard.8 ? I recently rented a phys. machine and installed OpenBSD on it[1], smartctl already tells me that the disks have seen better times, that's why I am a bit worried about wearing them out even faster without trimming: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 202 Percent_Lifetime_Remain 0x0030 075 075 001Old_age Offline - 25 202 Percent_Lifetime_Remain 0x0030 078 078 001Old_age Offline - 22 Cheers Oliver [1] Little write-up: https://hackmd.gfuzz.de/s/Qsk14kc3i (OpenBSD & Hetzner) No, OpenBSD does not do "TRIM" (unless something was slipped in when I wasn't looking). There are a lot of ways a hard drive fails...mechanical failure of magnetic drives is JUST ONE WAY. SSDs are prone to all the same electronic failures, minus the mechanical failure, plus billions of tiny capacitors trying to store data for years, any of which failing to do their job well will ruin your day. Oh, and "write fatigue". (I have a bit of knowledge of how floating gate storage works, and frankly, it gives me the creeps. It's amazing it works at all, but obviously it does). Are you catching my drift as to just how tiny the "write fatigue" "problem" is in the Big Picture? Even if you got rid of 100% of "write fatigue" failures, it probably be almost a rounding error in the total picture of "reasons for unexpected downtime". And if you can't handle an unexpected downtime, you should probably be thinking about "bigger picture" solutions than TRIM. But really, for something important, I'd suggest retiring your hw (all of it) every five years, or at least demoting it to lower importance roles. I'm all-in for recycling hardware, but HDs are so bloomin' cheap, just buy new ones every few years, it's not worth worrying about. If you really want to arrange the deck chairs on the Titanic, get a drive a lot bigger than you need (say...250G for a firewall), allocate 20GB of that for your FW at the front of the disk. In a year, replace that first 20G partition with a new one, in the next 20G of the disk. In a few years, maybe you need 25G or 30G. But this way, you can never use storage that has been worn for more than a year. Might get ten years of "fresh" disk on a single SSD that way. Do this, I'll laugh at you. :) Nick.
Re: Automatic Disk Partitioning
On 8/4/24 15:16, David Uhden Collado wrote: Hello, I have observed that the automatic partitioning feature of disklabel(8) does not allocate more than approximately 350GB to system partitions [1]. In my opinion, the tool should have been designed to use all available space on the storage device when partitioning. I'd say, your opinion is wrong. I would like to understand the rationale behind this design choice. Is there a specific reason why the automatic partitioning is limited to around 350GB for system partitions? Any insights or explanations you can provide would be greatly appreciated. It is basically impossible to buy a conventional (and because it is 2024, let's include SSDs in "conventional") hard disk which is too small for OpenBSD (or any other OS, really). And especially since most modern OSs have at least some ability to expand into unused space, Honestly, I would prefer if the /home partition capped out at 20G or so. After that, whatever is being done with the system should dictate where space goes. Unused space is a valuable resource on any computer. Over the life of a machine, initial decisions almost always turn out to need revision. With unused space, I can do amazing remote rebuilds of systems remotely (or at least, without getting out of my chair). But if you are building a firewall, you need maybe 20G of space, but the smallest "disk" you can get is 120G...there's ZERO reason to allocate all 120G. Allocate what you need, and then you can adjust later if needed. Yes, I practice what I preach. Here's a firewall of mine: sd0> p g OpenBSD area: 64-312576705; size: 149.0G; free: 0.0G #size offset fstype [fsize bsize cpg] a: 0.5G 64 4.2BSD 2048 16384 8032 # / b: 6.0G 1028160swap# none c: 149.1G0 unused d: 5.0G 13623136 4.2BSD 2048 16384 12960 # /usr e: 1.0G 24113536 4.2BSD 2048 16384 12960 # /tmp f:10.0G 26218080 4.2BSD 2048 16384 12960 # /var g: 2.0G 57689408 4.2BSD 2048 16384 12960 # /usr/local h: 5.0G 47198944 4.2BSD 2048 16384 12960 # /home o: 117.5G 66107456 4.2BSD 2048 16384 12960 yes, there's a 117G partition to show me quickly how much I have available should I someday decided to move things around. Delete it, change what I want. (and yes, I did basically all custom partitioning on this system. That, I don't recommend. Follow the defaults (except for size of /home) until you are good enough that you can deal with the issues when you find out you were not as smart as the OpenBSD devs after all. I like hitting those issues, because then I learn something). Nick.
Re: trying to boot on HP EliteBook 820 G1
On 7/24/24 08:24, Jan Stary wrote: On Jul 24 07:46:09, kolip...@exoticsilicon.com wrote: On Wed, Jul 24, 2024 at 12:19:34PM +0200, Jan Stary wrote: > The problem persists with every USB stick, > with each of miniroot75.img, install75.img > and a full usb stick install, on every USB port. Out of curiosity, does the machine successfully boot OpenBSD/i386 from a USB stick? No. Booting install75,img gets to boot>, but stops at the booting hd0a:/7.5/i386/bsd.rd: | The rotating slash stops rotating and the machine freezes This is what _sometimes_ also happens with amd64, but more often, the amd64 reboots at that point. Interesting twist -- boots from installed SSD but not from install image on USB. So ... while you are thinking there's a boot issue with USB, I'm more inclined to believe it is the install kernel vs. the full kernel. So ... two tests...one easy, one slow: 1) Can the installed system boot the install kernel from SSD? boot> boot bsd.rd 2) IF on another computer you build an installed system on a USB stick, so rather than booting the installer, it boots an installed OpenBSD, will that work on this machine? I'm betting a very tiny amount of money #2 works, but #1 fails. I have a machine where bsd.rd fails because there's no monitor attached to the HDMI port. Attach a monitor or HDMI "fake monitor" plug, and the thing boots bsd.rd fine. But...it's a thin client machine, no monitor at all..I'm having trouble believing your laptop is having this same issue. (this particular machine is noted for this problem on Linux, too, except Linux won't boot headless at all; the full OpenBSD kernel boots just fine headless, but you can't do a headless upgrade.) Nick.
Re: trying to boot on HP EliteBook 820 G1
On 7/22/24 09:22, Jan Stary wrote: I am trying to boot current/amd64 on this HP laptop from USB stick. Disabling the "secure boot" in BIOS, so that something else than the preinstalled windows is even allowed to boot, and choosing USB Flash Disk as the boot source, I see the usual Using drive 0, partition 3 etc, up to boot> There, the rotating slash either stops and nothing else happens, or the machine reboots after the first number in booting hd0a:/bsd 12345678 + [reboot] This happens with both bsd and bsd.rd. The USB stick holds a full current/amd64 installation which I regularly boot on various amd64 machines, so I don;t suppose that is the problem. Any clues please? Jan Have you tried UEFI and "Legacy" modes? I've seen some machines that like one over the other. But yes, HPs are weird. Some work great, others are horribly non-standard, "Works with windows, ship it!". Nick.
Re: CD/DVD install failed
On 6/23/24 09:40, Anon Loli wrote: Installer medium is a BD-RE(I think) CD, everything worked up until this error while installing fileset base75.tgz: "Installing base75.tgz 100% |***..**| 408 MB.. gzip: stdin: crc error That's pretty clear. tar: End of archive volume 1 reached tar: Premature end of file on archive red Installation of base75.tgz failed. Continue anyway? [no] The destination medium is a nvme ssd, with FDE, it has a very fast CPU, 16GB RAM, etc., the deviations from the installer defaults are as follows: - did a DD of /dev/urandom on the same disk - custom partitioning scheme, /root is the a partition I did verify the install medium with signify, etc. did you verify the install MEDIUM, or the install image file? Big difference. The way I wrote to the disc was by using cdrecord, writing mode was DAO And the fact that you got that far indicates your basic process was correct. I didn't continue, and it again asked for pathname to sets and stuff, and I repeated the installing process again (without rebooting or anyhting), and now comp75 failed, same error, but this time it defaulted to "done" on file sets location and I didn't notice thats right away, so I didn't get to see if it'd continue The system won't run without baseXX.tgz, so skipping it is not a good thing. compXX.tgz can be skipped and installed post boot. Not a good thing, but recoverable post-install. on the next reboot, I only did the partitioning scheme deviation Now the error message is the exact same, except after "volume 1 reached" now it says "tar: Failed seek on file ./var/yp/README: Invalid argument so I went to redo the installation of base75 again just as last boot, and now I got this when base75.tgz was at 97% installated: "...ETAtar: Invalid header, starting valid header search." ...base75.tgz 100%... (and then the 1st error message repeated) I'll abort this and install via USB instead because I have to do something that's time sensitive You have an issue in the CD creation process. Either your burner is bad, your media is damaged, or the reader is bad. I've seen all three, lots of times. Be glad you got the error...back in the olden days, I had a drive that would happily install every Novell Netware file on a server...but most were corrupted. Nick.
Re: sshd /var/empty
On 6/19/24 00:42, 4 wrote: On Tue, Jun 18, 2024 at 4:14 PM 4 wrote: i'm sorry, i'm not smart, but i have a several questions. imagine that we launch a ship far into space. we have only one communication channel with this ship, and one day, when the ship is already very far away from us, communication channel stops working [...] You did something wrong. It's pretty apparent from the tone of your message you don't want help identifying what it was or how to fix it, but for the benefit of others who find this thread in the future, read the sshd_config man page to find out how to use the ChrootDirectory option correctly. i'm not talking about how to properly use chroot, but about the fact that sshd refuses to launch because /var/empty has "too many rights". You seem to fail to understand one of the basic goals of OpenBSD: security through correctness. Your starting example (spaceship communications) is the an example of "Fail Open" -- when things go wrong, you want to be able to retain/regain control and fix the problem. (It is also an example of "embedded systems" programming, where faults just aren't supposed to happen. But it also mandates very simple and verifiable code). OpenBSD is very much a "Fail Closed" design. If someone is storing your personal information on an OpenBSD server, and that server is compromised, which would you rather happen? 1) system continues to operate as best it can? 2) Shut down, panic, stop doing whatever it was doing that allows your data to escape? You clearly think option 1 is the preferred choice. OpenBSD developers (and I) prefer option 2. Let's look at /var/empty, which you are so upset about. That's not a storage location. As the name implies, it is intended to be an empty directory. The sshd process is chrooted into it. It isn't just your sshd's home directory, it's its entire existence. If something goes wrong with sshd, we want it confined within a space with no files, and a space it can't create files and can't wander out to the rest of the file system. If someone finds a way to "break" sshd, the first hope and first line of defense is it should crash and just kick the user out. Failing that, we don't want the attacker to be able to wander the tree or create files. Back to your spaceship example...if at launch time, the control systems detect the fuel tank is full of LOX, the LOX tank is full of fuel, and one of the side boosters is mounted upside down, what do you want to happen? You seem to advocate yelling, "You only live once!" and hitting the launch button. Again, that's not the OpenBSD way. I do believe an OpenBSD developer once took great pride in how UNSTABLE the OpenBSD kernel is. The code has a path it needs to follow, deviate from that path, and things get killed. Deliberately. By design. Because...the code shouldn't have done that, and if it isn't playing by the rules anymore...it needs to die because it can't be trusted. Uptime is good. Security is good. Most people say, "Security is most important!"...then start listing the exceptions. "high uptime" "Run my favorite poorly written software". So really, security is the least important consideration. You want to be able to break your system and repair it over the network without console access. To your credit, you are honest about that. That's your call, but you are gonna want a different OS. Perhaps Windows 95 (remember the user name/PW prompt, where if you just hit ESC, it went away and dropped you at the desktop?). OpenBSD is probably not the tool you want. Nick.
Re: booting and RAID-5
On 6/15/24 09:05, Marco van Hulten wrote: Hello, I got a new amd64 system with 3 NVMe disks of each 2 TB, with the idea to put them in RAID-5. I did not realise until now that one cannot boot from RAID-5. Would a good approach be to create a root device on one disk (and maybe altroots on one or both of the others) and use the rest of all disks as RAID-5 device? Or is there a good reason to boot from a disk separate from the envisioned RAID-5 configuration? I just set something up like this, myself. Four 4T disks. I wanted redundancy but also recoverability. My solution: each drive has a 25G disklabel partition and a "almost rest of drive" disklabel partition ("almost rest" because I'm paranoid about having to someday replace the drive, and finding the new drive is a thousand sectors smaller than the old drives. This hasn't been much of a problem in my observation lately, but I'm old, I remember when Seagate shipped two drives with the exact same model number, but the replacement drive had one less cylinder than the original drive...not fun!). The 25G partitions are in a four drive RAID1, and the "rest of drive" partitions are in a RAID5 config. The base OS and all standard partitions is in that 25G array, the "rest of drive" is all data storage. So..if I lose a drive (or several), I should be able to boot at least the core OS and get some idea what went wrong. If you need a larger core OS system, go for it. I do NOT recommend putting just the root partition on this drive. Make it stand-alone useful. At this point, some of the kids start screaming, "you can't do a four drive RAID1!". Yes you can. The fact that your HW RAID card can't, doesn't mean it's an invalid concept. softraid (and at least some other software RAID systems) handles >2 drives in a RAID1 config seemingly just fine. It's four copies of the same data. Stunningly inefficient, not very fast for writes but very robust. And, what else am I supposed to do with the 25G empty space on the other drives, anyway? :) (a further benefit -- if I have to swap the drives to another physical machine, ANY of the drives will able to be booted, I don't have to make sure I get the right drive in the "drive 0" position). One big word of warning: when you have to replace a drive on a system like this...rebuild one array than the other. You probably don't want to have the system thrashing between the two partitions on the same disk; that's a great way to turn a slow process into a glacial process (though probably not so big a deal with SSDs as it is with spinning drives). So when I test the drive replacement process, I plan to rebuild the OS partition first (anticipated time: minutes), then the data partition later (anticipated time: days). And yes, I'm testing the behaviors of this thing and the drive replacement process before I commit it to production. Nick.
Re: Edit: Installation amd64 7.5: How to access the distribution sets on the USB stick?
On 6/7/24 18:26, rfab...@mhsmail.ch wrote: Edit: I have just found in Michael W. Lucas' "OpenBSD Mastery: Filesystems" that "the rd recovery disk image is the OpenBSD install environment", not the USB stick. But my question (see below) remains the same. Am 2024-06-07 23:21, schrieb rfab...@mhsmail.ch: Dear community I have copied the 'install75.img' to a USB stick, booted from it and chosen the "(I)nstall" option. My intention is to install the distribution sets from the stick, and not via http, because I'd like to install OpenBSD on our 4 home office PCs without downloading the sets 4 well...OpenBSD is small, and bandwidth is cheap/free. But yeah, I was "recycling" back when it was called being "a cheap bastard", I get it. Escaping to a shell and entering 'sysctl hw.disknames' shows: 'sd0, sd1, sd2, rd0'. 'sdX' are the 3 internal SSDs. Am I right in assuming that 'rd0' is the USB stick? as you have discovered...no. Installation step "Let's install the sets!": I have chosen the option to install from a local disk partition, and answered with "partition not mounted". correct. Issue: The installer shows 'sd0 sd1 sd2' as available disks, but not the USB stick 'rd0'. also correct. Besides, rd0 is mounted. But it is also wrong. Question: What do I have to do to make the USB installation stick available for accessing the distribution sets? Concerning 'install75.img', the "Installation notes" say: "An install or upgrade can be done with a USB key without network connectivity." But how? dmesg|grep sd will show you what all the devices are, pick your USB drive. It will guess correctly after that. Installing the sets via http works without any issues, but that's not my plan for the remaining and future installations. But here's an easier way, if you understand a bit of what is going on. The system booted from bsd.rd, and it has utilities in "rd0". At this point, it is NOT ACTUALLY USING the USB drive. So...you can now unplug and plug it back in...and you will get some white on blue text telling you what device was unplugged and what was plugged in. Of course, you don't really want to do that if you don't know for sure that the drive is unused, but if things are as you describe it, it's safe. But most likely, it's sd2, because USB devices are enumerated AFTER IDE/SATA/SCSI/SAS/RAID connected drives. (but there are things that can happen that keep me saying, "most likely" and "here's how you find out" rather than just assuming sd2. :) ) Nick.
Re: mounting audio cd
On 5/31/24 14:15, MIZSEI Zoltán wrote: Interestingly BeOS and Haiku lets you to mount an audio cd, it generates a vfs from the toc and shows the tracks as wav or flac (fixme), it does an automatic conversion behind the courtains if you copy a file from an audio cd. To each their own, I guess, but I don't consider this a good idea. To me, that sounds like a lot of unneeded magic going on at the kernel level that should be a non-root, application thing. The few times I want to directly see the data on a CD, I'm generally digitizing the contents of the CD, and running an application to do that is just fine with me. OpenBSD provides cdio(1), which has the "cdrip" option to extract audio tracks to .wav files. In the base system. Nick.
Re: advice debugging lockups with swap-thrashing symptoms?
On 5/23/24 03:18, Stuart Henderson wrote: On 2024-05-22, James Cook wrote: One of my OpenBSD boxes sometimes gets in a weird locked-up or almost-locked-up state. I'm wondering what I can do to debug it further next time it happens. ... I would also expect the cache number to be much higher. E.g. on this occasion, I was running "git annex fsck", which reads plenty of data from disk. Heavy filesystem access can result in this sort of thing, I used to have unpacked ports source on one of my machines for grepping over, the machine was pretty much unusable for anything else while that was running. Might be worth trying some noatime mount flags if you don't already have them, at least then you can avoid turning some reads into writes. Definitely a possibility. Long time ago, I think I asked about the possibility of a "disknice" to throttle disk access on individual tasks. TedU@ came through for me with something that definitely solved my problem, and I use it from time to time since -- basically, it just suspends a particular program occasionally, which lets other programs have a chance to get disk access. I saved it (and made a tiny update that is needed now) and put it here: https://holland-consulting.net/scripts/disknice.html Also... I've seen disks "fail" where they get super-slow. The failure modes seems to be difficulty reading data...but after enough retries, it succeeds, resetting the retry counter back to zero, and then the next read encounters the same problem. You may be able to hear lots of activity on the drive with little obvious progress. I'm not convinced this is your problem, but ... something to consider. Nick.
Re: how to fsck automatically at boot
On 5/22/24 08:08, Kirill A. Korinsky wrote: On Wed, 22 May 2024 12:53:11 +0100, Nick Holland wrote: For reasons of multi-hour fsck's on a few systems, I'm looking at remounting the problem file systems as "rw" when writing is actually needed and "ro" after the writing is complete (IN THIS APPLICATION, this is known) to reduce my "at risk of power outage" window a lot, but I suspect this will fall deeply within the category of "when I break things, I get to keep all the pieces". :) Do you need atime on that FS? Disable it dramatically reduces chances of manual interraction with fsck. If you move forward and add sync which slow down write but allows to get almost zero porbability of fsck interraction. Already done. :) This is a backup system I have -- lots of symlinks, lots of files. Cool thing is, the fsck is painful, but almost never have to help the fsck along, at least once softdep was removed and they quit crashing in the middle of backups. (softdep removal really hurt these systems -- some tasks went from an hour or so to many hours...but it doesn't impact my life one bit. On the other hand, obviously I was tickling some of those softdep bugs I had heard hit some people). And in other news: couple days ago, I said I rarely need manual intervention on the systems I just yank the cords from. Well, this morning, a system I manage remotely apparently had a couple power events, and one system needed help with the fsck. That's what happens when one boasts. :D Nick.
Re: how to fsck automatically at boot
On 5/21/24 08:28, Stuart Henderson wrote: On 2024-05-21, Nick Holland wrote: ... When I remove that disk the boot sequence stops and asks for a fsck I would like that this disk is mounted when it's present, but when it's not installed I don't want the boot sequence to stop Make it also "noauto" in fstab and mount it in rc.local. Last I tried this, it didn't do what I wanted -- "noauto" still expects to have the disk there and will fsck it on boot. Failure to be able to do this stops the boot. It's been a while since I last tried this, so perhaps something has changed (including my recollection?) See fstab(5) about fs_passno. ah, so "0" or blank. cool. learned something. That will simplify a few things! And this might be a solution for the OP's problem: make /usr and /usr/* "ro" during normal operation reorder_kernel is run in the background from /etc/rc; for RO /usr you need to wait for that to finish. And I forgot that. d'oh. So yes, file my tidbit under "REALLY BAD ADVICE" and ignore it. For reasons of multi-hour fsck's on a few systems, I'm looking at remounting the problem file systems as "rw" when writing is actually needed and "ro" after the writing is complete (IN THIS APPLICATION, this is known) to reduce my "at risk of power outage" window a lot, but I suspect this will fall deeply within the category of "when I break things, I get to keep all the pieces". :) Nick.
Re: how to fsck automatically at boot
On 5/20/24 09:37, Jan Stary wrote: On May 20 13:22:26, mikyde...@yahoo.fr wrote: Hello, I have two use cases and problems with fsck. 1) When my openbsd boots after an outage, the system asks me to fsck /, /usr, /var or /home manually. So I do fsck /dev/sd0a And then I'm asked questions and I usually answer F So my question is that I want this process to be done automatically at boot time for each partition that has a problem. The /etc/rc boot script calls fsck -p; if that fails, it means fsck -p was unable to fix a major problem. It is the point that it requires an admin's intervention. You would have to change the fsck call to fsck -y; but don't do that. I'd look at why your file systems are always needing these manual interventions after a hard shutdown. I routinely power down my personal systems with yanking the power cord if it would take me longer "properly" connect a console and properly shut down. yeah, I get fscks, but I rarely get a manual intervention required. It does happen...but rarely. (Also, don't let a server have power outages, obviously.) This is because I use a small server without screen and keyboard. So what? That is no excuse to leave broken filesystems unattended. 2) I have another disk in my small server, and I mount one partition of it with in fstab aa929243b0f5.a /var/mylogs ffs rw,nodev,nosuid 1 2 When I remove that disk the boot sequence stops and asks for a fsck I would like that this disk is mounted when it's present, but when it's not installed I don't want the boot sequence to stop Make it also "noauto" in fstab and mount it in rc.local. Last I tried this, it didn't do what I wanted -- "noauto" still expects to have the disk there and will fsck it on boot. Failure to be able to do this stops the boot. It's been a while since I last tried this, so perhaps something has changed (including my recollection?) I have some backup servers with big file systems that can take hours to fsck. I pulled the mount lines out of /etc/fstab and put them in a separate script that is invoked at boot from /etc/rc.local And this might be a solution for the OP's problem: make /usr and /usr/* "ro" during normal operation, and move all the "lots of volatile data" stuff over to partitions that are mounted post boot by a separate script. Maybe make /tmp an MFS if that's an option. That will minimize the fsck problems, and allow the system to come up for either manual, remote fixing or even fsck -y in the mountall script. Don't forget you ro'd the /usr partitions, otherwise your upgrades will be unpleasant. :) Nick.
Re: Favorite configuration and system replication tools?
On 5/7/24 19:25, Jo MacMahon wrote: I'm interested if anybody has solutions using just the base system - I would want something like etckeeper or git that was a true version control system, rather than dump(8)/restore(8) which are backup systems. I'm idly considering learning CVS for it, and I suppose if I'm going to become a true OpenBSD user I will have to learn CVS at some point! Jo almost? base+rsync is pretty close. For over 20 years now, I've been using an rsync --link-dest backup system to make system backups. Several daily backups, several monthly backups. Not a true revision control system, but you have the ability to compare versions of a file as far back as you wish to keep copies. Plus, since it stores its backups in fully readable form, you can do all kinds of fantastic system research. Backups are stored in /ibs///(backed up file system tree). through the magic of hard links, every backup is incremental from the backup before in terms of files moved over the wire and space on disk, but every backup directory is a full backup. grep and careful wildcards gets you all kinds of info: What systems is user "bob" on? $ grep "bob" /ibs/*/.latest/etc/passwd When how long as "bob" been on server "server"? $ grep "bob" /ibs/server/*/etc/passwd What systems are set up using dhcp? $ grep autoconf /ibs/*/.latest/etc/hostname.* When I bring up a new laptop, I typically install OpenBSD, install rsync, install whatever packages I want, install a root authorized key from my backup server, and then push my home directory from a backup to the new system. https://holland-consulting.net/scripts/ibs/ I've scaled it from home use to "big" (current employer, almost 500 systems doing just etc and a few other directories. Last job, about 100 systems with about 30TB of backup data) client: rsync. backup server: Rsync + script. Other options: CVS is in base, it works, but I don't find it as useful for system configs as my Incremental Backup System. But it is 100% in base. If you are a fan of git, you might want to try Game of Trees (GOT), which is a LOT lighter weight in terms of required support than git. https://gameoftrees.org/index.html Same comments apply as for CVS, though -- works, but not as useful to me. But...git seems to be the new favorite revision control system, so knowing got/git is more marketable than cvs. :-/ Nick.
Re: pfstat is having a bad time
On Sun, May 5, 2024, 13:05 Christer Solskogen wrote: > Running pfstat -q gives: > ioctl: DIOCGETSTATUS: Permission denied > pf_query: query_counters() failed > > This is on a newly updated system (current) > OpenBSD tugs.antarctica.no 7.5 GENERIC.MP#50 amd64 > > Packages are also all up to date. > this may be related to the transaction/ticket changes in pf(4) that happened a while back. I know pftop doesn't work quite right any more, nor does my own poorly maintained go code since then. > -- > chs > >
Re: Upgraded to 7.5: vfs.ffs.dirhash_dirsize no longer exists and large directory ere veeery slow
On 4/11/24 05:47, Federico Giannici wrote: We have a server with A LOT of files in some directories (an email server in maildir format). Since we upgraded from OpenBSD amd64 7.3 to 7.5 (passing through 7.4) it became very very very slow to access these large directories! ,,, You may be being bitten by the removal of softdeps (soft updates) in 7.4 more than the availability of a knob to twist. This was a huge hit for some things -- I had one backup job go from a couple hours to eight or so hours. However, it turned out that increase in time has not inconvenienced me at all, and some random lockups related to softdeps have gone away. Overall, win for me (the fscks after a lockup took hours, too, not to mention all the time and effort spent replacing part after part assuming it was a HW issue). As I understand it...there were known (known unknown?) bugs in the softdep code, the code was ugly, and it made it difficult to actually improve the code. Nick.
Re: OpenBSD 7.5 bsd.upgrade hangs after sysupgrade
On 4/7/24 10:42, Страхиња Радић wrote: Дана 24/04/07 12:46PM, Страхиња Радић написа: Ok. The alternative would be to find a way to make 7.5 efifb work on my laptop. The version of efifb from 7.4 works (that is how I installed 7.4 in the first place), unlike 7.5 efifb. I'd just like to add that it efifb might not even be the reason for system hang. I noticed these lines in the output from 7.5 bsd.upgrade I got when I entered `verbose` at the UKC prompt and exited UKC: uhub0: device problem, disabling port 2 uhub0: device problem, disabling port 3 uhub0: device problem, disabling port 5 uhub0: device problem, disabling port 6 on my working 7.4 system, I have uhub0 at usb0 configuration 1 interface 0 "AMD xHCI root hub" rev \ 3.00/1.00 addr 1 and later urtwn0 at uhub0 port 2 configuration 1 interface 0 "Realtek 802.11n \ NIC" rev 2.00/0.00 addr 2 urtwn0: MAC/BB RTL8188EU, RF 6052 1T1R, address uhidev0 at uhub0 port 3 configuration 1 interface 0 "SiGmaMicro USB \ Optical Mouse" rev 1.10/1.10 addr 3 uhidev0: iclass 3/1 ums0 at uhidev0: 3 buttons, Z dir wsmouse2 at ums0 mux 0 uvideo0 at uhub0 port 5 configuration 1 interface 0 "Sonix Technology \ Co., Ltd. Integrated Camera" rev 2.00/0.28 addr 4 video0 at uvideo0 ugen0 at uhub0 port 6 "Atheros Communications product 0xe300" rev \ 2.01/0.01 addr 5 so the devices which have a "problem" are all devices connected to USB ports; or rather, the USB hub itself? Are there any regressions in the AMD xHCI hub code? My 100% guess is that you have a machine that's very dependent upon ACPI, and the install kernel's ACPI support is very minimal, or has a funny UEFI system. Or a funny BIOS. Some machines work better as UEFI, some work better running BIOS. A firmware upgrade may change that (which could suck). There are other ways, though... First, I would verify that the 7.5 kernel boots -- copy it to /bsd75, for example, then "boot bsd75 -s" (the -s is so it doesn't try to go multi-user with a mixed new kernel/old userland/packages). If that seems happy, just do a "remote upgrade", using the "Manual Upgrade (without the install kernel)" process in https://www.openbsd.org/faq/upgrade75.html. Nick.
Re: 7.5 NO hard drive?
On 4/7/24 03:03, lati...@vcn.bc.ca wrote: Hello i have 1 DELL Latitude E4300 that had OBSD 7.3 working correctly, but i decided to do a clean installation of 7.5 deleting everything on it with a live cd linux; then tested 7.5 and it says NO disk. After that i tested Linux, NetBSD, FreeBSD all them where installed without a problem; But, OBSD 7.3 7.4 7.5 said NO disk! It is something related to OBSD? What could happened? How to install OBSD 7.5 PS: Thanks for the new version 7.5 i run 2 laptops and 1 server with it! Thanks So OpenBSD has been correctly installed, thanks so much to maintain it nice! The problem was with the BIOS, it needs IHCH or something like that to be recognized! But it is working now as a xfce Desktop! probably AHCI and not the so-called RAID mode that many Dells default to, but definitely not Dell only "feature". This is our 25+ year "friend", BIOS assisted software RAID. The idea is the BIOS will handle initial tagging and replication of the drive until the OS is booted, then the OS takes over as it takes over the low-level disk support. This handles the "boot off any surviving disk" issue, but it creates a huge potential issue where a drive might end up being duplicated by the BIOS to a second disk...unintended! This would be bad. Not only could you clobber data on a second drive, but in the modern world of UUIDs for disks, you just put two disks on the same system with the same "uniq" identifiers, and one of those disks is very incomplete. This is also bad. OpenBSD disabled this "RAID" mode support over ten years ago (from memory), FreeBSD did around the same time, and a number of Linux distros took their time, but eventually did the same thing. Now...this was true on OpenBSD 7.3 as well, so something changed on your computer, I'm suspicious your CMOS battery has died, and the system came back up in the defaults, which include this RAID "feature". Nick.
Re: ipv6 assistance
On Sat, Apr 6, 2024 at 8:10 AM Sonic wrote: > > Running -current on my router and finally (after years) decided to move into > using ipv6. > I added "inet6 autoconf" to hostname.em0 (also has "inet autoconf") and I get > a link local address: > = > # ifconfig em0 > em0:inet6 fe80::2132:31ff:fe0b:7ea4%em0 prefixlen 64 scopeid 0x1 > inet 69.31.273.6 netmask 0xfc00 broadcast 69.31.273.255 > = > And an ipv6 default route: > = > Internet6: > Destination Gateway > Flags Refs Use Mtu Prio Iface > default fe80::301:5bcf:fe75:2646%em0 > UGS0 22 - 8 em0 > = > Which matches the default router proposal listed by slaacctl: > = > em0: > index: 1 running: yes temporary: yes > lladdr: 40:62:31:0b:7e:a4 > inet6: fe80::2132:31ff:fe0b:7ea4%em0 > Router Advertisement from fe80::201:5cff:fe75:2646%em0 > received: 2024-04-06 10:49:17; 0s ago > Cur Hop Limit: 0, M: 1, O: 1, Router Lifetime: 1800s > Default Router Preference: Medium > Reachable Time: 360ms, Retrans Timer: 1000ms > prefix: 2001:623:8016:54::/64 > On-link: 0, Autonomous address-configuration: 0 > vltime: 604800, pltime: 302400 > prefix: 2001:623:6007:a5::/64 > On-link: 0, Autonomous address-configuration: 0 > vltime: 604800, pltime: 302400 > prefix: 2001:623:500e:16::/64 > On-link: 0, Autonomous address-configuration: 0 > vltime: 604800, pltime: 302400 > prefix: 2001:623:4020:a5::/64 > On-link: 0, Autonomous address-configuration: 0 > vltime: 604800, pltime: 302400 > Default router proposals > id:1, state: PROPOSAL_CONFIGURED > router: fe80::301:5bcf:fe75:2646%em0 > router lifetime: 1800 > Preference: Medium > updated: 2024-04-06 10:49:17; 0s ago, timeout: 1788s > = > However, there's no other ipv6 address on the interface - I suspect an > address from one of those 2001: prefix groups needs to be assigned. > Should not dhcpleased handle this? > Most of the web posts I find deal with the pre-dhcpleased days. > > I'm on Comcast (Xfinity) in the US. i have comcast, and i use dhcpcd for ipv6. replace rge0 and vport0 with your wan/lan interface.. # /etc/dhcpcd.conf ipv6only duid persistent vendorclassid option rapid_commit option interface_mtu # make dhcpcd not touch nameservers. nohook resolv.conf require dhcp_server_identifier slaac private allowinterfaces rge0 interface rge0 ipv6rs iaid 1 ia_na 1 ia_pd 1/::/64 vport0/0/64 > > Thank you, > Chris > > >
Re: Bridging firewall with online update/upgrade
On 4/3/24 12:19, Karel Lucas wrote: Hi all, I am creating a bridging firewall with OpenBSD and the following hardware: https://www.amazon.nl/dp/B0B6J89MXJ?ref=ppx_pop_dt_b_asin_image&th=1. OpenBSD is already installed. I want to use ETH1 for the input from my ADSL modem, ETH2 and ETH3 for the output to my network. Furthermore, I would like to use ETH4 for the update/upgrade of the firewall. Remove the connection from ETH1, plug it into ETH4, and update/upgrade. Then the connection returns to ETH1. ETH4 therefore receives an IP address and ETH1,ETH2 and ETH3 not. But now the problem: as long as the network connection of the ADSL modem is in ETH4, my network, including the firewall, is no longer secured, and attackers can take advantage. I therefore wonder whether it is possible to let the data flow via ETH1 and ETH4 first pass through PF before an update/upgrade is done via ETH4. This means that the bridging firewall will have two entrances, one without and one with an IP address. I would like to know if that is possible, or if there is another option. There are lots of options, but I'm not seeing the point of the bridging firewall here. Sounds like you are making things complicated and I'm suspicious you won't be getting much benefit from it. I think you would do much better with NAT. But...pretending for the moment this is the right solution for you, if you are already planning on physically moving to the box to do upgrades, just download the installXX.img file on another machine, drop it on a thumb drive, walk over to your bridge and reboot from the thumb drive and upgrade, don't bother fiddling with cables. I'm also pretty sure you can put an internal IP on one of the ports other than the bridge, and copy the files and install from there. That would have the benefit of remote administration, too. Nick.
Re: Bash instead of ksh
On 4/2/24 15:34, Steve Litt wrote: ... Does "general shell" mean the interactive shell you use? If so, I think that's an excellent idea for non-root accounts. Ok, I'll bite... Why do you think that's an "excellent idea" -- something you would encourage people to do? What is it that you see bash doing so much better than stock pdksh? Nick.
Re: Bash instead of ksh
On 4/1/24 12:24, Karel Lucas wrote: Hi all, Instead of ksh I want to use bash as a general shell. But how can I set it up that way? Bash is already installed. Easy to do, as several have explained how. ...BUT... I'd really suggest not doing that. If you are writing a script that requires bash, just set your #! line properly. (presumably #!/usr/local/bin/bash) If you really need bash for a user shell at a particular moment, invoke it at a command line. The pdksh that comes with OpenBSD by default is very good and supports most of the "fancy" stuff that bash does, but is stock with the system, so it has no dependencies, no issues at upgrade, and is quite lean compared to bash. I'd suggest that administrative accounts be kept as close to stock as you can. Now, if you have a non-administrative user who only knows Linux...ok, sure, change their default shell. But as a system administrator, you will generally find benefit in knowing the native tools. During the week for a living, I administer Linux machines, and use bash. In evenings and weekends, I work with OpenBSD and pdksh. I really have no issue switching between the two. Nick.
Re: UKC> disable "smth"
On 3/16/24 08:52, ofthecentury wrote: I boot with 'boot -c' and then enter 'disable mei' and then 'quit'. Pcidump still shows Intel MEI, just as it does when booting with default config. I don't think anything changed. In this case, correct. As was already pointed out -- devices exist or don't -- but that's a hw config that the OS doesn't usually have a lot of control over. All the OS can do is connect a driver or not. config or ukc only disables OS support for something. pcidump will show you what HW the OS knows exists, and on modern machines, that's going to be a pretty complete list. But UKC doesn't complain when I disable mei, so I know it knows 'mei' and disables it. this assumption is not correct: ukc> disable nothing # invalid device -- no response ukc> disable ep # valid device -- response! 110 ep* disabled 111 ep* disabled You can easily verify this with a known good device and a bogus name (like my 'nothing' above). But how would I know it does disable it? Also, 'boot -c' accumulates what changes I do. How does one reset changes to go back to vanilla kernel? Again, an incorrect assumption. boot -c does NOT retain changes between boots. UKC> is after the kernel is loaded but before the kernel is fully running. While in ukc>, the kernel doesn't really have an ability to write to disk, as it hasn't been fully started yet. IF you want to make changes to disk, use "config -ef" from the booted system, then write your changes to disk. Then you can either use config -ef to re-enable a device, or just copy over an unmodified kernel. Be aware that altering the kernel binary will "break" the Kernal Address Re-Linking (KARL). There are fixes for this, HOWEVER, I'm not sure what your goals are here in tweaking your kernel like this, but I'm guessing breaking KARL isn't your biggest problem you are about to create for yourself. This probably isn't something you want to be doing. Nick.
Re: Saving UKC> list output
On 3/15/24 07:56, ofthecentury via misc wrote: When you want to turn off a device on OpenBSD you can do it at boot time with manual `boot -c` command. (Can also be automated) After entering entering `boot -c` you get UKC> configuration prompt. I type `list` and get a nice list of all drivers I can disable with `disable mei` or disable `lpc`. But how do I get that list into a file so I can review it? Is there some way to do it? Thx! um... your formatting is giving me Commodore VIC20(1) flashbacks... Anyway: script config -e /bsd ... ukc> list [hit enter a bunch of times] CTRL-C (to get out of config) CTRL-D (to get out of script) ta-da! output in 'typescript'. config does some of what boot -c does from a running system. script captures screen input and output. man config man script Nick.
Re: many serial ports
On 2/8/24 04:00, Jan Stary wrote: What HW do people use to read data from many serial ports simultaneously? My use case is reading the output of https://en.wikipedia.org/wiki/Electropalatography The device has eight serial port outputs; I need to read those at the computer side. Do I just stuff my box with 8 cereals, or is there something more elegant? Some multiplexing USB dongle? Jan I have used a few modest-price USB to 8 port serial converters, they seem to "Just Work'. Here's one: uhub2 at uhub0 port 4 configuration 1 interface 0 "NEC product 0x0050" rev 2.00/1.00 addr 2 uftdi0 at uhub2 port 1 configuration 1 interface 0 "FTDI FT232R USB UART" rev 2.00/6.00 addr 3 ucom0 at uftdi0 portno 1 uftdi1 at uhub2 port 2 configuration 1 interface 0 "FTDI FT232R USB UART" rev 2.00/6.00 addr 4 ucom1 at uftdi1 portno 1 uftdi2 at uhub2 port 3 configuration 1 interface 0 "FTDI FT232R USB UART" rev 2.00/6.00 addr 5 ucom2 at uftdi2 portno 1 uftdi3 at uhub2 port 4 configuration 1 interface 0 "FTDI FT232R USB UART" rev 2.00/6.00 addr 6 ucom3 at uftdi3 portno 1 uftdi4 at uhub2 port 5 configuration 1 interface 0 "FTDI FT232R USB UART" rev 2.00/6.00 addr 7 ucom4 at uftdi4 portno 1 uftdi5 at uhub2 port 6 configuration 1 interface 0 "FTDI FT232R USB UART" rev 2.00/6.00 addr 8 ucom5 at uftdi5 portno 1 uhub3 at uhub2 port 7 configuration 1 interface 0 "NEC hub" rev 2.00/1.00 addr 9 uftdi6 at uhub3 port 1 configuration 1 interface 0 "FTDI FT232R USB UART" rev 2.00/6.00 addr 10 ucom6 at uftdi6 portno 1 uftdi7 at uhub3 port 2 configuration 1 interface 0 "FTDI FT232R USB UART" rev 2.00/6.00 addr 11 ucom7 at uftdi7 portno 1 And here's another one: uhub3 at uhub0 port 4 configuration 1 interface 0 "NEC hub" rev 2.00/1.00 addr 2 umcs0 at uhub3 port 1 configuration 1 interface 0 "MosChip MCS7840 Serial" rev 2.00/0.01 addr 3 ucom0 at umcs0 portno 0: usb0.4.1.0 ucom1 at umcs0 portno 1: usb0.4.1.0 ucom2 at umcs0 portno 2: usb0.4.1.0 ucom3 at umcs0 portno 3: usb0.4.1.0 umcs1 at uhub3 port 2 configuration 1 interface 0 "MosChip MCS7840 Serial" rev 2.00/0.01 addr 4 ucom4 at umcs1 portno 0: usb0.4.2.0 ucom5 at umcs1 portno 1: usb0.4.2.0 ucom6 at umcs1 portno 2: usb0.4.2.0 ucom7 at umcs1 portno 3: usb0.4.2.0 I'm not going to provide names or product numbers, because I've been using both for well over six or seven years now, so anything you buy new will almost certainly be "different". Both were under $150US at the time. Selection was based on "If this doesn't work, am I going to cry about the wasted money?" process. Both worked. You may get better results with a bigger price tag, you may not. One is basically just a snoot-load of individual FTDI USB to Serial chips behind a couple USB hubs. The other is a couple four port USB to serial chips, also behind a USB hub. OpenBSD handles both just fine. I've had occasional issues where the things "break" (can't establish communications with the serial ports) and to get serial ports running again requires a physical unplug/plug-in or an OS reboot. So far, a reboot has always fixed it for me. So it shouldn't be on a machine that requires a maintenance window for reboot, but rather a more-or-less application dedicated system. Dunno if all devices do this, but I've seen some people complain about this on other OSs, too -- I kinda have the impression the FTDI chips were designed to be plugged in and unplugged a lot, not left attached and operating for months at a time, but ... no idea if there is anything to that other than my speculation (I don't use the MosChip box as much as the FTDI, so I really can't say if it has the same problem. And thinking about it, I don't recall having to reboot the system the FTDI device is attached to in a while due to port lockup, so maybe it's fixed in the OS, maybe it has become so automatic to me, I just do it and don't log it in my brain). Nick.
Re: questions about RAID5C, RAID6, RAID6C, can Openbsd be a good storage-server OS?
rs, and for SOME applications, having a whole other machine ready to roll is a better solution. Granted, my FIRST choice is TWO machines running RAID storage, but that's not always practical. Nick.
Re: [answered]Re: how to play bytebeat on openbsd?
try piping to sox -r 8000 -c 1 -t u8 - -d for example, this should work as a demo: python3 -c 'import sys; [sys.stdout.write(chr(( t & (t >> 8)) % 256)) for t in range(2**19)]' | sox -r 8000 -c 1 -t u8 - -d On Sat, Feb 3, 2024 at 6:20 AM wrote: > > thank you, stranger! > > I found so many good C formulas, some sound like they could be used within a > game, even has pauses with silence and everything! > > I had to find out how to use sox, though on another site: `sox -r 8000 -c -t > u8 test.raw output.wav` > > what is weird is that I can't get bytebeats if the `t` is int8_t or > something.. doesn't seem like that makes sense, it's like 4 bytes 32-bit, not > 1 byte. > not sure difference between signed 32, 64 and unsigned, but I tried 16-bit `t` > and it's just not it.. am I messing something up? > > does this only mimic bytebeat, and is not true 8-bit technique to get > realistic bytebeat? > > On Fri, February 2, 2024 9:15 pm, Nick Owens wrote: > > back when i used to mess with these, i frequently used `sox` to play the > > 8-bit > > samples. it can do the sample conversion for you to whatever the system > > needs. > > > > > > On Fri, Feb 2, 2024 at 11:08 AM Omar Polo wrote: > > > >> > >> On 2024/02/02 18:41:46 +, beecdadd...@danwin1210.de wrote: > >> > >>> hello > >>> > >>> I've tried for hours to play bytebeat as everyone else > >>> > >>> > >>> I cannot find anything on the entire internet > >>> > >>> > >>> all I got is `cat a.out >> /dev/speaker)` as root.. a.out is compiled > >>> code , a loop and `putchar(t*((t>>12|t>>8)&63&t>>4));`.. this doesn't > >>> sound nearly the same as it does to other people it's also slow, not fast > >> > >> I don't think it makes sense to feed speaker(4) with an executable code. > >> > >> > >> Haven't seen the code, but based on your description I guess it should > >> be more like > >> > >> $ ./a.out | doas tee /dev/speaker > >> > >> > >> or at least that's my guess, my crystall ball don't always works correctly. > >> > > > > > > >
Re: how to play bytebeat on openbsd?
back when i used to mess with these, i frequently used `sox` to play the 8-bit samples. it can do the sample conversion for you to whatever the system needs. On Fri, Feb 2, 2024 at 11:08 AM Omar Polo wrote: > > On 2024/02/02 18:41:46 +, beecdadd...@danwin1210.de wrote: > > hello > > > > I've tried for hours to play bytebeat as everyone else > > > > I cannot find anything on the entire internet > > > > all I got is `cat a.out >> /dev/speaker)` as root.. a.out is compiled code > > , a > > loop and `putchar(t*((t>>12|t>>8)&63&t>>4));`.. this doesn't sound nearly > > the > > same as it does to other people > > it's also slow, not fast > > I don't think it makes sense to feed speaker(4) with an executable code. > > Haven't seen the code, but based on your description I guess it should > be more like > > $ ./a.out | doas tee /dev/speaker > > or at least that's my guess, my crystall ball don't always works > correctly. >
Re: Adaptec 8405 SGL drivers these days?
On 1/26/24 00:37, Kevin wrote: Hey gang, Looking at a server whose only option for storage comes via an Adaptec 8405 SGL. Given the battles between OpenBSD and Adaptec for documentation that pre-date the Hoover administration, I'm curious if this card is supported. Let's be clear: it isn't about documentation of how the card works, it is about documentation of how the cards are BROKEN. Lots of HW has bugs that have to be worked around in software...but those bugs have to be documented in order to have a useful product and driver. It's a 4-port SATA RAID on a beefy server with gobs of RAM and storage and is an offensively reasonable price. Do you like your data? If so, you need to find a different solution. If not, save yourself some time and just delete your data now. Adaptec RAID cards are crap. The company was crap. Note: this story is on a Linux based system. https://nickh.org/warstories/adaptec.html (no ads!) Nick
Re: GENERIC.MP#1600 last snapshot cvs cant create tmp subdir
On 1/17/24 12:07, Todd C. Miller wrote: On Wed, 17 Jan 2024 11:11:36 -0500, "Sven F." wrote: well i tried anoncvs.spacehopper.org after the fail and then anoncvs.comstyle.com ( default one is in the trace, is "anon...@obsdacvs.cs.toronto.edu:/cvs" ) I can confirm the problem with obsdacvs.cs.toronto.edu but other servers are fine. So it does appear to be a problem on obsdacvs.cs.toronto.edu itself. - todd Yes. the cvs checkout tmp directory was filled on obsdacvs.cs.toronto.edu. That has been fixed. My apology for the issue. Nick.
Re: Communication between hosts on different network interfaces
On 1/6/24 15:09, Ibsen S Ripsbusker wrote: Dear colleagues, I have various network appliances that I don't really trust, like a printer. I have these plugged into an unmanaged switch and connected to network interface igc2. I want to allow the igc1 network to make web requests to the igc2 network, and I want the igc2 network to have very restricted access outside of igc2. what does a printer need internet access for? nevermind. Don't answer that. It's the 21st century. Many people think their bloomin' thermostats should have Internet access...(I'm really close to replacing my non-internet connected digital programmable thermostat with a 100% mechanical. Because...they don't suck) (My main computer is connected to network interface igc1. And the egress interface is igc0.) MY QUESTION: What would be a normal way of achieving this? let's abstract this a bit... (in large part because a sequence of letters and numbers confuses me quickly.) So you have a trusted network, an untrusted network, and of course, the Internet, which we will just call "The Evil". While you can do it with a bridge, I don't want to think that hard. And it would be a lot of work. [snip bridge stuff] I also tried setting different subnets. yeah. that's the way I'd go. trusted: /etc/hostname.igc1:>inet 192.168.2.1/24 untrusted: /etc/hostname.igc2: inet 192.168.3.1/24 With this everything works as I want except that the only way I figured out to allow hosts on 192.168.2.1/24 to access 192.168.3.1/24 was with NAT, and that can't be right. yeah, the problem is, it sounds like your barrier machine is not your primary gateway/firewall. So when your trusted machine in 192.168.2/24 talks to an address in 192.168.3/24, it talks to your primary gateway, and your gateway says, "whoa, dude. wazzat?" I'd fix this by making your main firewall the barrier machine. This would require a three or more port firewall. Pass in from trusted to anywhere. block in quick on untrusted to trusted Pass from untrusted to anywhere (but trusted is already blocked) Failing that, with a separate barrier machine, you will need to add a static route for the 192.168.3/24 subnet to point to the "trusted" address of your barrier machine. That way, when your trusted network machines try to access the untrusted network, they know to route through your barrier machine. Every single trusted machine that wants to access something in that subnet will need that extra route added. Clumsy at best (probably doable with the DHCP server. I just glanced, looks kinda ugly). I guess if there is only one untrusted device, you could just use an inbound NAT tunnel for whatever ports need to access that device, then just use the barrier's IP address to access the device. But I don't normally think in quantities of one, and this doesn't scale well. But if there's only one device, or several devices, but they can all be hit on different ports, that's an option. Another way to do it is with two NATting firewalls: Evil <--[NAT-FW] <- untrusted network [NAT-FW] <- trusted network. (internet) (192.168.3/24) (192.168.2/24) traffic flows unimpeded in the direction of the arrows, and is blocked going backwards. Your trusted machines can hit untrused machines or the internet, untrusted machines can hit the Internet, but they can't dig through to your trusted network. Yeah, the down side is that the trusted network has to jump through two routers, so the untrusted network potentially has better access than the trusted network, and that's just not fair. But ... it's easy. I've done the opposite, what I call "portable DMZ"s, where untrusted machines need access to the Internet but shouldn't be allowed to touch the trusted machines, but unlike your situation, the untrusted machines don't need to be accessed by the trusted. Small machine, two NICs. One NIC is DHCP to the trusted network, NAT and DCHP server on the untrustedv side, maybe a logging DNS server. Block all from the untrusted to the trusted subnet, pass everything else (internet). These don't need those inbound static routes. Nick.
Re: man.openbsd.org, cvsweb.openbsd.org maintenance
man.openbsd.org, cvsweb.openbsd.org, openbsd.cs.toronto.edu obsdacvs.cs.toronto.edu are all back up and running. Snapshots and packages should be up to date, now, too. My apologies for the inconvenience. Nick. On 12/19/23 15:38, Nick Holland wrote: Hello, man.openbsd.org, cvsweb.openbsd.org, openbsd.cs.toronto.edu and obsdacvs.cs.toronto.edu will be unavailable for site maintenance starting Thursday, December 21 about 6:00am ET (UTC-5) and hopefully be back up and running by Saturday, December 23, 6:00am ET. Sorry for any inconvenience. Nick.
Re: man.openbsd.org timing out via HTTP & HTTPS
On 12/29/23 17:55, Eric Pruitt wrote: On Fri, Dec 29, 2023 at 02:46:39PM -0600, Tim Chase wrote: Not much to add to the subject. For a couple days now, I've tried connecting via HTTP & HTTPS from various points around the internet and they all time out. Sounds like something hung or accidentally lost power and needs a nudge. Known issue: - https://marc.info/?l=openbsd-misc&m=170301839017559&w=2 - https://marc.info/?l=openbsd-misc&m=170345453930038&w=2 Eric yep... With some luck, I'm hoping man.openbsd.org and cvsweb.openbsd.org will be back on line Tuesday or Wednesday next week (Jan 2-3). In the meantime, as Eric pointed out, https://cvsweb.egoslike.us/ https://man.egoslike.us/ are available as temporary fill-ins. Nick.
Re: self-hosted man.openbsd.org script?
On 12/24/23 08:25, Paul Pace wrote: I have this vague memory of reading someone who posted a script, IIRC, to convert the system's man pages to HTML, or similar, into somewhere under /var/www and the pages worked just like the highly useful man.openbsd.org, and not like the plain text pages that everyone always posts to their websites. Does someone happen to know where that is? /usr/src/usr.bin/mandoc is where the source for man.cgi resides. Frequent small updates take place, I believe it would be good to use the -current source code if you wish to play with it. It has very simple dependencies, so should be no issue running -current man.cgi code compiled on a -stable. ... however ... being that UofT might be down for a few days, I have lit up a VPS with cvsweb and man content on them. https://cvsweb.egoslike.us/ https://man.egoslike.us/ And look, my backups and notes don't suck. :) These are not official, but they are run by one of the people who run the official sites. They will go away once the official site is back up and running. Nick. On 12/23/23 11:16 AM, Nick Holland wrote: On 12/19/23 15:38, Nick Holland wrote: Hello, man.openbsd.org, cvsweb.openbsd.org, openbsd.cs.toronto.edu and obsdacvs.cs.toronto.edu will be unavailable for site maintenance starting Thursday, December 21 about 6:00am ET (UTC-5) and hopefully be back up and running by Saturday, December 23, 6:00am ET. Sorry for any inconvenience. Nick. Unfortunately, it seems there's a problem impacting our servers, and everyone is celebrating the holiday. So ... return of man.openbsd.org, cvsweb.openbsd.org and the install and anoncvs mirrors will be delayed. Nick.
Re: man.openbsd.org, cvsweb.openbsd.org maintenance
On 12/19/23 15:38, Nick Holland wrote: Hello, man.openbsd.org, cvsweb.openbsd.org, openbsd.cs.toronto.edu and obsdacvs.cs.toronto.edu will be unavailable for site maintenance starting Thursday, December 21 about 6:00am ET (UTC-5) and hopefully be back up and running by Saturday, December 23, 6:00am ET. Sorry for any inconvenience. Nick. Unfortunately, it seems there's a problem impacting our servers, and everyone is celebrating the holiday. So ... return of man.openbsd.org, cvsweb.openbsd.org and the install and anoncvs mirrors will be delayed. Nick.
Re: Post (snap) update emails: fsck errors and (in)security output
On 12/20/23 06:02, Why 42? The lists account. wrote: ... Reply-To: Hi All, A couple of questions ... I have "ROOTBACKUP=1" in /etc/daily.local to replicate my root partition as described in the FAQ (https://www.openbsd.org/faq/faq14.html#altroot) I noticed after an update to a new snapshot via sysupgrade that the next daily output email contains many many fsck "UNREF FILE" errors (See the output included below). Is this expected, or is there some problem? Most or all of the files seem to be owned by me (robb) so I'm thinking that these errors may be related to files in /tmp ... Not sure why this occurs though? the ROOTBACKUP process is making an image of a live file system; fsck grumblings ARE expected. It's just one of those things you aren't supposed to do (but I do it regularly, because normally, you can get away with it). Why the files it is grumbling about are owned by you ... that is a puzzle. Is your /tmp on a separate partition? If so, it shouldn't be being backed up by the ROOTBACKUP process. Same for "home" or any other file system you have access write to. I also see this: Backing up root=/dev/rsd1a to /dev/rsd0a: is sd1a actually your root, and sd0a actually your altroot? Second question: Also after an upgrade, the "daily insecurity output" contains a huge amount of setuid changes e.g. ... -r-xr-sr-x 1 root auth 21144 Nov 30 15:36:52 2023 /usr/bin/skeyinit -r-xr-sr-x 1 root auth 21144 Dec 19 08:35:26 2023 /usr/bin/skeyinit -r-xr-sr-x 1 root _sshagnt 440496 Nov 30 15:36:53 2023 /usr/bin/ssh-agent -r-xr-sr-x 1 root _sshagnt 443856 Dec 19 08:35:26 2023 /usr/bin/ssh-agent -r-sr-xr-x 1 root bin19608 Nov 30 15:36:53 2023 /usr/bin/su -r-sr-xr-x 1 root bin19608 Dec 19 08:35:27 2023 /usr/bin/su -r-xr-sr-x 1 root tty17936 Nov 30 15:36:54 2023 /usr/bin/wall -r-xr-sr-x 1 root tty17936 Dec 19 08:35:28 2023 /usr/bin/wall -r-xr-sr-x 1 root tty14184 Nov 30 15:36:55 2023 /usr/bin/write -r-xr-sr-x 1 root tty14184 Dec 19 08:35:28 2023 /usr/bin/write -r-xr-sr-x 4 root _token 21248 Nov 30 15:36:44 2023 /usr/libexec/auth/login_activ -r-xr-sr-x 4 root _token 21248 Dec 19 08:35:18 2023 /usr/libexec/auth/login_activ ... What actually changed then? The files. Surely many or all of these files had the same permission bits before the upgrade? Maybe these files now have diffent inode numbers, after the upgrade? Why is each filename reported twice? Are these "old" and "new" values? This isn't complaining about the EXISTENCE of setuid programs, it is advising that setuid programs CHANGED from their last recorded version. After all, if I manage to drop a new setuid program on your system, perhaps naming it "ping" or "su", that would be bad, you might want to know about it. Sure, dropping a setuid program that wasn't setuid before could be bad, but replacing an existing one would be more sneaky. You upgraded your machine, so you replaced a lot of setuid programs. And yes, it shows date&time stamp and size of the old file and the new file. Seeing something bump up or down a few bytes and matching the same date and time stamp of other binaries after an upgrade is expected. Seeing that "su" went from 20k to 70k might warrant investigation. (and yes, I have seen events where a major upgrade caused a lot of noise in a "something changed" file...which unfortunately hid something we needed to know about ALSO happened, and was dismissed as "part of the upgrade noise". This wasn't OpenBSD nor was it a "security event", but it did delay the detection and repair of a redundancy failure issue because one line was missed in a sea of thousands of lines of "yeah, that's expected" noise.) Nick. Thanks in advance for any feedback! Cheers, Robb. Subject: mjoelnir daily output ... OpenBSD 7.4-current (GENERIC.MP) #1535: Tue Dec 19 00:55:53 MST 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP 1:30AM up 7:20, 7 users, load averages: 0.62, 0.44, 0.40 Backing up root=/dev/rsd1a to /dev/rsd0a: 131071+0 records in 131071+0 records out 1073733632 bytes transferred in 10.509 secs (102169077 bytes/sec) ** /dev/rsd0a ** Last Mounted on / ** Phase 1 - Check Blocks and Sizes INCORRECT BLOCK COUNT I=26656 (64 should be 32) CORRECT? yes INCORRECT BLOCK COUNT I=26688 (4128 should be 0) CORRECT? yes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts UNREF FILE I=26064 OWNER=robb MODE=100600 SIZE=4 MTIME=Dec 20 01:30 2023 CLEAR? yes UNREF FILE I=26069 OWNER=robb MODE=10640 SIZE=0 MTIME=Dec 19 19:02 2023 CLEAR? yes UNREF FILE I=26070 OWNER=robb MODE=10640 SIZE=0 MTIME=Dec 20 01:02 2023 CLEAR? yes UNREF FILE I=26073 OWNER=robb MODE=100600 SIZE=28672 MTIME=Dec 20 01:30 202
man.openbsd.org, cvsweb.openbsd.org maintenance
Hello, man.openbsd.org, cvsweb.openbsd.org, openbsd.cs.toronto.edu and obsdacvs.cs.toronto.edu will be unavailable for site maintenance starting Thursday, December 21 about 6:00am ET (UTC-5) and hopefully be back up and running by Saturday, December 23, 6:00am ET. Sorry for any inconvenience. Nick.
Re: Auto-install over network using UEFI
On Tue, Nov 21, 2023 at 7:03 PM Chris Narkiewicz wrote: > > I'm experimentin with auto-install over network using linux libvirt > (qemu). > > I managed to load pxeboot in BIOS mode and I'm wondering if UEFI > is supported. > > According to this blog, I should load BOOTX64.EFI instead of pxeboot. > > https://eradman.com/posts/autoinstall-openbsd.html > > I was skeptical but tried it neverthekess and system immediately reboots after > probing disk: > > probing: p0 com0 mem[640K 2029M 9M 3M] > disk:BS->LocateHandle() returns 14 > > > Is it possible to net-boot installer in UEFI using QEMU? > > Cheers, > Chris > i had some trouble getting PXE set up with dhcpd - see my mail from april, "dhcpd user-class and vendor-class". i think there is also a bug in the EFI loader when run under OVMF as you experienced, but i never figured it out.
Re: a couple question about my fde setup
On 11/19/23 18:09, Shadrock Uhuru wrote: hi all a couple question about my fde first, i have fde setup using a keydisk on my laptop, encryption and decryption works fine when i reboot with the key inserted it doesn't find the key, i have to shut the machine down and restart it then the key is detected, is this normally how a reboot works with fde and keydisk ? second when i boot the laptop it tries to boot from the wrong disk, it tries to boot off hd0 whereby at the boot prompt i then have to type boot sd0a:/bsd which then proceeds to a normal boot, do i just run /usr/mdec/installboot -v /boot /usr/mdec/biosboot sd0 to fix this ? You have provided a whole lot of no-information here. dmesg, disk layout and boot mode would be nice starting points. "hd0"? What is that in your machine? Both issues sound like a firmware issue. Boot device is usually controllable in BIOS/firmware setup -- once the OpenBSD boot loader is running, it is too late to determine what you boot from. USB storage not being found under some boot conditions and being seen on others, sounds like a firmware bug. Almost certainly, in fact, as OpenBSD itself isn't loaded and running, it's just the boot code talking to the firmware or BIOS. Many modern-ish computers support both UEFI and BIOS booting. They often have different bugs in different modes. I have a couple machines here that were sold running embedded Linux with a warning "must use BIOS mode" in the firmware for their original application...but OpenBSD only can see storage in EFI mode. Also look for firmware updates to your system. I'd suggest starting with reloading in the opposite boot mode first, because if a new BIOS introduces new bugs, it is sometimes difficult to revert. And yes, you will have to reinstall to switch boot modes (technically, no, but if you have to ask, yes). Nick.
Re: Three more orphan packages
On 11/16/23 18:12, Daniele B. wrote: Just found out that in my system persist the following stuff: in /etc/passwd: user _nagios I don't really think you want users deleted when you uninstall a package. Things may be invisibly (to the package manager) be connected to that user. in /var: /nagios/ /nagios/rw/nagios.cmd 0 kb /nagios/objects.cache 27.0 kb /nagios/retention.dat 35.9kb If I try to delete /var/nagios this is recreated probably at system boot. There is no cron job nor rc service present apparently for Nagios Never, EVER say, "there is no ..." until you find the actual cause. It just never goes well, and I say that as someone who has foolishly made the claim, and as the person who laughed their *** off when it became clear the claimer was failing to fix the problem because they believed their own boast. Any explanation for this happening and any help to clean away all properly? Obviously something is creating it. The OpenBSD Startup process is very straight forward, it really shouldn't be too hard to find. A "grep -R" of a few appropriate strings in the /etc directory would probably find the culprit pretty easily. You could also read and understand rc(8) and find what is going on by following the startup process. Nick.
Re: Upgrading from 7.3 to 7.4 with sysupgrade
On 11/16/23 20:25, Odd Martin Baanrud wrote: Hello, I’m planning to upgrade my router from 7.3 to 7.4 using sysupgrade, but I’ve one concern. Some time ago, I upgraded a RPi4 from 7.2 to 7.3, and X got installed, even though it wasn’t before the upgrade. I thaught sysupgrade only upgraded the installed sets. Nope. Never did. It always assumes a full, all file-set install. How does it work on 7.3? Same as it has om the past. Full upgrade. On my router, I have base, comp and man installed, and I don’t want the X sets on that machine. if you don't want X or any other file set, just do a manual upgrade from the console. It's that simple. No one mandates the use of sysupgrade, sysupgrade is just a very special case (though highly useful) subset of potential ways to do an install But, whatever your reason for wanting to keep some files off your computer, it is probably flawed. So I'd really suggest, just don't worry about it, just do an upgrade, let it install everything, and be done with it. But if you don't like the way sysupgrade does things, don't use that tool. Nick.
Re: Slow relink in 7.4
On 10/17/23 05:07, David Higgs wrote: I have an underpowered amd64 VPS and attempted to (auto)upgrade it to 7.4. Everything went swimmingly until it attempted to relink the kernel, at which point it (seemingly) hung. With previous releases, I would expect the host to become unresponsive for a few minutes, and eventually recover. I chalked the issue up to insufficient RAM and hitting swap - however, my upgrade has been in this state for more than 6 hours. I plan to consult the manual upgrade guide to hopefully figure out a way to successfully finish the install, and then disable relinking while I find a solution. Does anyone have tips for this situation, aside from throwing more hardware at it? Thanks! —david I had some issues with a VPS for a while -- absolutely horrific disk performance. Upgrades that used to take ten minutes (and yes, THAT was really bad) started taking well over an hour (I gave up, stopped it, and did it manually by unpacking tar files, coping kernel, etc., so I have no idea what the actual time was going to be if I had let it complete). I contacted tech support at the VPS, and they came back with, "oh yeah, you are on some really old hardware. Please set up a new instance and migrate to that, that should solve your problem", but since the machine was doing its usual job just fine (low volume mail and webserver), I was slow to actually do this. Finally, they sent me notice they were decommissioning the old hw I was on, and I HAD to move by x/x/, and thus, I did, and things are much better. And it turned out, cheaper. However, I did find it interesting that my poor disk performance was even worse when doing the upgrade. Moral: might be worth talking to your VPS provider. You might be on old hw, too. A number of releases ago, but after KARL and library relinks1, I found that on i386, 384MB was required to prevent swapping during the kernel and library relink at boot. I'm assuming it is "worse" now, and worse yet on amd64. Nick.
Re: OpenBSD 7.4
On 10/12/23 13:54, Karel Lucas wrote: Is it already known when openBSD 7.4 will be released? I would like to know that, because of a project I am working on. The answer to your question is already out there, but I offer this procedural tip: IF you wish to follow releases, start your project on the PREVIOUS release. When you think your project is complete, but before going into actual production, do an upgrade to the active release. Why? Because the hardest part of most long-term projects seems to be keeping things up-to-date. You shouldn't be putting things into production and hoping that the upgrade process will be figured out "later", and maximize you get to put off that "problem". The upgrade process has to be core to the design and implementation, and should be tested before going into production. This isn't an OpenBSD specific tip, either. In fact, this is easier on OpenBSD than most Linuxes, because routine upgrades are part of the OpenBSD mindset, unlike many linux distros, where upgrades are to be put off as long as possible via "Long Term Support" distributions. After watching the fiascos at every company I've ever seen "Long Term Support" Linux releases used in, I've become absolutely convinced LTS is just a BAD IDEA and I'm thankful OpenBSD doesn't do that. Nick.
Re: sftp activity logging?
On 8/31/23 17:29, myml...@gmx.com wrote: Hi All, I am setting an openbsd 7.3 stable system to serve files via ssh's sftp subsystem. Does openssh have a native way to audit what files were downloaded/uploaded with user/timestamp information? If not, are there any recommendations? Thanks in advance. Try this, perhaps? man sftp-server, options of interest may include -f, -l. You will probably have to have a /dev/log inside the chroot, which also means the "nodev" option is not your friend. Nick.
Re: I nuked my filesystem
On 9/26/23 21:42, sprits killshot wrote: I did the thing. dd'd a 5gb img to my ssd instead of my usb and I want to die. dd if=file.iso of=/dev/sd1c I am using a CRYPTO RAID partition and luckily I'm smart enough not to nuke that. My ssd is 2TB so I believe it uses FFS2 by default. I'm hopelessly running scan_ffs on it in case it was silently updated or the man is wrong or there's a God. ok...so the first 5G of sd1 is gone. So most likely, all file systems that have any bit of them in that first 5g are not practically recoverable. (here's the sad bit -- if you were trying to steal info like credit card numbers or personal ID numbers, there's probably lots still accessible, but for your uses, just consider all partitions that start in the first 5G gone. BUT ... everything after that has potential. Put in pictures ... * If you have one big 2TB partition, stop reading now, you can start crying, and wish you had a good backup system in place. ==> sd1a: 2000GB # Practically speaking, gone. Too much clobbered. * If you have multiple partitions and some of them start after 5GB, you might be in luck. Let's say you have three partitions: (start of disk) ==> sd1a: 4GB# Totally gone. ==> sd1d: 500GB # Practically gone. Too much clobbered. ==> sd1e: 1496GB # untouched. (note: the letter orders don't matter, it's the starting offsets that matter to you. If you put the 1.5TB sd1e at the front of the disk, and sd1a and sd1d after it, sd1a and sd1d are untouched, but sd1e is not (practically) recoverable.) To recover sd1e, you need to recreate a disklabel that matches what was there before...exactly. To the sector. Now..I see you clobbered sd1c, not sd0c. With a bit of luck, perhaps sd0 (or at least, not sd1!) is where your /var partition is, and with a little more luck, you have left your machine on over night enough times to let /etc/daily run and save your butt. [edit: just realized sd1 is probably your softraid encrypted drive, so you probably lost your /var. But maybe you have a copy somewhere] Take a look in /var/backups/ for disklabel.sd1*. IF they exist, they are backups of exactly the disklabel that was on that disk when they were made. Hopefully, that is recent enough for you. Drop a new MBR (or EFI) on sd1 with fdisk, then import that disklabel (disklabel -e sd1, clear it, ":r /var/backups/disklabel.sd1.current", write it, quit), and you should be in business -- your un-nuked partitions will become immediately available (but sd1a and sd1d will not be "formatted" for you at this point). Note: I haven't done exactly this, but I think it will work, based on doing enough things with OpenBSD disk layout that I think I know what you can get away with. Practicing on a spare system would be advisable. Now...what if that /var/backups directory doesn't contain a disklabel backup? Well, you MIGHT still be in business. OpenBSD disk layout stuff is very predictable. IF you know how your disk was originally laid out and you repeat that process, you will end up in the same place again. For example, if you know that you created a 4GB partition, a 500GB partition, and then the rest of the disk as a third partition, AND you know the disk was created using an MBR layout, you can probably: fdisk -iy sd0 disklabel -E sd0 > create 1G partition > create 500G partition > create "rest of disk" partition And...most likely, that 1G partition would be where it was before, the 500G would be where it was, and (ta-da) your "rest of disk" partition would be exactly where it was. Exception: a number of years ago, OpenBSD changed the default starting offset from 63 sectors to 64 sectors to better handle 4k block drives. You will need exactly the correct offset. Assuming your disks were set up at the same time, your sd0 would be a good guide there. I just reread your note and realize that you might be saying that sd1 is an encrypted disk. In which case, all the above applies, BUT you probably can't see your /var partition, so you might be out of luck. But if you know how it was created (and your daily output e-mails might be of use there), you might get lucky recreating the disklabel. You might want to start by imaging the remains of the disk to another drive before going any further so you can try again if you guess wrong. But yeah. You need a good backup. here's mine: https://holland-consulting.net/scripts/ibs/ ksh shell script + rsync + another computer and big disk. Nick.
httpd stopping
Hello, Twice in the last couple weeks, I've had httpd fall over on me. Only clue I've got is this in /var/log/messages: MASTER $ grep httpd daemon Sep 23 05:24:06 node2 httpd[69989]: logger exiting, pid 69989 Sep 23 05:24:06 node2 httpd[80972]: parent terminating, pid 80972 Sep 23 05:24:06 node2 httpd[46871]: server exiting, pid 46871 Sep 23 05:24:06 node2 httpd[34953]: server exiting, pid 34953 first time was after seven days of uptime, this time after six days. (dmesg below) I've not seen httpd fall over like this before...where can I look to provide better info on this problem? (I've got a pair of machines here. I've flipped over to the other after reving it up to -current (yesterday's snapshot, but machine that failed twice is still at the snapshot that failed for now). Nick. OpenBSD 7.3-current (GENERIC.MP) #1360: Fri Sep 8 19:01:03 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 50078154752 (47758MB) avail mem = 48540717056 (46292MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x6f3c3000 (84 entries) bios0: vendor American Megatrends Inc. version "3.4" date 10/30/2020 bios0: Supermicro X11SPW-TF efi0 at bios0: UEFI 2.7 efi0: American Megatrends rev 0x5000e acpi0 at bios0: ACPI 6.2 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP FPDT FIDT SPMI UEFI SSDT MCFG HPET APIC MIGT MSCT PCAT PCCT RASF SLIT SRAT SVOS WDDT OEM4 OEM1 SSDT OEM3 SSDT SSDT DMAR HEST BERT ERST EINJ WSMT acpi0: wakeup devices XHCI(S4) RP17(S4) PXSX(S4) RP18(S4) PXSX(S4) RP19(S4) PXSX(S4) RP20(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 acpimcfg0: addr 0x8000, bus 0-255 acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) Bronze 3204 CPU @ 1.90GHz, 1900.06 MHz, 06-55-07, patch 05003604 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,MPX,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,AVX512CD,AVX512BW,AVX512VL,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,TSX_CTRL,MISC_PKG_CT,ENERGY_FILT,SBDR_SSDP_N,PSDP_NO,FB_CLEAR,RRSBA,GDS_CTRL,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 16-way L2 cache, 8MB 64b/line 11-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 25MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) Bronze 3204 CPU @ 1.90GHz, 1900.17 MHz, 06-55-07, patch 05003604 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,MPX,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,AVX512CD,AVX512BW,AVX512VL,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,TSX_CTRL,MISC_PKG_CT,ENERGY_FILT,SBDR_SSDP_N,PSDP_NO,FB_CLEAR,RRSBA,GDS_CTRL,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 16-way L2 cache, 8MB 64b/line 11-way L3 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) Bronze 3204 CPU @ 1.90GHz, 1900.13 MHz, 06-55-07, patch 05003604 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,MPX,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,AVX512CD,AVX512BW,AVX512VL,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,TSX_CTRL,MISC_PKG_CT,ENERGY_FILT,SBDR_SSDP_N,PSDP_NO,FB_CLEAR,RRSBA,GDS_CTRL,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 16-way L2 cache, 8MB 64b/line 11-way L3 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor
Re: man.openbsd.org is down?
On 9/23/23 13:42, S V wrote: Any info on man.openbsd.org state? It is down for me and web checkers. It is back up now. Seems my monitor's alert to text me is handled as spam by my cellular service now. Sorry for the downtime! Nick.
Re: desire for journaled filesystem
On 9/6/23 08:23, John Holland wrote: Janne- Thanks for all that useful information. others- this is a thinkpad, that's not on all the time, so a cron backup is not that good. I actually back up manually, currently using "borg" for that. I mostly just do email and web on it so there's probably nothing serious lost. In a few days I will have the external disk with the backup back here and I may see what I can find on it. My /home partition has a lot of data on it because I built an AWS Openbsd machine image on it. But it would be good to see whether my system is working correctly. Cats are fuzzy Fire is hot Journaling file systems are complicated Backups are important. That's four mostly unrelated topics. I'd argue there is more connection between cats and journaled file systems then there is between journaled filesystems and backups, in that both cats and fancy file systems can be adorably cute and cause lots of data loss (and the backups are how you recover from bad file systems and cat mischief). Put bluntly, I turn my OpenBSD machines off by yanking power from them often, and I've been doing that for well over 20 years (since OpenBSD v2.5). Sometimes accidentally (bad laptop battery, power outage, tripping over a power cord), sometimes out of lazy indifference and not feeling like logging in and doing it right. Yeah, I get lots of scary looking messages about my data being turned to hash, but you know how often I've had actual data loss because of that? Only when I didn't save my work (which does happen too often). The ONLY time I remember I had an "event" that caused actual file system corruption that wasn't easily fixed with a routine fsck was when a SCSI controller literally fell out of the computer while the computer was on. Yeah, ended up reformatting that one. Pretty sure your journaled file systems would have been in pretty much the same place, and ZFS would have shit itself on an unrelated computer across the room in sympathy. (oh, there was that incident with the nail gun going through the hard disk, but I'm pretty sure no FS was gonna save that one). You know how often your beloved "journaling file system" would have saved my data? I can't think of one time. I'm sure someone somewhere will swear it saved their data, but that's hard to prove. I'm just lacking experience losing data on FFS that could have been saved by a "better" FS. Twenty+ years of power outages, broken hardware, testing software, tripping over power cords and being lazy with hundreds of machines, and can't say I ever said, "Gee, I wish I had a journaled file system, that really would have saved me right there". You know how often those piece of shit Linux File System of the Month have bit me in various ways? A lot. Just spent the last week dealing with a problem that turned out to be 100% CAUSED by BTRFS. A problem that just wouldn't have been a thing if it was running FFS. It was literally "features" taking down a customer facing system, over and over. You are trying to "fix" a non-problem by making things more complicated. Not gonna work they way you expect. Nick.
Re: volatility or something like that in the future ?
On 8/19/23 06:05, whistlez wrote: ... I honestly don't understand this hatred. ... Dude, for a self-proclaimed sensitive person, you are really very offensive, and begging to have your tender little ass handed (verbally) to you on a platter. You are spending a lot of time telling very skilled people that you are both ignorant on this topic AND how to do their jobs. You know what is offensive around here? * Telling developers how they should spend their efforts. * Being offended when someone suggests YOU demonstrate work. * Taking pride in your ignorance on how to do something but assuming you have the right to tell others to utilize their skill. * Suggesting that because Linux does something, OpenBSD should do it without understanding how WRONG so much of Linux is (at least in an OpenBSD mindset). Linux has become Windows Reinvented Badly. You seem to think OpenBSD should become Linux Reinvented Badly. That's offensive. Nick.
Re: Stuck in X start and crash loop
On 8/17/23 12:10, l...@ena.re wrote: Hey, I am new to OpenBSD. I run 7.3-stable. My understanding after reading X(7), Xsecurity(7) and xenodm(1) is that one can set the environment variable XAUTHORITY to specify the location of the file, which by default, is located at $HOME/.Xauthority.> In $HOME/.profile I set XAUTHORITY=$HOME/.config/X/Xauthority and moved .Xauthority to $HOME/.config/X/Xauthority. However, now, when I boot and X is started, I see the cursor in the middle of the screen for a moment and then X seems to crash and start again. I am stuck in this loop. Why do I not witness the behaviour I expected? Should I have set the environment variable in $HOME/.xsession? if you want my opinion of what you should do, i'd argue you should leave it alone. More importantly, how do I exit this loop and revert the changes? What isn't clear is when you get the loop. Are you logging in in text mode then starting X as you, and getting this loop? or is X starting on boot, and you are getting that loop? If X is starting on boot and looping, I think you have another problem, because a file in your home directory isn't being referenced until you log in. But, to answer your question about how to fix it...depending on what is going on, I'd start with CTRL-ALT-F1 to get to the command line, log in, undo. You might be able to hit CTRL-ALT-BackSpace to shut down X, but if you are running xenocara, that will just take you back to the login prompt. But NOW you might be able to CTRL-ALT-F1 back to the CLI. WORST CASE, reboot the machine, and boot in single user mode. # mount -a # export TERM=vt220 ...fix it Nick.
Re: Mouse not working via KVM switch
On 8/14/23 13:37, Karel Lucas wrote: HI all, On a recent install of openBSD I can't get the mouse to work through my KVM switch. I work with various computers via a KVM switch on 1 monitor with a keyboard/mouse combination. Only on the PC with openBSD the mouse does not work, the keyboard on the other hand works fine. Both are connected to the KVM switch via USB, and the switch via USB to the computers. The brand of the mouse is Logitech. Does anyone know why the mouse doesn't work, but the keyboard does? Good thing Logitech only makes one kind of mouse. HA! HAHAHaHahahaha!!! I am so funny. Really, though -- you thought mentioning just the brand name of one of the more diverse makers of mice over 40+ years is all we needed to know? KVM switches are like a lot of other things -- tested with Windows, MAYBE Linux. And there are widely differing qualities and designs, some probably weren't tested at all. I can assure you, OpenBSD has no intrinsic issue with KVM switches. I regularly use a dual HDMI monitor 4-way KVM switch on OpenBSD and Windows machines, works great in spite of being shockingly cheap (until it seems two of the USB input ports died...but fortunately, it had two extras, and I wouldn't be surprised if a complete powerdown fixed it). That one replaced an even cheaper single monitor switch which was almost useful, but had a lot of issues (including keyboard/mouse just dying from time to time). First of all, does your mouse work directly plugged into the OpenBSD computer? If so, it's your KVM switch. Replace it. If not, it is your mouse. Replace it. Second...if you boot the OpenBSD machine with the KVM pointed at the OpenBSD machine, does it work? If so, your KVM switch is cranky. You might be able to improve how OpenBSD deals with KVM switched mice, because yes, it does seem to be a little more touchy than some other OSs, but someone with good programming and HW trouble shooting skills AND a cheap-*** POS KVM switch would have to care. Most people that skilled generally just buy a better KVM switch and move on. What does the dmesg show as you switch the KVM around? That would tell us how the KVM works. Some are equiv. of plugging and unplugging the mouse/keyboard/monitor, some do some kind of "keep alive" so the computer thinks the mouse is still there. Both can cause problems of different types (my "good" one seems to plug/unplug the mouse/keyboard, but has a great keep-alive for the monitor). Nick.
Re: nsd listening on localhost is zone transfer possible transfer ?
On 8/4/23 13:23, Shadrock Uhuru wrote: hi everyone i have unbound setup on port 53 and nsd listening on localhost port 53530 i have set up another dns server as a secondary am i correct to assume that i can't zone transfer because as the nsd's are listening on localhost the primary can't reach the secondary ? i have these errors on the primary error: xfrd: zone 1.10.10.in-addr.arpa: max notify send count reached, 10.10.1.5 unreachable error: xfrd: zone forwardzone: max notify send count reached, 10.10.1.5 unreachable shadrock yes, they have to have some way to talk. Lots of ways around this, including alternate ports, redirection in PF, etc. For example...you could redirect from ONE IP address (your "other" server) to NSD, the rest goes to unbound. Or have unbound listen on another port that is filtered to only listen to your other server. But my recommended way: don't do zone transfers. Manage your DNS in another way. I consider the whole zone transfer thing a bad idea. What's the reason for having multiple DNS servers? Redundancy. What do you get when one of your "redundant" systems controls the other? A: A system that isn't very redundant. If that controlling system goes down, you have issues. LONG TIME AGO...in a job far, far away, I set up a pair of DNS servers, and a little script. I (or my teammates) could make changes to either DNS server, test them, then run the script. The script would: 1) run a diff between the zone file on THIS system and the OTHER system. 2) Put that diff into a file, named with the date and time. 3) Put me in vi to edit that file, so I could put a comment in it explaining what the change was for. This gives me a chance to verify the change is JUST what I want, and make sure there weren't other changes made that didn't get replicated. 4) IFF I saved that file with changes, it would: a) copy and install the file to the "other" system b) save the diff file to a history directory on BOTH systems 5) Compare the replication script to make sure I didn't update one and forget to update the other. Now you have two DNS servers that hold the same data when you want them to, can be managed separately for testing, and brought back into sync. Either machine can run indefinitely without the other, either machine can be used as a source for rebuilding the other. You also have near zero-effort "change control". Same concept works for PF and other redundant systems. Today, lots of people will recommend a central management system, and that's not all bad, but I have found often with DNS, you want to be able to test a change on one machine before breaking everything...and then waiting for the next refresh cycle to fix it. Nick.
Re: Installing openBSD
On 8/3/23 16:48, Karel Lucas wrote: Hi, My openBSD installation was successful! I first removed all partitions except for the EFI partition, which I left. Second I created one openBSD partition(type A6) on the freed space, after which I partitioned that partition with auto layout. Then I continued with the regular installation, and after reboot I got the login prompt. So in hindsight it was wise to leave the EFI partition. Perhaps others can benefit from this experience. So you leapt from "This didn't break the shit out of my computer" to "everyone should do it this way". Creative. But wrong. NO. If you don't have reason to retain the EFI partition (i.e., multibooting), just pick whole disk GPT and quit wasting time. If you don't know what is in your EFI partition, you SHOULD overwrite it so you know you have a clean and trustable system. OpenBSD is designed to be able to install on wiped disks, new disks, or co-exist with other systems. You seem to think that if you go out a buy a new hard disk at the store, you couldn't possibly install OpenBSD on it because there's no existing EFI partition. A lot of people can assure you this is incorrect. Nick. Op 01-08-2023 om 07:04 schreef patric conant: Hitting enter in the installer to use the whole disk will take care of you. As pointed out repeatedly, there are no requirements from pfsense to install or maintain openbsd. In the same way that pfsense didn't need anything form OpenBSD to install, OpenBSD can create all the necessary partitions for successful EFI experience, and doesn't need anything from pfsense. On Sun, Jul 30, 2023 at 12:41 PM Karel Lucas wrote: Hi all, I'm going to install openBSD on a small PC that currently has PfSense on it. This PC boots this OS via (U)EFI, and therefore has an EFI partition on the existing SSD. The current partition table looks like, as shown by openBSD fdisk: 0: efiboot0 1: gptboot0 2: swap0 3: zfs0. Should I keep the (U)EFI partition? And if so, how do I mount the future openBSD root partition to this (U)EFI installation? Are there any other things I should watch out for? I look forward to receiving responses from this community. Sincerely, Karel. -- Patric Conant Mirage Computing Lead Consultant @MirageComputing <https://twitter.com/MirageComputing>on twitter https://m.facebook.com/MirageComputing/ 316 409 2424
Re: Installing openBSD
On 7/30/23 13:30, Karel Lucas wrote: Hi all, I'm going to install openBSD on a small PC that currently has PfSense on it. This PC boots this OS via (U)EFI, and therefore has an EFI partition on the existing SSD. The current partition table looks like, as shown by openBSD fdisk: 0: efiboot0 1: gptboot0 2: swap0 3: zfs0. Should I keep the (U)EFI partition? And if so, how do I mount the future openBSD root partition to this (U)EFI installation? Are there any other things I should watch out for? I look forward to receiving responses from this community. Sincerely, Karel. The OpenBSD installer is designed to be able to install to a totally blank hard disk, so there is no need to retain any of the current partitions. IF you are trying to do simple wipe and load, just chose the "entire disk GPT" option and everything will happen as you wish, most likely. If you think your hardware is special, you might want to test on another disk, at least temporarily. IF you want to multiboot, just don't until you can answer questions like this yourself. Multibooting is very complicated, and requires a mastery of the boot process of ALL the OSs installed. People often consider it a way to "learn" a new OS, I disagree, it is a good way to get massively frustrated and lose a lot of data. Nick.
Re: How to customize disk partition in UEFI?
On 7/22/23 15:44, ykla wrote: For OpenBSD installation, I choose custom disk in partition. And I set the first partition is MSDOS and mountpoint is /boot/efi and the second partition is /, the last partition is swap. And I continue install openbsd, but at least it warning me that boot install failed, the system will not boot. And set none mountpoint is also be errors. Last I Automated partition first and delete all partition except i that is MSDOS partition. Then everything is fine. So how to customize disk partition in UEFI except Auto creates EFI partition? ykla I think you are confusing the fdisk and disklabel parts of the install, and you aren't providing enough details about what you are trying to do. During the fdisk stage, you don't worry about root and swap. During the disklabel stage, you don't worry about the efi stuff. So ... let's assume you are doing an OpenBSD-only UEFI install. In the installer, pick "Whole Disk GPT" or something similar to set up the UEFI partition and the OpenBSD partition. Done. IF you are trying to multi-boot and adjust your fdisk partitions, I'd suggest starting with the OS that is most picky and/or gives you the least control over the install -- probably Linux or Windows. Then boot the OpenBSD installer, and work an OpenBSD partition into available space, and do the install as normal. Now customize the disklabel partitions as you wish. You went out of your way to mention swap and root, and nothing else. I'm taking this as meaning you are intending to do things wrong by making a root- only system. Please stop and reconsider your life choices here, this one is probably not one of your better ones. Nick.
Re: Concise passage in OpenBSD documentation about motivation
On 7/18/23 13:26, Ibsen S Ripsbusker wrote: Dear colleagues, About 20 years ago I read in some OpenBSD documentation, likely the installation instructions, that we want people to copy our OpenBSD even if to use it even in proprietary products, because the alternative is that incompetent people write their own software instead of copying and then the users suffer. I found this particular passage to be very well written. Does someone know where I might find this wonderful passage? With great honor, Ibsen Dang, that sounds familiar. I think I found it: https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/www/faq/faq1.html?rev=1.147&content-type=text/html#ReallyFree I definitely say something similar regularly, but it looks like the original text here was from Theo, himself. I've been similarly inspired and found the example memorable. :) Nick.
Re: Intel DRM error on T 440
On 7/6/23 01:46, Jonathan Drews wrote: uname: OpenBSD 7.3 GENERIC.MP#1125 amd64 I get the following error message when my Thinkpad T440 wakes up: drm:pid73944:intel_dp_aux_wait_done *ERROR* [drm] *ERROR* AUX A/DDI A/PHY A: did not complete or timeout within 10ms (status 0xa01300e1) I have Googled that error message and no fixes turn up. In other respects, my OpenBSD T440 works just great. My rc.conf.local contains this:> apmd_flags=-A pf=YES pkg_scripts=messagebus cupsd mysqld xenodm_flags= Any suggestions as to what I may have misconfigured would be helpful. I have loaded the firmware using fw_update. This error did not occur in OpenBSD 7.2. I believe what you are seeing is an informative message about what is going on under the covers, not an problem you (as a user) need to deal with if everything is working as it should be. However, if things are NOT working as they should, messages like this are potentially helpful to developers to track down the problem. Hardware is often imperfect, and often doesn't behave as documented, and has to be "fixed" (or more accurately, worked around) in software. I think that's all you are seeing here -- notification that something was worked around (or at least, didn't behave as expected) -- if there are no other symptoms. Nick.
Re: encrypted_hdd_data_recovery(OpenBSD_7.3)
On 6/30/23 08:30, soko.tica wrote: Thanks NIck, How do I exactly try to unlock the disk with bioctl command? I do not have the appropriate disk to try to rebuild it. I am trying it from openbsd 6.9 bootable usb. The encrypted hdd was 7.3. don't do that. I'm not aware of any incompatibilities between 7.3 and 6.9, but I'm not going to look, it just isn't a good idea. Bring your 6.9 box up to 7.3, then do it. But ... after you upgrade your recovery machine to 7.3, let's assume your drive you are after is sd2, and the encrypted drive is partition d (note there are two assumptions there, hopefully my example is wrong, and you have to understand what I'm suggesting here before blindly doing it!) : # bioctl -c C -l /dev/sd2d softraid0 at that point, it will prompt you for your passphrase, and if you enter that correctly and the disk is intact, it will create a new "drive", which will have its own disklabel, and you can mount those partitions. Nick. Please. Thanks in advance On Sat, Jun 17, 2023 at 4:33 PM Nick Holland wrote: On 6/17/23 08:40, soko.tica wrote: > Hello list, > > I have managed to screw by > #fsck_ffs /dev/sd1a > > the root partition of my unmounted HDD (OpenBSD 7.3 stable, possibly not > fully updated). It crashed during boot due to the power outage, than it was > unable to boot and required fsck_ffs, and I answered 'F' to the 'Fyn' > prompt. > > Here is the present status of it (it is sd0 in this sequence). > === > Script started on Sat Jun 17 12:26:43 2023 > think# disklabel sd0 > > # /dev/rsd0c: > type: SCSI > disk: SCSI disk > label: HGST HTS725050A7 > duid: 35e70751b7e36f98 > flags: > bytes/sector: 512 > sectors/track: 63 > tracks/cylinder: 255 > sectors/cylinder: 16065 > cylinders: 60801 > total sectors: 976773168 > boundstart: 64 > boundend: 976768065 > drivedata: 0 > > 16 partitions: > #size offset fstype [fsize bsize cpg] >a:976768001 64RAID >c:9767731680 unused > think# ^D > > > Script done on Sat Jun 17 12:26:54 2023 > === this is as I'd expect. but you aren't showing what happens when you try to unlock it I understand you have a problem, but you haven't told us what it is. I was corrected off-list here. You told us the problem, the problem is "no backup" If you have a problem when unlocking the disk with the bioctl command, you probably aren't going to get your data back. If you can get the drive unlocked and available as another logical drive, you will probably have to fsck each partition within it. Hopefully any horrible problems here would be contained to individual partitions, and you can pull data off the rest. ... > Naturally, there is data there, and naturally, I have no backup of it. Of > course I do know the passphrase, it is my hdd. this is what we call a learning experience. > If there is any chance to recover it, please let me know. chance, maybe. But almost by design, encrypted storage is more fragile than unencrypted storage. Nick.
Re: Which hardware for a firewall?
On 6/20/23 13:13, Karel Lucas wrote: Hi all, I'm going to create a firewall with openBSD, and would like to use the ARM64 or ARMv7 distribution for that. Unfortunately I don't know what hardware I can get for this, and that's the reason for this mail. Can someone point me to a suitable platform for this? If this email does not belong on this mailing list, I offer my apology. This is my first post on this mailing list, and ask for understanding. Sincerely, Karel. Fortunately, since there's only one speed connection, a set number of devices doing a fixed number of things in each location, we will have no problem advising you on the best choice for your application... oh, wait... :) Well, here's the HW compatibility for those platforms: https://www.openbsd.org/arm64.html https://www.openbsd.org/armv7.html You will have to decide what fits your needs. Honestly, though, I'd suggest just recycling an old PC and a surplus network card (or multi-port card, depending on how people toss stuff out around you). If you want "the best choice", this is probably it. Nick.
Re: Wrong SHA256 sums for latest snapshot
On 6/19/23 14:38, Benjamin Stürz wrote: Hi misc@, I have issues installing the latest snapshot from cdn.openbsd.org. Snapshots change frequently. They take time to distribute around the world. Content Delivery Networks pull from lots of different sources and cache various things at various times. Kinda easy to see how things like this not only happen, but are kinda expected. For snapshots, you might want to pick a favorite local mirror and use that. I doubt you will see a huge difference in performance for an install or upgrade. Nick.
Re: encrypted_hdd_data_recovery(OpenBSD_7.3)
On 6/17/23 08:40, soko.tica wrote: Hello list, I have managed to screw by #fsck_ffs /dev/sd1a the root partition of my unmounted HDD (OpenBSD 7.3 stable, possibly not fully updated). It crashed during boot due to the power outage, than it was unable to boot and required fsck_ffs, and I answered 'F' to the 'Fyn' prompt. Here is the present status of it (it is sd0 in this sequence). === Script started on Sat Jun 17 12:26:43 2023 think# disklabel sd0 # /dev/rsd0c: type: SCSI disk: SCSI disk label: HGST HTS725050A7 duid: 35e70751b7e36f98 flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 60801 total sectors: 976773168 boundstart: 64 boundend: 976768065 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a:976768001 64RAID c:9767731680 unused think# ^D Script done on Sat Jun 17 12:26:54 2023 === this is as I'd expect. but you aren't showing what happens when you try to unlock it I understand you have a problem, but you haven't told us what it is. If you have a problem when unlocking the disk with the bioctl command, you probably aren't going to get your data back. If you can get the drive unlocked and available as another logical drive, you will probably have to fsck each partition within it. Hopefully any horrible problems here would be contained to individual partitions, and you can pull data off the rest. ... Naturally, there is data there, and naturally, I have no backup of it. Of course I do know the passphrase, it is my hdd. this is what we call a learning experience. If there is any chance to recover it, please let me know. chance, maybe. But almost by design, encrypted storage is more fragile than unencrypted storage. Nick.
Re: media on full screen in current
On 6/12/23 07:54, Pau A.S. wrote: Hi, ... This has led to a FS corruption which I do not know how to fix, only in one partition. Upon boot, the system runs fsck on them but the output is that they are clean with some level of fragmentation. In any case, /usr/local is corrupted. Is there a way to repair it? I naively hoped that an upgrade would do it, but it does not. I'd like to see how you determined that /usr/local is corrupted. You have given a diagnosis, not the data. Your diagnosis may be incorrect. But in general: umount /usr/local (1) fsck /usr/local (look at output. Give up hitting "Y" a lot, hit "F") (MAKE SURE YOU TELL IT TO MARK FILE SYSTEM AS CLEAN!) mount /usr/local IF for some reason that doesn't work, worst case, copy everything off to some other place, umount, newfs that partition, remount, restore. But I'd like to see the actual output of this activity. Nick. (1) this may require bringing the system up in single user mode. /usr/local probably can be done without single user mode but many other mounts will require it)
Re: paket tag, veb0, virtual machine and relayd
On Wed, Jun 7, 2023 at 4:38 AM Stuart Henderson wrote: > On 2023-06-07, Nick Bouliane wrote: > > I have a bridge veb0 to which is connected tap1, the interface of a > virtual > > machine. > > On the bridge I have a rule for tap1: > > pass in on tap1 src 11:22:33:44:55:66 tag VM1 > > > > In the bridge I also have an interface vport0 with the IP address > > 1921.168.0.1 > > This virtual machine has the IP 192.168.0.2 > > > > When a packet comes out of the VM (i.e: curl) it gets tagged by the rule > > that I have on the veb bridge. > > I know the tag is working because I can drop packets with pf (pf.conf) > if I > > add that rule: > > block in on tap1 tagged VM1 > > > > I have relayd listening on vport0 and in my relayd.conf I have this > filter: > > pass path "/something.html" tagged VM1 > > Those "rule tags" are specific to relayd and are not connected with the > PF tags at all. > > The only place relayd interacts with PF tags is if you use "pftag" in a > relayd redirection. > Thank you for enlightening me ! > > > -- > Please keep replies on the mailing list. > >
paket tag, veb0, virtual machine and relayd
I have a bridge veb0 to which is connected tap1, the interface of a virtual machine. On the bridge I have a rule for tap1: pass in on tap1 src 11:22:33:44:55:66 tag VM1 In the bridge I also have an interface vport0 with the IP address 1921.168.0.1 This virtual machine has the IP 192.168.0.2 When a packet comes out of the VM (i.e: curl) it gets tagged by the rule that I have on the veb bridge. I know the tag is working because I can drop packets with pf (pf.conf) if I add that rule: block in on tap1 tagged VM1 I have relayd listening on vport0 and in my relayd.conf I have this filter: pass path "/something.html" tagged VM1 It doesn't work. If I try to match only the path it works, only the IP it works, etc... but the tag doesn't match. Is it supposed to work ? Does the veb strips the tag ? thank you, Nick
Re: relayd filter
On Tue, Jun 6, 2023 at 11:08 AM Paul Pace wrote: > On 6/5/23 3:15 PM, Nick Bouliane wrote: > > Hi, > > > > in relayd.conf I'm trying to do : > > > > pass from 192.168.1.1 path "/something.html" > > > > If I individually specify the "from" or the "path", it works > > but when I combine both, it doesn't work. > > Nowadays, when I come upon this I just use tags and move on. > > Something like this might work: > > match path "/something.html" tag something > pass from 192.168.1.1 tagged something > oh, it works well, thank you ! > > > > > Am I missing something or if it's just not possible ? > > Or is there another way to express this another way ? > > > > thank you, > > Nick > >
relayd filter
Hi, in relayd.conf I'm trying to do : pass from 192.168.1.1 path "/something.html" If I individually specify the "from" or the "path", it works but when I combine both, it doesn't work. Am I missing something or if it's just not possible ? Or is there another way to express this another way ? thank you, Nick
softdep / softraid RAID1 issue?
Hiya. tl;dr version: multiple machines with softraid RAID1 & softdep have file systems freeze when doing lots of I/O, possibly involving adding and removing links from the same files at the same time. Workaround found. Need help finding better diagnostic information. long version: = I have a couple systems which have had an issue for a long time where suddenly, disk activity would just ... stop. No message on console, no panic. Usually, I can still log in, but if I touch the effected file systems, my SSH session (or console login) freezes. Always happens during some intense disk activity (more on that in a moment). When it happens, I can not reboot the system without a hard reset or power cycle (and these systems have multi-TB file systems on them, so doing this is painful). umount on the impacted file systems hangs. I'm not really sure if I lose all file systems or just some. Most of the file systems are very "static". Some things seem to work for a while, but it could well be just cached data. I tried swapping computers, replacing disks, and even doing weekly reboots, all to seemingly no impact. Problem has occurred for well over a year, maybe longer. Upgraded frequently to most recent snaphot, no change seen (I often use hangs as an opporunity to upgrade). Recently, however, I think I caught it in mid-failure. Disk activity was still going on, but it was very slow. 'top' showed "WAIT" on softdep (or something similar). The jobs that should have been long done was still running according to the logs (new files being added to the list of files backed up), but very very slowly. And then it came to a hard stop, as before. This may have been an unusual event, or I might just have happened to look in right place to see something was still happening. These machines are used for rsync --link-dest backup. The short version of the algorithm is something like this: =- PREVIOUS=(find previous backup) TODAY=(today's date) OLDEST=(find oldest backup in the set) REMOTE=(machine we are backing up) # remove oldest backup rm -r $OLDEST & mkdir $TODAY # make new backup rsync --link-dest $PREVIOUS $REMOTE $TODAY =- This backup process basically makes a hard link for files that haven't changed, and copies over files that did change. After first backup, all future backups are incrementals, both in time and additional disk usage. A bunch of these will typically be running at the same time, maybe five to ten of them (adjusting this number didn't seem to have any effect). When it fails, usually a few succeed, and the rest just never complete. Here's where it gets weird -- removing the '&' after the rm -r $OLDEST line seems to have FIXED THE PROBLEM. No problems in 18 days, which is a pretty good record. SPECULATION: the rm and rsync processes running at the same time can potentially be putting both new links and removing old links from the same file at the same time (well...multi-tasking definition of "same time"). Maybe something is having a problem with this. I have another machine running the same backup process, which has not had a problem. It has been running happily for 123 days now (yeah, I kinda forgot about it). It is a little laptop, so only one hard disk, but I am using a softraid encrypted disk. So yes, also using softraid, but only one media to read/write to. So maybe associated with either RAID1 or multiple disk I/Os. So, my problem is worked around, but I suspect there's still a bug there. I am happy to put the '&' back and gather more information next time it happens...if someone tells me what info to gather. Nick. Machine that has had problems, but fixed by no longer backgrounding the rm -r $OLDEST backup: OpenBSD 7.3-current (GENERIC.MP) #1175: Wed May 3 08:19:33 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 5872685056 (5600MB) avail mem = 5675061248 (5412MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb240 (42 entries) bios0: vendor AMI version "7.16" date 01/18/2012 bios0: Hewlett-Packard p6-2108p acpi0 at bios0: ACPI 4.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG SLIC HPET SSDT SSDT DBGP acpi0: wakeup devices SBAZ(S4) P0PC(S4) UHC1(S3) UHC2(S3) USB3(S3) UHC4(S3) USB5(S3) UHC6(S3) UHC7(S3) XHC0(S3) XHC1(S3) PE20(S4) PE21(S4) PE22(S4) PE23(S4) BR15(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD E2-3200 APU with Radeon(tm) HD Graphics, 2395.89 MHz, 12-01-00 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,3DNO
Using pf route-to to Route Network Traffic a tun interface and Replying from it
Hi Folks, I am writing to seek assistance regarding an issue I am experiencing in trying to route my Personal Computer's network traffic to a TUN interface. My objective is to modify some of its content and subsequently return the traffic back. So far, I have successfully created a TUN interface using the following configuration: andersen@pc% ifconfig tun8 inet 172.16.122.1/32 172.16.122.2 up andersen@pc% ifconfig tun8 tun8: flags=8051 mtu 1500 inet 172.16.122.1 --> 172.16.122.2 netmask 0x Subsequently, I have also inspected the primary Ethernet interface, em0, as follows: andersen@pc % ifconfig em0 em0: flags=8863 mtu 1500 options=6463 ether xx:xx:xx:xx:xx:xx inet 192.168.1.128 netmask 0xff00 broadcast 192.168.1.255 nd6 options=201 media: autoselect status: active And I've updated pf.conf; set skip on { lo0 tun8 } ext_if="em0" tun_if="tun8" # allow dns pass in log quick on $ext_if inet proto { tcp udp } from any to any port 53 pass out log quick on $ext_if inet proto { tcp udp } from any to any port 53 pass in log quick on $ext_if pass out log quick on $ext_if route-to (tun8 (tun8)) no state pass out log quick on $tun_if reply-to (em0 (em0)) -- I implemented a small C program that reads packets from /dev/tun8 and writes them back to the same device. During the writing phase, I have attempted to add a 4-byte TUN header (with AF_INET byte). The issue arises when I enable pf, as my connectivity ceases to function. I suspect that the problem may be linked to the reply-to rule. I can accurately read all network packets, but my network connectivity is disrupted when I activate pf. Are there any thoughts about what I'm doing wrong? Thanks! Here is a sample from pflog; andersen@pc% sudo tcpdump -nettti pflog0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 246 bytes 00:00:00.00 rule 6/0(match): pass out on em0: 192.168.1.128.52553 > 17.248.173.70.443: Flags [S], seq 1289016582, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 1617830816 ecr 0,sackOK,eol], length 0 00:00:00.005332 rule 6/0(match): pass out on em0: 192.168.1.128.52569 > 17.248.172.107.443: Flags [S], seq 1886843796, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 386220006 ecr 0,sackOK,eol], length 0 00:00:00.178005 rule 6/0(match): pass out on em0: 192.168.1.128.52554 > 17.248.172.208.443: Flags [S], seq 3787270145, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 1898437799 ecr 0,sackOK,eol], length 0 00:00:00.079092 rule 6/0(match): pass out on em0: 192.168.1.128.52570 > 17.248.173.83.443: Flags [S], seq 606598735, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 2940552698 ecr 0,sackOK,eol], length 0 00:00:00.174093 rule 6/0(match): pass out on em0: 192.168.1.128.52555 > 17.248.172.172.443: Flags [S], seq 1449413825, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 212268682 ecr 0,sackOK,eol], length 0 00:00:00.079048 rule 6/0(match): pass out on em0: 192.168.1.128.52571 > 17.248.172.135.443: Flags [S], seq 1322915507, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 1857621092 ecr 0,sackOK,eol], length 0 00:00:00.251641 rule 6/0(match): pass out on em0: 192.168.1.128.52572 > 17.248.173.70.443: Flags [S], seq 445446, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 2056755864 ecr 0,sackOK,eol], length 0 00:00:00.257416 rule 6/0(match): pass out on em0: 192.168.1.128.52573 > 17.248.172.208.443: Flags [S], seq 1732485582, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 1481034375 ecr 0,sackOK,eol], length 0 00:00:00.251107 rule 6/0(match): pass out on em0: 192.168.1.128.52574 > 17.248.172.172.443: Flags [S], seq 3829285313, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 2878347929 ecr 0,sackOK,eol], length 0 00:00:00.013117 rule 6/0(match): pass out on em0: 192.168.1.128.52558 > 23.53.168.52.443: Flags [S], seq 4080379298, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 2646123787 ecr 0,sackOK,eol], length 0 00:00:00.37 rule 6/0(match): pass out on em0: 192.168.1.128.52557 > 23.53.168.52.443: Flags [S], seq 357265796, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 4150893962 ecr 0,sackOK,eol], length 0 00:00:02.208051 rule 6/0(match): pass out on em0: 192.168.1.128.52567 > 17.248.173.13.443: Flags [S], seq 3186783538, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 119993039 ecr 0,sackOK,eol], length 0 00:00:00.077884 rule 4/0(match): pass in on em0: 192.168.1.1 > 224.0.0.1: igmp query v2 00:00:00.175705 rule 6/0(match): pass out on em0: 192.168.1.128.52568 > 17.248.172.177.443: Flags [S], seq 1856508746, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 2360328967 ecr 0,sackOK,eol], length 0 00:00:00.255099 rule 6/0(match): pass out on em0: 192.168.1.128.52569 > 17.248.172.107.443: Flags [S], seq 1886843796, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val
Re: carp flapping
Followup... On 5/12/23 08:17, Stuart Henderson wrote: On 2023-05-12, Nick Holland wrote: ... I had several other people suggest network problems. I'm not going to say "impossible" or even "unlikely", but my understanding is that the two machines are both plugged into the same switch, in the same rack. I've since had someone more familiar with the physical environment say my blind trust in their switch hw may be slightly misplaced. :) You can also look at netstat -ni -I ixl0 netstat -ni -I ixl0 -e kstat ixl0::: These looked REALLY clean. no drops, fails or collisions. which may give some other clues even pfctl -si might have something relevant Several people pointed out I was using the default advskew of 1 second, which means a small network glitch (or system load? maybe I'm all wrong about this system never breaking a sweat, at least when it comes to network traffic) would flip it, so I've increased it to 10 on both machines (and apparently just induced a flip of my own. oops). By the nature of this system, some people will be annoyed by any flip, so it really doesn't matter if it was a 1 second outage or a 30 second outage, I just want the system available again after an unhappy event (or routine maintenance). the course adjustment in seconds is advbase, advskew is a much smaller delay meant for a config with primary/backup where the backup advertises just slightly less frequently. Um. yeah. I set advbase, and typed advskew in the e-mail. my bad. After setting to 10, I have gone over two weeks without any flips, so that looks like that is a pretty good fix. Thanks for the guidance! Nick.
Re: carp flapping
On 5/12/23 03:28, Stuart Henderson wrote: On 2023-05-12, Nick Holland wrote: Here's the problem I've seen: I have my two machines flipping state randomly(?). This bothers me because that means it is breaking people's downloads. Longest period betweek flips was less than two weeks. So ... I cranked up the carp logging to 5 and then 7 to see what it had to say about why...and it had almost nothing to say. Does netstat -s -p carp give any enlightenment? ok, I just skewed the stats by taking the opportunity to bring the now backup up to -current, so node1 does not have the most recent flap: node1 $ uptime 7:18AM up 8:22, 1 user, load averages: 0.00, 0.05, 0.08 node1 $ doas netstat -s -p carp carp: 29981 packets received (IPv4) 0 packets received (IPv6) 0 packets discarded for bad interface 0 packets discarded for wrong TTL 0 packets shorter than header 0 discarded for bad checksums 0 discarded packets with a bad version 0 discarded because packet too short 0 discarded for bad authentication 0 discarded for unknown vhid 0 discarded because of a bad address list 0 packets sent (IPv4) 0 packets sent (IPv6) 0 send failed due to mbuf memory error 0 transitions to master node2 $ uptime 7:19AM up 4 days, 20:58, 2 users, load averages: 0.83, 0.78, 0.73 $ ] netstat -s -p carp carp: 367836 packets received (IPv4) 0 packets received (IPv6) 0 packets discarded for bad interface 0 packets discarded for wrong TTL 0 packets shorter than header 0 discarded for bad checksums 0 discarded packets with a bad version 0 discarded because packet too short 0 discarded for bad authentication 0 discarded for unknown vhid 0 discarded because of a bad address list 52806 packets sent (IPv4) 0 packets sent (IPv6) 0 send failed due to mbuf memory error 2 transitions to master Will monitor going forward, though. I had several other people suggest network problems. I'm not going to say "impossible" or even "unlikely", but my understanding is that the two machines are both plugged into the same switch, in the same rack. Several people pointed out I was using the default advskew of 1 second, which means a small network glitch (or system load? maybe I'm all wrong about this system never breaking a sweat, at least when it comes to network traffic) would flip it, so I've increased it to 10 on both machines (and apparently just induced a flip of my own. oops). By the nature of this system, some people will be annoyed by any flip, so it really doesn't matter if it was a 1 second outage or a 30 second outage, I just want the system available again after an unhappy event (or routine maintenance). Nick.
carp flapping
Hi, I have a couple identical servers that provide a few services (not FW or gateway -- http, ftp, etc.). Figured they would make a great CARP pair, so if the primary broke, the secondary would take over immediately. It would also make maintenance windows shorter...make changes on secondary machine, test, reboot primary to force the secondary to become master. The two machines should be equals. I have no preference on running on one machine or the other. IF nothing breaks, I'd prefer that the one that is serving keep serving until I tell it otherwise. Both machines should have no issue with performance with the tasks they have, lots of proc, lots of RAM, nvme disk, etc. Here's the problem I've seen: I have my two machines flipping state randomly(?). This bothers me because that means it is breaking people's downloads. Longest period betweek flips was less than two weeks. So ... I cranked up the carp logging to 5 and then 7 to see what it had to say about why...and it had almost nothing to say. Here is the info from messages from both machines for the most recent flip. Past ones look basically the same. Node 2: /var/log $ zgrep carp0 messages May 9 21:51:23 node2 /bsd: carp0: state transition: BACKUP -> MASTER May 9 21:51:25 node2 /bsd: carp0: state transition: MASTER -> BACKUP May 11 16:36:04 node2 /bsd: carp0: state transition: BACKUP -> MASTER Node 1: /var/log $ zgrep carp messages May 9 21:51:25 node1 /bsd: carp0: state transition: MASTER -> BACKUP May 9 21:51:28 node1 /bsd: carp0: state transition: BACKUP -> MASTER May 11 16:36:07 node1 /bsd: carp0: state transition: MASTER -> BACKUP hostname.carp0 from both machines: inet a.b.c.240 255.255.255.0 128.100.17.255 vhid 1 carpdev ixl0 pass censored inet alias a.b.c.241 255.255.255.255 128.100.17.255 inet alias a.b.c.243 255.255.255.255 128.100.17.255 inet alias a.b.c.246 255.255.255.255 128.100.17.255 verified identical (before slight anonymizing) on both systems. hostname.ixl0 on node1: inet a.b.c.248/24 hostname.ixl0 on node2: inet a.b.c.247 0xff00 pf.conf includes this before any other "quick" statements: pass quick inet proto carp all Is there something I'm missing? Incorrect expectations on my part? Nick. dmesg: OpenBSD 7.3-current (GENERIC.MP) #1175: Wed May 3 08:19:33 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 50078154752 (47758MB) avail mem = 48540807168 (46292MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x6f3c3000 (84 entries) bios0: vendor American Megatrends Inc. version "3.4" date 10/30/2020 bios0: Supermicro X11SPW-TF efi0 at bios0: UEFI 2.7 efi0: American Megatrends rev 0x5000e acpi0 at bios0: ACPI 6.2 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP FPDT FIDT SPMI UEFI SSDT MCFG HPET APIC MIGT MSCT PCAT PCCT RASF SLIT SRAT SVOS WDDT OEM4 OEM1 SSDT OEM3 SSDT SSDT DMAR HEST BERT ERST EINJ WSMT acpi0: wakeup devices XHCI(S4) RP17(S4) PXSX(S4) RP18(S4) PXSX(S4) RP19(S4) PXSX(S4) RP20(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 acpimcfg0: addr 0x8000, bus 0-255 acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) Bronze 3204 CPU @ 1.90GHz, 1900.06 MHz, 06-55-07 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,MPX,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,AVX512CD,AVX512BW,AVX512VL,PKU,WAITPKG,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 16-way L2 cache, 8MB 64b/line 11-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 25MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) Bronze 3204 CPU @ 1.90GHz, 1900.09 MHz, 06-55-07 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,MPX,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,AVX512CD,AVX512BW,AVX512VL,PKU
Re: What is the best way to move a VM to a bigger image?
On 5/6/23 12:54, Hannu Vuolasaho wrote: Hello, I made a silly mistake when I set up my VM and my disk image is too small for my next operation. My plan is to give the new image to the VM, run a minimal install on it so I get the boot loader installed. Also disklabel will be good. After that I remove all the files and mount the old VM image to another part of the tree. Rest is just a dump and restore operation. And checking the /etc/fstab Is this a good way to skin this cat? Or is there a better way to do it? Not enough information to give an absolute answer, but on minimal thought, I can think of a few ways to deal with a space problem on a VM: 0) Just start over * Advantage: Disk space probably wasn't your only error in setup. Good time to fix those other issues, too. Practice in config. * Disadvantage: Opportunity to make NEW errors! :) 1) build a new VM, restore from your backup to the new VM. * Advantage: tests your backup and restoration process. If your routine backup/restore process doesn't get you through this, you have a problem. You still have your old VM untouched. * Disadvantage: More or less end up with where you started, but more space. 2) Add additional virtual disks to your VM. Copy partitions to new disk, delete partitions on old disk, growfs partitions on old disk to use space of partitions, etc. * Advantage: you really learn disk manipulation, can sometimes be done with minimal downtime. * Disadvantage: you can really screw stuff up, too, leading to option #0 2a) Enlarge the existing virtual disk, use the additional space as with option #2 above. 3) Dang, I thought I had another option here, but I'm blanking on what it was. Advantage: someone else can put their thoughts in. Disadvantage: do you really want to trust someone this forgetful? Nick.
Re: Very slow smtp connection to mail.openbsd.org
On 5/3/23 18:30, S V wrote: Hello, I'm trying to setup my own mail server and while I can send email to any already tested and interesting for me domains. I always get "delayed" with misc@openbsd.org: Connection closed unexpectedly while trying openbsd lists. I telnet to 25 port and see that it has extremely slow speed like 1 character per second. I telnet from other "non-mail" vps and I see that for first seconds it is also slow, but later it become "instant". Are there any "delay" filter for spammers? If yes then why it detects my non-mail vps as ok and still slows my "mail server" (with existing PTR)? If there are no delay... ugh, guess I'm out of luck with my ISP ? But then again why vps is ok? Thanks in advance for any suggestions! man spamd It's running on the OpenBSD mail server. also look up "Greylisting" with your favorite search engine. Nick.
Re: openbsd firewall configuration for extreme hostile environment
ill bring their own tools, meanwhile stuff will be falling apart all around you over your misguided sense of security. 5) Disabled Services. The services in the file rc.conf are kept in its default state which is mostly disabled. the binary files sshd, portmap, ntpd are deleted from the /bin directory. Other binary files telnet, ssh, scp, sftp are removed to prevent any file transfer from the firewall to the LAN network. so .. you have rendered your machine unmaintainable, un-patchable. NO. DON'T DO ANY OF THIS. Strictly for a firewall, what additional services/binary files that should be disabled/removed to prevent firewall penetration, and/or prevent any rootkit, malware from getting executed and/or accessing the LAN network. Managing the firewall is only through direct terminal access. NONE. You are proposing doing this wrong. You are confusing administrative pain with security. My opinion backed up with lots of experience: if you can't administer and maintain your systems, it won't be secure. I am trying to make the openbsd firewall bulletproof as much as possible, sealing all possible gaps, otherwise, IDS/IPS is useless. Just do this: Do a base install of the entire OpenBSD system (yes, comp73, x*, games73. Leave all the boxes checked. Say "no" when it asks if you want to run X, say you don't want root to be able to login via SSH (or prohibit password). Assuming multiple administrators, set up doas. when done, disable root logins by password, both in ssh and by adding or deleting a few characters in the PW hash in vipw. Install all your administrator's public keys. Disable PW logins in ssh. (yeah, I kinda said that three times. kinda). (this paragraph, you could call "hardening". That will make a C-level happy). Set up a tight set of PF rules. Probably block ssh from the outside. Don't add anything to the machine you don't absolutely need, but don't delete or "disable" stuff, either. I usually add rsync to a FW (helps with backups, though for other things, included openrsync is probably sufficient). I can't think of anything else you want to add to a basic, tight firewall...but don't remove anything, either. Now...update it whenever the urge or need hits you -- at least every six months. But it's easy to do. Do this, and your firewall won't be how people break into your systems. They will do it like they always do...bad C-level executive decisions, stupid managers, bad applications, indifferent users (in roughly that order). But it won't be your firewall that is the entry point, nor a resource for the attackers. As others said, be realistic about what the firewall does and doesn't do for your security. Your firewall isn't how bad guys are getting into your systems. Set up properly, it will slow 'em down, and perhaps slow the spread from one vulnerable system to another. Nick.
Re: SATA disk identify taking 10 seconds to give me output
On 4/20/23 05:56, Raja Sekhar wrote: Hi, I am running OpenBSD_7.1 on VMWare workstation16. It has two hard disks(wd0 & sd0) I am trying to get hard disk information using the following command. *$atactl identify* If I use the disk wd0, I am getting output immediately. If I use the disk sd0, I am getting the output after 10 seconds. I need to trigger the above command multiple times, it is causing delay in my scenario. When I go through the kernel code the delay is occuring in scsi_xs_sync() function. What's the problem and what is the fix for this issue. well, the problem is pretty clearly in VMware Workstation. I don't see a problem with real hw. First, I'd start by getting to 7.3. See if your "problem" is still showing. Second, I'd look at the virtual HW you have selected. Try a different interface card emulation. And why do you have different types of hardware on a VM anyway? Put your virtual disks on the hw that works best for you. So many questions would be answered with a dmesg... Nick. Nick.
Re: dmesg and sensors for ODROID H3
On Tue, Apr 18, 2023 at 7:28 AM stolen data wrote: > > Everything seems to work. Only caveat noticed is that the firmware is > UEFI-only with no CSM/legacy mode, and it will only boot an OpenBSD > installation from GPT which must contain an EFI system partition holding > the bootloader. great choice. my ODROID H2+ is still holding strong with the add-in card for 4 extra NICs. it is a fine home firewall. my only complaint is sometimes having rge5: watchdog timeout rge2: watchdog timeout in dmesg and occasional link state issues, but i didn't dig into whether its from the rge driver or stuff i attached. if you can, provide an iperf3 result in both forward and reverse mode. here, i only have about 1.60 Gbit/s in both directions, but that's fine for my wan link. > > > sensors and timers: > > masheen# sysctl hw.sensors kern.timecounter.choice > hw.sensors.cpu0.temp0=25.00 degC > hw.sensors.cpu0.frequency0=8.00 Hz > hw.sensors.cpu1.frequency0=8.00 Hz > hw.sensors.cpu2.frequency0=8.00 Hz > hw.sensors.cpu3.frequency0=8.00 Hz > hw.sensors.acpitz0.temp0=27.80 degC (zone temperature) > hw.sensors.softraid0.drive0=online (sd1), OK > kern.timecounter.choice=i8254(0) tsc(2000) acpihpet0(1000) acpitimer0(1000) > > > dmesg: > > OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 4115353600 (3924MB) > avail mem = 3971211264 (3787MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x78d74000 (138 entries) > bios0: vendor American Megatrends Inc. version "5.19" date 02/27/2023 > bios0: HARDKERNEL ODROID-H3 > efi0 at bios0: UEFI 2.7 > efi0: American Megatrends rev 0x50013 > acpi0 at bios0: ACPI 6.2 > acpi0: sleep states S0 S5 > acpi0: tables DSDT FACP MCFG FIDT SSDT SSDT SSDT HPET APIC PRAM SSDT SSDT > NHLT LPIT SSDT SSDT DBGP DBG2 SSDT DMAR SSDT TPM2 WSMT FPDT > acpi0: wakeup devices PEGP(S0) PEGP(S0) PEGP(S0) PEGP(S0) SIO1(S0) RP01(S0) > PXSX(S0) RP02(S0) PXSX(S0) RP03(S0) PXSX(S0) RP04(S0) PXSX(S0) RP05(S0) > PXSX(S0) RP06(S0) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimcfg0 at acpi0 > acpimcfg0: addr 0xc000, bus 0-255 > acpihpet0 at acpi0: 1920 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Celeron(R) N5105 @ 2.00GHz, 798.28 MHz, 06-9c-00 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,RDSEED,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB > 64b/line 12-way L2 cache, 4MB 64b/line 16-way L3 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 38MHz > cpu0: mwait min=64, max=64, C-substates=0.2.0.2.2.1.1.1, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Celeron(R) N5105 @ 2.00GHz, 798.28 MHz, 06-9c-00 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,RDSEED,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB > 64b/line 12-way L2 cache, 4MB 64b/line 16-way L3 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 4 (application processor) > cpu2: Intel(R) Celeron(R) N5105 @ 2.00GHz, 798.27 MHz, 06-9c-00 > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,RDSEED,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB > 64b/line 12-way L2 cache, 4MB 64b/line 16-way L3 cache > cpu2: smt 0, core 2, package 0 > cpu3 at mainbus0: apid 6 (application processor) > cpu3: Intel(R) Celeron(R) N5105 @ 2.00GHz, 798.28 MHz, 06-9c-00 > cpu3: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX
Re: File system is full after using dd
On 4/15/23 10:14, Lorenzo Torres wrote: Hello, I've run the dd command to wipe the data of an SD card:dd if=/dev/zero of=/dev/rsdb1c bs=1MAfter quite some time it crashed ^^ bzzzt. game over. saying that the / filesystem is full and even after a reboot the same happens. Now I can't even run xorg because the fs is full. Any idea on why this happened? I have a 1TB NVME SSD as root disk and I have only a root partition as well as the efi partition on the root disk ^ game took a while to be over, didn't it? As people have already said, you created a file, you didn't zero your SD card. But...what wasn't said (yet? as I'm typing this? Probably twenty people will respond about this two seconds after I hit "SEND") was pointing out this is one of many reasons NOT to create a huge root partition and nothing else. Granted, OpenBSD has lots of OpenBSD-only reasons, too, but one big root partition is Bad Unix Administration. If you had an appropriate sized root partition, perhaps 1G (default), you would have quickly discovered something was wrong, probably in a few seconds. Instead, it took a while, and you assumed you had accomplished your mission of zeroing an SD card. So not only did you fill root, your sensitive data is still on the card. Many system administrators can tell you stories about thinking they were backing up every night to tape, only to find out that they were dumping a big backup *file* in their /dev directory rather than putting their data to tape...and find this when they realize their tape has never been written when they need a restore. $DAYJOB involves helping maintain a bunch of systems that regularly fill their root partitions. Not always by bad initial design, but often because there was "plenty of space" on the root partition, so someone started dropping data or applications there. And then, one day...boom. Partition your system. And / should be as small as you can sanely get away with. That isn't to say it should be super-tiny. But if you have 1GB to spare, it is probably too big. I did learn to regret a 200MB root because OpenBSD grew a lot over around ten years that I used that install. Nick.
Re: Help for another wiped out disklabel
On 4/13/23 16:08, Greg Thomas wrote: Thank you! I gave it one more shot before attempting the script and I'm back in. I figured I'd try 0 for the beginning of the partition. grits# disklabel sd1 # /dev/rsd1c: type: SCSI disk: SCSI disk label: Ext SSD duid: 2eeb6058175bf1f7 flags: bytes/sector: 512 sectors/track: 20 tracks/cylinder: 22 sectors/cylinder: 440 cylinders: 2131143 total sectors: 937703088 boundstart: 0 boundend: 937703088 16 partitions: #size offset fstype [fsize bsize cpg] a:9377030400 4.2BSD 4096 32768 1 c:9377030880 unused OUCH. Don't do this! I'm not sure why your disklabel got overwritten *in your case*, but there is stuff that's supposed to be at sector zero, and a disklabel is NOT IT. Something someday will clobber it. And it did. Please, back your data up, put either a UEFI or MBR partition table on it, and then use the rest of the disk for your backup. With modern disk sizes, the amount of space you "save" isn't worth the first time this happens to you. Nick. (who went back to look at your dmesg to make sure it wasn't a sparc64 :)
Re: Unable to receive dhcplease from ISP
On 4/1/23 19:57, Bill A wrote: Hi all, I ran into this issue today when I decided to do some maintenance on my home network. My laptop runs OpenBSD 7.2. I attempted to get a dhcplease from Spectrum Internet with a direct connection to my em0 ethernet interface. I got no response. I'm having the same problem with another computer that I wanted to use as my firewall (also running OpenBSD, same ver). There is no dhcpleased.conf on my laptop, as I didn't see how any defaults needed to change. I also haven't had any recent issues getting a lease on it in other situations (yet). Cabling is good. A different (non-OpenBSD) firewall normally sits on this interface, and after I put it back, everything was working as normal. I'm happy to provide any additional information as requested. I tried this several times, cleared and shutdown the iwm0 interface, cleared the em0 interface, etc, this is output from the last time. I can replicate that with my ISP if I follow your steps. With my service, if I change the MAC address of the machine attached to my cable modem, I have to power cycle the cable modem to get a new DHCP lease. Not saying that is your problem, but you never indicated you power cycled the modem...which I have found critical for the last 20+ years. Nick.
Re: Home folder default permission
On 3/23/23 14:36, Matthew Weigel wrote: On 2023-03-23 11:53 am, ch...@qatland.com wrote: I did not look at the code at all for this. Only using existing programs. If this should not be working then a patch will be needed somewhere. I didn't give it a try, but I took your report at face value and looked closer at the code. When it copies /etc/skel over, it does so with a command like "pax -rw -pe /etc/skel /home/$USER"(https://github.com/openbsd/src/blob/869ed59d760a94e6086f364d91f2b56074421cc9/usr.sbin/user/user.c#L316) which sets all permissions, starting with /etc/skel. That's why it behaved as you observed, the way the original poster wanted. However I will state that having the ability to set the default permissions somewhere would be useful, and a requirement in some environments. I agree, not that I have any say. It's also worth pointing out that you can have multiple skeleton directories and specify which one you want to use when you run the program; there's no need to change the default skeleton directory (or, it's possible to keep a traditional readable-by- all skeleton directory around even if you make it not the default). Matthew I kinda like the /etc/skel directory providing the default. That's the model for a new user -- it has a basic .profile, a .ssh directory and empty .ssh/authorized_keys file, all with permissions properly set. Yeah, I know some compliance people want to see complete privacy on home directories, but that kinda defeats a point of a multi-user system, that people might just want to collaborate with each other. Nick.
dhcpd user-class and vendor-class
hi, dhcpd.conf(5) has two undocumented options i experimented with recently for doing pxe boot on my lan. for example, one might write the following: # iPXE client user-class "iPXE" { filename "menu.ipxe"; } to configure a iPXE script as the boot file for ipxe clients, or # UEFI PXE Boot vendor-class "PXEClient:Arch:7:UNDI:003001" { filename "BOOTX64.EFI"; # avoid proxy dhcp option vendor-encapsulated-options 06:01:0a; } to send the EFI bootloader to a UEFI client. should these be documented? i can't find them in the manuals.
Re: Tor daemon is unable to connect to the Tor network
works ok here. i installed tor-0.4.7.13 on my 7.2 home gateway, no special setup. i have not done any fiddling with login.conf. maybe you can set "Log debug syslog" and see what comes out? fugu$ uname -a OpenBSD fugu.offblast.org 7.2 GENERIC.MP#6 amd64 fugu$ grep '^[A-Z]' /etc/tor/torrc Log notice syslog RunAsDaemon 1 DataDirectory /var/tor User _tor fugu$ curl --silent --socks5-hostname localhost:9050 https://check.torproject.org | grep Congratulations Congratulations. This browser is configured to use Tor. Congratulations. This browser is configured to use Tor. fugu$ grep -i tor /var/log/daemon Mar 14 00:05:12 fugu Tor[84209]: Tor 0.4.7.13 running on OpenBSD with Libevent 2.1.12-stable, OpenSSL LibreSSL 3.6.0, Zlib 1.2.12, Liblzma N/A, Libzstd N/A and Unknown N/A as libc. Mar 14 00:05:12 fugu Tor[84209]: Tor can't help you if you use it wrong! Learn how to be safe at https://support.torproject.org/faq/staying-anonymous/ Mar 14 00:05:12 fugu Tor[84209]: Read configuration file "/etc/tor/torrc". Mar 14 00:05:12 fugu Tor[84209]: Opening Socks listener on 127.0.0.1:9050 Mar 14 00:05:12 fugu Tor[84209]: Opened Socks listener connection (ready) on 127.0.0.1:9050 Mar 14 00:05:12 fugu Tor[84209]: Parsing GEOIP IPv4 file /usr/local/share/tor/geoip. Mar 14 00:05:13 fugu Tor[84209]: Parsing GEOIP IPv6 file /usr/local/share/tor/geoip6. Mar 14 00:05:13 fugu Tor[84209]: We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently lacks accelerated support for the NIST P-224 and P-256 groups. Building openssl with such support (using the enable-ec_nistp_64_gcc_128 option when configuring it) would make ECDH much faster. Mar 14 00:05:13 fugu Tor[84209]: Bootstrapped 0% (starting): Starting Mar 14 00:05:13 fugu Tor[84209]: Starting with guard context "default" Mar 14 00:05:14 fugu Tor[84209]: Bootstrapped 5% (conn): Connecting to a relay Mar 14 00:05:14 fugu Tor[84209]: Bootstrapped 10% (conn_done): Connected to a relay Mar 14 00:05:15 fugu Tor[84209]: Bootstrapped 14% (handshake): Handshaking with a relay Mar 14 00:05:15 fugu Tor[84209]: Bootstrapped 15% (handshake_done): Handshake with a relay done Mar 14 00:05:15 fugu Tor[84209]: Bootstrapped 20% (onehop_create): Establishing an encrypted directory connection Mar 14 00:05:15 fugu Tor[84209]: Bootstrapped 25% (requesting_status): Asking for networkstatus consensus Mar 14 00:05:15 fugu Tor[84209]: Bootstrapped 30% (loading_status): Loading networkstatus consensus Mar 14 00:05:19 fugu Tor[84209]: I learned some more directory information, but not enough to build a circuit: We have no usable consensus. Mar 14 00:05:19 fugu Tor[84209]: Bootstrapped 40% (loading_keys): Loading authority key certs Mar 14 00:05:20 fugu Tor[84209]: The current consensus has no exit nodes. Tor can only build internal paths, such as paths to onion services. Mar 14 00:05:20 fugu Tor[84209]: Bootstrapped 45% (requesting_descriptors): Asking for relay descriptors Mar 14 00:05:20 fugu Tor[84209]: I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 0/6489, and can only build 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, and 0% of end bw (no exits in consensus, using mid) = 0% of path bw.) Mar 14 00:05:21 fugu Tor[84209]: Bootstrapped 50% (loading_descriptors): Loading relay descriptors Mar 14 00:05:26 fugu Tor[84209]: The current consensus contains exit nodes. Tor can build exit and internal paths. Mar 14 00:05:34 fugu Tor[84209]: Bootstrapped 56% (loading_descriptors): Loading relay descriptors Mar 14 00:05:36 fugu Tor[84209]: Bootstrapped 63% (loading_descriptors): Loading relay descriptors Mar 14 00:05:38 fugu Tor[84209]: Bootstrapped 68% (loading_descriptors): Loading relay descriptors Mar 14 00:05:38 fugu Tor[84209]: Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits Mar 14 00:05:38 fugu Tor[84209]: Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits Mar 14 00:05:38 fugu Tor[84209]: Bootstrapped 95% (circuit_create): Establishing a Tor circuit Mar 14 00:05:39 fugu Tor[84209]: Bootstrapped 100% (done): Done On Mon, Mar 13, 2023 at 4:35 AM Matt Wehowsky wrote: > > On 2023-03-12 09:53 AM, Stuart Henderson wrote: > > I don't think the problem you're seeing is related to login.conf but a > > few comments on that, > > > > ... > > > > I suggest removing login.conf.db (it is not created by default) and not > > using cap_mkdb, to avoid any problems with the db file getting out of > > sync after other changes. You probably want to override openfiles-cur as > > well, not just -max. > > Done. Thanks for the insight, Stuart. > > > Note any daemon-specific config here will only be used automatically if > > you're running it via rcctl or the rc.d script. (If you run it "by hand" > > you can set the login class with su -c or sudo -c). > > I’m aware of that, but thank you for clarification nonethe
disk integrity checking
(this is a request for a "that's stupid", not a suggestion of something people should do at this point) An idea that's been floating around in my head, inspired by the ZFS "scrubbing" idea: rather than build that "check your data" process into the file system, just do something periodically like this: # dd if=/dev/rsd0c of=/dev/null bs=1m and repeat against all physical drives. The logic being, all hard drives have some kind of error detection logic in them, at least a checksum of some kind on all data blocks. See if you can read every block on the disk. No errors, your data might be intact. Errors, it probably isn't (or won't be in the future). Crypto-grade integrity, probably not... but probably quite sufficient for spotting most bad spots on the disk. So...I tried it against disks with mounted file systems and softraid partitions on them. It...seems to work. I did have one laptop with a softraid encrypted drive that gave a nice, clear "Input/output error", but I can't reproduce it (maybe it got locked out? Seems odd on a read, but ... Is this sane? is it safe to attempt to read all the blocks on an entire 'c' partition of a disk that's doing "other things" at the same time, including a layers of softraid? Nick.
Re: Performance optimizing OpenBSD 7.2
On 2/15/23 04:54, Claudio Jeker wrote: On Wed, Feb 15, 2023 at 10:28:57AM +0100, Gábor LENCSE wrote: Hi Lars, > I downscaled from 8 to 4 vCPUs and from 8 to 4 gig RAM - and the two obsd > now seems to hold the packages decently. As for performance optimization, I think the direction is good, and perhaps you could go even further if you have a load balancing device that can distribute the traffic among the multiple VMs. Not sure why reducing the memory should help. Also reducing the number of virtual CPUs has probably little effect as well. The main point in reducing the number of cores and disabling threads is to give modern CPUs more thermal/power headroom to run the fewer CPUs at a higher clockspeed. I doubt you get the same effect on vCPUs. Quite some time ago, the story with VMware (and I'm guessing it is true of all x86 virtualization) is that to have "time" on the processor, ALL the required CPUs had to be available. A single CPU VM could almost always find time to run...an 8 CPU VM had to wait until there were all eight cores available to run, so if your task didn't use lots of cores, you often lost by requesting more than you needed. Not sure how true it was "back then" or now, but if better performance is seen with fewer cores, this might be why. Nick.
Re: Calculating VMs/CPU
On 2/4/23 17:31, latin...@vcn.bc.ca wrote: Hello misc i am building an only VMD server: How could calculate the relation: CPU, Ram, Storage, VMs please? Thanks. PD: I have a Lenovo ThinkPad Edge 4 i3 cores, 500GB disk. 8GB Ram. This is kinda virtualization 101 stuff, not really specific to OpenBSD. RAM: assume more than 1:1. The VM will require certain overhead, as will the base OS. So, if you want 2G VMs, you won't be getting four of them on your 8G machine. You might get three. (some VM systems support "thin provisioning" of RAM. This is really a great way to hurt yourself unless you really know what you -- and all your guest OSs -- are doing. And you are still really likely to hurt yourself). Disk: Assume 1:1. Even if your VM system supports thin provisioning (OpenBSD doesn't appear to), don't. Assume you will use 100% of the disk you provision for a VM. Because you will. Thin provisioning VMs is generally a bad idea. CPU: Test, don't speculate. This is where you can get some benefit from resource sharing. You can also end up fooling yourself into thinking that 10 VMs that are usually 90% idle can share one CPU, because that 10% busy time? They are all working on the same task. In your case of a 4xi3 8g/500g, I suspect your machine will run out of RAM, CPU and then disk, in that order, though if you work at it, you can run out in any order you wish. :) But it is all how you define your VMs and what you do with it. Your host i3 could be maxed out with a web browser, so the VMs you run are going to have to be minimal and your expectations modest. Nick.
Re: Max number of NICs
On 1/23/23 17:54, Lars Bonnesen wrote: How many physical NICs can you add to an OpenBSD host (vmx) I am asking because I am running an OpenBSD on a VMware host but apparently OpenBSD can only see 8 of them. Can I raise the limit somehow? Regards, Lars. may years ago (back in the 3.x days, iirc), someone asked me to jam a machine full of NICs and see what happened. Four 4-port dc(4) NICs (16 ports) plus one 3com 3c905 on the main board later, I saw no issues, but then I lacked any use for a 17 port machine. If I recall properly, the person who asked me to do it was expecting some kind of issue, but when I told him they were dc(4)s, he was disappointed and said, "Well, of course those will work". I had a machine for a while with something like ten or eleven em(4)s in it, I had fired it up, don't recall seeing any problems with it identifying all the ports (in fact, iirc, it found a port on the MoBo that was not extended to the outside). Again, no issue, but after staring at the power hungry box for many years and never doing anything with it, it finally got recycled. Again, that was many releases ago...so not sure how it applies today. Current FW box is a old citrix appliance with a six port NIC and two onboard ports, for eight em(4)s. Nick.
Re: Relinking to create unique kernel... failed!
Thanks for the tips. I opened up the case and checked the cables, nothing obviously damaged or poorly connected, but certainly dusty in there. I reseated the cables and rebooted into single-user mode. fsck -f on each partition didn't reveal any issues, but after rebooting again the ahci0 errors went away. However, the reorder_kernel error remained. BUT your pointers got me to think "maybe the files in /usr/share/relink/kernel/GENERIC.MP/ are corrupt and overwriting them might fix things." I didn't know the best way to go about doing that, so I forced an OS "update" via bsd.rd and what do you know, things seem to be running smoothly again, relinking/reodering and everything. I may have a failing harddrive, but for now this immediate problem seems to be resolved. Thanks! -Nick On Fri, Jan 13, 2023 at 2:00 PM Crystal Kolipe wrote: > > On Fri, Jan 13, 2023 at 11:45:31AM -0800, Philip Guenther wrote: > > On Fri, Jan 13, 2023 at 10:59 AM Nick Templeton > > wrote: > > > > > Ever since upgrading my machine to 7.2 I've been unable to relink my > > > kernel, anybody have any idea why? > > > > ... > > > > > Running "/usr/libexec//reorder_kernel" manually resulted in a kernel > > > panic: > > > > > > mode = 0100600, inum = 7, fs = /tmp > > > panic: ffs_valloc: dup alloc > > > Stopped at db_enter+0x10: popq %rbp > > > > > > > You have at least one filesystem with latent corruption. You should reboot > > in single-user mode and run fsck with the -f option on each partition. > > But it would be wise to check the hardware first, because he also mentions: > > > Rebooting the machine results in this at the login prompt: > > > > login: ahci0: attempting to idle device > > ahci0: couldn't recover NCQ error, failing all outstanding commands. > > ahci0: attempting to idle device > > ahci0: couldn't recover NCQ error, failing all outstanding commands. > > This could be caused by a faulty sata cable, dirty connector, or something > more serious. > > Probably not a great idea to get half way through an fsck and have the drive > start failing commands.
Relinking to create unique kernel... failed!
Ever since upgrading my machine to 7.2 I've been unable to relink my kernel, anybody have any idea why? I was reminded of this when I attempted to apply the latest errata today: $ doas syspatch Get/Verify syspatch72-009_xserver... 100% |*| 4384 KB00:01 Installing patch 009_xserver Get/Verify syspatch72-010_vmd.tgz 100% || 2338 00:00 Installing patch 010_vmd Get/Verify syspatch72-011_gpuinv.tgz 100% |*| 197 KB00:00 Installing patch 011_gpuinv Get/Verify syspatch72-012_acme.tgz 100% |***| 40197 00:00 Installing patch 012_acme Get/Verify syspatch72-013_tcp.tgz 100% || 508 KB00:00 Installing patch 013_tcp Relinking to create unique kernel... failed! !!! "/usr/libexec/reorder_kernel" must be run manually to install the new kernel Running "/usr/libexec//reorder_kernel" manually resulted in a kernel panic: mode = 0100600, inum = 7, fs = /tmp panic: ffs_valloc: dup alloc Stopped at db_enter+0x10: popq %rbp TID PID UID PRFLAGS PFLAGS CPU COMMAND * 47548 27451 0 0x13 0 4K sh db_enter() at db_enter+0x10 panic (81f1612f) at panic+0xbf ffs_inode_alloc(fd820bedf878,8180, fd81fe987008, 800022e4f528) at ffs_inode_alloc+0x42e ufs_makeinode (8180, fd8200b73130, 800022e4f820,800022e4f850) at ufs_makeinode+0x79 ufs_create(800022e4f5d8) at ufs_create+0x3c VOP CREATE (fd8200b73130,800022e4f820, 800022e4f850, 800022e4f630) at VOP_CREATE+0x3f vn_open(800022e4f7f0, a03,180) at vn_open+0x162 doopenat (800022ba8a88, ff9c, 5d2b50be3b0, a02, 180, 800022e4f9d0) at doo penat+0x1cd syscall(800022e4fa40) at syscall+0x35f Xsyscall at Xsyscall+0x128 end of kernel end trace frame: 0x7f7c9820, count: 5 https://www.openbsd.org/ddb.html describes the minimum info required in bug reports. Insufficient info makes it difficult to find and fix bugs. ddb{4}> show panic cpu4: ffs_valloc: dup alloc ddb{4}) trace db_enter() at db_enter+0x10 panic (81f1612f) at panic+0xbf| ffs_inode_alloc(fd820bedf878,8180, fd81fe987008, 800022e4f528) at ffs_inode_alloc+0x42e ufs_makeinode (8180, fd8200b73130,800022e4f820,800022e4f850) at ufs_m ake inode+0x79 ufs_create(800022e4f5d8) at ufs_create+0x3c VOP_CREATE(fd8200b73130,800022e4f820,800022e4f850,800022e4f630) at VOP_CREATE+0x3f vn_open(800022e4f7f0, a03,180) at vn_open+0x162 doopenat (800022ba8a88, ff9c, 5d2b50be3b0, a02, 180, 800022e4f9d0) at doo penat+0x1cd syscall(800022e4fa40) at syscall+0x35f Xsyscall at Xsyscall+0x128 end of kernel end trace frame: 0x7f7c9820, count: -10 ddb{4}> mach ddbcpu 0 Stopped at x86_ipi_db+0x12: leave x86_ipi_db(822c7ff0) at x86_ipi_db+0x12 x86_ipi_handler() at x86_ipi_handler+0x80 Xresume_lapic_ipi() at Xresume_lapic_ipi +0x23 acpicpu_idle() at acpicpu_idle+0x203 sched_idle(822c7ff0) at sched_idle+0x280 end trace frame: 0x0, count: 10 ddb {0}> mach ddbcpu 1 Stopped at x86_ipi_db+0x12: leave x86_ipi_db(800022509ff0) at x86_ipi_db+0x12 x86_ipi_handler() at x86_ipi_handler+0x80 Xresume_lapic_ipi() at Xresume_lapic_ipi+0x23 acpicpu_idle() at acpicpu_idle+0x203 sched_idle(800022509ff0) at sched_idle+0x280 end trace frame: 0x0, count: 10 ddb{1}> mach ddbcpu 2 Stopped at x86_ipi_db+0x12: leave x86_ipi_db(800022512ff0) at x86_ipi_db+0x12 x86_ipi_handler() at x86_ipi_handler+0x80 Xresume_lapic_ipi() at Xresume_lapic_ipi+0x23 acpicpu_idle() at acpicpu_id le+0x203 sched_idle(800022512ff0) at sched_idle+0x280 end trace frame: 0x0, count: 10 ddb{2}> mach ddbcpu 3 Stopped at x86_ipi_db+0x12: leave x86_ipi_db(80002251bff0) at x86_ipi_db+0x12 x86_ipi_handler() at x86_ipi_handler+0x80 Xresume_lapic_ipi() at Xresume_lapic_ipi+0x23 acpicpu_idle() at acpicpu_idle+0x203 sched_idle(80002251bff0) at sched_idle+0x280 end trace frame: 0x0, count: 10 ddb{3}> mach ddbcpu 5 Stopped at x86_ipi_db+0x12: leave x86_ipi_db(80002252dff0) at x86_ipi_db+0x12 x86_ipi_handler() at x86_ipi_handler+0x80 Xresume_lapic_ipi() at Xresume_lapic_ipi+0x23 acpicpu_idle() at acpicpu_idle+0x203 sched_idle(80002252dff0) at sched_idle+0x280 end trace frame: 0x0, count: 10 ddb{5}) mach ddbcpu 6 Stopped at x86_ipi_db+0x12: leave x86_ipi_db(800022536ff0) at x86_ipi_db+0x12 x86_ipi_handler() at x86_ipi_handler +0x80 Xresume_lapic_ipi() at Xresume_lapic_ipi+0x23 acpicpu_idle() at acpicpu_id le+0x203 sched_idle(800022536ff0) at sched_idle+0x280 end trace frame: 0x0, count: 10 ddb {6}) mach ddbcpu 7 Stopped at x86_ipi_db+0x12: leave x86_ipi_db(80002253fff0) at x86_ipi_db+0x12 x86_ipi_handler() at x86_ipi_handler +0x80 Xresume_lapic_ipi() at Xresume_lapic_ipi+0x23 acpicpu_idle() at acpicpu_idle+0x203 sched_idle (80002253fff0) at sched_idle+0x280 end trace frame: 0x0, count: 10 ddb{7}> (ps output from the kernel debugger is not copy/pasting well, but I can provide it if it is truly necessary as mentioned on https://www.openbsd
Re: Query on openrsync(1)
On 1/10/23 03:49, Abhishek Chakravarti wrote: OpenBSD newbie here. While trying to backup my OpenBSD configs to my Arch Linux box, I noted a discrepancy between the openrsync(1) manpage examples and what I encountered. The steps to reproduce are as follows: ``` $ uname -a OpenBSD oberon.taranjali.org 7.2 GENERIC.MP#758 amd64 $ touch foo bar $ rsync -av foo bar abhishek@192.168.1.3:/home/abhishek ksh: rsync: not found $ openrsync -av foo bar abhishek@192.168.1.3:/home/abhishek Enter passphrase for key '/home/abhishek/.ssh/id_ed25519': Transfer starting: 2 files bar foo Transfer complete: 56 B sent, 187 B read, 0 B file size ``` The EXAMPLES section for the openrsync(1) specifically mention rsync and not openrsync. I did find an earlier thread related to this issue: https://marc.info/?l=openbsd-misc&m=162123821229046&w=2 The suggestion from that thread seems to be to use the rsync package instead of openrsync. Is this still the case? And if not, shouldn't the openrsync(1) manpage examples invoke openrsync instead of rsync? Thank you for your time and consideration. I'm a big fan of rsync, and was really excited by openrsync being built into OpenBSD, but so far, it hasn't done the jobs I need it to do :-/ A few things that cause me trouble are the lack of a -H (preserve hard links -- I bet that's ugly to code), -W (disable the delta-transfer "feature". Yes, I know it was The Reason for rsync, but in my experience, it takes longer to do the delta transfers than to just send the whole bloomin' file for the vast majority of my usage. And I don't mean 5% longer -- I'm talking 400% longer sometimes. And maybe worse...unpredictable), and I'm a big fan and user of --link-dest. But ... if it does what you want, absolutely, give it a spin. If it doesn't...either install the package or grab the source code to openrsync, add what you need and submit it. :) I think there was some talk about ultimately naming it rsync, but unless it is 100% feature compatible (and I'm not sure I'd consider that a good thing), that will cause confusion in my world. Nick.
Re: CARP and DHCP
On 1/6/23 02:31, Christer Solskogen wrote: On Mon, Jan 2, 2023 at 5:14 PM Nick Holland wrote: hiya. Goal: home (i.e., DHCP external network config) redundant firewalls with CARP and PFSYNC. Totally doable. I've been running it like that for the last 7 years at home. My ISP doesn't like it when the two firewalls have different mac-addresses, same here. :) so I have to do some spoofing on the slave machine. ifstated is your very good friend here. My /etc/hostname.$extif is empty. CARP is only in use for the internal interface. This if my ifstated.conf on mster: carp_up = "carp0.link.up" carp_down = "!carp0.link.up" carp_init = "carp0.link.unknown" init-state auto state auto { if ($carp_up) set-state fw_master if !($carp_up) set-state fw_slave } state fw_master { init { run "route -qn flush" run "ifconfig em2 inet autoconf" run "pfctl -f /etc/pf.conf" } if ($carp_down) set-state fw_slave if ($carp_init) run "sleep 2" } state fw_slave { init { run "ifconfig em2 -inet" run "route -qn flush" run "route add default 192.168.0.3" } if ($carp_up) set-state fw_master } Does this actually maintain state? I'm thinking pfsync might not work properly when the external interface "changes" like that. It wouldn't actually matter much in *my case*, but I'm wondering about the more general case. Thanks! Nick.
Re: (video) obsd install initial boot process slowed down
On 1/5/23 02:22, Sylvain Saboua wrote: https://youtu.be/lzGT1TAGG1Y OpenBSD 7.2 (GENERIC.MP) #758: Tue Sep 27 11:57:54 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8449818624 (8058MB) avail mem = 8176320512 (7797MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xda571018 (40 entries) bios0: vendor American Megatrends Inc. version "4.6.5" date 11/11/2013 Not exactly a new machine (i.e., my vintage. :) ) ... cpu0: Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz, 2693.94 MHz, 06-2a-07 ...ten year old processor. ... ahci0 at pci0 dev 31 function 2 "Intel 7 Series AHCI" rev 0x04: msi, AHCI 1.3 ahci0: port 0: 6.0Gb/s ... sd0 at scsibus1 targ 0 lun 0: naa.5002538f40c128a7 sd0: 953869MB, 512 bytes/sector, 1953525168 sectors, thin good. don't think that was factory. :) ...[snip]... That didn't seem *that* slow to me. For giggles, I compared your startup time vs. my netbook with full disk encryption. It turns out, you are right, you actually were slower for the kernel load (once the kernel loaded, your system kicked my netbook's butt) What you are seeing is the initial kernel load taking place. The OS is not running then -- the firmware has loaded /boot and it is pulling up the kernel a little bit at a time through the system firmware and with only one core jumping between the system firmware, the boot code, decrypting data, etc., and it has 22MB to load (that used to be SO HUGE!). You are 100% dependent upon the system firmware at this point, OpenBSD is not running yet (OpenBSD provided code, yes, the kernel, no). I don't think this counts as an OpenBSD bug at all, it's just the way your machine works until a modern OS is loaded and takes over managing the hardware. /boot has only a few ways to get data off the disk, it basically ends up working through somewhat updated (for large disk) tools that existed on the 1982 IBM XT. Looks like you are using UEFI boot -- you might want to try it with BIOS/Legacy. That's an old enough machine that UEFI might not have been the optimal way to boot that machine. You could see if there's a newer BIOS for your computer. Nick.