Re: sysupgrade with latest snapshot: The directory '/home/_sysupgrade/' does not exist.

[Greg Thomas]

 "Have sysupgrade just do the right thing. For example, there could be
a _sysupgrade user in the systems /etc/passwd, whose $HOME would
indicate the preferred location for sets"

Holy fucking overkill.

On Sun, Sep 27, 2020 at 2:29 PM Why 42? The lists account. 
wrote:

>
> On Sun, Sep 27, 2020 at 04:25:58PM -0400, Ian Darwin wrote:
> > > ...
> > > after the download of the new sets and the reboot, I would have been
> > > prompted as to what to do i.e. Install, Upgrade, or Shell.  Then for a
> > > keyboard layout (e.g. de) and for the name of the disk containing
> OpenBSD
> > > (i.e. the system root partition) or "/").
> >
> > Something is wwrong here. That is not how sysupgrade works. Probably you
> > didn't install updated boot blocks and it has been failing to "switch
> > to bsd.upgrade" when rebooting after the download, and your latest
> > change installed the updated boot blocks, and now it is working.
>
> I am not sure about that.
>
> IMO probably the something wrong here is/was that after installing
> OpenBSD as a proof of concept (of a new desktop "daily driver" system) I
> subsequently added a second disk to provide more space, for my /home.
>
> At that time this new disk (an ssd) then became know as, or inherited,
> the name sd0, and the pre-existing nvme device with the OS became sd1.
>
> Since that time I have been able to sysupgrade many times without issue,
> other than that I had to manually respond to sysupgrade e.g. to specify
> which disk device held the OS.
>
> > Here you describe how sysupgrade normally works.
> Right, although what is new for me (I think) is to see this message:
> "Performing non-interactive upgrade..."
>
> > >  2. The upgrade then proceeds, however it fails to identify the
> > >  location of the newly downloaded sets. The error is: "The directory
> > >  '/home/_sysupgrade/' does not exist."
> >
> > I've never tried using a symlink to /home. Can you mount /home properly
> > and see if that works?
> Over many sysupgrades it has always been sufficent to manually respond
> that the sets are on disk, the disk is mounted and that the path to them
> is "/mnt/space/home/_sysupgrade".
>
> Sysupgrade does a nice job presenting the information needed e.g. what is
> mounted where.
>
> I'm not sure what you mean by "Can you mount /home properly". At the
> point were I am having the issue, sysupgrade is in charge, has rebooted
> the system and mounted things where it wants them. Unfortunately, it
> doesn't find the sets and then apparently promptly reboots the system.
>
> What I would like would be able to do (one of):
>  1. Interrupt the "non-interactive upgrade" somehow, so as to provide my
> own answers.
>
>  2. Figure out how to tell sysupgrade the right answers in advance i.e.
> via the auto_upgrade.conf mechanism
>
>  3. Have sysupgrade just do the right thing. For example, there could be
> a _sysupgrade user in the systems /etc/passwd, whose $HOME would
> indicate the preferred location for sets ... But best understand the
> problem before designing a solution :)
>
> I guess that is reverse order of preference :)
>
> Cheers,
> Robb.
>
>
> FYI: From the normal running system:
>
> mjoelnir% sysctl hw.disknames
> hw.disknames=sd0:7a1775fef773535e,sd1:281ef747da03afe7,sd2:67c92dad63883338
>
> mjoelnir% dmesg | grep targ
> ...
> scsibus0 at mpath0: 256 targets
> scsibus1 at ahci0: 32 targets
> sd0 at scsibus1 targ 2 lun 0: 
> naa.5002538e4109632a
> scsibus2 at nvme0: 2 targets, initiator 0
> sd1 at scsibus2 targ 1 lun 0: 
> scsibus3 at umass0: 2 targets, initiator 0
> sd2 at scsibus3 targ 1 lun 0: 
> serial.1058262039344E4B4E5A
> scsibus4 at vscsi0: 256 targets
> scsibus5 at softraid0: 256 targets
>
> mjoelnir% df -h
> Filesystem SizeUsed   Avail Capacity  Mounted on
> /dev/sd1a 1005M314M640M33%/
> mfs:6361   7.7G201K7.4G 0%/tmp
> /dev/sd1e 58.3G   92.6M   55.3G 0%/var
> /dev/sd1f  2.0G1.2G686M64%/usr
> /dev/sd1g 1005M251M703M26%/usr/X11R6
> /dev/sd1h 19.7G   11.0G7.7G59%/usr/local
> /dev/sd1k  5.9G2.0K5.6G 0%/usr/obj
> /dev/sd1j  2.0G2.0K1.9G 0%/usr/src
> /dev/sd1l  295G   10.0G271G 4%/fast
> /dev/sd0h  1.8T964G758G56%/space
>
> (sd2 is just a USB attached external Western Digital hard disk for
> backup.)
>
>

Re: Issues with TP-Link UE300

[Kevin Lo]

On Sun, Sep 27, 2020 at 11:43:13PM +0200, Joel Carnat wrote:
> 
> Hi,
> 
> I have plugged a TP-Link UE300 on my ThinkPad X260 running OpenBSD -snapshot
> and it seems I can't get more than 100Mbps.
> 
> The dongle attaches and get an IP address. But the speed seems limited.
> Same behaviour when attached to the USB3 port of my APU4D4 (running 6.7).
> When plugged in a MacBook Pro (running macos), it gets Gbps speed.
> 
> I have noticed that it gets attached to cdce0;
> I thought the RTL8153 chipset would give me an ure0 device.
> 
> Is this expected?
> Is there something I can do to get Gbps out of this device?

Please try this diff, thanks.

Index: sys/dev/usb/if_ure.c
===
RCS file: /cvs/src/sys/dev/usb/if_ure.c,v
retrieving revision 1.18
diff -u -p -u -p -r1.18 if_ure.c
--- sys/dev/usb/if_ure.c4 Aug 2020 14:45:46 -   1.18
+++ sys/dev/usb/if_ure.c28 Sep 2020 02:24:40 -
@@ -76,7 +76,8 @@ const struct usb_devno ure_devs[] = {
{ USB_VENDOR_LENOVO, USB_PRODUCT_LENOVO_DOCK_ETHERNET },
{ USB_VENDOR_REALTEK, USB_PRODUCT_REALTEK_RTL8152 },
{ USB_VENDOR_REALTEK, USB_PRODUCT_REALTEK_RTL8153 },
-   { USB_VENDOR_REALTEK, USB_PRODUCT_REALTEK_RTL8156 }
+   { USB_VENDOR_REALTEK, USB_PRODUCT_REALTEK_RTL8156 },
+   { USB_VENDOR_TPLINK, USB_PRODUCT_TPLINK_UE300 }
 };
 
 inture_match(struct device *, void *, void *);
Index: sys/dev/usb/usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.720
diff -u -p -u -p -r1.720 usbdevs
--- sys/dev/usb/usbdevs 3 Aug 2020 14:25:44 -   1.720
+++ sys/dev/usb/usbdevs 28 Sep 2020 02:24:40 -
@@ -4317,6 +4317,7 @@ product TPLINK RTL8192EU  0x0107  RTL8192E
 product TPLINK RTL8192EU_2 0x0108  RTL8192EU
 product TPLINK RTL8192EU_3 0x0109  RTL8192EU
 product TPLINK RTL8188EUS  0x010c  RTL8188EUS
+product TPLINK UE300   0x0601  UE300 Ethernet
 
 /* Trek Technology products */
 product TREK THUMBDRIVE0x  ThumbDrive
Index: sys/dev/usb/usbdevs.h
===
RCS file: /cvs/src/sys/dev/usb/usbdevs.h,v
retrieving revision 1.732
diff -u -p -u -p -r1.732 usbdevs.h
--- sys/dev/usb/usbdevs.h   3 Aug 2020 14:25:56 -   1.732
+++ sys/dev/usb/usbdevs.h   28 Sep 2020 02:24:40 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs.h,v 1.732 2020/08/03 14:25:56 deraadt Exp $   */
+/* $OpenBSD$   */
 
 /*
  * THIS FILE IS AUTOMATICALLY GENERATED.  DO NOT EDIT.
@@ -4324,6 +4324,7 @@
 #defineUSB_PRODUCT_TPLINK_RTL8192EU_2  0x0108  /* RTL8192EU */
 #defineUSB_PRODUCT_TPLINK_RTL8192EU_3  0x0109  /* RTL8192EU */
 #defineUSB_PRODUCT_TPLINK_RTL8188EUS   0x010c  /* RTL8188EUS */
+#defineUSB_PRODUCT_TPLINK_UE3000x0601  /* UE300 
Ethernet */
 
 /* Trek Technology products */
 #defineUSB_PRODUCT_TREK_THUMBDRIVE 0x  /* ThumbDrive */
Index: sys/dev/usb/usbdevs_data.h
===
RCS file: /cvs/src/sys/dev/usb/usbdevs_data.h,v
retrieving revision 1.726
diff -u -p -u -p -r1.726 usbdevs_data.h
--- sys/dev/usb/usbdevs_data.h  3 Aug 2020 14:25:56 -   1.726
+++ sys/dev/usb/usbdevs_data.h  28 Sep 2020 02:24:40 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs_data.h,v 1.726 2020/08/03 14:25:56 deraadt Exp $  
*/
+/* $OpenBSD$   */
 
 /*
  * THIS FILE IS AUTOMATICALLY GENERATED.  DO NOT EDIT.
@@ -11068,6 +11068,10 @@ const struct usb_known_product usb_known
{
USB_VENDOR_TPLINK, USB_PRODUCT_TPLINK_RTL8188EUS,
"RTL8188EUS",
+   },
+   {
+   USB_VENDOR_TPLINK, USB_PRODUCT_TPLINK_UE300,
+   "UE300 Ethernet",
},
{
USB_VENDOR_TREK, USB_PRODUCT_TREK_THUMBDRIVE,

Re: Issues with TP-Link UE300

[Theo de Raadt]

In other words, you don't know but are very eager to use your mail client
right now.


Torsten  wrote:

> Sorry
> 
> Still connected to USB, I looked it up before replying
> 
> It looks more like a hardware design issue of the device it is connected to 
> plus many other issues related to the “Dongle” itself.
> 
>  
> 
> T 
> 
>  
> 
>  
> 
> From: Joel Carnat  
> Sent: 28 September 2020 00:21
> To: Torsten 
> Cc: misc@openbsd.org
> Subject: Re: Issues with TP-Link UE300
> 
>  
> 
> Well, this is no wifi device. This is an ethernet dongle.
> 
> That particular one:
> 
> https://www.tp-link.com/en/home-networking/computer-accessory/ue300/
> 
> Envoyé de mon iPad
> 
> 
> 
> 
> 
> Le 28 sept. 2020 à 00:55, Torsten   > a écrit :
> 
> HI
> As far as I can tell, WiFi is nominal speed, not designated speed
> Another dominating factors for that would be USB connection type, hardware 
> bus connections, motherboard design, direct processor lanes to where
> 
> Wifi is what it is, never as good as hard wired 100mb/1000mb or even 10gb 
> connections
> 
> Best
> T 
> 
> -Original Message-
> From: owner-m...@openbsd.org   
> mailto:owner-m...@openbsd.org> > On Behalf Of Joel 
> Carnat
> Sent: 27 September 2020 22:43
> To: misc@openbsd.org  
> Subject: Issues with TP-Link UE300
> 
> Hi,
> 
> I have plugged a TP-Link UE300 on my ThinkPad X260 running OpenBSD -snapshot 
> and it seems I can't get more than 100Mbps.
> 
> The dongle attaches and get an IP address. But the speed seems limited.
> Same behaviour when attached to the USB3 port of my APU4D4 (running 6.7).
> When plugged in a MacBook Pro (running macos), it gets Gbps speed.
> 
> I have noticed that it gets attached to cdce0; I thought the RTL8153 chipset 
> would give me an ure0 device.
> 
> Is this expected?
> Is there something I can do to get Gbps out of this device?
> 
> Thanks for help,
> Jo
> 
> --
> OpenBSD 6.8 (GENERIC.MP) #85: Sun Sep 27 13:39:51 MDT 2020
> 
> cdce0 at uhub0 port 15 configuration 2 interface 0 "TP-LINK USB 10/100/1000 
> LAN" rev 3.00/30.00 addr 4
> 
> # doas usbdevs -v 
>  
> Controller /dev/usb0:
> addr 01: 8086: Intel, xHCI root hub
> super speed, self powered, config 1, rev 1.00
> driver: uhub0
> addr 02: 8087:0a2b Intel, Bluetooth
> full speed, self powered, config 1, rev 0.01
> driver: ugen0
> addr 03: 5986:0706 SunplusIT Inc, Integrated Camera
> high speed, power 500 mA, config 1, rev 0.12
> driver: uvideo0
> addr 04: 2357:0601 TP-LINK, USB 10/100/1000 LAN
> super speed, power 64 mA, config 2, rev 30.00, iSerial 0100
> driver: cdce0
> 
> 
> 

Re: Issues with TP-Link UE300

[Torsten]

Sorry

Still connected to USB, I looked it up before replying

It looks more like a hardware design issue of the device it is connected to 
plus many other issues related to the “Dongle” itself.

 

T 

 

 

From: Joel Carnat  
Sent: 28 September 2020 00:21
To: Torsten 
Cc: misc@openbsd.org
Subject: Re: Issues with TP-Link UE300

 

Well, this is no wifi device. This is an ethernet dongle.

That particular one:

https://www.tp-link.com/en/home-networking/computer-accessory/ue300/

Envoyé de mon iPad





Le 28 sept. 2020 à 00:55, Torsten mailto:tors...@cnc-london.net> > a écrit :

HI
As far as I can tell, WiFi is nominal speed, not designated speed
Another dominating factors for that would be USB connection type, hardware bus 
connections, motherboard design, direct processor lanes to where

Wifi is what it is, never as good as hard wired 100mb/1000mb or even 10gb 
connections

Best
T 

-Original Message-
From: owner-m...@openbsd.org   
mailto:owner-m...@openbsd.org> > On Behalf Of Joel 
Carnat
Sent: 27 September 2020 22:43
To: misc@openbsd.org  
Subject: Issues with TP-Link UE300

Hi,

I have plugged a TP-Link UE300 on my ThinkPad X260 running OpenBSD -snapshot 
and it seems I can't get more than 100Mbps.

The dongle attaches and get an IP address. But the speed seems limited.
Same behaviour when attached to the USB3 port of my APU4D4 (running 6.7).
When plugged in a MacBook Pro (running macos), it gets Gbps speed.

I have noticed that it gets attached to cdce0; I thought the RTL8153 chipset 
would give me an ure0 device.

Is this expected?
Is there something I can do to get Gbps out of this device?

Thanks for help,
Jo

--
OpenBSD 6.8 (GENERIC.MP) #85: Sun Sep 27 13:39:51 MDT 2020

cdce0 at uhub0 port 15 configuration 2 interface 0 "TP-LINK USB 10/100/1000 
LAN" rev 3.00/30.00 addr 4

# doas usbdevs -v   
   
Controller /dev/usb0:
addr 01: 8086: Intel, xHCI root hub
super speed, self powered, config 1, rev 1.00
driver: uhub0
addr 02: 8087:0a2b Intel, Bluetooth
full speed, self powered, config 1, rev 0.01
driver: ugen0
addr 03: 5986:0706 SunplusIT Inc, Integrated Camera
high speed, power 500 mA, config 1, rev 0.12
driver: uvideo0
addr 04: 2357:0601 TP-LINK, USB 10/100/1000 LAN
super speed, power 64 mA, config 2, rev 30.00, iSerial 0100
driver: cdce0

Re: Issues with TP-Link UE300

[Joel Carnat]

Well, this is no wifi device. This is an ethernet dongle.
That particular one:
https://www.tp-link.com/en/home-networking/computer-accessory/ue300/

Envoyé de mon iPad

> Le 28 sept. 2020 à 00:55, Torsten  a écrit :
> 
> HI
> As far as I can tell, WiFi is nominal speed, not designated speed
> Another dominating factors for that would be USB connection type, hardware 
> bus connections, motherboard design, direct processor lanes to where
> 
> Wifi is what it is, never as good as hard wired 100mb/1000mb or even 10gb 
> connections
> 
> Best
> T 
> 
> -Original Message-
> From: owner-m...@openbsd.org  On Behalf Of Joel Carnat
> Sent: 27 September 2020 22:43
> To: misc@openbsd.org
> Subject: Issues with TP-Link UE300
> 
> Hi,
> 
> I have plugged a TP-Link UE300 on my ThinkPad X260 running OpenBSD -snapshot 
> and it seems I can't get more than 100Mbps.
> 
> The dongle attaches and get an IP address. But the speed seems limited.
> Same behaviour when attached to the USB3 port of my APU4D4 (running 6.7).
> When plugged in a MacBook Pro (running macos), it gets Gbps speed.
> 
> I have noticed that it gets attached to cdce0; I thought the RTL8153 chipset 
> would give me an ure0 device.
> 
> Is this expected?
> Is there something I can do to get Gbps out of this device?
> 
> Thanks for help,
> Jo
> 
> --
> OpenBSD 6.8 (GENERIC.MP) #85: Sun Sep 27 13:39:51 MDT 2020
> 
> cdce0 at uhub0 port 15 configuration 2 interface 0 "TP-LINK USB 10/100/1000 
> LAN" rev 3.00/30.00 addr 4
> 
> # doas usbdevs -v 
>  
> Controller /dev/usb0:
> addr 01: 8086: Intel, xHCI root hub
> super speed, self powered, config 1, rev 1.00
> driver: uhub0
> addr 02: 8087:0a2b Intel, Bluetooth
> full speed, self powered, config 1, rev 0.01
> driver: ugen0
> addr 03: 5986:0706 SunplusIT Inc, Integrated Camera
> high speed, power 500 mA, config 1, rev 0.12
> driver: uvideo0
> addr 04: 2357:0601 TP-LINK, USB 10/100/1000 LAN
> super speed, power 64 mA, config 2, rev 30.00, iSerial 0100
> driver: cdce0
> 
> 

Re: Issues with TP-Link UE300

[Torsten]

HI
As far as I can tell, WiFi is nominal speed, not designated speed
Another dominating factors for that would be USB connection type, hardware bus 
connections, motherboard design, direct processor lanes to where

Wifi is what it is, never as good as hard wired 100mb/1000mb or even 10gb 
connections

Best
T 

-Original Message-
From: owner-m...@openbsd.org  On Behalf Of Joel Carnat
Sent: 27 September 2020 22:43
To: misc@openbsd.org
Subject: Issues with TP-Link UE300

Hi,

I have plugged a TP-Link UE300 on my ThinkPad X260 running OpenBSD -snapshot 
and it seems I can't get more than 100Mbps.

The dongle attaches and get an IP address. But the speed seems limited.
Same behaviour when attached to the USB3 port of my APU4D4 (running 6.7).
When plugged in a MacBook Pro (running macos), it gets Gbps speed.

I have noticed that it gets attached to cdce0; I thought the RTL8153 chipset 
would give me an ure0 device.

Is this expected?
Is there something I can do to get Gbps out of this device?

Thanks for help,
Jo

--
OpenBSD 6.8 (GENERIC.MP) #85: Sun Sep 27 13:39:51 MDT 2020

cdce0 at uhub0 port 15 configuration 2 interface 0 "TP-LINK USB 10/100/1000 
LAN" rev 3.00/30.00 addr 4

# doas usbdevs -v   
   
Controller /dev/usb0:
addr 01: 8086: Intel, xHCI root hub
 super speed, self powered, config 1, rev 1.00
 driver: uhub0
addr 02: 8087:0a2b Intel, Bluetooth
 full speed, self powered, config 1, rev 0.01
 driver: ugen0
addr 03: 5986:0706 SunplusIT Inc, Integrated Camera
 high speed, power 500 mA, config 1, rev 0.12
 driver: uvideo0
addr 04: 2357:0601 TP-LINK, USB 10/100/1000 LAN
 super speed, power 64 mA, config 2, rev 30.00, iSerial 0100
 driver: cdce0

Issues with TP-Link UE300

[Joel Carnat]

Hi,

I have plugged a TP-Link UE300 on my ThinkPad X260 running OpenBSD -snapshot
and it seems I can't get more than 100Mbps.

The dongle attaches and get an IP address. But the speed seems limited.
Same behaviour when attached to the USB3 port of my APU4D4 (running 6.7).
When plugged in a MacBook Pro (running macos), it gets Gbps speed.

I have noticed that it gets attached to cdce0;
I thought the RTL8153 chipset would give me an ure0 device.

Is this expected?
Is there something I can do to get Gbps out of this device?

Thanks for help,
Jo

--
OpenBSD 6.8 (GENERIC.MP) #85: Sun Sep 27 13:39:51 MDT 2020

cdce0 at uhub0 port 15 configuration 2 interface 0 "TP-LINK USB 10/100/1000 
LAN" rev 3.00/30.00 addr 4

# doas usbdevs -v   
   
Controller /dev/usb0:
addr 01: 8086: Intel, xHCI root hub
 super speed, self powered, config 1, rev 1.00
 driver: uhub0
addr 02: 8087:0a2b Intel, Bluetooth
 full speed, self powered, config 1, rev 0.01
 driver: ugen0
addr 03: 5986:0706 SunplusIT Inc, Integrated Camera
 high speed, power 500 mA, config 1, rev 0.12
 driver: uvideo0
addr 04: 2357:0601 TP-LINK, USB 10/100/1000 LAN
 super speed, power 64 mA, config 2, rev 30.00, iSerial 0100
 driver: cdce0

Re: sysupgrade with latest snapshot: The directory '/home/_sysupgrade/' does not exist.

[Theo de Raadt]

Stuart Henderson  wrote:

> >  3. Have sysupgrade just do the right thing. For example, there could be
> > a _sysupgrade user in the systems /etc/passwd, whose $HOME would
> > indicate the preferred location for sets ... But best understand the
> > problem before designing a solution :)
> >
> > I guess that is reverse order of preference :)
> 
> There have been proposals (probably either here or on the tech@ list) to
> allow changing the path before, but IIRC not a robust diff to do this yet
> (problems with proposals included removing files that should not be
> removed under certain bad input).

The correct proposal is:

 Install your machines in a normal way.

It is not unreasonable.

Re: sysupgrade with latest snapshot: The directory '/home/_sysupgrade/' does not exist.

[Stuart Henderson]

On 2020-09-27, Why 42? The lists account.  wrote:
>
> On Sun, Sep 27, 2020 at 04:25:58PM -0400, Ian Darwin wrote:
>> > ...
>> > after the download of the new sets and the reboot, I would have been
>> > prompted as to what to do i.e. Install, Upgrade, or Shell.  Then for a
>> > keyboard layout (e.g. de) and for the name of the disk containing OpenBSD
>> > (i.e. the system root partition) or "/").
>> 
>> Something is wwrong here. That is not how sysupgrade works. Probably you
>> didn't install updated boot blocks and it has been failing to "switch
>> to bsd.upgrade" when rebooting after the download, and your latest
>> change installed the updated boot blocks, and now it is working.
>  
> I am not sure about that.
>
> IMO probably the something wrong here is/was that after installing
> OpenBSD as a proof of concept (of a new desktop "daily driver" system) I
> subsequently added a second disk to provide more space, for my /home.
>
> At that time this new disk (an ssd) then became know as, or inherited,
> the name sd0, and the pre-existing nvme device with the OS became sd1.
>
> Since that time I have been able to sysupgrade many times without issue,
> other than that I had to manually respond to sysupgrade e.g. to specify
> which disk device held the OS.
>  
>> Here you describe how sysupgrade normally works.
> Right, although what is new for me (I think) is to see this message:
> "Performing non-interactive upgrade..."

The non-interactive upgrade is normal for sysupgrade. If working correctly
it should not ask any questions, there should be nothing to type. It just
runs through the installer in upgrade mode automatically and reboots at
the end.

>> >  2. The upgrade then proceeds, however it fails to identify the
>> >  location of the newly downloaded sets. The error is: "The directory
>> >  '/home/_sysupgrade/' does not exist."
>>
>> I've never tried using a symlink to /home. Can you mount /home properly
>> and see if that works?
> Over many sysupgrades it has always been sufficent to manually respond
> that the sets are on disk, the disk is mounted and that the path to them
> is "/mnt/space/home/_sysupgrade".
>
> Sysupgrade does a nice job presenting the information needed e.g. what is
> mounted where.
>
> I'm not sure what you mean by "Can you mount /home properly". At the
> point were I am having the issue, sysupgrade is in charge, has rebooted
> the system and mounted things where it wants them. Unfortunately, it
> doesn't find the sets and then apparently promptly reboots the system.
>
> What I would like would be able to do (one of):
>  1. Interrupt the "non-interactive upgrade" somehow, so as to provide my
> own answers.

For that you would normally download sets and boot to bsd.rd yourself,
the point of sysupgrade is really for non-interactive use.

>  2. Figure out how to tell sysupgrade the right answers in advance i.e.
> via the auto_upgrade.conf mechanism

This is fairly easy:

sysupgrade -s -n
vi /auto_upgrade.conf, edit "Pathname to the sets"
reboot

>  3. Have sysupgrade just do the right thing. For example, there could be
> a _sysupgrade user in the systems /etc/passwd, whose $HOME would
> indicate the preferred location for sets ... But best understand the
> problem before designing a solution :)
>
> I guess that is reverse order of preference :)

There have been proposals (probably either here or on the tech@ list) to
allow changing the path before, but IIRC not a robust diff to do this yet
(problems with proposals included removing files that should not be
removed under certain bad input).

Re: pf and Wireguard

[Stuart Henderson]

On 2020-09-26, Jan Betlach  wrote:
>
> Hi,
>
> I’ve setup Wireguard on my home router running -current.
> The tunnel works, I have access to my LAN resources ONLY in case pf is 
> disabled. When I enable pf, Wireguard connects, does handshakes, however 
> I cannot even ping the router nor access anything in the network.
>
> So that it seems my rules in pf are the reason. I admit I am a novice in 
> respect with pf. Therefore I’d like to ask you to help or direct me to 
> a solution.
>
> My pf rules are pretty easy, basically taken from FAQ - building a 
> router. Here they are:
>
> wan="em0"
> lan="em1"
> localnet=$lan:network
> table  { 0.0.0.0/8 10.0.0.0/8 127.0.0.0/8 169.254.0.0/16 \
>  172.16.0.0/12 192.0.0.0/24 192.0.2.0/24 224.0.0.0/3 \
>  192.168.0.0/16 198.18.0.0/15 198.51.100.0/24\
>  203.0.113.0/24 }
> set skip on lo0
> set block-policy drop
> set loginterface egress
> match in all scrub (no-df random-id max-mss 1440)
> match out on egress inet from !(egress:network) to any nat-to (egress:0)
> antispoof quick for { egress $lan }
> block in quick on egress from  to any
> block return out quick on egress from any to 
> block all
> pass out quick inet keep state
> pass in on { $lan } inet keep state
> pass in proto udp from any to any port XXX keep state
> match out on egress from (wg0:network) to any nat-to (egress:0)

One thing I've noticed, you "pass out quick" so outbound traffic
"short circuits" the rest of the ruleset, then later have a second
match...nat-to which is unreached by outbound traffic. Though that
should be a noop anyway because you ahve the earlier "match out on
egress inet from !(egress:network)" which I think already will have
natted the relevant traffic.

Another, the only *inbound* traffic you allow is on $lan or udp to
some port; there's no rule to pass inbound (encapsulated) traffic
from the wireguard interface, only the wireguard tunnel itself.
So you probably want "pass in on wg0" or something.

Re: sysupgrade with latest snapshot: The directory '/home/_sysupgrade/' does not exist.

[Theo de Raadt]

Theo de Raadt  wrote:

> sysupgrade cannot handle strange setups.  By the time we started
> building it, there weren't enough free bytes left in bsd.rd to
> embed an AI to come with the crazy shit people do.

to cope with, I mean.

Q. "bsd.rd, can you come to my house and fix this?"
A. "No."

Re: sysupgrade with latest snapshot: The directory '/home/_sysupgrade/' does not exist.

[Theo de Raadt]

Why 42? The lists account.  wrote:


> On Sun, Sep 27, 2020 at 04:25:58PM -0400, Ian Darwin wrote:
> > > ...
> > > after the download of the new sets and the reboot, I would have been
> > > prompted as to what to do i.e. Install, Upgrade, or Shell.  Then for a
> > > keyboard layout (e.g. de) and for the name of the disk containing OpenBSD
> > > (i.e. the system root partition) or "/").
> > 
> > Something is wwrong here. That is not how sysupgrade works. Probably you
> > didn't install updated boot blocks and it has been failing to "switch
> > to bsd.upgrade" when rebooting after the download, and your latest
> > change installed the updated boot blocks, and now it is working.
>  
> I am not sure about that.

Your system is layed out strangely and sysupgrade cannot handle all
absurd layouts.

You can go back to manual upgrades.  Or you can reinstall your system
to look more normal.


sysupgrade cannot handle strange setups.  By the time we started
building it, there weren't enough free bytes left in bsd.rd to
embed an AI to come with the crazy shit people do.

Re: sysupgrade with latest snapshot: The directory '/home/_sysupgrade/' does not exist.

[Why 42? The lists account.]

On Sun, Sep 27, 2020 at 04:25:58PM -0400, Ian Darwin wrote:
> > ...
> > after the download of the new sets and the reboot, I would have been
> > prompted as to what to do i.e. Install, Upgrade, or Shell.  Then for a
> > keyboard layout (e.g. de) and for the name of the disk containing OpenBSD
> > (i.e. the system root partition) or "/").
> 
> Something is wwrong here. That is not how sysupgrade works. Probably you
> didn't install updated boot blocks and it has been failing to "switch
> to bsd.upgrade" when rebooting after the download, and your latest
> change installed the updated boot blocks, and now it is working.
 
I am not sure about that.

IMO probably the something wrong here is/was that after installing
OpenBSD as a proof of concept (of a new desktop "daily driver" system) I
subsequently added a second disk to provide more space, for my /home.

At that time this new disk (an ssd) then became know as, or inherited,
the name sd0, and the pre-existing nvme device with the OS became sd1.

Since that time I have been able to sysupgrade many times without issue,
other than that I had to manually respond to sysupgrade e.g. to specify
which disk device held the OS.
 
> Here you describe how sysupgrade normally works.
Right, although what is new for me (I think) is to see this message:
"Performing non-interactive upgrade..."
 
> >  2. The upgrade then proceeds, however it fails to identify the
> >  location of the newly downloaded sets. The error is: "The directory
> >  '/home/_sysupgrade/' does not exist."
>
> I've never tried using a symlink to /home. Can you mount /home properly
> and see if that works?
Over many sysupgrades it has always been sufficent to manually respond
that the sets are on disk, the disk is mounted and that the path to them
is "/mnt/space/home/_sysupgrade".

Sysupgrade does a nice job presenting the information needed e.g. what is
mounted where.

I'm not sure what you mean by "Can you mount /home properly". At the
point were I am having the issue, sysupgrade is in charge, has rebooted
the system and mounted things where it wants them. Unfortunately, it
doesn't find the sets and then apparently promptly reboots the system.

What I would like would be able to do (one of):
 1. Interrupt the "non-interactive upgrade" somehow, so as to provide my
own answers.

 2. Figure out how to tell sysupgrade the right answers in advance i.e.
via the auto_upgrade.conf mechanism

 3. Have sysupgrade just do the right thing. For example, there could be
a _sysupgrade user in the systems /etc/passwd, whose $HOME would
indicate the preferred location for sets ... But best understand the
problem before designing a solution :)

I guess that is reverse order of preference :)

Cheers,
Robb.


FYI: From the normal running system:

mjoelnir% sysctl hw.disknames
hw.disknames=sd0:7a1775fef773535e,sd1:281ef747da03afe7,sd2:67c92dad63883338

mjoelnir% dmesg | grep targ
...
scsibus0 at mpath0: 256 targets
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 2 lun 0:  naa.5002538e4109632a
scsibus2 at nvme0: 2 targets, initiator 0
sd1 at scsibus2 targ 1 lun 0: 
scsibus3 at umass0: 2 targets, initiator 0
sd2 at scsibus3 targ 1 lun 0:  
serial.1058262039344E4B4E5A
scsibus4 at vscsi0: 256 targets
scsibus5 at softraid0: 256 targets

mjoelnir% df -h
Filesystem SizeUsed   Avail Capacity  Mounted on
/dev/sd1a 1005M314M640M33%/
mfs:6361   7.7G201K7.4G 0%/tmp
/dev/sd1e 58.3G   92.6M   55.3G 0%/var
/dev/sd1f  2.0G1.2G686M64%/usr
/dev/sd1g 1005M251M703M26%/usr/X11R6
/dev/sd1h 19.7G   11.0G7.7G59%/usr/local
/dev/sd1k  5.9G2.0K5.6G 0%/usr/obj
/dev/sd1j  2.0G2.0K1.9G 0%/usr/src
/dev/sd1l  295G   10.0G271G 4%/fast
/dev/sd0h  1.8T964G758G56%/space

(sd2 is just a USB attached external Western Digital hard disk for
backup.)

Re: sysupgrade with latest snapshot: The directory '/home/_sysupgrade/' does not exist.

[Ian Darwin]

On Sun, Sep 27, 2020 at 08:14:13PM +0200, Why 42? The lists account. wrote:
> 
> I am running:
> kern.version=OpenBSD 6.8-beta (GENERIC.MP) #69: Tue Sep 15 12:34:41 MDT 2020
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> I just tried to use sysupgrade and I notice that its behaviour has
> changed a bit since my last upgrade. Previously (last six months or so)
> after the download of the new sets and the reboot, I would have been
> prompted as to what to do i.e. Install, Upgrade, or Shell.  Then for a
> keyboard layout (e.g. de) and for the name of the disk containing OpenBSD
> (i.e. the system root partition) or "/").

Something is wwrong here. That is not how sysupgrade works. Probably you
didn't install updated boot blocks and it has been failing to "switch
to bsd.upgrade" when rebooting after the download, and your latest
change installed the updated boot blocks, and now it is working.

>  1. Now on the console I see (post reboot):

Here you describe how sysupgrade normally works.

>  2. The upgrade then proceeds, however it fails to identify the location
> of the newly downloaded sets. The error is:
> "The directory '/home/_sysupgrade/' does not exist."
> 
>  3. It then seems to abort the upgrade and reboot the system. Thus
> leaving me back where I started.

I've never tried using a symlink to /home. Can you mount /home properly and
see if that works?

sysupgrade with latest snapshot: The directory '/home/_sysupgrade/' does not exist.

[Why 42? The lists account.]

Hi All,

I am running:
kern.version=OpenBSD 6.8-beta (GENERIC.MP) #69: Tue Sep 15 12:34:41 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

I just tried to use sysupgrade and I notice that its behaviour has
changed a bit since my last upgrade. Previously (last six months or so)
after the download of the new sets and the reboot, I would have been
prompted as to what to do i.e. Install, Upgrade, or Shell.  Then for a
keyboard layout (e.g. de) and for the name of the disk containing OpenBSD
(i.e. the system root partition) or "/").
 
 1. Now on the console I see (post reboot):
"Performing non-interactive upgrade..."
It automatically selects a "root" disk, and in my case it correctly
selects sd1. which is great.

 2. The upgrade then proceeds, however it fails to identify the location
of the newly downloaded sets. The error is:
"The directory '/home/_sysupgrade/' does not exist."

 3. It then seems to abort the upgrade and reboot the system. Thus
leaving me back where I started.

 4. I get an excellent log via email of sysupgrades actions (see below).

The sets are (or at least they were) present on disk, located in
/space/home/_sysupgrade. There is also a symlink from /home/_sysupgrade
to this directory.

Sysupgrade has this partition mounted as "/mnt/space".

How can I best tell sysupgrade where to find the sets?

According to the man page for autoinstall it seems as if I should be able
control it with an upgrade response file e.g. previous sysupgrade runs
sent this sample/example via email:
> Which disk is the root disk = sd1
> Force checking of clean non-root filesystems = no
> Location of sets = disk
> Is the disk partition already mounted = yes
> Pathname to the sets = /mnt/space/home/_sysupgrade
> Set name(s) = done
> Directory does not contain SHA256.sig. Continue without verification = yes
> Location of sets = done

But what I am missing is how to supply the response file to sysupgrade.
In the above man page it states "... If either /auto_install.conf or
/auto_upgrade.conf is found on bsd.rd's built-in RAM disk,"

But how do I get the file into the .rd RAM disk? Or should I put it
somewhere else entirely? This is a (snapshot) upgrade, not an complete
install.

The man page also mentions serving it up via the network, using http and
dhcp, but that would require another running system.

Or, can I somehow tell sysupgrade _not_ to automatically run, but rather
interrupt it so as to manually provide the right answers (path)?

Cheers,
Robb.


Email content:
...
Subject: mjoelnir.domain.tld upgrade log

Choose your keyboard layout ('?' or 'L' for list) [default] default
Available disks are: sd0 sd1.
Which disk is the root disk? ('?' for details) [sd0] sd1
Checking root filesystem (fsck -fp /dev/sd1a)... OK.
Mounting root filesystem (mount -o ro /dev/sd1a /mnt)... OK.
Force checking of clean non-root filesystems? [no] no
fsck -p 281ef747da03afe7.e... OK.
fsck -p 281ef747da03afe7.f... OK.
fsck -p 281ef747da03afe7.g... OK.
fsck -p 281ef747da03afe7.h... OK.
fsck -p 281ef747da03afe7.k... OK.
fsck -p 281ef747da03afe7.j... OK.
fsck -p 281ef747da03afe7.l... OK.
fsck -p 7a1775fef773535e.h... OK.
/dev/sd1a (281ef747da03afe7.a) on /mnt type ffs (rw, local)
/dev/sd1e (281ef747da03afe7.e) on /mnt/var type ffs (rw, local, nodev, nosuid)
/dev/sd1f (281ef747da03afe7.f) on /mnt/usr type ffs (rw, local, nodev)
/dev/sd1g (281ef747da03afe7.g) on /mnt/usr/X11R6 type ffs (rw, local, nodev)
/dev/sd1h (281ef747da03afe7.h) on /mnt/usr/local type ffs (rw, local, nodev, 
wxallowed)
/dev/sd1k (281ef747da03afe7.k) on /mnt/usr/obj type ffs (rw, local, nodev, 
nosuid)
/dev/sd1j (281ef747da03afe7.j) on /mnt/usr/src type ffs (rw, local, nodev, 
nosuid)
/dev/sd1l (281ef747da03afe7.l) on /mnt/fast type ffs (rw, local, nodev, nosuid)
/dev/sd0h (7a1775fef773535e.h) on /mnt/space type ffs (rw, local)

Let's upgrade the sets!
Location of sets? (disk http nfs or 'done') [http] disk
Is the disk partition already mounted? [yes] yes
Pathname to the sets? (or 'done') [6.8/amd64] /home/_sysupgrade/
The directory '/home/_sysupgrade/' does not exist.