Re: Fixing stretch debian-installer on armhf

2019-03-26 Thread Vagrant Cascadian 
On 2019-03-09, Adam D. Barratt wrote:
> On Thu, 2019-03-07 at 22:01 +, 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


signature.asc
Description: PGP signature

Re: Fixing stretch debian-installer on armhf

2019-03-09 Thread Adam D. Barratt 
On Thu, 2019-03-07 at 22:01 +, 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

Re: Fixing stretch debian-installer on armhf

2019-03-07 Thread Cyril Brulebois 
Vagrant Cascadian  (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 (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Fixing stretch debian-installer on armhf

2019-03-07 Thread Cyril Brulebois 
Ben Hutchings  (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 (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Fixing stretch debian-installer on armhf

2019-03-07 Thread Vagrant Cascadian 
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


signature.asc
Description: PGP signature

Re: Fixing stretch debian-installer on armhf

2019-03-07 Thread Ben Hutchings 
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.




signature.asc
Description: This is a digitally signed message part

Re: Fixing stretch debian-installer on armhf

2019-03-07 Thread Gene Heskett 
On Thursday 07 March 2019 08:39:19 Cyril Brulebois wrote:

> Hi,
>
> Vagrant Cascadian  (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).
>
However, for rpi 3b's that can't be convinced to boot from spinning rust, 
I have 2 of those, u-sd images that can be dd'd to a 32GB card, and 
actually occupy only 2 or 3 GB at download time, because they've had the 
unused space removed, then restored at first boot might be quite 
popular.  Its the only way I have to update my pi's. Once up and 
running, synaptic works well. A similar situation also exists for the 
rock64's, which are 20x faster than a pi and a full arm64 arch. They are 
20x faster because the internal usb port the rpi uses is not part of the 
data path in the rock64's.

> > 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,


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page

Re: Fixing stretch debian-installer on armhf

2019-03-07 Thread Cyril Brulebois 
Hi,

Vagrant Cascadian  (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 (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Fixing stretch debian-installer on armhf

2019-03-06 Thread Vagrant Cascadian 
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


signature.asc
Description: PGP signature