Hang in clock-setup and when booting the installed system on an A20-Olinuxino-Lime2 (was: Archive changes)
[Limited the address list to debian-boot as the remaining issues
are independent from the archive changes that originally triggered
this thread]
On Fri, Mar 25, 2016 at 01:10:12PM +0100, Karsten Merker wrote:
> On Fri, Mar 25, 2016 at 06:54:27PM +0900, Roger Shimizu wrote:
> > On Thu, Mar 24, 2016 at 10:29 PM, Roger Shimizu <rogershimizu@gmail.com> wrote:
> > > On Thu, Mar 24, 2016 at 5:50 PM, Christian PERRIER <bubulle@debian.org> wrote:
> > >> Thanks for investigating (and hopefully fixing) this. I just upload
> > >> net-retriever with your changes.
> > >
> > > Appreciated your help!
> > > So I can test tomorrow's d-i daily, again.
> >
> > I confirm today's d-i daily is able to proceed the install, for
> > armel/marvell and amd64 platform.
> >
> > > Karsten,
> > If it's in your convenient, could you help to test on your armhf device again?
>
> Net-retriever works in today's daily d-i build:
>
> https://d-i.debian.org/daily-images/armhf/20160325-00:33/netboot/
>
> but I have stumbled to over two other problems in d-i (which are probably
> unrelated to the archive changes):
>
> Clock-setup hangs (installation continues after clock-setup has been
> canceled) and the installed system boots, but doesn't bring up a getty.
> I'll try to debug this further.
The clock-setup issue seems to be an intermittent problem. It
didn't occur always and since today I cannot reproduce it anymore
at all. Maybe there was a problem with one of the round-robin
NTP servers behind 0.debian.pool.ntp.org.
The hang of the installed system on an A20-Olinuxino-Lime2 seems
to be caused by a locked-up i2c bus, which in turn seems to be an
indirect result of a regulator-related change in u-boot v2016.03
(which has recently entered sid and stretch) together with the
regulator settings in the kernel's dts file for the board. The
precise mechanism that leads to the bus lock-up is still being
investigated and it is not yet finally decided whether the issue
is to be worked around on the u-boot or on the kernel side. If
somebody is interested in more details, please read the threads
at:
u-boot:
http://lists.denx.de/pipermail/u-boot/2016-March/249119.html
kernel:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/417786.html
The hang occurs only in the installed system but not in d-i
because the module udebs in d-i don't contain the relevant i2c
controller driver while the regular kernel deb does.
Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
Reply to: