Re: [PATCH]: sysupgrade(8) don't create /home/_sysupgrade/keep
Nice catch!
Committed, thanks.
On Tue, Jun 16, 2020 at 01:36:22PM +0200, Martin Vahlensieck wrote:
> Hi
>
> In the last revision install.sub stopped using /home/_sysupgrade/keep,
> so unless I miss something this line can be removed.
>
> Best,
>
> Martin
>
> Index: sysupgrade.sh
> ===
> RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
> retrieving revision 1.37
> diff -u -p -r1.37 sysupgrade.sh
> --- sysupgrade.sh 26 Jan 2020 22:08:36 - 1.37
> +++ sysupgrade.sh 16 Jun 2020 10:40:25 -
> @@ -178,8 +178,6 @@ if [[ -n ${DL} ]]; then
> unpriv cksum -qC SHA256 ${DL}
> fi
>
> -${KEEP} && > keep
> -
> cat <<__EOT >/auto_upgrade.conf
> Location of sets = disk
> Pathname to the sets = /home/_sysupgrade/
>
--
I'm not entirely sure you are real.
[PATCH]: sysupgrade(8) don't create /home/_sysupgrade/keep
Hi
In the last revision install.sub stopped using /home/_sysupgrade/keep,
so unless I miss something this line can be removed.
Best,
Martin
Index: sysupgrade.sh
===
RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
retrieving revision 1.37
diff -u -p -r1.37 sysupgrade.sh
--- sysupgrade.sh 26 Jan 2020 22:08:36 - 1.37
+++ sysupgrade.sh 16 Jun 2020 10:40:25 -
@@ -178,8 +178,6 @@ if [[ -n ${DL} ]]; then
unpriv cksum -qC SHA256 ${DL}
fi
-${KEEP} && > keep
-
cat <<__EOT >/auto_upgrade.conf
Location of sets = disk
Pathname to the sets = /home/_sysupgrade/
Re: [PATCH] sysupgrade
On Thu, Apr 30, 2020 at 11:19:14AM +, Kevin Chadwick wrote: > On 2020-04-30 03:28, James Jerkins wrote: > > 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 used to avoid installing the X sets and I found that even on e.g. a web > server > without X11 running. I would end up installing them in the end as certain > ports > would require them. Struggling to remember why I wanted to do it, to be > honest. > A notion from securing Linux perhaps. As Linux often runs things automatically > when they're installed and desktop distros run a lot by default. It is what is > in RAM, that is more important, which is very little by default on OpenBSD > (~60M). > > May be worth re-considering if it is worth the effort to save a fairly small > amount of space with potentially unexpected consequences? > > Instead to make options for specifig sets how about just possible to use upgrade.conf file. That enables to set what ever sets you may want and other options also like site sets. -- Henri Järvinen
Re: [PATCH] sysupgrade
On Sun, May 03, 2020 at 04:41:13AM -0400, Chris Bennett wrote: > The FAQ already describes exactly how to upgrade with whatever sets one > wants to. I have used that method many, many times successfully. > I can't see any reason whatsoever to turn an addon tool into anything > more than what it is. If someone can't even bother to read the FAQ, why > should they even be using OpenBSD at all? People read the FAQ and see that partial install is possible: The complete OpenBSD installation is broken up into a number of file sets: ... New users are recommended to install all of them. ... The xservXX.tgz set is rarely needed if you don't intend to run X. So no mentioning about this kind of setup being "second-class". People see that now instead of manual update with bsd.rd it is possible to use sysupgrade. Yay! People see missing pieces (sysupgrade does not support partial install) and try to patch sysupgrade because manual upgrade does allow partial install. It's kinda expected that this topic will be raised over and over again. Maybe FAQ should be adjusted to say something like: BEWARE: ANY PARTIAL INSTALL IS NOT FULLY SUPPORTED CONFIGURATION WE ARE PROVIDING NO SUPPORT FOR THAT KIND OF STUFF. Because that's what people usually get in response when they are asking in misc@ about sysupgrade and sets.
Re: [PATCH] sysupgrade
Le 03/05/2020 à 10:41, Chris Bennett a écrit : On Sun, May 03, 2020 at 04:40:44AM +0200, Stéphane Aulery wrote: a) Removing sets selection from the installer b) Supporting an upgrade of the sets already installed. The FAQ already describes exactly how to upgrade with whatever sets one wants to. I have used that method many, many times successfully. I can't see any reason whatsoever to turn an addon tool into anything more than what it is. If someone can't even bother to read the FAQ, why should they even be using OpenBSD at all? No intention to sound rude, but everything is already spelled out in detail on the website. I actually read it, and it is very good. You don't get the point. I'm againts adding a new options to sysupgrade. The problem is that there is a discourse that says: using the sets is not supported, your are on your own. And on the other side, installing a selection of sets is still possible with an explanation in the FAQ. To be consistent I would have: - Deleted the choice of sets. Case settled. - Added an explanation in FAQ 4 (in File Sets section) and the manual page of sysupgrade which says that sysupgrade only works for all sets. So you known your are on your own. No surprise. - Completed sysupgrade to install the selected sets. Regards, -- Stéphane Aulery
Re: [PATCH] sysupgrade
On Sun, May 03, 2020 at 04:40:44AM +0200, Stéphane Aulery wrote: > > a) Removing sets selection from the installer > b) Supporting an upgrade of the sets already installed. > The FAQ already describes exactly how to upgrade with whatever sets one wants to. I have used that method many, many times successfully. I can't see any reason whatsoever to turn an addon tool into anything more than what it is. If someone can't even bother to read the FAQ, why should they even be using OpenBSD at all? No intention to sound rude, but everything is already spelled out in detail on the website. Chris Bennett
Re: [PATCH] sysupgrade
Hello, Le 30/04/2020 à 10:07, Anders Andersson a écrit : On Thu, Apr 30, 2020 at 6:02 AM James Jerkins wrote: 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. I recently bought an APU with the smallest disk I could find (16 GB mSATA), I don't remember the full install of all sets taking more than 10%. No need to remove stuff. I don't really see why a system-wide tool should have several options for hardcoded subsets of some of the possible ways to create a non-standard installation, especially when using these options will break an otherwise working setup. IF there is such an option, surely it should take a list of sets that you have installed? Especially when I've read here that there is a wish for some of the devs that the option of selecting subsets should probably just be removed. Right. This question comes up again and again. IMHO, there are only two sensible ways to solve it: a) Removing sets selection from the installer b) Supporting an upgrade of the sets already installed. a) seems the best thing, since selection is not officially supported (why this was added to the installer?) and brings only refined ways to shoot yourself in the foot. The total size of the sets is only 774 MB uncompressed which is not really that big. The absolute requirement is 291 MB (base). Going lower is certainly possible but is better served by derived OS who pursue their own goal [1]. Just because you can do something doesn't mean you have to do it. Leaving the choice is sometimes a bad idea. [1] https://en.wikipedia.org/wiki/List_of_BSD_operating_systems#OpenBSD-based Regards, -- Stéphane Aulery
Re: [PATCH] sysupgrade
>> Struggling to remember why I wanted to do it, to be honest. > >Because until relatively recently X was installed sgid root. But that >was fixed for 6.5: > That wasn't a factor. You could always mount it nosuid, even noexec anyway.
Re: [PATCH] sysupgrade
On Thu, Apr 30, 2020 at 11:19:14AM +, Kevin Chadwick wrote: > I used to avoid installing the X sets and I found that even on e.g. a web > server without X11 running. I would end up installing them in the end as > certain ports would require them. Often there's a no_x11 FLAVOR, but avoiding that extra work in ports maintenance is part of the motivation for deprecating non-X installations. IIRC, ports maintainers have for years made it clear that providing and maintaining no_x11 FLAVORs isn't a priority. > Struggling to remember why I wanted to do it, to be honest. Because until relatively recently X was installed sgid root. But that was fixed for 6.5: https://cvsweb.openbsd.org/xenocara/xserver/Makefile.bsd-wrapper?rev=1.67=text/x-cvsweb-markup
Re: [PATCH] sysupgrade
On Wed, Apr 29, 2020 at 10:28:12PM -0500, James Jerkins wrote:
> 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
*if* we want the ability to upgrade not all sets, it should be done
automatically for the sets that are currently present, not with an
option. The latter is a sure way to end up with partial upgrades.
-Otto
>
>
> 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.8 3 Oct 2019 12:43:58 - 1.10
> +++ sysupgrade.8 30 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: [PATCH] sysupgrade
On 2020-04-30 03:28, James Jerkins wrote: > 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 used to avoid installing the X sets and I found that even on e.g. a web server without X11 running. I would end up installing them in the end as certain ports would require them. Struggling to remember why I wanted to do it, to be honest. A notion from securing Linux perhaps. As Linux often runs things automatically when they're installed and desktop distros run a lot by default. It is what is in RAM, that is more important, which is very little by default on OpenBSD (~60M). May be worth re-considering if it is worth the effort to save a fairly small amount of space with potentially unexpected consequences?
Re: [PATCH] sysupgrade
On 2020/04/30 10:07, Anders Andersson wrote:
> I recently bought an APU with the smallest disk I could find (16 GB
> mSATA), I don't remember the full install of all sets taking more than
> 10%. No need to remove stuff.
With current auto layouts from the installer it's usually ok, but with
ones from a couple of releases ago it's very much not. It's also tricky to
fit everything if you're using a system from a few years ago with say a
1-2GB CF.
> I don't really see why a system-wide tool should have several options
> for hardcoded subsets of some of the possible ways to create a
> non-standard installation, especially when using these options will
> break an otherwise working setup. IF there is such an option, surely
> it should take a list of sets that you have installed?
The only way I see this making sense is if it detects which sets are
installed. But the impression I got was that this was unwanted for sysupgrade
(so I use my own script). FWIW in case it helps anyone writing their own,
I use these for detection.
[ -r /usr/share/man/man1/dd.1 ] && _SETS="${_SETS}man,"
[ -r /usr/X11R6/bin/xterm ] && _SETS="${_SETS}xbase,"
[ -r /usr/lib/libc.a ] && _SETS="${_SETS}comp,"
[ -r /usr/X11R6/include/X11/X.h ] && _SETS="${_SETS}xshare,"
[ -r /usr/X11R6/bin/X ] && _SETS="${_SETS}xserv,"
[ -d /usr/X11R6/lib/X11/fonts/misc ] && _SETS="${_SETS}xfont,"
[ -r /usr/games/rain ] && _SETS="${_SETS}game,"
Re: [PATCH] sysupgrade
James Jerkins(j...@jamesjerkinscomputer.com) on 2020.04.29 22:28:12 -0500: > 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 We wont add tons of options to this tool for every use case. Just make a copy of the sysupgrade script and add your own mondifications there. Or a wrapper around it.
Re: [PATCH] sysupgrade
On Thu, Apr 30, 2020 at 6:02 AM James Jerkins wrote: > > 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. I recently bought an APU with the smallest disk I could find (16 GB mSATA), I don't remember the full install of all sets taking more than 10%. No need to remove stuff. I don't really see why a system-wide tool should have several options for hardcoded subsets of some of the possible ways to create a non-standard installation, especially when using these options will break an otherwise working setup. IF there is such an option, surely it should take a list of sets that you have installed? Especially when I've read here that there is a wish for some of the devs that the option of selecting subsets should probably just be removed.
[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
