Re: auto_upgrade.conf ignored?
On Sat, 8 Jan 2022, Jan Stary wrote: Buy a bigger machine. Or use Linux, Now that is just rude ... You are also rude, much ruder than that, to others. Did you think, you are very special, so that you deserve a different treatment?
Re: auto_upgrade.conf ignored?
On Jan 07 11:49:41, dera...@openbsd.org wrote: > Jan Stary wrote: > > > > 1) If you edit that file yourself, > > > > Is there any other way this file is supposed to come to existence > > (except the one containing the default answers, which sysupgrade > > writes itself) beside editing it by hand? > > sysupgrade creates it, exactly as it wants it to be. > > If you edit it, you are no longer using sysupgrade. You are on your > own. > > > > how can you say you are using sysupgrade? > > > > Perhaps I was unclear: I took the response log of a sysupgrade run > > (as mailed afterwards) and created /auto_upgrade.conf from it. > > I am not touching sysupgrade itself, obviously. > > Ah, you edited the file. > > Then you are not using sysupgrade. You are using your own process, and > you need to understand all the consequences. misc@ owes you nothing. > > > > sysupgrade manages the whole process. When you subvert a program, you are > > > responsible. > > > > Is creating /auto_upgrade.conf considered subversion? > > No. You can create your own /auto_upgrade.conf > > But if you create it, it is not sysupgrade that created it OK, this is where my whole premise is wrong it seems: namely, that /auto_upgrade.conf is a user-edited config of the sysupgrade process. Sorry for the noise. > Buy a bigger machine. Or use Linux, Now that is just rude ...
Re: auto_upgrade.conf ignored?
Jan Stary wrote: > > 1) If you edit that file yourself, > > Is there any other way this file is supposed to come to existence > (except the one containing the default answers, which sysupgrade > writes itself) beside editing it by hand? sysupgrade creates it, exactly as it wants it to be. If you edit it, you are no longer using sysupgrade. You are on your own. > > how can you say you are using sysupgrade? > > Perhaps I was unclear: I took the response log of a sysupgrade run > (as mailed afterwards) and created /auto_upgrade.conf from it. > I am not touching sysupgrade itself, obviously. Ah, you edited the file. Then you are not using sysupgrade. You are using your own process, and you need to understand all the consequences. misc@ owes you nothing. > > sysupgrade manages the whole process. When you subvert a program, you are > > responsible. > > Is creating /auto_upgrade.conf considered subversion? No. You can create your own /auto_upgrade.conf But if you create it, it is not sysupgrade that created it If you create a file which doesn't work, have you considered blaming the creator of the file? > > Especially when it is not documented what will happen. > > sysupgrade(8) says > > /auto_upgrade.conf Response file for the ramdisk kernel. > > I agree that only documents the file is recognized to exist. But you are not using sysupgrade. Why do you refer to the sysupgrade manual page? You have placed *your own ideas* of what should be in that file. sysupgrade does not use ambigious question=answer lines. But you do. You are acting completely clueless here. > > 2) You assume you can provide multiple answers to a question -- > >how do you expect this to work? > > I naively assumed the undocumented file replaces > the interactive dialogue of a bsd.rd upgrade. My bad. If it was replacing the dialogue 1:1, then the lines would only need to be answers. But every line is question = answer. Obviously, the parsing of this won't keep-state then, and it acts as either first-match or last-match, so you cannot repeat questions. > > 3) see _autorespond in install.sub > > Thank you. > > My original problem is that some machines are small/slow enough > to warant not having e.g. the X sets, and I am trying to persuade > sysupgrade to do that. Is there a user-visible way to do that > via /auto_upgrade.conf? what the hell does "slow" have to do with installing files you won't use? Buy a bigger machine. Or use Linux, which will mean you need to buy a bigger machine. I'm dead serious -- OpenBSD is a small enough operating system that we don't need to bend-over for people who want to use it on ridiculously miserly systems. We have tradeoffs to make and I see NO POINT in focusing on people who's machines are that small.
Re: auto_upgrade.conf ignored?
On Jan 07 11:15:20, dera...@openbsd.org wrote: > Jan Stary wrote: > > > On Jan 07 10:52:51, dera...@openbsd.org wrote: > > > Set name(s) = -x* > > > Set name(s) = done > > > > > > By giving two seperate answers to the same question, you are making a > > > gigantic assumption. > > > > Yes, that's probably wrong. > > But the same happens with just > > > > Set name(s) = -x* > > > > Is the grammar of th eauto update response discribed somewhere? > > Naively, I just tweaked the response log of a previous sysupgrade. > > 1) If you edit that file yourself, Is there any other way this file is supposed to come to existence (except the one containing the default answers, which sysupgrade writes itself) beside editing it by hand? > how can you say you are using sysupgrade? Perhaps I was unclear: I took the response log of a sysupgrade run (as mailed afterwards) and created /auto_upgrade.conf from it. I am not touching sysupgrade itself, obviously. > sysupgrade manages the whole process. When you subvert a program, you are > responsible. Is creating /auto_upgrade.conf considered subversion? > Especially when it is not documented what will happen. sysupgrade(8) says /auto_upgrade.conf Response file for the ramdisk kernel. I agree that only documents the file is recognized to exist. > 2) You assume you can provide multiple answers to a question -- >how do you expect this to work? I naively assumed the undocumented file replaces the interactive dialogue of a bsd.rd upgrade. My bad. > 3) see _autorespond in install.sub Thank you. My original problem is that some machines are small/slow enough to warant not having e.g. the X sets, and I am trying to persuade sysupgrade to do that. Is there a user-visible way to do that via /auto_upgrade.conf?
Re: auto_upgrade.conf ignored?
Jan Stary wrote: > On Jan 07 10:52:51, dera...@openbsd.org wrote: > > Set name(s) = -x* > > Set name(s) = done > > > > By giving two seperate answers to the same question, you are making a > > gigantic assumption. > > Yes, that's probably wrong. > But the same happens with just > > Set name(s) = -x* > > Is the grammar of th eauto update response discribed somewhere? > Naively, I just tweaked the response log of a previous sysupgrade. 1) If you edit that file yourself, how can you say you are using sysupgrade? sysupgrade manages the whole process. When you subvert a program, you are responsible. Especially when it is not documented what will happen. 2) You assume you can provide multiple answers to a question -- how do you expect this to work? 3) see _autorespond in install.sub
Re: auto_upgrade.conf ignored?
On Jan 07 10:52:51, dera...@openbsd.org wrote: > Set name(s) = -x* > Set name(s) = done > > By giving two seperate answers to the same question, you are making a > gigantic assumption. Yes, that's probably wrong. But the same happens with just Set name(s) = -x* Is the grammar of th eauto update response discribed somewhere? Naively, I just tweaked the response log of a previous sysupgrade.
Re: auto_upgrade.conf ignored?
Set name(s) = -x* Set name(s) = done By giving two seperate answers to the same question, you are making a gigantic assumption.
auto_upgrade.conf ignored?
This is current/arm64 (I have the same problem on current/amd64).
I am trying toi sysupgrade with the following /auto_uprade.conf:
Which disk is the root disk = sd0
Force checking of clean non-root filesystems = no
Location of sets = disk
Is the disk partition already mounted = yes
Pathname to the sets = /home/_sysupgrade/
Set name(s) = -x*
Set name(s) = done
Directory does not contain SHA256.sig. Continue without verification = yes
Location of sets = done
Is seems that these responses are ignored (upgrade log below).
However, the file does not exist after the sysupgrade,
so something must have touched it ...
Am I missing something obvious?
Jan
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2022 OpenBSD. All rights reserved. https://www.OpenBSD.org
Welcome to the OpenBSD/arm64 7.0 installation program.
Performing non-interactive upgrade...
Terminal type? [vt220] vt220
Available disks are: sd0.
Which disk is the root disk? ('?' for details) [sd0] sd0
Checking root filesystem (fsck -fp /dev/sd0a)... OK.
Mounting root filesystem (mount -o ro /dev/sd0a /mnt)... OK.
Force checking of clean non-root filesystems? [no] no
fsck -p 9bf87e93dfb93353.j... OK.
fsck -p 9bf87e93dfb93353.k... OK.
fsck -p 9bf87e93dfb93353.d... OK.
fsck -p 9bf87e93dfb93353.e... OK.
fsck -p 9bf87e93dfb93353.f... OK.
fsck -p 9bf87e93dfb93353.g... OK.
fsck -p 9bf87e93dfb93353.h... OK.
fsck -p 9bf87e93dfb93353.p... OK.
fsck -p beab8e6b584570ba.a... OK.
/dev/sd0a (9bf87e93dfb93353.a) on /mnt type ffs (rw, local, noatime)
/dev/sd0j (9bf87e93dfb93353.j) on /mnt/usr type ffs (rw, local, noatime, nodev)
/dev/sd0k (9bf87e93dfb93353.k) on /mnt/usr/local type ffs (rw, local, noatime,
nodev, wxallowed)
/dev/sd0d (9bf87e93dfb93353.d) on /mnt/tmp type ffs (rw, local, noatime, nodev,
nosuid)
/dev/sd0e (9bf87e93dfb93353.e) on /mnt/var type ffs (rw, local, noatime, nodev,
nosuid)
/dev/sd0f (9bf87e93dfb93353.f) on /mnt/var/log type ffs (rw, local, noatime,
nodev, nosuid)
/dev/sd0g (9bf87e93dfb93353.g) on /mnt/var/www type ffs (rw, local, noatime,
nodev, nosuid)
/dev/sd0h (9bf87e93dfb93353.h) on /mnt/var/mail type ffs (rw, local, noatime,
nodev, nosuid)
/dev/sd0p (9bf87e93dfb93353.p) on /mnt/home type ffs (rw, local, noatime,
nodev, nosuid)
/dev/sd1a (beab8e6b584570ba.a) on /mnt/backup type ffs (rw, local, noatime,
nodev, nosuid)
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') [7.0/arm64] /home/_sysupgrade/
Select sets by entering a set name, a file name pattern or 'all'. De-select
sets by prepending a '-', e.g.: '-game*'. Selected sets are labelled '[X]'.
[X] bsd [X] base70.tgz[X] game70.tgz[X] xfont70.tgz
[X] bsd.mp[X] comp70.tgz[X] xbase70.tgz [X] xserv70.tgz
[X] bsd.rd[X] man70.tgz [X] xshare70.tgz
Set name(s)? (or 'abort' or 'done') [done] done
Directory does not contain SHA256.sig. Continue without verification? [no] yes
Installing bsd 100% |**| 13704 KB00:02 ETA
Installing bsd.mp 100% |**| 13778 KB00:02 ETA
Installing bsd.rd 100% |**| 17063 KB00:02 ETA
Installing base70.tgz 100% |**| 99237 MB - 01:43eETA
Installing comp70.tgz 100% |**| 70834 KB01:10 ETA
Installing man70.tgz100% |**| 7588 KB00:15 ETA
Installing game70.tgz 100% |**| 2715 KB00:01 ETA
Installing xbase70.tgz 100% |**| 48628 KB00:25 ETA
Installing xshare70.tgz 100% |**| 4545 KB00:22 ETA
Installing xfont70.tgz 100% |**| 22965 KB00:10 ETA
Installing xserv70.tgz 100% |**| 13087 KB00:05 ETA
Location of sets? (disk http nfs or 'done') [done] done
Making all device nodes... done.
fw_update: added none; updated none; kept bwfm
Multiprocessor machine; using bsd.mp instead of bsd.
Relinking to create unique kernel... done.
CONGRATULATIONS! Your OpenBSD upgrade has been successfully completed!
syncing disks... done
rebooting...
