Re: pf.conf: modifier :0 doesn't work for IPv6 addresses
On Thu, Jan 18, 2024 at 01:01:31AM +0100, Alexandr Nedvedicky wrote: > If I remember correct it's been pointed out in 2020. > Unfortunately I'm not able to find details. > > the diff was not accepted because we could not find > a good way to establish concept of primary address (:0) > and alias addresses in IPv6. It sort of works for IPv4 but > in case of IPv6 there is some friction. > > I think currently the :0 is assigned to the first > IP address assigned to interface (hence primary) > In case of IPv6 the :0 is always a link-local address. There are certainly real world use cases where one or more modifiers similar to :0 would be useful on interfaces with multiple IPv6 addresses. We use cellular data links as redundant backups for fixed-line connections which need high availability. Typically the machines on the LAN have fixed static IPs, some globally routable and others locally scoped. Ideally, the backup link would provide access to the same block of global IPs, (and there are indeed ISPs out there who are happy to arrange that at a cost), but in reality the solution is usually a standard data service which provides a random dynamically assigned /64. (In the old days where the setup was generally 'leased line with ISDN backup' it was _much_ easier to get the same IP ranges on both. But back then the whole thing was often IPv4 only anyway.) This shouldn't pose a problem, as we can run NAT on the IPv6 block. Not one-to-many NAT, but just using the subnet part of the static addresses with the dynamically assigned prefix. Unfortunately, whilst that would be straightforward if the cellular link had a static prefix, when it is assigned dynamically via SLAAC there is no way to configure the necessary translation directly within pf.conf. Ugly hacks are possible using shell scripts to monitor address changes and update the pf config as necessary, but that didn't seem like a good long-term solution. Alternatively, it's possible to do one-to-many NAT over IPv6, and masquerade all of the LAN machines to the router's global IPv6 address. Except that the router usually has multiple globally-scoped IPv6 addresses, as well as link-local and ULA addresses. By default, with a simple NAT rule in pf.conf, any of these except the link-local addresses might up being used as the re-written source IP. Unfortunately, this simple avoiding of the link-local address doesn't ensure that the re-written address has sufficient scope to reach the destination, because ULA addresses are not excluded from the pool. However, as long as you don't have ULA addresses configured, you should always reach the destination, but you can't force the same behaviour for NAT'ed addresses that you would see by default on outbound connections originated directly from the router, which would prefer the IPv6 temporary addresses over the address derived from the NIC's MAC address. In these situations, it would be nice to have a modifier like :0 that returns 'the first non-deprecated IPv6 address with global scope'. That way, you could do something like: pass out on rge2 from foobar nat-to (rge2:1) where :1 is the hypothetical new modifier described above. Currently, if you do: pass out on rge2 from foobar nat-to (rge2:0) The link-local address will be used at the new source address, which is useless in most cases. Interestingly, there seems to be a bug or limitation in the handling of the 'bitmask' pool type in this case, because if you do: pass out on rge2 from foobar nat-to (rge2:0) bitmask The re-written source address does NOT have it's lower bits changed to match those of the real source address. OTOH, with: pass out on rge2 from foobar nat-to 2001:db8:::1/64 bitmask The lower bits are correctly re-written. Note that this is not the limitation described in the manual page that 'bitmask' is not permitted with more than one redirection address. The rule with '(rge2:0) bitmask' is correctly loaded with no errors, but the behaviour is buggy. Trying to use '(rge2) bitmask' will obviously fail with 'interface is not supported by pool type', and makes no sense anyway, as the interface typically has multiple IPv6 prefixes configured. Using 'source-hash', it's usually possible to avoid the link-local addresses, but there are no guarantees, as the ordering of configured addresses can change: pass out on rge2 from foobar nat-to 2001:db8:::1/64 source-hash 0x0001 Overall, it's possible to achieve a configuration that works, but there are certainly times where a more comprehensive set of address modifiers that were designed around these IPv6 specific scenarios would be very useful.
Re: passwd bug with specific password
On Sat, Jan 06, 2024 at 12:30:10AM +, Aaron Lott wrote: > So it turns out that OpenBSD 7.4, specifically the amd64 version but > possibly others as well, really doesn't like it when i set the root password > to: > > qU+wFoM"%=J@s4j" > > When i do so, it doesn't let me log in as root -- but when i use `su`, i'm > able to become root and change it to a password that does work. Your bug report is incomplete. You haven't told us whether you are logging in via the console or via xenodm. Are you sure that you are not using a different keyboard mapping at the login prompt to the one that was used in the installer? In which case, the " and @ symbols might be on different keys. (This is also an issue with softraid crypto passwords entered in the bootloader that were set at a console using a regional keyboard mapping, by the way.)
Re: FAQ Remap Caps Lock to be Control Left does not work
On Tue, Nov 21, 2023 at 11:47:56PM -0800, Alfred Morgan wrote: > 3) my resulting /etc/wsconsctl.conf looks like: > -f /dev/wskbd0 keyboard.map+="keysym Caps_Lock = Control_L" > -f /dev/wskbd1 keyboard.map+="keysym Caps_Lock = Control_L" > -f /dev/wskbd2 keyboard.map+="keysym Caps_Lock = Control_L" > -f /dev/wskbd3 keyboard.map+="keysym Caps_Lock = Control_L" > -f /dev/wskbd4 keyboard.map+="keysym Caps_Lock = Control_L" > -f /dev/wskbd5 keyboard.map+="keysym Caps_Lock = Control_L" > -f /dev/wskbd6 keyboard.map+="keysym Caps_Lock = Control_L" > -f /dev/wskbd7 keyboard.map+="keysym Caps_Lock = Control_L" > -f /dev/wskbd8 keyboard.map+="keysym Caps_Lock = Control_L" > -f /dev/wskbd9 keyboard.map+="keysym Caps_Lock = Control_L" > > not pretty and throws a block of errors on boot but gets the job done. I > guess not a big issue. > > 4) hot plugging in a keyboard after boot doesn't get any of the mapping I > configured. If the problem is just that you want to swap caps lock and control, rather than be able to make any arbitrary changes to the keyboard mapping after boot, then you can likely solve the problem simply by using one of the built-in mappings which already includes this change: # kbd -l | grep swap us.swapctrlcaps uk.swapctrlcaps jp.swapctrlcaps fr.swapctrlcaps fr.swapctrlcaps.dvorak be.swapctrlcaps us.swapctrlcaps.dvorak us.swapctrlcaps.colemak us.swapctrlcaps.iopener Just put the desired one in /etc/kbdtype and it should just work.
Re: FAQ Remap Caps Lock to be Control Left does not work
On Mon, Nov 20, 2023 at 06:14:54PM -0800, Alfred Morgan wrote: > wsconsctl keyboard.map+="keysym Caps_Lock = Control_L" > and it doesn't seem to do anything. Try: wsconsctl -f /dev/wskbd1 keyboard.map+="keysym Caps_Lock = Control_L"
Re: vxlan(4) custom destination UDP port seems not working
On Sun, Nov 19, 2023 at 06:04:16PM +0100, Luca Di Gregorio wrote: > Confirmed with the cloud service provider that they block input traffic of > type VXLAN. > Not only the port 4789, all ports carrying VXLAN. Did it mention that in their terms of service? If not, can't you just tunnel it via IPSEC, or do they block IPSEC tunnels as well? Or just ask them if it can be enabled for your account. Or switch to a better provider.
Re: X freeze with firefox/chromium on 7.4
How did you capture the debug info? Were you using a serial console, or hand copying? The reason for asking is that you seem to be experiencing spurious bit flips: On Sun, Nov 05, 2023 at 09:09:37PM +0100, Josh wrote: > chrome output before freeze: > test# chrome --debug > [67850:-1106581952:1104/174401.831825:ERROR:bus.co(406)] Failed to > connect to the bust Failed to connect to socket This should be 'bus:'. > /var/run/dbus/system_bus_socket: No such file or directory libGL > error: MESA-LOADER: failed to retrieve device information > libGL error: MESA-LOADER: failed to open andgpu: File not found > (search paths /usr/??116/lib/modules/dri, suffix_dri) libGL error: > failed to load driver: andgpu ^^ Expecting amdgpu. > libGL error: failed to open /dew/dri/card0: No such File on directory ^^^ Expecting dev. Interestingly the t/: is not a simple bitflip, but a shift: : 0x3a 00111010 t 0x74 01110100
Re: OpenBSD installation on Pinebook Pro
On Mon, Oct 16, 2023 at 04:34:06PM +0100, a...@disroot.org wrote: > I'm trying and so far failing to migrate my Pinebook Pro from armbian to > OpenBSD. > > Following https://ftp.openbsd.org/pub/OpenBSD/snapshots/arm64/INSTALL.arm64 > I created a SD card and booted from it without any problem. > The below I tested with 6.9, 7.0, 7.3 and 7.4 > > With all of the above releases I can boot but they all stop at "ohci0 at > mainbus0" as you can see at the end of the picocom output below. > > Would be thankful for any hint or pointer. > > Many thanks, > Andi > > # > > U-Boot TPL 2022.04-armbian (Apr 04 2023 - 04:33:44) You seem to be using a proprietary version of U-Boot that was left over from your old armbian installation rather than the recommended version for a fresh OpenBSD installation.
Re: No response to SSH server on network
On Wed, Oct 04, 2023 at 09:30:52PM +0500, Nurmurat Gurbanliyew wrote:
> Issue : Everytime when I leave my notebook on idle for more than 2 hours, I
> can not connect to this model from my LAN (from another notebook that uses
> wifi, both of them connected to lan through wifi) using SSH . There is no
> change in sshd_config in /etc/ssh/ folder everything is in default state.
>
> Q: Why I cannot connect from a notebook (connected to lan with wifi) to an
> OpenBSD machine (lenovo IdeaPad, connected to lan using wifi) using SSH
> after 2 hours idle?
Without more information, this sounds like either a firewall configuration
error, (you are not explicitly allowing SSH connections through, but state
that was previously created allows it temporarily), or otherwise if you are
using IPv6 and connecting to the temporary, ('privacy'), address then that
address is changing and no longer valid when you try to connect later on.
BTW, the public mailing lists are probably a better place to ask these
questions than open...@openssh.com.
Re: tcpdump/print-cdp.c
On Sat, Feb 25, 2023 at 11:55:50AM +0100, Peter J. Philipp wrote: > I have found this function in tcpdump/util.c called fn_printn() that escapes > text. Why would we want to use this function instead of just passing the string directly to vis? The transformation it performs is not even uniquely invertible.
Re: Odd X behaviour from root console (possible xauth bypass (but as root)?)
On Sun, Feb 19, 2023 at 09:27:33PM +, cho...@jtan.com wrote: > I haven't looked into what's causing this behaviour yet because I > was cooking So am I :-). > I was playing a series of flac files through mplayer (single process, > many files) in a root shell on the text console ^^ Don't do this. > (DISPLAY will not > have been set, nor XAUTHORITY) and using X normally. When mplayer > started a new track the X display acted as though a key was stuck > down. Which key was stuck changes (it may have been related to keys > I was pressing). Off the top of my head, I'm guessing that mplayer is trying to open various devices directly to display it's output on the framebuffer console, since X is not running. Since it's running as root, this will obviously succeed, and bad things will happen if another process is expecting exclusive access. Try this experiment: * Kill X * Log in as root on a VT * Run: # while true ; do dd if=/dev/wskbd0 of=/dev/null bs=512 count=1 ; sleep 1 ; done Now try to use the machine. You'll note that switching VTs is difficult, because pressing CTRL-ALT-Fx, often the first keystoke gets swallowed by the dd process. But it works if you do various dummy keystrokes, then do the CTRL-ALT-Fx combination between invocations of the dd in the loop, (I.E. during the one second pause). If you run mplayer as a normal user, (who is not also logged in on ttyC0), then the open of the device files should fail.
Re: Caps Lock influences yubikey
On Tue, Feb 07, 2023 at 02:14:14PM +0100, Paul de Weerd wrote: > On Tue, Feb 07, 2023 at 12:37:32PM +, Stuart Henderson wrote: > | On 2023/02/07 12:13, Paul de Weerd wrote: > | > Should yubikey really depend on the caps lock state of an (external) > | > keyboard? Would it make sense to lower the case of any password > | > | there's complex code to handle 90 odd different keymaps, it would seem > | silly to go to that much trouble and not cope with capslock. > > Hmm, thanks. When I was looking into this, I was wondering if this > was such a good idea, but your point seems valid to me. If committed, the change should probably be mentioned in the 7.2 -> 7.3 upgrade notes.
Re: No data transfer via comports after OpenBSD amd64 7.0 -> 7.1 upgrade
On Fri, Jan 27, 2023 at 11:25:24AM +0300, a...@werner-spb.ru wrote: > OpenBSD runs on Intel D2700MUD motherboard with Intel Atom processor, Intel > BIOS and 4 GB > of RAM. OpenBSD 7.0 updated to version 7.1 from the official mirror. After > the update, the system > on this computer works without errors, but I was unable to access devices > connected to the serial > ports, which worked fine in version 7.0. The serial ports are successfully > detected during the boot > process of OpenBSD 7.1. However, after it completes, no data is transferred > via /dev/cua00 and > /dev/cua01, nor /dev/tty00 and /dev/tty01. Upgrading to 7.2 did not change > the situation. Between 7.0 and 7.1 there were changes to make com ports attach via acpi. Do you have the dmesg from 7.0? Specifically, what does it say in place of: > 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
Re: 7.2: 'No buffer space available' after a while with axe0
On Thu, Dec 29, 2022 at 02:04:24PM +0100, Landry Breuil wrote: > i can add a monit check to do the down/up dance when the aforementioned > patterns show up in var/log/messages, but i'd be curious in > investigating it. What system metric should be monitored via systat to > check for that 'buffer space' ? You might want to look at the output of 'netstat -m'.
Re: iwx(4) randomly stopped connecting to Wi-Fi
On Tue, Dec 27, 2022 at 06:50:55PM +, Jeremy Potter wrote: > I ran "doas sh /etc/netstart iwx0 && dhcpleasectl iwx0" repeatedly, and also > rebooted my computer repeatedly, but the problem persisted for the entire day. > This morning, however, the problem suddenly disappeared. Did you just reboot it, or actually power cycle it? This looks like a hardware problem.
Re: Bug in awk script...
On Mon, Dec 26, 2022 at 06:03:42AM +0800, wuwow...@gmail.com wrote:
> Sad... Not working...
> OpenBSD 7.1
>
> #!/usr/bin/awk -f
> BEGIN {
> d = "/tmp/test/";
> system("mkdir -p " d);
> i = -1;
> while (++i < 1000) {
> f = d i;
> printf("") > f;
> }
> }
>
> awk: can't open file /tmp/wow/125
>
> It' seems that "one true awk" is buggy...
Not really. You just need to increase the limit for openfiles in
/etc/login.conf.
Re: Unable to complete secure online login
On Tue, Sep 20, 2022 at 10:32:29AM -0400, Raul Miller wrote: > On Tue, Sep 20, 2022 at 10:06 AM Alton Shaw wrote: > > I don't know it this is the same thing but I opened Firefox's console ... > > The network inspector should be a tab in the console. > > That said, I believe network errors should show up in the console. > > That said, it's entirely possible that the message is from a > javascript timeout, which would underline some of the points raised in > Crystal Kolipe's summary. (It's also plausible that the bank's > security people have decided that an excessively slow network is, for > their purposes, an insecure network.) So the next step would be to either: 1. Read through all of the javascript, work out which requests should be made, and compare that list to the actual list of requests made. or 2. Compare the requests made on a setup which is known to work, with the requests made on a setup which does not work. Presumably either something is not being sent from the client, or something is not received, (or is received too late, after a timeout has expired). Or maybe it is being sent as far as the client is concerned, but then gets mangled or delayed at the IP layer. Getting that far is complicated by the fact that there could be more than one issue, more than one request not being serviced, that the requests might be answered by different machines at the remote end, and there might also be some intentional randomisation going on between otherwise 'identical' login attempts. If you do manage to work out which javascript-initiated communication is not going through, you then need to find the _real_ reason why. It could be something seemingly completely unrelated. Maybe deep within that javascript is a function that is also implemented in web-assembly and that version is being used on Firefox but not on Surf, (which doesn't support it), causing a slight timing difference. The list of possibilities is almost endless at this point.
Re: Unable to complete secure online login
On Tue, Sep 20, 2022 at 01:04:01PM +0100, Stuart Henderson wrote: > On 2022/09/20 05:00, Alton Shaw wrote: > > Thanks for the suggestion Mikhail. > > > > Early on I had tried Chromium with the same result which I find very curious > > as I don't believe they share any code. So I was thinking it was something > > in how OpenBSD passed browser traffic to the web. But at Crystal's > > suggestion I also gave Surf a go and it was the only browser that > > consistently worked with the bank's website so I at least have a work around > > should Firefox start acting up again. > > Also be aware that the bank or their service provider/s may be changing > things while you are testing, also that they may direct different connections > to different backend servers which might be configured differently. > So things might change even if you do nothing different other than > get different sessions with the bank's website. He does seem to have had fairly consistent results with each configuration, though. So if there are indeed two or more clusters of servers at the bank which are configured differently, I don't think that he is just connecting to them randomly in a round-robin fashion. Rather, a particular client, (surf, firefox, etc), is for some reason connecting to a pool with a particular config. This may be due to subtle differences in the connections at the IP level, E.G. re-using an existing connection, using different source ports, number of concurrent connections, etc, etc. The error message that is displayed about the bank having technical issues and to try again later, is NOT coming from the server as a response to the login request. It's pre-stored somewhere within the Javascript login code. You can test this without an account at the bank and with any browser that is known to work - load the login page, and attempt to log in as user 'foobar' with password 'foobar'. You should see a error message saying that they were expecting something different, (I.E. username or password invalid, but we're not saying which). If you disconnect from the network before hitting the login button, (remove the LAN cable, or adjust the firewall settings on your local firewall to block traffic to your workstation), then you will see the, "sorry we're having technical difficulties" message. So, this message appears as a generic error when there is a failure of communication between the javascript-based login code, and the remote server. This explains why the bank rep that he spoke to said that they couldn't see any sign of an attempted login. It also strongly suggests that the problem does not lie with a mis-configured user-agent, nor with cookies, because the problem is at a lower level than that. The fact that Surf works pretty much confirms that the bank doesn't care much about the user-agent, because Surf's default user agent is something like: Mozilla/5.0 (X11; Linux x86_64; OpenBSD amd64) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.0 Safari/605.1.15 Surf/2.1" So it clearly announces itself as being Surf on OpenBSD, but otherwise looks like a regular modern UA string to any sensible huristics on the server. Since Surf works and Firefox and Chromium don't, I suggested off-list that he tried disabling http/2, as Surf does not support http/2, and this was one obvious difference between it and the browsers which do not work. However, it turns out not to be the issue. The bank seems to be IPv4 only, with no records for secure.royalbank.com, although some other domain that the javascript login code connects to might plausibly have IPv6 connectivity. If one browser is connecting over IPv4 only and another via IPv6, that might cause the issue he is seeing, but I don't think that that is the issue here. He says that Firefox running on OpenBSD within a VM in virtualbox running on an Ubuntu host works 50% of the time, whereas it works 0% of the time running the same configuration of Firefox on OpenBSD on the bare hardware. This suggests to me that some low-level manipulation of the packets at the IP layer is happening as they traverse the VM hypervisor and head out via the Linux networking stack, mitigating a packet-loss issue that is present in the native OpenBSD installation. Although the problem has now disappeared, it could easily return since we don't know what caused it in the first place. Unfortunately, further investigation would probably require analysing the network traffic to and from the client, as well as understanding the large lump of javascript that runs the whole affair. At this point, without any co-operation from the bank, the effort of debugging it rather exceeds the satisfaction gained from doing so. There is an issue somewhere, though, and whether it's in OpenBSD or somewhere else, it would be nice to fix it.
Re: re(4) drivers not working
On Fri, Sep 16, 2022 at 09:39:56AM +0200, Stefan Sperling wrote: > On Fri, Sep 16, 2022 at 08:27:59AM +0200, Adam Szewczyk wrote: > > Checked on actual hardware it seems to work fine. So I report it also to > > Qubes and Xen Project, but marmarek (head of qubes development team) > > suggest that it can be a problem with driver itself: > > "I'm not sure if that's relevant, but a common cause is incorrect MSI / > > MSI-X detection/support by the driver. HVM in Qubes do not support MSI-X, > > but do support MSI. MSI-X, even if the device really supports it, is masked > > from PCI capabilities. Driver should fallback to MSI (or INTx) if MSI-X > > fails to setup (or isn't there at all), but many drivers have this path > > buggy, since it isn't exercised in most common (native) scenario." > > re(4) only uses MSI, it does not ever even try MSI-X. As can be seen here: > https://github.com/openbsd/src/blob/master/sys/dev/pci/if_re_pci.c#L161 But there has been at least one report of MSI, (not MSI-X), causing the error that the OP is seeing with an 're' device on bare hardware, (no hypervisor): https://marc.info/?l=openbsd-tech=165987603706259=2 So maybe test the patch in that mail to see if using a regular non-MSI interrupt mitigates the problem. Then look for the real bug if it does.
Re: X crashes when moving cursor from keyboard (fvwm1, fvwm2 or cwm)
On Sun, Aug 28, 2022 at 08:20:34PM +0200, Walter Alejandro Iglesias wrote: > On Aug 27 2022, Crystal Kolipe wrote: > > On Sat, Aug 27, 2022 at 01:07:30PM +0200, Walter Alejandro Iglesias wrote: > > > X crashes when moving cursor from keyboard bindings. I can reproduce > > > the bug with cwm, fvwm or fvwm2 (because this window managers have that > > > option). According to the logs the cause could be in wsmouse. > > > > Can you reproduce this using the window-move and window-resize functions > > of cwm? Or is it strictly the pointer-move functions that cause it? > > > > For example: > > > > bind-key C-Up window-move-up > > bind-key C-Down window-move-down > > bind-key C-Left window-move-left > > bind-key C-Right window-move-right > > bind-key M-Up window-move-up-big > > bind-key M-Down window-move-down-big > > bind-key M-Left window-move-left-big > > bind-key M-Right window-move-right-big > > bind-key 4-Up window-resize-up-big > > bind-key 4-Down window-resize-down-big > > bind-key 4-Left window-resize-left-big > > bind-key 4-Right window-resize-right-big > > That's exactly how I reproduced it the first time. When I noticed that > moving the cursor alone produced the same effect (having in mind that > the commands above also move the cursor) I thought it could be the > cursor, but perhaps it's the keyboard input what makes X crash, I don't > know. I have not been able to reproduce this problem here so far, and I've used X without a mouse on OpenBSD on various machines for over a decade, on a daily basis. So either the issue has been introduced very recently, or it is only triggerable on particular hardware configurations. Can you test an older -release and see if you can reproduce it? Does it happen if you use the 'Pointer_EnableKeys' directive in .Xmodmap? For example, if you configure the right hand ALT key with: keycode 113 = Pointer_EnableKeys Pointer_Accelerate Then with X running, hit the right ALT key and you should be able to move the mouse pointer with the numeric keypad. > PS: Crystal, your @exoticsilicon.com address returns my messages. Yes, your mailserver doesn't support TLS 1.3, so we reject your connection. This is intentional. Please tell your ISP to upgrade their mailserver.
Re: how to use <> to assign entire disk to /+swap
On Fri, Jun 10, 2022 at 10:57:49AM -0600, Theo de Raadt wrote: > Crystal Kolipe wrote: > > > On Fri, Jun 10, 2022 at 10:46:28AM -0600, Theo de Raadt wrote: > > > Crystal Kolipe wrote: > > > > > > > On Fri, Jun 10, 2022 at 06:21:42PM +0200, Claudio Jeker wrote: > > > > > On Fri, Jun 10, 2022 at 11:43:50AM -0400, Andrew Cagney wrote: > > > > > > On Fri, 10 Jun 2022 at 10:52, Crystal Kolipe > > > > > > wrote: > > > > > > > > > > > > > > On Fri, Jun 10, 2022 at 10:40:47AM -0400, Andrew Cagney wrote: > > > > > > > > I'm trying to use <> to auto partition a > > > > > > > > disk > > > > > > > > with most of the disk assigned to / but also with some swap. > > > > > > > > > > > > > > Try: > > > > > > > > > > > > > > / 1g-*100% > > > > > > > swap1g 0% > > > > > > > > > > > > That worked: > > > > > > > > > > > > [root@openbsd root]# disklabel sd0 > > > > > > ... > > > > > > #size offset fstype [fsize bsize cpg] > > > > > > a: 18874240 64 4.2BSD 2048 16384 12960 # > > > > > > / > > > > > > b: 2097152 18874304swap# > > > > > > none > > > > > > c: 209715200 unused > > > > > > > > > > > > Thanks! > > > > > > > > > > > > Can I suggest adding this as an example to disklabel(8). I suspect > > > > > > assigning the entire disk to / is a common scenario, and would help > > > > > > clarify how * and % interact. > > > > > > > > > > That is a bad advice. Using single / is just bad habit and does not > > > > > allow > > > > > to limit mountpoints with nodev, nosuid or wxallowed. For disks in > > > > > the 10G > > > > > space I would make sure that /var, /tmp, /usr, /home are different > > > > > partitions. > > > > > > > > Just for the record, the original post doesn't actually mention anything > > > > about this being for the _root_ disk. > > > > > > > > I assumed that he had a second or subsequent disk that was to be used as > > > > a single volume, but wanted to reserve a small space for swap to improve > > > > performance by interleaving the swap over multiple physical disks. > > > > > > > > > It is you making an assumption on thin evidence. 99% of our user base has > > > 1 disk. > > > > The original post did not include a dmesg. > > > > It should have done. > > Why should it contain a dmesg? The dmesg has nothing to do with this. A dmesg would have shown how many physical disks are in the system. It's an example of how not providing a dmesg because you don't think it's relevant, can imply that you know enough not to need your hand held, and therefore just get the direct answer to the question you asked, (which is what I provided, nothing more, nothing less). In previous posts to the list, the OP said that he is porting libreswan to OpenBSD. So it's perfectly reasonable to assume that he is somewhat familar with the OS, and therefore shouldn't require the "don't use a single / partition" warning.
Re: how to use <> to assign entire disk to /+swap
On Fri, Jun 10, 2022 at 10:46:28AM -0600, Theo de Raadt wrote: > Crystal Kolipe wrote: > > > On Fri, Jun 10, 2022 at 06:21:42PM +0200, Claudio Jeker wrote: > > > On Fri, Jun 10, 2022 at 11:43:50AM -0400, Andrew Cagney wrote: > > > > On Fri, 10 Jun 2022 at 10:52, Crystal Kolipe > > > > wrote: > > > > > > > > > > On Fri, Jun 10, 2022 at 10:40:47AM -0400, Andrew Cagney wrote: > > > > > > I'm trying to use <> to auto partition a disk > > > > > > with most of the disk assigned to / but also with some swap. > > > > > > > > > > Try: > > > > > > > > > > / 1g-*100% > > > > > swap1g 0% > > > > > > > > That worked: > > > > > > > > [root@openbsd root]# disklabel sd0 > > > > ... > > > > #size offset fstype [fsize bsize cpg] > > > > a: 18874240 64 4.2BSD 2048 16384 12960 # / > > > > b: 2097152 18874304swap# none > > > > c: 209715200 unused > > > > > > > > Thanks! > > > > > > > > Can I suggest adding this as an example to disklabel(8). I suspect > > > > assigning the entire disk to / is a common scenario, and would help > > > > clarify how * and % interact. > > > > > > That is a bad advice. Using single / is just bad habit and does not allow > > > to limit mountpoints with nodev, nosuid or wxallowed. For disks in the 10G > > > space I would make sure that /var, /tmp, /usr, /home are different > > > partitions. > > > > Just for the record, the original post doesn't actually mention anything > > about this being for the _root_ disk. > > > > I assumed that he had a second or subsequent disk that was to be used as > > a single volume, but wanted to reserve a small space for swap to improve > > performance by interleaving the swap over multiple physical disks. > > > It is you making an assumption on thin evidence. 99% of our user base has > 1 disk. The original post did not include a dmesg. It should have done.
Re: how to use <> to assign entire disk to /+swap
On Fri, Jun 10, 2022 at 06:21:42PM +0200, Claudio Jeker wrote: > On Fri, Jun 10, 2022 at 11:43:50AM -0400, Andrew Cagney wrote: > > On Fri, 10 Jun 2022 at 10:52, Crystal Kolipe > > wrote: > > > > > > On Fri, Jun 10, 2022 at 10:40:47AM -0400, Andrew Cagney wrote: > > > > I'm trying to use <> to auto partition a disk > > > > with most of the disk assigned to / but also with some swap. > > > > > > Try: > > > > > > / 1g-*100% > > > swap1g 0% > > > > That worked: > > > > [root@openbsd root]# disklabel sd0 > > ... > > #size offset fstype [fsize bsize cpg] > > a: 18874240 64 4.2BSD 2048 16384 12960 # / > > b: 2097152 18874304swap# none > > c: 209715200 unused > > > > Thanks! > > > > Can I suggest adding this as an example to disklabel(8). I suspect > > assigning the entire disk to / is a common scenario, and would help > > clarify how * and % interact. > > That is a bad advice. Using single / is just bad habit and does not allow > to limit mountpoints with nodev, nosuid or wxallowed. For disks in the 10G > space I would make sure that /var, /tmp, /usr, /home are different > partitions. Just for the record, the original post doesn't actually mention anything about this being for the _root_ disk. I assumed that he had a second or subsequent disk that was to be used as a single volume, but wanted to reserve a small space for swap to improve performance by interleaving the swap over multiple physical disks. Using a single / partition on the root disk is almost always a bad idea, and I don't recommend it.
Re: how to use <> to assign entire disk to /+swap
On Fri, Jun 10, 2022 at 10:40:47AM -0400, Andrew Cagney wrote: > I'm trying to use <> to auto partition a disk > with most of the disk assigned to / but also with some swap. Try: / 1g-*100% swap1g 0%
Re: `cwm`: custom `bind-key` for `command term` don't work
On Tue, May 24, 2022 at 11:18:59PM +0300, u...@mailo.com wrote: > There are 2 special `command`s: `term` and `lock`. No, there are two special commands: 'terminal' and 'lock'. You probably want: bind-key M-Return terminal
Re: System upgraded from 7.0 to 7.1 hangs after fs mounts
On Sat, May 21, 2022 at 10:31:37AM -0400, Johan Huldtgren wrote: > So the work around is commenting out that line, any clues to why that line > breaks > this hardware? Does this com port actually exist on your hardware: > com1 at acpi0 UAR1 addr 0x2f8/0x8 irq 3: ti16750, 64 byte fifo > com1: probed fifo depth: 0 bytes How is it reported in the dmesg from previous OpenBSD versions?
Re: ThinkPad X1 Carbon gen9 - suspend and hibernate not working
On Sat, Jan 15, 2022 at 01:04:35PM -0800, Mike Larkin wrote: > On Sat, Jan 15, 2022 at 09:00:44PM +, Mikolaj Kucharski wrote: > > # dmesg | grep swap > > root on sd1a (091f997bd652ed0b.a) swap on sd1b dump on sd1b > > but you have no 'b' on sd1, so this is likely why you're failing. get_hibernate_info is hard-coded to use swdevt[0], so it's definitely one reason. There may be others, too.
Re: (C/C++] getline... do a "double free memory leek"
On Fri, Jan 14, 2022 at 01:03:21PM +0100, Bilal Emohmadian wrote: > Writing my game engine in Cpp to see OpenBSD support but when my program > want to use this method. > CC is ok to use getline's method but binary don't. > > > a.out(84808) in recallocarray(): bogus pointer (double free?) 0x7f7f47a8 This is a bug in your program, not in OpenBSD.
Re: 7.0 install from install70.img no firmware for wifi (iwn-5000)
On Wed, Jan 05, 2022 at 03:11:47PM +0100, Marek Kozlowski wrote: > 1. Is it (missing firmware) intentional or is it a bug to be fixed? The firmware cannot be distributed with the OpenBSD base system for licensing reasons. > 2. It informs that it cannot find formware - error 2... then it asks for > ESSID and a WPA passphrase for that interface..? I'm not sure if I > understand that idea... > > 3. Is there or isn't there any difference between installation with and > without working network connection? As you are using install70.img, you don't need a working network connection to complete the installation of the base system. All of the files you need are included in install70.img. > 4. Currently I have only Linux installed. I'm wondering what is the easiest > way of updating the install USB flash drive. If you really want to have the wireless NIC working during installation, you could manually download the firmware file from: http://firmware.openbsd.org/firmware/ and copy it to another USB flash drive. You can then exit to a shell in the installer, and mount the second flash drive on /etc/firmware/. However, it would be much easier to complete the installation first, then use fw_update with the -p option to install the firmware from a local copy that you have already downloaded separately.
Re: 7.0 install from install70.img no firmware for wifi (iwn-5000)
On Wed, Jan 05, 2022 at 09:12:48AM +0100, Marek Kozlowski wrote: > After I set up the ESSID and WPA-PSK the following message is displayed: > > iwn0: could not read firmware iwn-5000 (error 2) Your NIC requires firmware files which are available from: http://firmware.openbsd.org/firmware/ It's probably easiest to complete the install without setting it up, then install the firmware and configure the wireless adaptor manually afterwards. The iwn(4), and fw_update(1) manual pages have more relevant information.
Re: rcctl man page does not describe -d and -f flags, at least, not sufficiently
On Thu, Dec 23, 2021 at 03:06:01PM -0500, Sean McBride wrote: > On 13 Dec 2021, at 15:46, Crystal Kolipe wrote: > > >On Mon, Dec 13, 2021 at 03:39:31PM -0500, Sean McBride wrote: > >>The rcctl man page fails to actually describe what the -d and -f flags > >>do. It mentions they exist, but doesn't say more. > > > >If you look at the referenced rc.d(8) manpage, you'll see that they are > >fully explained there. > > Thanks for the reply. Am I alone in feeling that it's pretty odd to look > for the explanation of a command's parameters in a *different* man page? It > was not at all obvious to me, my two colleagues I showed this to before > posting, and I guess it was not clear to that blogger either. It seems completely logical to me, since the parameters are simply passed through to rc.d. Documenting them in rcctl(8) would just be duplicating text across several manual pages, which is generally avoided. The majority of manual pages reference other manual pages, and in many cases you'll need to read more than one to get all of the information required.
Re: rcctl man page does not describe -d and -f flags, at least, not sufficiently
On Mon, Dec 13, 2021 at 03:39:31PM -0500, Sean McBride wrote: > The rcctl man page fails to actually describe what the -d and -f flags do. > It mentions they exist, but doesn't say more. If you look at the referenced rc.d(8) manpage, you'll see that they are fully explained there.
Re: Some Framework Laptops fail to resume from zzz
On Tue, Dec 07, 2021 at 10:53:33AM -0500, Ian Darwin wrote: > Dmesg is from MP but SP behaves the same. > dmesg: > OpenBSD 7.0-current (GENERIC) #150: Tue Dec 7 01:26:44 MST 2021 This is SP.
Re: ACPI panic on amd64
On Fri, Nov 26, 2021 at 05:16:08PM +0100, Parodper wrote: > Here is a gzipped collage of a video I took of the dmesg. Please don't send such large attachments to the list.
Re: df(1)s missing -m and -g options
> df(1) is missing the standard options to display size units in
> Megabytes or Gigabytes.
alias df_m="df | perl -e '<>; print ("Filesystem1M-blocks Used
Available Capacity Mounted on\n"); while ($i=<>) { $i =~ /^(.*?) +(\d+) +(\d+)
+(\d+)(.*)/; printf ("%s % 13d % 10d %
11d%s\n",$1,int($2/2048),int($3/2048),int($4/2048),$5); }'"
Re: vi: segfault on exit
On Sun, Oct 24, 2021 at 03:05:01PM -0500, Edgar Pettijohn wrote: > > On 10/24/21 10:11 AM, Klemens Nanni wrote: > >I fat fingered commands and it crashed. Here is a reproducer > >(files do not have to exist): > > > > $ vi foo > > :e > > :e bar > > :q! > > vi(12918) in free(): write after free 0xea559a2d980 > >Abort trap (core > > dumped) > > > >In words: open a file, open an empty file, open another file, exit > >forcefully. > > > >Here's a backtrace produced with a DEBUG='-g3 -O0' exectuable: > > > >#0 thrkill () at /tmp/-:3 > >3 /tmp/-: No such file or directory. > >#0 thrkill () at /tmp/-:3 > >#1 0x0f8c41ddb78e in _libc_abort () at > >/usr/src/lib/libc/stdlib/abort.c:51 > >#2 0x0f8c41d8e096 in wrterror (d=0xf8c0ff999e0, msg=0xf8c41d6c911 > >"write after free %p") at /usr/src/lib/libc/stdlib/malloc.c:307 > >#3 0x0f8c41d8ee1a in ofree (argpool=0x7f7f3dc0, p=, > >clear=, check=, argsz=) at > >/usr/src/lib/libc/stdlib/malloc.c:1439 > >#4 0x0f8c41d8e2db in free (ptr=0xf8bcf80a600) at > >/usr/src/lib/libc/stdlib/malloc.c:1470 > >#5 0x0f89c487c803 in opts_free (sp=0xf8c03c1e7a0) at > >/usr/src/usr.bin/vi/build/../common/options.c:1096 > >#6 0x0f89c4880936 in screen_end (sp=0xf8c03c1e7a0) at > >/usr/src/usr.bin/vi/build/../common/screen.c:192 > >#7 0x0f89c489a013 in vi (spp=0x7f7f41d8) at > >/usr/src/usr.bin/vi/build/../vi/vi.c:257 > >#8 0x0f89c4875a4b in editor (gp=0xf8c5dfc85f0, argc=1, > >argv=0x7f7f4320) at /usr/src/usr.bin/vi/build/../common/main.c:429 > >#9 0x0f89c484566b in main (argc=2, argv=0x7f7f4318) at > >/usr/src/usr.bin/vi/build/../cl/cl_main.c:97 > > > > > >I have no time to look at this myself, feel free to take over. > > > If it helps to narrow this down I can't reproduce on 6.9 Are you sure? I'm seeing the issue on a 6.9 installation here.
Re: Off by one in cmd_i386.c
Ping?
On Mon, Aug 16, 2021 at 12:09:51AM -0300, Crystal Kolipe wrote:
> Hi,
>
> The patch below fixes an off-by-one in /arch/amd64/stand/libsa/cmd_i386.c.
>
> The affected code path is handling the machine boot command in the
> bootloader. Currently, trying to boot from MBR partition 'a', with a command
> such as machine boot hd0a, will in fact boot from whichever partition is
> flagged as active, rather than forcing a boot from partition 'a'.
>
> The bug was introduced in revision 1.20 of the original i386 architecture
> file over 20 years ago on 19980224.
>
> untrusted comment: verify with signify key for exoticsilicon.com
> RWRn5d3Yx35u0w51USyxAkjCzjLo99UNE67gXzvuaTGbD9cMlTKdDTOAOe7JA6LV/VLWqmomwo7D9m399vKnra2KyrUn/EYcUgo=
> --- arch/amd64/stand/libsa/cmd_i386.c.distFri May 10 18:20:43 2019
> +++ arch/amd64/stand/libsa/cmd_i386.c Sun Aug 15 23:44:45 2021
> @@ -107,7 +107,7 @@
> dev += (cmd.argv[1][2] - '0');
> part = (cmd.argv[1][3] - 'a');
>
> - if (part > 0)
> + if (part >= 0)
> printf("[%x,%d]\n", dev, part);
> else
> printf("[%x]\n", dev);
> @@ -119,7 +119,7 @@
> goto bad;
>
> /* Frob boot flag in buffer from HD */
> - if ((dev & 0x80) && (part > 0)){
> + if ((dev & 0x80) && (part >= 0)){
> int i, j;
>
> for (i = 0, j = DOSPARTOFF; i < 4; i++, j += 16)
> --- arch/i386/stand/libsa/cmd_i386.c.dist Fri Jun 10 15:36:06 2016
> +++ arch/i386/stand/libsa/cmd_i386.c Sun Aug 15 23:44:23 2021
> @@ -119,7 +119,7 @@
> dev += (cmd.argv[1][2] - '0');
> part = (cmd.argv[1][3] - 'a');
>
> - if (part > 0)
> + if (part >= 0)
> printf("[%x,%d]\n", dev, part);
> else
> printf("[%x]\n", dev);
> @@ -131,7 +131,7 @@
> goto bad;
>
> /* Frob boot flag in buffer from HD */
> - if ((dev & 0x80) && (part > 0)){
> + if ((dev & 0x80) && (part >= 0)){
> int i, j;
>
> for (i = 0, j = DOSPARTOFF; i < 4; i++, j += 16)
>
Off by one in cmd_i386.c
Hi,
The patch below fixes an off-by-one in /arch/amd64/stand/libsa/cmd_i386.c.
The affected code path is handling the machine boot command in the bootloader.
Currently, trying to boot from MBR partition 'a', with a command such as
machine boot hd0a, will in fact boot from whichever partition is flagged as
active, rather than forcing a boot from partition 'a'.
The bug was introduced in revision 1.20 of the original i386 architecture file
over 20 years ago on 19980224.
untrusted comment: verify with signify key for exoticsilicon.com
RWRn5d3Yx35u0w51USyxAkjCzjLo99UNE67gXzvuaTGbD9cMlTKdDTOAOe7JA6LV/VLWqmomwo7D9m399vKnra2KyrUn/EYcUgo=
--- arch/amd64/stand/libsa/cmd_i386.c.dist Fri May 10 18:20:43 2019
+++ arch/amd64/stand/libsa/cmd_i386.c Sun Aug 15 23:44:45 2021
@@ -107,7 +107,7 @@
dev += (cmd.argv[1][2] - '0');
part = (cmd.argv[1][3] - 'a');
- if (part > 0)
+ if (part >= 0)
printf("[%x,%d]\n", dev, part);
else
printf("[%x]\n", dev);
@@ -119,7 +119,7 @@
goto bad;
/* Frob boot flag in buffer from HD */
- if ((dev & 0x80) && (part > 0)){
+ if ((dev & 0x80) && (part >= 0)){
int i, j;
for (i = 0, j = DOSPARTOFF; i < 4; i++, j += 16)
--- arch/i386/stand/libsa/cmd_i386.c.dist Fri Jun 10 15:36:06 2016
+++ arch/i386/stand/libsa/cmd_i386.cSun Aug 15 23:44:23 2021
@@ -119,7 +119,7 @@
dev += (cmd.argv[1][2] - '0');
part = (cmd.argv[1][3] - 'a');
- if (part > 0)
+ if (part >= 0)
printf("[%x,%d]\n", dev, part);
else
printf("[%x]\n", dev);
@@ -131,7 +131,7 @@
goto bad;
/* Frob boot flag in buffer from HD */
- if ((dev & 0x80) && (part > 0)){
+ if ((dev & 0x80) && (part >= 0)){
int i, j;
for (i = 0, j = DOSPARTOFF; i < 4; i++, j += 16)
