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=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?
IRST 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>>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>>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=170301839017559=2 - https://marc.info/?l=openbsd-misc=170345453930038=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 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 2023 CLEAR? yes ... ** Phase 5 - Check Cyl groups FRE
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) cpu3: Intel(R) Xeon(R) Bronz
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=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,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOW
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,MD_CLEAR,IBRS,IBPB,STIBP
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
r 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: >
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
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
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=162123821229046=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.
Re: 回复: Softraid crypto metadata backup
On 1/2/23 23:54, Nathan Carruth wrote: Thank you for the response. I am with you 100% on backups. My real question was, How does one backup crypto volume metadata? Given that it can be backed up, clearly it should be, but there is no information in any of the cited documentation as to where the metadata is or how to back it up. There appears to be no intended way to backup this crypto metadata you are worried about. Not that I'd really want extra copies of anything related to a crypto disk floating around anywhere if I could help it. Not sure what you are hoping to get "backed up", but it sure sounds like something useful to the wrong people. Encrypted disks are supposed to "fail closed". If that scares you, your backup sucks or you shouldn't be running encrypted drives. (well...you COULD # dd bs=1m if=/dev/rsd0c of=/mnt/someotherdevice/disk.img and that would get your meta data, your data, your microdata your macrodata and possibly your first born). So let me offer you this, instead. A backup of potentially someday useful disk data: for DISK in $(sysctl -n hw.disknames|tr ',' ' '); do D=$(echo $DISK| cut -f1 -d:) print print "== $DISK ===" fdisk $D disklabel $D done (note: this script is surely missing edge and special cases. It has been run on three different machines. I do not wish to talk about how much time I've spent making it look prettier. I guarantee it is worth about what you paid for it and nothing more). Run that periodically, redirect the output to a file, get that file to another place, and you have full info about your disk partitions, both fdisk and disklabel, in case you overwrite them someday. Far more likely than a crypto failure that can be recovered by some crypto metadata backup. And the cool thing since the prefix "meta" basically boils down to "sounds cool, no idea what it means", we can call this metadata. :) (Yes, the disklabel info is stored by security(8), ... kinda. Spot checking two of my systems right now, I see both are missing drives...and I'm not sure why, I suspect there's a good reason. But fdisk output is NOT there, and I'd rather prefer it be there too on fdisk platforms). Nick. Thanks! Nathan Does a softraid(4) crypto volume require metadata backup? (I am running amd64 OpenBSD 6.9 if it is relevant, will probably upgrade in the next few months.) I understand FreeBSD GELI (e.g.) requires such a backup to protect against crypto-related metadata corruption rendering the encrypted volume inaccessible. Neither the OpenBSD disk FAQ nor the man pages for softraid(4) or bioctl(8) have anything to say about the matter. Web searches also turn up no relevant information. Storage requires backup. Encrypted storage is (by design) more fragile than unencrypted storage. Sounds like you are trying to protect against ONE form of storage failure and avoid the solution you really need to have: a good backup system, to deal with *all* forms of storage failure. I'd suggest a good backup system...to deal with ALL forms of data loss. Yes, encrypted storage implies a certain care has to be taken with the backups as well, you need to pick a solution that is appropriate for your needs -- or accept that yeah, stuff will go bye-bye someday. I don't see a benefit to trying to protect against some single failure mode when all the other failure modes still exist. If you have good backups, you are good. If you don't, dealing with a 1% problem isn't going to change much. Nick.
Re: obsd install initial boot process slowed down
On 1/4/23 01:13, Sylvain Saboua wrote: Hi, my openbsed (encrypted) install is functionning really well, apart from one thing, that would signal a bug or smth: The initial boot process, right after I type the security key in, which displays cyphers aligning in between rotating semicolumns (I hope this is clear), is slow, on this install. Nope. Totally not clear. What platform, what hardware, dmesg. Also...no idea what you are talking about. First boot after install? every boot? during install? EXACTLY What are you seeing on the screen when it is "slow"? And what does "slow" mean? I've got encrypted partitions running on 1GHz class netbooks, which I'll admit is painful, but it's not the crypto that is the core problem. So you have to show what is different in your configuration than mine. Nick.
Re: Softraid crypto metadata backup
On 1/2/23 22:22, Nathan Carruth wrote: Does a softraid(4) crypto volume require metadata backup? (I am running amd64 OpenBSD 6.9 if it is relevant, will probably upgrade in the next few months.) I understand FreeBSD GELI (e.g.) requires such a backup to protect against crypto-related metadata corruption rendering the encrypted volume inaccessible. Neither the OpenBSD disk FAQ nor the man pages for softraid(4) or bioctl(8) have anything to say about the matter. Web searches also turn up no relevant information. Storage requires backup. Encrypted storage is (by design) more fragile than unencrypted storage. Sounds like you are trying to protect against ONE form of storage failure and avoid the solution you really need to have: a good backup system, to deal with *all* forms of storage failure. I'd suggest a good backup system...to deal with ALL forms of data loss. Yes, encrypted storage implies a certain care has to be taken with the backups as well, you need to pick a solution that is appropriate for your needs -- or accept that yeah, stuff will go bye-bye someday. I don't see a benefit to trying to protect against some single failure mode when all the other failure modes still exist. If you have good backups, you are good. If you don't, dealing with a 1% problem isn't going to change much. Nick.
CARP and DHCP
hiya. Goal: home (i.e., DHCP external network config) redundant firewalls with CARP and PFSYNC. Long ago, I think the word was "CARP and DHCP network configs don't work well together". A bit of searching man pages isn't showing me anything. A bit of googling is showing some old solutions that were fairly complicated. A lot has changed, lots of nifty new tools. Is there anything that would make a DHCP-configured redundant FW relatively straight-forward? I can think of a lot of reasons why this would NOT be an easy thing to accomplish, but maybe I've missed something. (Goal is to re-acquaint myself with CARP. I can accomplish that goal with a "buffer" machine between the CARP/PFSYNC FW and the outside Internet, but if I can skip the extra machine and get the benefits of redundancy, I'd like to do so). Nick.
Re: sysupgrade fails with "FAILED" when "verifying sets"?
On 12/12/22 07:22, Why 42? The lists account. wrote: Hi All, Today sysupgrade failed for me, but I'm not sure why? Here's the output: [ ... ] There is a problem with the distribution network currently. Hopefully will be resolved soon. Doing a quick check, looks like only amd64 is broke..but of course, that's what you probably want. (good time to upgrade your other platforms!) Nick.
Re: PC Engines APU alternative for OpenBSD - 2022h2
hardkernel makes the odroid-h3/h3+. i haven't used this new generation, but my home firewall is an odroid-h2+ (the previous generation) and i use it with their 4-port pci nic addon card for a total of 6 rge(4) interfaces. they work good so far in veb(4). there's uart on the pin header but i've never tried it. dmesg for my odroid-h2+: 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 = 8367374336 (7979MB) avail mem = 8096378880 (7721MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x79801000 (60 entries) bios0: vendor American Megatrends Inc. version "1.22" date 11/13/2020 bios0: HARDKERNEL ODROID-H2 acpi0 at bios0: ACPI 6.2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP FPDT FIDT MCFG SSDT DBG2 DBGP HPET LPIT APIC NPKT SSDT SSDT SSDT SSDT SSDT SSDT SSDT DMAR WDAT WSMT acpi0: wakeup devices HDAS(S3) XHC_(S4) XDCI(S4) RP01(S4) RP02(S4) RP03(S4) RP04(S4) RP05(S4) RP06(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, 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) J4115 CPU @ 1.80GHz, 1795.04 MHz, 06-7a-01 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,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 4MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 19MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.2.4.2.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Celeron(R) J4115 CPU @ 1.80GHz, 1795.04 MHz, 06-7a-01 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,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu1: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 4MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Celeron(R) J4115 CPU @ 1.80GHz, 1795.04 MHz, 06-7a-01 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,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu2: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 4MB 64b/line 16-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Celeron(R) J4115 CPU @ 1.80GHz, 1795.04 MHz, 06-7a-01 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu3: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 4MB 64b/line 16-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 120 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 5 (RP01) acpiprt2 at acpi0: bus 6 (RP02) acpiprt3 at acpi0: bus 1 (RP03) acpiprt4 at acpi0: bus 2 (RP04) acpiprt5 at acpi0: bus 3 (RP05) acpiprt6 at acpi0: bus 4 (RP06) acpiec0 at acpi0: not present acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo com1 at acpi0 UAR2 addr 0x2f8/0x8 irq 3: ns16550a, 16 byte fifo acpicmos0 at acpi0 acpibtn0 at acpi0: PWRB glkgpio0 at acpi0 GPO1 uid 1 addr 0xd0c4/0xcef irq 14, 80 pins glkgpio1 at acpi0 GPO0 uid 2 addr 0xd0c5/0xaff irq 14, 80 pins glkgpio2 at acpi0 GPO2 uid 3 addr 0xd0c9/0x7bf irq 15, 20 pins glkgpio3 at acpi0 GPO3 uid 4 addr 0xd0c8/0x82f
Re: Configure OpenBSD for remote server rarely used
On 11/27/22 12:10, James Johnson wrote: Thanks for your response. I am not intending to switch the machine. In terms of resources, I am mainly concerned about hard drives and cpu being worn down unnecessarily. I am not sure how much of a concern this should be though. The CPU isn't going to "wear out" due to being running, at least not in a meaningful time scale. HISTORICAL EVIDENCE hints that a spinning drive will last longer than a frequently power cycled drive. Steady-state is easiest on hw. Powering up and down is large power surges, and that's generally not good. This is across the board -- power supply, hard drives, main board, CPU, memory, etc. The only part that I think gets a benefit from being turned off would be a CRT monitor, and maybe the HV in an older LCD monitor. That's based on historical experience with a lot of different machines. How that relates to the hardware you have at hand, there's no way to know, other than get 50 identical machines, power one half on-and-off regularly and leave the other half on. Yes, I do know in advance when the machine needs to run and when it can sleep. "Some machines have a wake option in their BIOS." -> thanks for the pointer, I will look into that. That might work for you, but I think your premise is flawed. "How much electricity have you saved by that?" -> I don't know. The main concern is not using the hardware unnecessarily, to hopefully increase its lifetime. Though less electricity usage is a nice side bonus. I just did some measurements here before seeing these replies. Short version: single 4TB 3.5" 5400 RPM drive draws less than 7W when running...and I doubt you get all that power "back" when you spin down the drive. CPUs mostly draw power when doing something, the difference between an mostly idle CPU running at 1GHz vs. 3GHz is fairly small. And on a rack mount server, fans may draw more power than an idle CPU. "How much resources would that save?" -> My thoughts was that it would be better for hard drive longevity to have them spun down, rather than them being up for months without any access needed. I don't know in practice if that matters for life expectancy of the drive? As someone who has seen a lot of hard drives power down working and not spin back up at next power-on...I'm pretty sure your plan is absolutely defeating your goal. I'm pretty sure a whole lot of other people are also screaming "NO!!!" at their computer right now. I hold a lot of unpopular views based on my experience, but I'm pretty sure "leave drives running for maximum life" is NOT one of them, it's pretty mainstream. From your elaboration on your goals, just leave it alone. By trying to make it a super-efficient system, you are going to increase your downtime and failure in a number of ways. Nick. On 27 Nov 2022, at 15:50, Jan Stary wrote: On Nov 27 09:37:19, mytraddr...@gmail.com wrote: The main thing I am trying to do is to make it sleep every now and then to protect resources. How much eletricity does the machine eat? (What other "resources" are you concerned about?) 1) Make it sleep and wake up when woken up remotely I investigated Wake On Lan, which I enabled via ifconfig. However, this system is deployed remotely, and I have no access to other computers on the LAN, so I am unable to make this work. 2) Make it sleep for a few hours and then wake up Do you know in advance at what hours the machine needs to run, and when it can sleep? After 3hours+ of research in man pages and the internet, I have not seen any solution for that. Some machines have a wake option in their BIOS. 3) hard drives Spin down, CPU lower freq I have been able to lower the CPU speed by running `apm -L`. How much electricity have you saved by that? I haven't been able to spin down the hard drives. How much resources would that save? I you are concerned about resources, wouldn't you be better off getting a low-power machine, with SSD disks? There are machines out there that eat around 10W and get the job done (dependeing on the job of course); and SSD doesn't need to spin down. I cannot share the full dmesg for security reasons Bullshit.
Re: Keyboard won't work during OpenBSD 7.1 or 7.2 installation.
On 11/22/22 00:54, Clint wrote: Dear Sirs, My name is Clint Wu, I had been told the DMP’s EBOX-336x mini PC (product page <https://www.compactpc.com.tw/products/children/15> ) can run OpenBSD 7.1. ... My keyboard stop working at this stage. Did any one report this problem before? Can you tell me how to solve this? what should I do next? Please advise, thank you. well, I have no knowledge of this machine, but one thing I would try is to see if you can switch it between legacy (BIOS, MBR, etc.) and UEFI booting. Some machines have bugs in one mode but not the other. My favorite example is a machine I have that was sold with a custom Linux install and a warning that "you MUST use legacy mode" for the standard app, but OpenBSD can't see the disk I/O unless you run it in UEFI mode. Different hardware WILL behave differently. Nothing has made me appreciate the PC BIOS more than the things that have tried to replace it. IF you got the model with the serial port, you could try using a serial console. Sounds like you got it loaded via alternative means, if you can ssh into the system and get a dmesg out of it, it would be interesting to look at and might shed some clues. But some of these specialty machines (including some virtualization products) are built and tested to certain OSs and not much regard is given to other system or the reference designs. Nick.
Re: Ctrl key doesn't interrupt boot
On 11/14/22 06:40, Harald Dunkel wrote: Hi folks, according to boot(8) holding the Ctrl key is supposed to interrupt boot before /etc/boot.conf is read. But it doesn't. I see boot's message on VGA that it switches over to serial (as mentioned in boot.conf), and then it doesn't boot for a reason I would like to investigate. The screen stays black. I am sure that console redirection is turned off in the BIOS. OpenBSD is version 7.2. USB Keyboard. Every helpful hint is highly appreciated. Harri Wild guess, but I suspect that your BIOS isn't setting the marker that /boot uses to see the pressing of the CTRL key on your system with a USB keyboard. /boot is pretty much dependent upon your system BIOS doing The Right Thing, as the OS hasn't loaded yet. So other than looking at Other Things, I'm not sure there's an OpenBSD fix for this. Does your machine accept a PS/2 keyboard? If so, does CTRL work as expected there? Nick.
Re: Can I undo OpenBSD GPT partition table and recover my data? was: Triple booting Windows/Debian/OpenBSD?
On 11/3/22 10:14, Ottavio Caruso wrote: On Tue, 1 Nov 2022 at 12:27, Ottavio Caruso naively wrote: ... This is how it looks from Debian: Device Start End Sectors Size Type ... /dev/sda6 223012864 877277183 654264320 312G Microsoft basic data ... So I officially joined the club of idiots who don't back up their partition table. I wanted to install OpenBSD to free space, instead I must have overwritten the partition table (hopefully not formatting the drive because I aborted soon after realizing the mistake). I have attached two screenshots. I don't mind reinstalling Windows and Linux but I have a 350GB fat32 partition with tons of videos and books that I'd like to recover. I have tried using testdisk from cgsecurity but it cannot recover that particular partition. Any help will be appreciated. IF you happen to know where the start and end of that FAT32 partition is, i.e., an old OpenBSD fdisk or disklabel output, you can create a new partition of the same type in that exact location and your data will Just Be There, though getting it out of a laptop would be a bit tricky. Looks like you have the info from your linux install. I'd suggest practicing on something else with whatever tools you have, I am pretty sure OpenBSD won't "help" you by doing anything to the newly (re)created partition, but I can't make promises about any other tool. I really can't make promises about OpenBSD, I haven't tried doing this in a while. Now repeat after me: multibooting is hard. Never do it on a system that you aren't prepared to completely reload... Nick.
Re: Installing OpenBSD on new Chromebook
On 10/29/22 10:11, Jeff Ross wrote: On 10/29/22 1:29 AM, Stuart Henderson wrote: On 2022-10-28, Gabriel Busch de Brito wrote: All of places I'm finding with directions on how to do this are from circa 2015 and do not work now. Anybody have a pointer to a more updated set of directions I can try? I suggest that you follow the installation guide at the FAQ section of the website. Chromebooks aren't standard computers and usually come with a locked-down bootloader that will need disabling to install another OS. Also if it's arm rather than x86 there will be additional challenges beyond this. So there's not enough information in the original post to give any kind of pointer. Thanks Stuart. It's an HP Chromebook 14a-na1083d with an Intel Celeron N4500 with 4G ram and 128 eMMC drive. Booting up in developer mode it tells me that it is Model LANTIS-MEXL if that helps. Just install it, see what happens. If you want a guarantee, buy me one exactly like it, and I'll do what I'm suggesting you do. :) (and then you will discover why I call model numbers "market position statements", not "unique HW configuration identification systems") Or maybe better yet, see if it will boot from an OpenBSD install image on a USB drive, if it does, set up a full OpenBSD install on a USB drive and see what happens. I've had pretty good luck with HP PC-like systems that weren't sold with "standard" operating systems on them, but past experience is no indicator yada-yada-yada. Pain points if you get past booting are likely to be wireless and graphics. If you can get it to boot from a USB drive to test, you are probably good for an install. If you can't, probably not worth the effort. There MAY be tricks you can do, but you can put a lot of time and effort into forcing something to install OpenBSD and then find out X doesn't work. Or there's no functioning network. Or both. Nick.
