[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Fixing stretch debian-installer on armhf

On Thursday 07 March 2019 08:39:19 Cyril Brulebois wrote:

> 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).
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 <http://geneslinuxbox.net:6309/gene>

Reply to: