syspatch silently skipped patch 001_rip6cksum

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

syspatch silently skipped patch 001_rip6cksum

chohag
Unrelated to my other syspatch email, I ran syspatch inside a chroot (same server so ignore the identical hostname) and this happened:

drogo# syspatch
Get/Verify syspatch65-002_srtp.tgz 100% |*************************|  4316 KB    00:04
Installing patch 002_srtp
Get/Verify syspatch65-003_mds.tgz 100% |**************************| 49488 KB    01:03
Installing patch 003_mds
Relinking to create unique kernel... failed!
drogo# syspatch -l
002_srtp
003_mds
drogo# ^D

Failing to relink the kernel isn't a problem, obviously, because there isn't one but why did it skip 001_rip6cksum without so much as a comment?

The chroot was created by simply extracting all the sets (and *etc.tgz), copying some /etc files and running MAKEDEV.

Matthew

Reply | Threaded
Open this post in threaded view
|

Re: syspatch silently skipped patch 001_rip6cksum

Antoine Jacoutot-7
On Thu, Jun 06, 2019 at 10:18:46PM +0300, [hidden email] wrote:

> Unrelated to my other syspatch email, I ran syspatch inside a chroot (same server so ignore the identical hostname) and this happened:
>
> drogo# syspatch
> Get/Verify syspatch65-002_srtp.tgz 100% |*************************|  4316 KB    00:04
> Installing patch 002_srtp
> Get/Verify syspatch65-003_mds.tgz 100% |**************************| 49488 KB    01:03
> Installing patch 003_mds
> Relinking to create unique kernel... failed!
> drogo# syspatch -l
> 002_srtp
> 003_mds
> drogo# ^D
>
> Failing to relink the kernel isn't a problem, obviously, because there isn't one but why did it skip 001_rip6cksum without so much as a comment?
>
> The chroot was created by simply extracting all the sets (and *etc.tgz), copying some /etc files and running MAKEDEV.

That is because 001 only includes kernel object files which you do not have
since you run under a chroot and didn't extract /usr/share/relink/kernel.tgz
So syspatch(8) considers you don't have that "set" installed.
syspatch-003 on the other end includes a header change and that header *is*
installed on your system. So syspatch installs it. But you are missing all the
other pieces to actually relink your kernel and that's why it fails.

You are running syspatch under a totally unsupported setup.


--
Antoine

Reply | Threaded
Open this post in threaded view
|

Re: syspatch silently skipped patch 001_rip6cksum

chohag
Antoine Jacoutot writes:
> That is because 001 only includes kernel object files which you do not have
> since you run under a chroot and didn't extract /usr/share/relink/kernel.tgz
> So syspatch(8) considers you don't have that "set" installed.
> syspatch-003 on the other end includes a header change and that header *is*
> installed on your system. So syspatch installs it. But you are missing all the
> other pieces to actually relink your kernel and that's why it fails.

Thank-you that makes sense.

It did throw me a little though; I would expect a tool such as this to report its inaction as well as its action.

I take it that syspatch performs these checks also with the other sets? eg. It would skip an X patch if the X sets were not installed?

> You are running syspatch under a totally unsupported setup.

This is a common refrain and I do understand why it's used but it's not a concern. I'm not after support, I can put the pieces back together when I break them.

But is 'all the sets' the only configuration which OpenBSD's tools consider valid in general? 'Supported'?

In any case I still do think there's a bug here but now it's clear that it's one of:

 * syspatch doesn't report skipping patches (it also skipped a kernel patch when it recognised the lack of kernel but attempted to relink it later anyway for another patch, which will boil down to the same test).

 * syspatch's manpage doesn't fully describe its behaviour when one or more sets are mising.

Please note that I'm not whinging that OpenBSD doesn't work the way I demand and insisting on change. I've noticed there's been a lot of that recently. I've found what I deem to be a fault and, if anyone else agrees, would like suggestions on how I could fix it (chiefly, which of the above is the real bug) and I will follow up with a patch.

Or neither and I'll just deal with it locally.

Matthew

Reply | Threaded
Open this post in threaded view
|

Re: syspatch silently skipped patch 001_rip6cksum

Antoine Jacoutot-7
On Fri, Jun 07, 2019 at 02:49:32AM +0300, [hidden email] wrote:

> Antoine Jacoutot writes:
> > That is because 001 only includes kernel object files which you do not have
> > since you run under a chroot and didn't extract /usr/share/relink/kernel.tgz
> > So syspatch(8) considers you don't have that "set" installed.
> > syspatch-003 on the other end includes a header change and that header *is*
> > installed on your system. So syspatch installs it. But you are missing all the
> > other pieces to actually relink your kernel and that's why it fails.
>
> Thank-you that makes sense.
>
> It did throw me a little though; I would expect a tool such as this to report its inaction as well as its action.
>
> I take it that syspatch performs these checks also with the other sets? eg. It would skip an X patch if the X sets were not installed?

Yes that's correct.
 
> > You are running syspatch under a totally unsupported setup.
>
> This is a common refrain and I do understand why it's used but it's not a concern. I'm not after support, I can put the pieces back together when I break them.
>
> But is 'all the sets' the only configuration which OpenBSD's tools consider valid in general? 'Supported'?

Well, it's not really about the sets.

From the man page:

CAVEATS
     syspatch is designed to work solely on official OpenBSD releases.

What you are running is not.
An official release comes with a kernel.
One can skip a set but if I think it's fair for the tools to assume one has
at least one kernel and baseXX installed...

> In any case I still do think there's a bug here but now it's clear that it's one of:
>
>  * syspatch doesn't report skipping patches (it also skipped a kernel patch when it recognised the lack of kernel but attempted to relink it later anyway for another patch, which will boil down to the same test).
I explained why.
It sees that there's a candidate for replacement (in this case some headers), so
it extracts the patch. Since it also contains kernel objects files, it will run
reorder_kernel, but you didn't extract the release object files in your chroot
(which the installer does)... so boom.

>  * syspatch's manpage doesn't fully describe its behaviour when one or more sets are mising.

We accept patches for man pages :-)

> Please note that I'm not whinging that OpenBSD doesn't work the way I demand and insisting on change. I've noticed there's been a lot of that recently. I've found what I deem to be a fault and, if anyone else agrees, would like suggestions on how I could fix it (chiefly, which of the above is the real bug) and I will follow up with a patch.

Documentation is clear that syspatch only works on releases. Your chroot is not
because you didn't extract some sets from the baseXX set (and again, IMHO it's
fine for our tools to assume you have at least that particular set installed).

--
Antoine

Reply | Threaded
Open this post in threaded view
|

Re: syspatch silently skipped patch 001_rip6cksum

Theo de Raadt-2
Summary:  Not a bug.

Antoine Jacoutot <[hidden email]> wrote:

> On Fri, Jun 07, 2019 at 02:49:32AM +0300, [hidden email] wrote:
> > Antoine Jacoutot writes:
> > > That is because 001 only includes kernel object files which you do not have
> > > since you run under a chroot and didn't extract /usr/share/relink/kernel.tgz
> > > So syspatch(8) considers you don't have that "set" installed.
> > > syspatch-003 on the other end includes a header change and that header *is*
> > > installed on your system. So syspatch installs it. But you are missing all the
> > > other pieces to actually relink your kernel and that's why it fails.
> >
> > Thank-you that makes sense.
> >
> > It did throw me a little though; I would expect a tool such as this to report its inaction as well as its action.
> >
> > I take it that syspatch performs these checks also with the other sets? eg. It would skip an X patch if the X sets were not installed?
>
> Yes that's correct.
>  
> > > You are running syspatch under a totally unsupported setup.
> >
> > This is a common refrain and I do understand why it's used but it's not a concern. I'm not after support, I can put the pieces back together when I break them.
> >
> > But is 'all the sets' the only configuration which OpenBSD's tools consider valid in general? 'Supported'?
>
> Well, it's not really about the sets.
>
> From the man page:
>
> CAVEATS
>      syspatch is designed to work solely on official OpenBSD releases.
>
> What you are running is not.
> An official release comes with a kernel.
> One can skip a set but if I think it's fair for the tools to assume one has
> at least one kernel and baseXX installed...
>
> > In any case I still do think there's a bug here but now it's clear that it's one of:
> >
> >  * syspatch doesn't report skipping patches (it also skipped a kernel patch when it recognised the lack of kernel but attempted to relink it later anyway for another patch, which will boil down to the same test).
> I explained why.
> It sees that there's a candidate for replacement (in this case some headers), so
> it extracts the patch. Since it also contains kernel objects files, it will run
> reorder_kernel, but you didn't extract the release object files in your chroot
> (which the installer does)... so boom.
>
> >  * syspatch's manpage doesn't fully describe its behaviour when one or more sets are mising.
>
> We accept patches for man pages :-)
>
> > Please note that I'm not whinging that OpenBSD doesn't work the way I demand and insisting on change. I've noticed there's been a lot of that recently. I've found what I deem to be a fault and, if anyone else agrees, would like suggestions on how I could fix it (chiefly, which of the above is the real bug) and I will follow up with a patch.
>
> Documentation is clear that syspatch only works on releases. Your chroot is not
> because you didn't extract some sets from the baseXX set (and again, IMHO it's
> fine for our tools to assume you have at least that particular set installed).
>
> --
> Antoine
>