[PATCH] sysupgrade
Hello,
This patch adds two new options to sysupgrade. The first option is for small
box systems like an APU system that only has the base and manual sets
installed. The second option is for headless systems without X11 like servers.
I have tested this patch from the 6.5 release to 6.6 release to current for
both the minimal and no X11 options. In order to test, I did remove the ftp -N
option which is not present in the 6.5 or 6.6 releases. I also tested
sysupgrade without invoking either new option from 6.5 to 6.6 to current for
regression. All of these tests resulted in a successful upgrade.
I also repeated the above tests from a full install to minimal and base
installs and, of course, the system is broken after such an upgrade. While it
is possible to check for the presence of clang or xinit to guess if the
requested upgrade is safe, I believe it would still only be a guess that
couldn't eliminate all the creative ways someone could break their
installation. If anyone has a suggestion for how to address this problem I am
willing to work on it and submit an updated patch.
Thank you to all the OpenBSD developers for the incredible work you do every
day on OpenBSD and for sharing your work.
James
Index: sysupgrade.sh
===
RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
retrieving revision 1.37
diff -u -p -u -p -r1.37 sysupgrade.sh
--- sysupgrade.sh 26 Jan 2020 22:08:36 - 1.37
+++ sysupgrade.sh 30 Apr 2020 03:07:15 -
@@ -34,7 +34,7 @@ ug_err()
usage()
{
- ug_err "usage: ${0##*/} [-fkn] [-r | -s] [installurl]"
+ ug_err "usage: ${0##*/} [-fkn] [-r | -s] [-x | -z] [installurl]"
}
unpriv()
@@ -78,14 +78,18 @@ SNAP=false
FORCE=false
KEEP=false
REBOOT=true
+NOX11=false
+MINIMAL=false
-while getopts fknrs arg; do
+while getopts fknrsxz arg; do
case ${arg} in
f) FORCE=true;;
k) KEEP=true;;
n) REBOOT=false;;
r) RELEASE=true;;
s) SNAP=true;;
+ x) NOX11=true;;
+ z) MINIMAL=true;;
*) usage;;
esac
done
@@ -96,6 +100,10 @@ if $RELEASE && $SNAP; then
usage
fi
+if $MINIMAL && $NOX11; then
+ usage
+fi
+
set -A _KERNV -- $(sysctl -n kern.version |
sed 's/^OpenBSD \([1-9][0-9]*\.[0-9]\)\([^ ]*\).*/\1 \2/;q')
@@ -152,9 +160,19 @@ if cmp -s /var/db/installed.SHA256 SHA25
exit 0
fi
+if $MINIMAL; then
+# INSTALL.*, bsd*, base*, man*
+ SETS=$(sed -n -e 's/^SHA256 (\(.*\)) .*/\1/' \
+ -e '/^INSTALL\./p;/^bsd/p;/^base/p;/^man/p' SHA256)
+elif $NOX11; then
+# INSTALL.*, bsd*, *.tgz without x*
+ SETS=$(sed -n -e 's/^SHA256 (\(.*\)) .*/\1/' \
+ -e '/^INSTALL\./p;/^bsd/p;/^x/d;/\.tgz$/p' SHA256)
+else
# INSTALL.*, bsd*, *.tgz
-SETS=$(sed -n -e 's/^SHA256 (\(.*\)) .*/\1/' \
--e '/^INSTALL\./p;/^bsd/p;/\.tgz$/p' SHA256)
+ SETS=$(sed -n -e 's/^SHA256 (\(.*\)) .*/\1/' \
+ -e '/^INSTALL\./p;/^bsd/p;/\.tgz$/p' SHA256)
+fi
OLD_FILES=$(ls)
OLD_FILES=$(rmel SHA256 $OLD_FILES)
Index: sysupgrade.8
===
RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.8,v
retrieving revision 1.10
diff -u -p -u -p -r1.10 sysupgrade.8
--- sysupgrade.83 Oct 2019 12:43:58 - 1.10
+++ sysupgrade.830 Apr 2020 03:07:30 -
@@ -24,6 +24,7 @@
.Nm
.Op Fl fkn
.Op Fl r | s
+.Op Fl x | z
.Op Ar installurl
.Sh DESCRIPTION
.Nm
@@ -66,6 +67,16 @@ This is the default if the system is cur
.It Fl s
Upgrade to a snapshot.
This is the default if the system is currently running a snapshot.
+.It Fl x
+Perform an upgrade of the kernel and all sets except the X11 sets.
+This option will render your system
+.Sy unusable
+if the current installation includes other sets.
+.It Fl z
+Perform an upgrade of the kernel and base and manual sets.
+This option will render your system
+.Sy unusable
+if the current installation includes other sets.
.El
.Sh FILES
.Bl -tag -width "/auto_upgrade.conf" -compact
Re: [macppc 6.7-beta] clang backend error: "adde Constant" issue
> Date: Tue, 28 Apr 2020 01:31:12 -0400
> From: George Koehler
>
> Moving from bugs@ to tech@,
> because some people might miss a clang diff on bugs@.
>
> This diff modifies LLVM's DAGCombiner to skip an optimization if it
> would make an illegal ISD::ADDE node. This fixes fatal errors from
> powerpc clang when building ports net/libtorrent-rasterbar and
> devel/avr/binutils on PowerPC. The fatal errors look like,
>
> On Sun, 19 Apr 2020 17:26:49 +0200
> Charlene Wendling wrote:
>
> > fatal error: error in backend: Cannot select: 0x90a1c1b0: i1,glue = adde
> > Constant:i1<0>, Constant:i1<-1>, 0xa6a2b1b0:1
> > 0xa6a2b828: i1 = Constant<0>
> > 0x90a1c630: i1 = Constant<-1>
> > 0xa6a2b1b0: i32,glue = addc 0x90a1c3a8, Constant:i32<-1>
>
> An example to cause this error, given unsigned 32-bit *p, is
> if (*p > ((*p + 15ULL) & ~15ULL)) ...
>
> The SelectionDAG goes through phases. The DAG starts with an i64 add
> *p + 15ULL, but 32-bit PowerPC has no i64 ops, so the legalize-types
> phase converts the i64 add to an i32 addc/adde pair. The DAG keeps
> some i1 ops because clang -mcrbits (the default) enables i1 ops on
> condition register bits. DAGCombiner is optimizing the i1 ops when it
> truncates the i32 adde to an i1 adde, but i1 adde is an illegal op.
>
> Legalize-ops runs next, and would convert illegal ops to legal ops,
> but it can't fix i1 adde, because it has no case for ISD::ADDE.
> LegalizeIntegerTypes.cpp:1966 knows this, and refuses to insert an
> illegal adde, but DAGCombiner::visitTRUNCATE didn't know.
>
> This diff might affect other arches. I guess that Aarch64, ARM, MIPS,
> Sparc don't have integer ops smaller than i32, and X86 doesn't use
> ISD::ADDE, so this diff might not affect them.
>
> OK to commit?
Upstream fixed this issue as well. Apparently only ADDE can't be
legalized (because it is "special") but ADDCARRY can. Do ypu want to
adjust your diff based on that information?
Either way, ok kettenis@
> Index: lib/CodeGen//SelectionDAG/DAGCombiner.cpp
> ===
> RCS file: /cvs/src/gnu/llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp,v
> retrieving revision 1.1.1.8
> diff -u -p -r1.1.1.8 DAGCombiner.cpp
> --- lib/CodeGen//SelectionDAG/DAGCombiner.cpp 23 Jun 2019 21:36:48 -
> 1.1.1.8
> +++ lib/CodeGen//SelectionDAG/DAGCombiner.cpp 27 Apr 2020 21:48:18 -
> @@ -9904,9 +9904,10 @@ SDValue DAGCombiner::visitTRUNCATE(SDNod
>// (trunc adde(X, Y, Carry)) -> (adde trunc(X), trunc(Y), Carry)
>// (trunc addcarry(X, Y, Carry)) -> (addcarry trunc(X), trunc(Y), Carry)
>// When the adde's carry is not used.
> + // Don't make an illegal adde: LegalizeDAG can't expand nor promote it.
>if ((N0.getOpcode() == ISD::ADDE || N0.getOpcode() == ISD::ADDCARRY) &&
>N0.hasOneUse() && !N0.getNode()->hasAnyUseOfValue(1) &&
> - (!LegalOperations || TLI.isOperationLegal(N0.getOpcode(), VT))) {
> + TLI.isOperationLegal(N0.getOpcode(), VT)) {
> SDLoc SL(N);
> auto X = DAG.getNode(ISD::TRUNCATE, SL, VT, N0.getOperand(0));
> auto Y = DAG.getNode(ISD::TRUNCATE, SL, VT, N0.getOperand(1));
>
>
release(8) - mention u-boot-*, dtb, raspberrypi-firmware
OK to add this? Index: release.8 === RCS file: /cvs/src/share/man/man8/release.8,v retrieving revision 1.94 diff -u -p -r1.94 release.8 --- release.8 23 Jun 2018 23:19:11 - 1.94 +++ release.8 29 Apr 2020 13:44:19 - @@ -157,6 +157,13 @@ The base system release consists of at l some installation media, the release tarballs, installation instructions, and checksum files. .Pp +On arm64 and armv7 architectures, additional files are required. +For armv7, install u-boot-arm and dtb using +.Xr pkg_add 1 +or from +.Xr ports 7 . +For arm64, install raspberrypi-firmware and u-boot-aarch64. +.Pp Create a .Va RELEASEDIR directory to store the release files.
Re: Install: Invalid group _sndiop in #163 amd64
On 2020/04/29 11:58, Oliver Marugg wrote: > Yes, I made the mistake using this older snap for install (was on my usb > stick) with consequences. > With a today downloaded install.fs to USB Stick and http install no problem > as you, Otto and Stuart mentioned. thx. > Sorry, I really should know using latest -current only, but I learnt not > using an older install.fs to install. Sorry for the noise. btw, since you are fetching new files from the net anyway, you can save time by just using miniroot67.fs instead of install67.fs install67 includes all the sets, which is useful if you're installing on a machine that doesn't have net unless you have wifi firmware, or need to install offline, but otherwise it's usually quicker to just dd the miniroot instead and avoid the extra stage.
Re: Install: Invalid group _sndiop in #163 amd64
On Wed, Apr 29, 2020 at 11:58:55AM +, Oliver Marugg wrote: > Yes, I made the mistake using this older snap for install (was on my usb > stick) with consequences. > With a today downloaded install.fs to USB Stick and http install no problem > as you, Otto and Stuart mentioned. thx. > Sorry, I really should know using latest -current only, but I learnt not > using an older install.fs to install. Sorry for the noise. Please always make sure youd are running an installer that matches the sets you are downloading. If not, bad things can happen. This case is just one of the things that can go wrong. -Otto > > -- Originalnachricht -- > Von: "Alexandre Ratchov" > An: "Otto Moerbeek" > Cc: "Oliver Marugg" ; tech@openbsd.org > Gesendet: 29.04.2020 13:53:46 > Betreff: Re: Install: Invalid group _sndiop in #163 amd64 > > > On Wed, Apr 29, 2020 at 01:26:51PM +0200, Otto Moerbeek wrote: > > > On Wed, Apr 29, 2020 at 01:02:29PM +0200, Otto Moerbeek wrote: > > > > > > > On Wed, Apr 29, 2020 at 10:28:37AM +, Oliver Marugg wrote: > > > > > > > > > Possible typo group _sniop shoud be _sndiod: > > > > > > > > Nope. _sniop is the correct name. The real issue is that that group > > > isn't in > > > > the /etc/group file used during install. > > > > > > > > How that can happen I do not know yet. > > > > > > Just did an install using install67.fg and did not see that error. > > > > > > > There was a snap ~1-2 weeks ago with a broken bsd.rd (with /etc/groups > > missing _sndiop). > > > > Now this is fixed. >
Re: Install: Invalid group _sndiop in #163 amd64
Yes, I made the mistake using this older snap for install (was on my usb stick) with consequences. With a today downloaded install.fs to USB Stick and http install no problem as you, Otto and Stuart mentioned. thx. Sorry, I really should know using latest -current only, but I learnt not using an older install.fs to install. Sorry for the noise. -- Originalnachricht -- Von: "Alexandre Ratchov" An: "Otto Moerbeek" Cc: "Oliver Marugg" ; tech@openbsd.org Gesendet: 29.04.2020 13:53:46 Betreff: Re: Install: Invalid group _sndiop in #163 amd64 On Wed, Apr 29, 2020 at 01:26:51PM +0200, Otto Moerbeek wrote: On Wed, Apr 29, 2020 at 01:02:29PM +0200, Otto Moerbeek wrote: > On Wed, Apr 29, 2020 at 10:28:37AM +, Oliver Marugg wrote: > > > Possible typo group _sniop shoud be _sndiod: > > Nope. _sniop is the correct name. The real issue is that that group isn't in > the /etc/group file used during install. > > How that can happen I do not know yet. Just did an install using install67.fg and did not see that error. There was a snap ~1-2 weeks ago with a broken bsd.rd (with /etc/groups missing _sndiop). Now this is fixed.
Re: Install: Invalid group _sndiop in #163 amd64
On Wed, Apr 29, 2020 at 01:26:51PM +0200, Otto Moerbeek wrote: > On Wed, Apr 29, 2020 at 01:02:29PM +0200, Otto Moerbeek wrote: > > > On Wed, Apr 29, 2020 at 10:28:37AM +, Oliver Marugg wrote: > > > > > Possible typo group _sniop shoud be _sndiod: > > > > Nope. _sniop is the correct name. The real issue is that that group isn't in > > the /etc/group file used during install. > > > > How that can happen I do not know yet. > > Just did an install using install67.fg and did not see that error. > There was a snap ~1-2 weeks ago with a broken bsd.rd (with /etc/groups missing _sndiop). Now this is fixed.
Re: Install: Invalid group _sndiop in #163 amd64
On Wed, Apr 29, 2020 at 01:02:29PM +0200, Otto Moerbeek wrote: > On Wed, Apr 29, 2020 at 10:28:37AM +, Oliver Marugg wrote: > > > Possible typo group _sniop shoud be _sndiod: > > Nope. _sniop is the correct name. The real issue is that that group isn't in > the /etc/group file used during install. > > How that can happen I do not know yet. Just did an install using install67.fg and did not see that error. > > -Otto > > > > > During fresh install from install.fs amd64 of OpenBSD 6.7-beta (GENERIC.MP) > > #163: Tue Apr 28 21:35:13 MDT 2020 > > ... > > Making all device nodes...chgrp: group is invalid: _sndiop > > chgrp: group is invalid: _sndiop > > done. > > > > Multiprocessor machine; using bsd.mp instead of bsd. > > ... > > > > -oliver > > > > >
Re: Install: Invalid group _sndiop in #163 amd64
On 2020/04/29 10:28, Oliver Marugg wrote: > Possible typo group _sniop shoud be _sndiod: > > During fresh install from install.fs amd64 of OpenBSD 6.7-beta (GENERIC.MP) > #163: Tue Apr 28 21:35:13 MDT 2020 You are showing the version of the installed GENERIC.MP kernel not the install image. I think you are using an old install67.fs. > ... > Making all device nodes...chgrp: group is invalid: _sndiop > chgrp: group is invalid: _sndiop > done. > > Multiprocessor machine; using bsd.mp instead of bsd. > ... > > -oliver >
Re: Install: Invalid group _sndiop in #163 amd64
On Wed, Apr 29, 2020 at 10:28:37AM +, Oliver Marugg wrote: > Possible typo group _sniop shoud be _sndiod: Nope. _sniop is the correct name. The real issue is that that group isn't in the /etc/group file used during install. How that can happen I do not know yet. -Otto > > During fresh install from install.fs amd64 of OpenBSD 6.7-beta (GENERIC.MP) > #163: Tue Apr 28 21:35:13 MDT 2020 > ... > Making all device nodes...chgrp: group is invalid: _sndiop > chgrp: group is invalid: _sndiop > done. > > Multiprocessor machine; using bsd.mp instead of bsd. > ... > > -oliver >
Install: Invalid group _sndiop in #163 amd64
Possible typo group _sniop shoud be _sndiod: During fresh install from install.fs amd64 of OpenBSD 6.7-beta (GENERIC.MP) #163: Tue Apr 28 21:35:13 MDT 2020 ... Making all device nodes...chgrp: group is invalid: _sndiop chgrp: group is invalid: _sndiop done. Multiprocessor machine; using bsd.mp instead of bsd. ... -oliver
Re: sdmmc: CIS tuple can have empty body
> Date: Tue, 28 Apr 2020 23:27:00 +0200
> From: Patrick Wildt
>
> On Tue, Apr 28, 2020 at 11:16:43PM +0200, Patrick Wildt wrote:
> > Hi,
> >
> > on my i.MX8MM EVK there's a ath10k-based WiFi chip which we
> > unfortunately do not support (yet?). But the SD/MMC CIS parser
> > complains:
> >
> > sdmmc0: CIS parse error at 4136, tuple code 0x14, length 0
> > manufacturer 0x0271, product 0x0701 at sdmmc0 function 1 not configured
> >
> > It's not a transmission bug though, since I saw prints from a Linux
> > dmesg on the web[0] stating something similar:
> >
> > <4>mmc0: queuing unknown CIS tuple 0x01 (3 bytes)
> > <4>mmc0: queuing unknown CIS tuple 0x1a (5 bytes)
> > <4>mmc0: queuing unknown CIS tuple 0x1b (8 bytes)
> > <4>mmc0: queuing unknown CIS tuple 0x14 (0 bytes)
> >
> > I guess the ath10k-Chips use some vendor-specific tuples in the CIS
> > structure. The thing that our CIS parser complains about is the tuple
> > without a length.
> >
> > Section 16 of the SDIO Simplified Specification 3.0[1] describes the CIS
> > formats, with Section 16.2 describing the Basic Tuple Format. What our
> > code calls "tpllen", the tuple body length, is called "link field" in
> > the specification.
> >
> > The specification explicitly says, that a empty tuple body is fine, by
> > saying: "If the link field is 0, then the tuple body is empty."
> >
> > Thus I propose that instead of complaining about that tuple, we just
> > continue our job. I guess sometimes the existance of a code is infor-
> > mation enough.
> >
> > ok?
> >
> > Patrick
> >
> > [0]
> > https://linuxlists.cc/l/9/linux-wireless/t/3226749/ath10k-sdio:_failed_to_load_firmware
> > [1]
> > https://www.sdcard.org/downloads/pls/pdf/index.php?p=PartE1_SDIO_Simplified_Specification_Ver3.00.jpg&f=PartE1_SDIO_Simplified_Specification_Ver3.00.pdf&e=EN_SSE1
>
> Actually it would be even better to just remove the check, since
> then we would fall into the default case which, given SDMMC_DEBUG
> is on, also lets us know of the unknown tuple:
>
> sdmmc0: unknown tuple code 0x1, length 3
> sdmmc0: unknown tuple code 0x22, length 4
> sdmmc0: unknown tuple code 0x1a, length 5
> sdmmc0: unknown tuple code 0x1b, length 8
> sdmmc0: unknown tuple code 0x14, length 0
> sdmmc0: unknown tuple code 0x22, length 42
> sdmmc0: unknown tuple code 0x80, length 1
> sdmmc0: unknown tuple code 0x81, length 1
> sdmmc0: unknown tuple code 0x82, length 1
>
> The individual switch-cases are checking tpllen properly, so there
> is no harm.
>
> ok?
ok kettenis@
> diff --git a/sys/dev/sdmmc/sdmmc_cis.c b/sys/dev/sdmmc/sdmmc_cis.c
> index 21cf530b24f..70e5b6283a7 100644
> --- a/sys/dev/sdmmc/sdmmc_cis.c
> +++ b/sys/dev/sdmmc/sdmmc_cis.c
> @@ -76,12 +76,6 @@ sdmmc_read_cis(struct sdmmc_function *sf, struct sdmmc_cis
> *cis)
> continue;
>
> tpllen = sdmmc_io_read_1(sf0, reg++);
> - if (tpllen == 0) {
> - printf("%s: CIS parse error at %d, "
> - "tuple code %#x, length %d\n",
> - DEVNAME(sf->sc), reg, tplcode, tpllen);
> - break;
> - }
>
> switch (tplcode) {
> case SD_IO_CISTPL_FUNCID:
>
>
