Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #63510 > unrolled thread

Fixing stretch debian-installer on armhf

Started byVagrant Cascadian <vagrant@debian.org>
First post2019-03-07 03:00 +0100
Last post2019-03-26 21:50 +0100
Articles 8 — 4 participants

Back to article view | Back to linux.debian.kernel

Contents

  Fixing stretch debian-installer on armhf Vagrant Cascadian <vagrant@debian.org> - 2019-03-07 03:00 +0100
    Re: Fixing stretch debian-installer on armhf Cyril Brulebois <kibi@debian.org> - 2019-03-07 14:40 +0100
      Re: Fixing stretch debian-installer on armhf Ben Hutchings <ben@decadent.org.uk> - 2019-03-07 23:10 +0100
        Re: Fixing stretch debian-installer on armhf Vagrant Cascadian <vagrant@debian.org> - 2019-03-07 23:40 +0100
          Re: Fixing stretch debian-installer on armhf Cyril Brulebois <kibi@debian.org> - 2019-03-08 00:00 +0100
        Re: Fixing stretch debian-installer on armhf Cyril Brulebois <kibi@debian.org> - 2019-03-08 00:00 +0100
        Re: Fixing stretch debian-installer on armhf "Adam D. Barratt" <adam@adam-barratt.org.uk> - 2019-03-09 12:10 +0100
          Re: Fixing stretch debian-installer on armhf Vagrant Cascadian <vagrant@debian.org> - 2019-03-26 21:50 +0100

#63510 — Fixing stretch debian-installer on armhf

FromVagrant Cascadian <vagrant@debian.org>
Date2019-03-07 03:00 +0100
SubjectFixing stretch debian-installer on armhf
Message-ID<xyQud-3K5-1@gated-at.bofh.it>

[Multipart message — attachments visible in raw view] — view raw

Due to #922478, the debian-installer images for stretch are currently
not bootable on the armhf architecture.

While the linux kernel packages have been fixed in stretch-updates and
stretch-proposed-updates, the debian-installer images still were built
with the broken kernel.

Even rebuilding the debian-installer images, while pulling in a working
kernel that would boot, debian-installer would load .udeb modules from
stretch, not stretch-updates. This might be ok for hd-media targets or
targets that do not load module .udeb files from the network, but
netboot targets are not likely to work at all.

So some of the options at the moment appear to be:

* Wait for another point release, rebuild debian-installer, leaving
  debian-installer on armhf broken until then. How long till the next
  point release?

* Rebuild the debian-installer images, pulling in updates from
  stretch-updates, leaving only armhf netboot targets broken. 

* Another point release with the kernel update sooner than planned, and
  rebuild debian-installer images.

* Other options?


In the future, I plan on setting up at least one or two of armhf
machines running stable-proposed-updates to try to catch this sort of
thing before release...


live well,
  vagrant

[toc] | [next] | [standalone]

#63515

FromCyril Brulebois <kibi@debian.org>
Date2019-03-07 14:40 +0100
Message-ID<xz1pD-2hT-5@gated-at.bofh.it>
In reply to#63510

[Multipart message — attachments visible in raw view] — view raw

Hi,

Vagrant Cascadian <vagrant@debian.org> (2019-03-06):
> Even rebuilding the debian-installer images, while pulling in a
> working kernel that would boot, debian-installer would load .udeb
> modules from stretch, not stretch-updates. This might be ok for
> hd-media targets or targets that do not load module .udeb files from
> the network, but netboot targets are not likely to work at all.

To clarify, from an earlier IRC conversations (#-boot yesterday,
#-kernel a couple of days ago): we're mostly considering rebuilding
src:debian-installer, not respinning ISO images (those don't seem to
be in widespread use in the arm* world).

> So some of the options at the moment appear to be:
> 
> * Wait for another point release, rebuild debian-installer, leaving
>   debian-installer on armhf broken until then. How long till the next
>   point release?

This wasn't confirmed yet but April 27 seems to be the front runner at
this stage.

> * Rebuild the debian-installer images, pulling in updates from
>   stretch-updates, leaving only armhf netboot targets broken. 

Expanding a bit: rebuilding src:debian-installer from the stretch
branch, which has s-p-u enabled, would fetch the fixed kernel and a
couple of its udebs, at build time; the resulting netboot images
wouldn't know about s-p-u though at run time, and would try to load
udebs from stretch. Even if we were to have some kind of support for
loading udebs from stretch and from s-p-u (backports support patches
could help), that would only be an option until a new linux is accepted
into s-p-u.

Finally, for completeness, there's no specific suppport regarding
stretch-updates; we pull stuff from a given suite and optionally from
$suite-p-u; of course, we could still switch from s-p-u to s-u for one
particular upload…

> * Another point release with the kernel update sooner than planned,
>   and rebuild debian-installer images.

This was brought up on #-kernel and it didn't spark joy (lots of teams
need to be around for a point release)…


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[toc] | [prev] | [next] | [standalone]

#63520

FromBen Hutchings <ben@decadent.org.uk>
Date2019-03-07 23:10 +0100
Message-ID<xz9nc-7xr-9@gated-at.bofh.it>
In reply to#63515

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2019-03-07 at 14:39 +0100, Cyril Brulebois wrote:
[...]
> > * Rebuild the debian-installer images, pulling in updates from
> >   stretch-updates, leaving only armhf netboot targets broken. 
> 
> Expanding a bit: rebuilding src:debian-installer from the stretch
> branch, which has s-p-u enabled, would fetch the fixed kernel and a
> couple of its udebs, at build time; the resulting netboot images
> wouldn't know about s-p-u though at run time, and would try to load
> udebs from stretch.
[...]

Why is that a problem?  The only change made in 4.9.144-3.1 is in the
kernel image, and the module udebs don't have versioned dependencies.

Ben.

-- 
Ben Hutchings
friends: People who know you well, but like you anyway.

[toc] | [prev] | [next] | [standalone]

#63522

FromVagrant Cascadian <vagrant@debian.org>
Date2019-03-07 23:40 +0100
Message-ID<xz9Qd-7Ko-11@gated-at.bofh.it>
In reply to#63520

[Multipart message — attachments visible in raw view] — view raw

On 2019-03-07, Ben Hutchings wrote:
> On Thu, 2019-03-07 at 14:39 +0100, Cyril Brulebois wrote:
> [...]
>> > * Rebuild the debian-installer images, pulling in updates from
>> >   stretch-updates, leaving only armhf netboot targets broken. 
>> 
>> Expanding a bit: rebuilding src:debian-installer from the stretch
>> branch, which has s-p-u enabled, would fetch the fixed kernel and a
>> couple of its udebs, at build time; the resulting netboot images
>> wouldn't know about s-p-u though at run time, and would try to load
>> udebs from stretch.
> [...]
>
> Why is that a problem?  The only change made in 4.9.144-3.1 is in the
> kernel image, and the module udebs don't have versioned dependencies.

If that's indeed the case, then that does seem like the best
approach. Happy to test images to confirm.


live well,
  vagrant

[toc] | [prev] | [next] | [standalone]

#63524

FromCyril Brulebois <kibi@debian.org>
Date2019-03-08 00:00 +0100
Message-ID<xza9z-7RF-5@gated-at.bofh.it>
In reply to#63522

[Multipart message — attachments visible in raw view] — view raw

Vagrant Cascadian <vagrant@debian.org> (2019-03-07):
> If that's indeed the case, then that does seem like the best approach.
> Happy to test images to confirm.

Rebuilding the stretch debian-installer source package within stretch
should give you everything you need to test. Beware if you go for a
manual build instead (make under build/, with a specific target), as
you'd need to pass some extra variable (see debian/rules).


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[toc] | [prev] | [next] | [standalone]

#63525

FromCyril Brulebois <kibi@debian.org>
Date2019-03-08 00:00 +0100
Message-ID<xza9z-7RF-1@gated-at.bofh.it>
In reply to#63520

[Multipart message — attachments visible in raw view] — view raw

Ben Hutchings <ben@decadent.org.uk> (2019-03-07):
> On Thu, 2019-03-07 at 14:39 +0100, Cyril Brulebois wrote:
> [...]
> > > * Rebuild the debian-installer images, pulling in updates from
> > >   stretch-updates, leaving only armhf netboot targets broken. 
> > 
> > Expanding a bit: rebuilding src:debian-installer from the stretch
> > branch, which has s-p-u enabled, would fetch the fixed kernel and a
> > couple of its udebs, at build time; the resulting netboot images
> > wouldn't know about s-p-u though at run time, and would try to load
> > udebs from stretch.
> [...]
> 
> Why is that a problem?  The only change made in 4.9.144-3.1 is in the
> kernel image, and the module udebs don't have versioned dependencies.

I had planned to clarify in this mail thread the limitations I was
mentioning in my early replies on IRC. I don't think I've said this
specific combination of kernel and udebs can't work. I hope people
knowledgeable about kernel and arm* stuff can figure out both what
theory (source code/packaging) and reality (tests on actual HW) look
like.


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[toc] | [prev] | [next] | [standalone]

#63533

From"Adam D. Barratt" <adam@adam-barratt.org.uk>
Date2019-03-09 12:10 +0100
Message-ID<xzI1z-4du-1@gated-at.bofh.it>
In reply to#63520
On Thu, 2019-03-07 at 22:01 +0000, Ben Hutchings wrote:
> On Thu, 2019-03-07 at 14:39 +0100, Cyril Brulebois wrote:
> [...]
> > > * Rebuild the debian-installer images, pulling in updates from
> > >   stretch-updates, leaving only armhf netboot targets broken. 
> > 
> > Expanding a bit: rebuilding src:debian-installer from the stretch
> > branch, which has s-p-u enabled, would fetch the fixed kernel and a
> > couple of its udebs, at build time; the resulting netboot images
> > wouldn't know about s-p-u though at run time, and would try to load
> > udebs from stretch.
> 
> [...]
> 
> Why is that a problem?  The only change made in 4.9.144-3.1 is in the
> kernel image, and the module udebs don't have versioned dependencies.

However, as an additional data point, the kernel currently sat in NEW
and destined for stable has an ABI bump. If that's accepted, then I
assume things will "just work" in the meantime as the old binary
packages will hang around until they're decrufted, but it's worth
bearing in mind.

Regards,

Adam

[toc] | [prev] | [next] | [standalone]

#63701

FromVagrant Cascadian <vagrant@debian.org>
Date2019-03-26 21:50 +0100
Message-ID<xG1bb-81X-3@gated-at.bofh.it>
In reply to#63533

[Multipart message — attachments visible in raw view] — view raw

On 2019-03-09, Adam D. Barratt wrote:
> On Thu, 2019-03-07 at 22:01 +0000, Ben Hutchings wrote:
>> On Thu, 2019-03-07 at 14:39 +0100, Cyril Brulebois wrote:
>> [...]
>> > > * Rebuild the debian-installer images, pulling in updates from
>> > >   stretch-updates, leaving only armhf netboot targets broken. 
>> > 
>> > Expanding a bit: rebuilding src:debian-installer from the stretch
>> > branch, which has s-p-u enabled, would fetch the fixed kernel and a
>> > couple of its udebs, at build time; the resulting netboot images
>> > wouldn't know about s-p-u though at run time, and would try to load
>> > udebs from stretch.
>> 
>> [...]
>> 
>> Why is that a problem?  The only change made in 4.9.144-3.1 is in the
>> kernel image, and the module udebs don't have versioned dependencies.
>
> However, as an additional data point, the kernel currently sat in NEW
> and destined for stable has an ABI bump. If that's accepted, then I
> assume things will "just work" in the meantime as the old binary
> packages will hang around until they're decrufted, but it's worth
> bearing in mind.

A debian-installer build for stretch-proposed-updates was made, which
may not get merged into stretch before the next point release. For the
time being:

  https://deb.debian.org/debian/dists/stretch-proposed-updates/main/installer-armhf/

I've successfully tested version "20170615+deb9u5+b3", as well as at
least one other person. It should continue to work until the next point
release, and I'll do at least some minimal testing of the next point
release on armhf before pushing it to stretch so this doesn't happen
again.

More details in:

  https://bugs.debian.org/924129


live well,
  vagrant

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web