Re: Query on openrsync(1)
Nick Holland writes: > 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. Thank you for taking the time to respond! So far, openrsysnc has indeed covered my requirements since they are rather simple. But it's good to know that the common rsync package exists in the ports, just in case. Your observation on -W is quite interesting; I'm going to explore that option further. -- Abhishek Chakravarti abhis...@taranjali.org | Kolkata, IN fifthestate.co.in | refpersys.org | taranjali.org
Can't start a pseudo terminal
I can't start pseudo terminals in the xfce4 desktop anymore, why??? The history is that I tried to get data from a Symcode barcode scanner which appeared with the device name /dev/wskbd3 in the dmesg command, but I did not get any data. No console could make connection to the barcode scanner. I made the mistake to try the same device name as the keyboard, and the cursor rushed forward. When I pressed a key then the character came in the pseudo terminal as long as I pressed the key. I rebooted the Raspberry Pi4 computer, and since then there is no possibility to start a pseudo terminal for me. A new installation of OpenBSD 7.2 current did not help. Best regards Freddy Fisker
Re: init: single user shell terminated, restarting
On 2023-01-15, Barry Grumbine wrote:
> In case someone else runs in to this, and bothers to check misc@
>
> In this commit:
> https://marc.info/?l=openbsd-cvs&m=167283731726983&w=2
>
> --execute-only (aka NX bit, aka XD bit, aka Data Execution Prevention)
> was turned on
NX ("no execute") is used with kernel protections that can prevent
memory which is mapped as being _writable_ from being executed. That afaik
didn't change recently (at least not on purpose?).
execute-only is something else, it relates to mappings which are
protected such that they _can_ be executed but not _read_. It's now used
on aarch64 and riscv64 in snapshots (not everything in ports has been
fixed to work with it yet). There's work towards using it on amd64 but
the necessary cpu feature is only available on fairly new AMD machines
and very (for my version of 'very') new Intel machines.
> On my ancient T520 I had to go in to BIOS and set:
> -> Security
> --> Memory Protection
> ---> Execution Prevention [Enable]
>
> Everything works just peachy now.
It would be interesting to figure out what is happening with your
system (e.g. which change actually broke things) - there's no way it can
be the commit you point out. That's "restore previous behaviour when
compiling the EFI boot loader on aarch64/riscv64 which had got changed
in a different diff".
Any idea whether the problem is just in ramdisk kernels or did it affect
normal boot e.g. GENERIC.MP as well?
Re: Issue with acpi0 on Intel NUC11TNHi3
On 1/15/23 21:01, Bradley Latus wrote: > Hello Stuart, > > I noticed that someone else had a similar issue on the openbsd-bugs list.. > https://marc.info/?l=openbsd-bugs&m=166497715729842&w=2 > > I was able to apply a patch I found from another user (Joe Miller) > which masks out > GPE_L6F messages and the problem was resolved. > https://gist.github.com/joemiller/9f5698c5634d4a93d101985dc5238365 > https://news.ycombinator.com/item?id=33279037 > > After applying his patch (removing the additional printing parts) > My system was restored to what should be expected. This also fixed the issue for me on a 4 port celeron box I picked up from Aliexpress in December. Running current from snapshots. Built a new kernel with the patch as in step 2 in release. Michael
Re: init: single user shell terminated, restarting
hello,
On 2023-01-16 10:23, Stuart Henderson wrote:
> On 2023-01-15, Barry Grumbine wrote:
> > In case someone else runs in to this, and bothers to check misc@
> >
> > In this commit:
> > https://marc.info/?l=openbsd-cvs&m=167283731726983&w=2
> >
> > --execute-only (aka NX bit, aka XD bit, aka Data Execution Prevention)
> > was turned on
>
> NX ("no execute") is used with kernel protections that can prevent
> memory which is mapped as being _writable_ from being executed. That afaik
> didn't change recently (at least not on purpose?).
>
> execute-only is something else, it relates to mappings which are
> protected such that they _can_ be executed but not _read_. It's now used
> on aarch64 and riscv64 in snapshots (not everything in ports has been
> fixed to work with it yet). There's work towards using it on amd64 but
> the necessary cpu feature is only available on fairly new AMD machines
> and very (for my version of 'very') new Intel machines.
>
> > On my ancient T520 I had to go in to BIOS and set:
> > -> Security
> > --> Memory Protection
> > ---> Execution Prevention [Enable]
> >
> > Everything works just peachy now.
>
> It would be interesting to figure out what is happening with your
> system (e.g. which change actually broke things) - there's no way it can
> be the commit you point out. That's "restore previous behaviour when
> compiling the EFI boot loader on aarch64/riscv64 which had got changed
> in a different diff".
>
> Any idea whether the problem is just in ramdisk kernels or did it affect
> normal boot e.g. GENERIC.MP as well?
I see this issue on my old Soekris net5501s as well. Using Barry's data
from above regarding dates I can confirm that the Janusary 6th snapshot
on hostserver.de's archive works, but trying to install the January 7th
snapshot results in the init message rolling until the system is power
cycled:
init: single user shell terminated, restarting
If I boot the January 7th bsd (with the January 6th userland) I see
the same behaviour as Barry reported if he upgraded using an older
bsd.rd, ie it gets to mounting the drives and then blows up:
root on wd0a (14df1105db104991.a) swap on wd0b dump on wd0b
init: /bin/sh on /etc/rc terminated abnormally, going to single user mode
Enter pathname of shell or RETURN for sh:
# ls
.cshrc boot bsd.rd home sys
.profile bsd bsd.upgrade mnt tmp
altroot bsd.booted dev root usr
bin bsd.jan7 etc sbin var
init: single user shell terminated, restarting
Enter pathname of shell or RETURN for sh:
# reboot
Here is dmesg with January 6th snapshot installed (where everything
works)
OpenBSD 7.2-current (GENERIC) #509: Thu Jan 5 08:26:46 MST 2023
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
real mem = 536363008 (511MB)
avail mem = 509444096 (485MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 20/71/05, BIOS32 rev. 0 @ 0xfac40
pcibios0 at bios0: rev 2.0 @ 0xf/0x1
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc8000/0xa800
cpu0 at mainbus0: (uniprocessor)
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 500
MHz, 05-0a-02
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
mtrr: K6-family MTRR support (2 registers)
amdmsr0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
0:20:0: io address conflict 0x6100/0x100
0:20:0: io address conflict 0x6200/0x200
pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x31
glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
vr0 at pci0 dev 6 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11, address
00:00:24:c9:58:4c
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063,
model 0x0034
vr1 at pci0 dev 7 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 5, address
00:00:24:c9:58:4d
ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063,
model 0x0034
vr2 at pci0 dev 8 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 9, address
00:00:24:c9:58:4e
ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063,
model 0x0034
vr3 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 12, address
00:00:24:c9:58:4f
ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, r
Re: init: single user shell terminated, restarting
kettenis figured out what the problem is.
There might be a solution tomorrow.
Johan Huldtgren wrote:
> hello,
>
> On 2023-01-16 10:23, Stuart Henderson wrote:
> > On 2023-01-15, Barry Grumbine wrote:
> > > In case someone else runs in to this, and bothers to check misc@
> > >
> > > In this commit:
> > > https://marc.info/?l=openbsd-cvs&m=167283731726983&w=2
> > >
> > > --execute-only (aka NX bit, aka XD bit, aka Data Execution Prevention)
> > > was turned on
> >
> > NX ("no execute") is used with kernel protections that can prevent
> > memory which is mapped as being _writable_ from being executed. That afaik
> > didn't change recently (at least not on purpose?).
> >
> > execute-only is something else, it relates to mappings which are
> > protected such that they _can_ be executed but not _read_. It's now used
> > on aarch64 and riscv64 in snapshots (not everything in ports has been
> > fixed to work with it yet). There's work towards using it on amd64 but
> > the necessary cpu feature is only available on fairly new AMD machines
> > and very (for my version of 'very') new Intel machines.
> >
> > > On my ancient T520 I had to go in to BIOS and set:
> > > -> Security
> > > --> Memory Protection
> > > ---> Execution Prevention [Enable]
> > >
> > > Everything works just peachy now.
> >
> > It would be interesting to figure out what is happening with your
> > system (e.g. which change actually broke things) - there's no way it can
> > be the commit you point out. That's "restore previous behaviour when
> > compiling the EFI boot loader on aarch64/riscv64 which had got changed
> > in a different diff".
> >
> > Any idea whether the problem is just in ramdisk kernels or did it affect
> > normal boot e.g. GENERIC.MP as well?
>
> I see this issue on my old Soekris net5501s as well. Using Barry's data
> from above regarding dates I can confirm that the Janusary 6th snapshot
> on hostserver.de's archive works, but trying to install the January 7th
> snapshot results in the init message rolling until the system is power
> cycled:
>
> init: single user shell terminated, restarting
>
> If I boot the January 7th bsd (with the January 6th userland) I see
> the same behaviour as Barry reported if he upgraded using an older
> bsd.rd, ie it gets to mounting the drives and then blows up:
>
> root on wd0a (14df1105db104991.a) swap on wd0b dump on wd0b
>
> init: /bin/sh on /etc/rc terminated abnormally, going to single user mode
>
> Enter pathname of shell or RETURN for sh:
>
> # ls
> .cshrc boot bsd.rd home sys
>
>
> .profile bsd bsd.upgrade mnt tmp
> altroot bsd.booted dev root usr
>
> bin bsd.jan7 etc sbin var
>
>
> init: single user shell terminated, restarting
> Enter pathname of shell or RETURN for sh:
> # reboot
>
> Here is dmesg with January 6th snapshot installed (where everything
> works)
>
> OpenBSD 7.2-current (GENERIC) #509: Thu Jan 5 08:26:46 MST 2023
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> real mem = 536363008 (511MB)
> avail mem = 509444096 (485MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 20/71/05, BIOS32 rev. 0 @ 0xfac40
> pcibios0 at bios0: rev 2.0 @ 0xf/0x1
> pcibios0: pcibios_get_intr_routing - function not supported
> pcibios0: PCI IRQ Routing information unavailable.
> pcibios0: PCI bus #0 is the last bus
> bios0: ROM list: 0xc8000/0xa800
> cpu0 at mainbus0: (uniprocessor)
> cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class)
> 500 MHz, 05-0a-02
> cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
> mtrr: K6-family MTRR support (2 registers)
> amdmsr0 at mainbus0
> pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
> 0:20:0: io address conflict 0x6100/0x100
> 0:20:0: io address conflict 0x6200/0x200
> pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x31
> glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
> vr0 at pci0 dev 6 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11, address
> 00:00:24:c9:58:4c
> ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr1 at pci0 dev 7 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 5, address
> 00:00:24:c9:58:4d
> ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr2 at pci0 dev 8 functi
Re: still struggling with dhcpcd and ipv6
I cannot comment on PPPoE, but I do know you have misspelled "persistent" in your dhcpcd.conf(5) file. I don't know if it will help, but you may try explicitly assigning an IAID to pppoe0 and perhaps use that same IAID for ia_na and ia_pd. You say you are delegated a /48, but you don't state how you know that. You may want to modify your ia_pd line and specify the prefix length to be delegated to you as well as the prefix lengths you want assigned to em0 and em1. For example, something like: interface pppoe0 iaid 0 ia_na 0 ia_pd 0/::/48 em0/0/64 em1/1/64 ipv6rs Note, if you want to use SLAAC for em0 and em1; then you need to add "/0" after "64" otherwise 1 will be used as your interface identifier. You may want to include the output of dhcpcd -U pppoe0 and perhaps a snippet of /var/log/daemon showing the exchange between dhcpcd and your ISP. You should probably include /etc/hostname.pppoe0 as well. You don't have "pass quick log on em1 all" in your pf(4) rules like you do with em0, so you may want to make sure IPv6 communication is not being blocked on it. Also, you may want to experiment with relaxing your ICMPv6 rules, at least temporarily. You appear to be allowing the necessary message types; but unless you know ICMPv6 well, you could be blocking more than you should. Finally, you may be overly restrictive with your DHCPv6 rules. For example, RFC 8415 says nothing about what _source_ ports clients and servers MUST use but only the _destination_ ports-a similar issue was addressed by Florian Obser in dhcpleased(8) (https://marc.info/?l=openbsd-bugs&m=163507791819694&w=2).
Re: init: single user shell terminated, restarting
Ha! This always happens. You guys are too good for a mere mortal like me.
Well I learned a little about cvs anyway.
Thanks for all you guys do!
I was actually trying to figure it out. Narrowed it down to one of these
three changes:
cvs -q diff -D"2023-01-05 12:00:00 MST" -D"2023-01-05 16:00:00 MST" -p src
Index: src/gnu/usr.bin/clang/clang/Makefile
===
RCS file: /cvs/src/gnu/usr.bin/clang/clang/Makefile,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -p -p -r1.17 -r1.18
--- src/gnu/usr.bin/clang/clang/Makefile 28 Apr 2021 12:55:37 - 1.17
+++ src/gnu/usr.bin/clang/clang/Makefile 5 Jan 2023 22:17:43 - 1.18
@@ -1,4 +1,4 @@
-# $OpenBSD: Makefile,v 1.17 2021/04/28 12:55:37 patrick Exp $
+# $OpenBSD: Makefile,v 1.18 2023/01/05 22:17:43 deraadt Exp $
.include
@@ -19,10 +19,13 @@ LINKS+= ${BINDIR}/clang ${BINDIR}/cc \
${BINDIR}/clang ${LIBEXECDIR}/cpp
maninstall:
+.if !defined(NOMAN)
cd ${DESTDIR}${MANDIR}1 && { \
rm -f cc.1 && ln clang.1 cc.1; \
rm -f c++.1 && ln clang.1 c++.1; \
rm -f cpp.1 && ln clang.1 cpp.1; }
+.endif
+
.endif
CPPFLAGS+= -I${.CURDIR}/../../../llvm/clang/include
Index: src/sys/arch/arm/arm/fault.c
===
RCS file: /cvs/src/sys/arch/arm/arm/fault.c,v
retrieving revision 1.46
retrieving revision 1.47
diff -u -p -p -r1.46 -r1.47
--- src/sys/arch/arm/arm/fault.c 2 Jan 2022 05:59:53 - 1.46
+++ src/sys/arch/arm/arm/fault.c 5 Jan 2023 20:35:44 - 1.47
@@ -1,4 +1,4 @@
-/* $OpenBSD: fault.c,v 1.46 2022/01/02 05:59:53 jsg Exp $ */
+/* $OpenBSD: fault.c,v 1.47 2023/01/05 20:35:44 kettenis Exp $ */
/* $NetBSD: fault.c,v 1.46 2004/01/21 15:39:21 skrll Exp $ */
/*
@@ -578,7 +578,7 @@ prefetch_abort_handler(trapframe_t *tf)
#endif
KERNEL_LOCK();
- error = uvm_fault(map, va, 0, PROT_READ | PROT_EXEC);
+ error = uvm_fault(map, va, 0, PROT_EXEC);
KERNEL_UNLOCK();
if (error == 0) {
Index: src/sys/kern/kern_exec.c
===
RCS file: /cvs/src/sys/kern/kern_exec.c,v
retrieving revision 1.240
retrieving revision 1.241
diff -u -p -p -r1.240 -r1.241
--- src/sys/kern/kern_exec.c 23 Nov 2022 11:00:27 - 1.240
+++ src/sys/kern/kern_exec.c 5 Jan 2023 21:39:57 - 1.241
@@ -1,4 +1,4 @@
-/* $OpenBSD: kern_exec.c,v 1.240 2022/11/23 11:00:27 mbuhl Exp $ */
+/* $OpenBSD: kern_exec.c,v 1.241 2023/01/05 21:39:57 deraadt Exp $ */
/* $NetBSD: kern_exec.c,v 1.75 1996/02/09 18:59:28 christos Exp $ */
/*-
@@ -826,9 +826,8 @@ exec_sigcode_map(struct process *pr)
* memory) that we keep a permanent reference to and that we map
* in all processes that need this sigcode. The creation is simple,
* we create an object, add a permanent reference to it, map it in
- * kernel space, copy out the sigcode to it and unmap it.
- * Then we map it with PROT_READ|PROT_EXEC into the process just
- * the way sys_mmap would map it.
+ * kernel space, copy out the sigcode to it and unmap it. Then we map
+ * it with PROT_EXEC into the process just the way sys_mmap would map it.
*/
if (sigobject == NULL) {
extern int sigfillsiz;
@@ -860,7 +859,7 @@ exec_sigcode_map(struct process *pr)
pr->ps_sigcode = 0; /* no hint */
uao_reference(sigobject);
if (uvm_map(&pr->ps_vmspace->vm_map, &pr->ps_sigcode, round_page(sz),
-sigobject, 0, 0, UVM_MAPFLAG(PROT_READ | PROT_EXEC,
+sigobject, 0, 0, UVM_MAPFLAG(PROT_EXEC,
PROT_READ | PROT_WRITE | PROT_EXEC, MAP_INHERIT_COPY,
MADV_RANDOM, UVM_FLAG_COPYONW | UVM_FLAG_SYSCALL))) {
uao_detach(sigobject);
On Mon, Jan 16, 2023 at 2:33 PM Theo de Raadt wrote:
> kettenis figured out what the problem is.
>
> There might be a solution tomorrow.
>
>
> Johan Huldtgren wrote:
>
> > hello,
> >
> > On 2023-01-16 10:23, Stuart Henderson wrote:
> > > On 2023-01-15, Barry Grumbine wrote:
> > > > In case someone else runs in to this, and bothers to check misc@
> > > >
> > > > In this commit:
> > > > https://marc.info/?l=openbsd-cvs&m=167283731726983&w=2
> > > >
> > > > --execute-only (aka NX bit, aka XD bit, aka Data Execution
> Prevention)
> > > > was turned on
> > >
> > > NX ("no execute") is used with kernel protections that can prevent
> > > memory which is mapped as being _writable_ from being executed. That
> afaik
> > > didn't change recently (at least not on purpose?).
> > >
> > > execute-only is something else, it relates to mappings which are
> > > protected such that they _can_ be executed but not _read_. It's now
> used
> > > on aarch64 and riscv64 in snapshots (not everything in ports has been
> > > fixed to work with it yet). There's work towards using it on amd64 but
> > > the necessary cpu feature is only available on fairly new AMD machines
> > > and very (for my version of 'very') new Intel machines.
> > >
> > > > On my ancient T520 I had to go in to BIOS and set:
> > > > -> Security
> > > > --> Memory Protection
> > > > ---> Executio
Crystal Kolipe
Crystal Kolipe, you sent me an email offlist about stuff I posted on misc@openbsd.org, and I tried to reply, it delayed for two days and then hard-failed. Could you please offlist email me an alternate address to which I can reply? I could find no way of contacting you on your website. I think you'll find my reply very constructive. Thanks, SteveT Steve Litt Autumn 2022 featured book: Thriving in Tough Times http://www.troubleshooters.com/bookstore/thrive.htm
Re: Crystal Kolipe
On Mon, Jan 16, 2023 at 07:25:21PM -0500, Steve Litt wrote: > Crystal Kolipe, you sent me an email offlist about stuff I posted on > misc@openbsd.org, and I tried to reply, it delayed for two days and > then hard-failed. Your email is being rejected because your mail server does not support TLS 1.3. This is a requirement to submit mail to our servers. Neither the original discussion nor this follow up is relevant to -misc, (which is why I replied off-list in the first place).
