On 23:21 Sat 23 Nov, cho...@jtan.com wrote:
> > You can't seriously be calling "-x* -game*" an unsupported configuration ?
> > Seems to me
> > like a sensible thing to do on any box that's going to be headless for its
> > entire life
> > and only ever accessed via SSH (or text console at a
On 24/11/2019 09:20, Rachel Roch wrote:
You can't seriously be calling "-x* -game*" an unsupported configuration ?
Seems to me like a sensible thing to do on any box that's going to be headless for its
entire life and only ever accessed via SSH (or text console at a push).
I agree in
> You can't seriously be calling "-x* -game*" an unsupported configuration ?
> Seems to me
> like a sensible thing to do on any box that's going to be headless for its
> entire life
> and only ever accessed via SSH (or text console at a push).
Lines 159-160 of /usr/sbin/sysupgrade read as
On 2019-11-23 14:20, Rachel Roch wrote:
This topic has been beat to death. deraadt@ and other have made it clear that
if you do not install all the sets, you are running an unsupported
configuration. It has been stated that if people keep bitching, they're just
going to merge the release
This topic has been beat to death. deraadt@ and other have made it clear that
if you do not install all the sets, you are running an unsupported
configuration. It has been stated that if people keep bitching, they're just
going to merge the release sets into one set.
I like the fact that
> This topic has been beat to death. deraadt@ and other have made it clear that
> if you do not install all the sets, you are running an unsupported
> configuration. It has been stated that if people keep bitching, they're just
> going to merge the release sets into one set.
>
> I like the
On 2019-11-23 13:45, Rachel Roch wrote:
- maybe sysupgrade needs to be patched to avoid this issue?
Probably not. sysupgrade has assumptions baked in to it which have
evidently been rendered invalid either by another tool or by the
person using them. That tool is where the patch most
>> - maybe sysupgrade needs to be patched to avoid this issue?
>>
>
> Probably not. sysupgrade has assumptions baked in to it which have
> evidently been rendered invalid either by another tool or by the
> person using them. That tool is where the patch most likely ought
> to be directed.
>
>
‐‐‐ Original Message ‐‐‐
On Friday, November 22, 2019 11:45 AM, Stuart Henderson
wrote:
> A combination of things:
>
> - You didn't install the comp set before
Thank you Stuart for your detailed mail. That's exactly it, I did not have
comp65.tgz set installed as I just recently read
On 2019-11-22, mabi wrote:
> Hi,
>
> I just tried out sysupgrade on one of my OpenBSD 6.5 servers in order to
> upgrade automatically to 6.6 but unfortunately it failed at the comp66.tgz
> and rebooted (upgrade log below).
>
> It looks like I am now running a half-upgraded hybrid OpenBSD
mabi writes:
> Hi,
>
> - reason why it failed?
It cannot remove /usr/include/machine because it is not empty.
> - what should I do now? retry to upgrade with sysupgrade?
Empty /usr/include/machine.
> - re-install the whole system?
If you like. It will certainly empty out /usr/include/machine.
Hi,
I just tried out sysupgrade on one of my OpenBSD 6.5 servers in order to
upgrade automatically to 6.6 but unfortunately it failed at the comp66.tgz and
rebooted (upgrade log below).
It looks like I am now running a half-upgraded hybrid OpenBSD 6.5/6.6 system.
It also didn't manage to
12 matches
Mail list logo
