OpenBSD -current GPT install boot failure

2025-03-30 Thread Dan
I tend to not understand much expecially when you mix up stuff to fix
with "Windows 10", sorry for that.

However, to have your efi partition working properly I'm guessing you miss 
something like:

fdisk -i -b blocks[@offset[:EF]] sdx (<- replacing sdx with your disk and 
offset)

To fully understand solution and risks please see my blog (signward), it should 
be the 5th post about a Mac setup
without efi boot.

Please note that I believe the above command should erase the disk data
and that the efi filenames must be uppercase to run properly.

NB: you should care about working in safe mode by making a backup
of you disk data before to do any operation, my tips are supplied ASIS, at
your own risk.


Dan

--
BSD: bsd.gaoxio.com - Repo: https://code.5mode.com

Please reply to the mailing-list, leveraging technical stuff.

Mar 30, 2025 05:38:14 Avon Robertson :

> 2. Is it possible to access and manually install the entire OpenBSD
>    boot variable from within an installed but unbootable OpenBSD, by
>    dropping to a shell as above?



Re: pair(4) question

2025-03-30 Thread David Gwynne
On Mon, Mar 24, 2025 at 09:03:49AM -0600, Diana Eichert wrote:
> inline
> 
> On Sun, Mar 23, 2025 at 10:30???PM Philipp Buehler
>  wrote:
> >
> > Am 24.03.2025 00:24 schrieb Diana Eichert:
> > > Am I missing something or is this the only way to automatically bring
> > > up a pair(4) patch?
> > >
> > > find /etc -name '*.pair*' -print -exec cat {} \;
> > > /etc/hostname.pair0
> > > rdomain 0
> >
> > > group pair
> > > lladdr 00:00:C0:44:44:00
> >
> > group and lladdr is optional
> 
> yep, just thought I'd post the entire file.  I have a weird quirk
> where I set lladdr on network interfaces to Western Digital OUI
> values, allows me to look at network device cam tables for my
> systems.
> 
> > > inet 10.1.1.0/31
> > > up
> > up is implied when setting inet/inet6

that's not always true anymore.

having address config imply bringing an interface up is awkward from an
error reporting and recovery point of view (if you get an error, is it
because adding the address changed or was it cos fiddling with the
interface failed?), and because it reaches across subsystems.

> yep, I was part of a thread on @tech where this was discussed.  To
> many years in network engineer where you explicitly bring an
> interface / port online.

i think it's a good habit.

> > > /etc/hostname.pair44
> > > rdomain 44
> > > group pair
> > > patch pair0
> >
> > this is the key line to "patch" those two together
> 
> yep, the "issue" is the order interfaces are brought up, pair0
> comes up first, but I can't put "patch pair44" in that config
> because pair44 isn't up yet.  I realize "patch pair44" isn't
> required, it is an artifact from the typo that took 6 days to
> discover.

/etc/netstart should create the pair interfaces before they're
configured. that's done in this bit of the file:

1.195 rpe   396:# Create all the pseudo interfaces up front.
1.191 dlg   397: vifscreate

and then they get configured via the ifmstart line just under this:

399: # Configure all the non-loopback interfaces which we 
know about, but
1.127 deraadt   400: # do not start interfaces which must be delayed. Refer 
to hostname.if(5)
1.217 dlg   401: ifmstart "" "aggr trunk svlan vlan carp pppoe tun tap 
gif etherip gre egre nvgre eoip vxlan pflow wg"

you should read line 401 as "start everything except aggr, trunk,
svlan, etc".

> > > lladdr 00:00:C0:44:00:44
> > > inet 10.1.1.1/31
> > > up
> > > !ifconfig pair0 patch pair44
> >
> > and the above would just do the same again as 'patch pair0'
> >
> > > !route -q -T 0 add -inet 44.31.83.0/24 10.1.1.1
> >
> > So not much to reduce - yet that extra !ifconfig could be painful when
> > you start changing things inconsistently
> > --
> > pb
> 
> yep, I should remove "!ifconfig pair0 patch pair44" from
> /etc/hostname.pair44 .  Because I want the route added when the pair
> comes up I have to be aware of consistent destroy / add interfaces.
> 
> thanks for your input,

you can also try rport(4) to replace pair(4) for p2p links between
rdomains.

> diana
> 
> 
> Virus-free.www.avg.com
> 
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> 



Re: pair(4) question

2025-03-30 Thread Philipp Buehler

Am 31.03.2025 03:49 schrieb David Gwynne:

you can also try rport(4) to replace pair(4) for p2p links between
rdomains.


Has been some years since i dug through all this - and rport is
pretty brand new , thanks for the hint. Unsure why no .Xr ..


PS: i would debate if I want a failed IP-config leading to an "up 
anyway",

but as an option, sure.

--
pb



Re: pair(4) question

2025-03-30 Thread Andrew Lemin
I had a similar issue years ago which I solved by putting 'up' as the first
line in the hostname.pairX files, so the pair interfaces come up without
any config first.

But that was probably even before the ordering improvements mentioned by
David above, and is probably not ideal anymore.

I used one rdomain for internal clients/VLAN, which has multipath default
routes pointing to a bunch of pair tunnels/patches. Each patch connects to
a different rdomain (with no physical interfaces attached) where I have
wireguard tunnel endpoints. This allows load balancing over multiple
wireguard or openvpn tunnels where tunnel addresses might overlap.
The tricky part was getting the tunnel daemon to use rdomain 0 for the
outer encrypted connection, but place the tunnel endpoint into different
rdomains for the clients.

So it does work, and it works really well. But I remember spending weeks
getting it to work ;)

Never knew about rport! will have to try that :)

Good luck



On Mon, 31 Mar 2025 at 14:57, Philipp Buehler <
e1c1bac6253dc54a1e89ddc046585...@posteo.net> wrote:

> Am 31.03.2025 03:49 schrieb David Gwynne:
> > you can also try rport(4) to replace pair(4) for p2p links between
> > rdomains.
>
> Has been some years since i dug through all this - and rport is
> pretty brand new , thanks for the hint. Unsure why no .Xr ..
>
>
> PS: i would debate if I want a failed IP-config leading to an "up
> anyway",
> but as an option, sure.
>
> --
> pb
>
>