On Jan 07 11:15:20, dera...@openbsd.org wrote:
> Jan Stary <h...@stare.cz> 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?
