Re: disk not found after first reboot

2024-01-19 Thread Noth



On 19/01/2024 01:38, Isak Lyberth wrote:

Hello guys, I am sorry to bother you with such a basic question.
After many years of only using my favorite OS on my firewall, I have
decided to install OpenBSD 7.4 on my Dell Latitude 7490 laptop, fitted with
a 500 GB Samsung 980 (non pro) nvme disk i use the entire disk with auto
partitioning).
it had Windows on it when iÍ got it, I removed it and used Linux Mint for
about a week and now i have installed OpenBSD 7.4. i have tried it a lot of
times, clearing the disk with the dd if=/dev/zero of=/dev/sd0 command and
also dd'd to sd0a, rsd0 and anything i could think of, i also tried exiting
to shell and done some fdisk -iy sd0 (suggested on reddit)
I have tested that I can get FreeBSD and Dragonfly bsd installed on the
laptop.

I will gladly supply more info if needed.
But how do I get my laptop to boot OpenBSD?

Kind regards Isak


Hi,

/dev/sd0c represents the whole drive, so dd should be pointed at it. 
Doing anything just creates a huge file in /dev. If you're having 
beginner problems, try using gpartdisk from a Linux flash drive to 
create an A6 partition and then installing OpenBSD.


Cheers

Noth



Re: cdn.openbsd.org: packages-stable not up to date

2024-01-19 Thread Matthew Ernisse

On Fri, Jan 19, 2024 at 08:29:30PM +0200, Mark said:

So, any clue?


Seems fine now, at least for whichever node the CDN returned for me.

bakeneko@20:02:19 ~ >curl -s 
https://cdn.openbsd.org/pub/OpenBSD/7.4/packages-stable/ | grep amd64
amd64/ 
17-Jan-2024 02:20   -


bakeneko@20:02:25 ~ >curl -s 
https://ftp.openbsd.org/pub/OpenBSD/7.4/packages-stable/ | grep amd64
amd64/ 
17-Jan-2024 02:20   -



--
Please direct replies to the list.



Re: cdn.openbsd.org: packages-stable not up to date

2024-01-19 Thread Mark
So, any clue?

15 Ocak 2024 Pazartesi tarihinde K R  yazdı:

> Hi,
>
> It seems packages-stable from cdn.openbsd.org haven't been
> updated since Dec, 25th:
>
> $ curl -s https://cdn.openbsd.org/pub/OpenBSD/7.4/packages-stable/ | grep
> amd64
> amd64/ 25-Dec-2023 06:06
>
> ftp.openbsd.org seems fine, though:
>
> $ curl -s https://ftp.openbsd.org/pub/OpenBSD/7.4/packages-stable/ | grep
> amd64
> amd64/ 13-Jan-2024 18:15
>
> Thanks,
> --Kor
>
>


Please test: wg(4): drop "while (!ifq_empty())" hack in wg_peer_destroy()

2024-01-19 Thread Vitaliy Makkoveev
Hi,

wg(4) stores reference to peer in the outgoing mbuf. Since it doesn't
use reference counting, to make the `peer' dereference safe within
wg_qstart(), wg_peer_destroy() has the following delay loop:

NET_LOCK();
while (!ifq_empty(>sc_if.if_snd)) {
/*
 * XXX: `if_snd' of stopped interface could still
 * contain packets
 */
if (!ISSET(sc->sc_if.if_flags, IFF_RUNNING)) {
ifq_purge(>sc_if.if_snd);
continue;
}
NET_UNLOCK();
tsleep_nsec(, PWAIT, "wg_ifq", 1000);
NET_LOCK();
}
NET_UNLOCK();

Regardless on exclusive netlock acquisistion which stops packet
processing, this loop also could became infinite on huge traffic. I
want to remove it. Unfortunately, we can't use reference counting for
outgoing packets because they could stuck within `if_snd' of stopped
interface. These packets will be removed on interface destruction, so
the reference of `peer' will never be released.

There is another way: to do wg_aip_lookup() for each packet within
wg_qstart(). This diff implements it. Obviously, wg_aip_lookup()
provides some performance impact, so I'm asking for help with testing
this diff on configuration with huge amount of peers and traffic
pressure. I'm interesting what is the performance impact and is the
performance impact acceptable. Of course any other help with testing is
also welcomed.

Also, this diff restores pf(4) delay option for wg(4) interfaces.

Index: sys/net/if_wg.c
===
RCS file: /cvs/src/sys/net/if_wg.c,v
retrieving revision 1.36
diff -u -p -r1.36 if_wg.c
--- sys/net/if_wg.c 18 Jan 2024 08:46:41 -  1.36
+++ sys/net/if_wg.c 19 Jan 2024 13:45:06 -
@@ -507,22 +507,6 @@ wg_peer_destroy(struct wg_peer *peer)
 
noise_remote_clear(>p_remote);
 
-   NET_LOCK();
-   while (!ifq_empty(>sc_if.if_snd)) {
-   /*
-* XXX: `if_snd' of stopped interface could still
-* contain packets
-*/
-   if (!ISSET(sc->sc_if.if_flags, IFF_RUNNING)) {
-   ifq_purge(>sc_if.if_snd);
-   continue;
-   }
-   NET_UNLOCK();
-   tsleep_nsec(, PWAIT, "wg_ifq", 1000);
-   NET_LOCK();
-   }
-   NET_UNLOCK();
-
taskq_barrier(wg_crypt_taskq);
taskq_barrier(net_tq(sc->sc_if.if_index));
 
@@ -2092,20 +2076,39 @@ wg_qstart(struct ifqueue *ifq)
struct ifnet*ifp = ifq->ifq_if;
struct wg_softc *sc = ifp->if_softc;
struct wg_peer  *peer;
-   struct wg_tag   *t;
struct mbuf *m;
SLIST_HEAD(,wg_peer) start_list;
 
SLIST_INIT(_list);
 
+   rw_enter_read(>sc_lock);
/*
 * We should be OK to modify p_start_list, p_start_onlist in this
 * function as there should only be one ifp->if_qstart invoked at a
 * time.
 */
while ((m = ifq_dequeue(ifq)) != NULL) {
-   t = wg_tag_get(m);
-   peer = t->t_peer;
+   switch (m->m_pkthdr.ph_family) {
+   case AF_INET:
+   peer = wg_aip_lookup(sc->sc_aip4,
+   (m, struct ip *)->ip_dst);
+   break;
+#ifdef INET6
+   case AF_INET6:
+   peer = wg_aip_lookup(sc->sc_aip6,
+   (m, struct ip6_hdr *)->ip6_dst);
+   break;
+#endif
+   default:
+   m_freem(m);
+   continue;
+   }
+
+   if (peer == NULL) {
+   m_freem(m);
+   continue;
+   }
+
if (mq_push(>p_stage_queue, m) != 0)
counters_inc(ifp->if_counters, ifc_oqdrops);
if (!peer->p_start_onlist) {
@@ -2120,6 +2123,8 @@ wg_qstart(struct ifqueue *ifq)
wg_timers_event_want_initiation(>p_timers);
peer->p_start_onlist = 0;
}
+   rw_exit_read(>sc_lock);
+
task_add(wg_crypt_taskq, >sc_encap);
 }
 
@@ -2175,19 +2180,6 @@ wg_output(struct ifnet *ifp, struct mbuf
if (m->m_pkthdr.ph_loopcnt++ > M_MAXLOOP) {
DPRINTF(sc, "Packet looped\n");
ret = ELOOP;
-   goto error;
-   }
-
-   /*
-* As we hold a reference to peer in the mbuf, we can't handle a
-* delayed packet without doing some refcnting. If a peer is removed
-* while a delayed holds a reference, bad things will happen. For the
-* time being, delayed packets are unsupported. This may be fixed with
-* another aip_lookup in wg_qstart, or refcnting as mentioned