Bug#782574: installation-reports: d-i does not boot on beaglebone black
Le 16/04/2015 09:20, Ian Campbell a écrit :
> On Wed, 2015-04-15 at 23:39 +0200, Cyril Brulebois wrote:
>> Karsten Merker <merker@debian.org> (2015-04-15):
>>> On Tue, Apr 14, 2015 at 06:42:57PM -0700, Vagrant Cascadian wrote:
>>>> Did some troubleshooting (far more than I expected, now I remember
>>>> why I hadn't already done this for BBB), and came up with a patch
>>>> for u-boot that makes it work with d-i by emulating some distro
>>>> bootcmd variables (similar to the patch for wandboard), and a small
>>>> patch to flash kernel to support the change in how the "bootpart"
>>>> variable is used.
>>
>> Since Karsten mentions both have to reach jessie in lockstep, I'm
>> wondering whether there should be a Breaks: somewhere to avoid some
>> breakages in case of a partial update.
>>
>>>> I've tested that it boots the armhf daily hd-media installer and
>>>> boots an installed system. I could upload a new version of u-boot if
>>>> it's deemed worth it; otherwise we'll just need more complicated
>>>> instructions for manually loading the installer on d-i. FWIW, The
>>>> netboot media via tftp works without any changes.
>>>>
>>>> If the user ever used u-boot's "saveenv" command, it may take
>>>> considerable effort resetting the environment using "env default -a"
>>>> followed by manually setting board_name, findfdt and/or fdtfile
>>>> variables so that it detects the correct .dtb. I didn't have
>>>> consistant success zeroing out the boot device, but in theory that
>>>> should work too.
>>>
>>> I had hoped to be able to spend some more time on the issue
>>> today, but things didn't work out as planned and as things are
>>> looking curently, I probably won't be able to dedicate time to it
>>> tomorrow as well.
>>>
>>> As the deadline for d-i-relevant changes is Friday, the question
>>> is what to do now. AFAICS due to the necessity to change the BBB
>>> boot script in flash-kernel when the patch is applied to u-boot,
>>> both flash-kernel and u-boot would have to enter Jessie in
>>> lockstep. As there is not enough time for regular migration to
>>> Jessie, the release team would have to urgent both packages in
>>> addition to an unblock to keep the deadline. The involved DDs
>>> are in vastly different timezones, which makes all this even more
>>> problematic. As stated above, I probably won't be able to take
>>> care of flash-kernel in time, so unless Ian would like to handle
>>> that, I do not see a a realistic chance to get this solved for
>>> Jessie.
>>>
>>> Ian, what is your take on the issue?
>>
>> So I've been thinking about this for a while and I'm not too happy about
>> possibly rushing these changes at this point. What could be considered
>> instead is having these changes staged into unstable, let them migrate
>> to testing/stretch when the freeze is lifted, and possibly backport them
>> in to the jessie first point release. A workaround can be documented in
>> the D-I Jessie RC3 errata.
>>
>> Would that seem reasonable to all people involved?
>
> Yes, IIRC from the thread the workaround is pretty simple, certainly in
> comparison with the scope of the proposed changes.
As far as I'm involved, I comfirm that the workaround is simple and
could easily be documented.
If needed, I could help documenting the it.
--
François-Régis
Reply to: