Re: Support for sunxi-based ARM systems in d-i
On Tue, 2014-05-06 at 21:24 +0200, Karsten Merker wrote:
> On Tue, May 06, 2014 at 08:25:58AM +0100, Ian Campbell wrote:
> > On Tue, 2014-05-06 at 00:39 +0100, Ben Hutchings wrote:
> > > On Mon, 2014-05-05 at 20:17 +0100, Ian Campbell wrote:
> > > > On Mon, 2014-05-05 at 20:39 +0200, Karsten Merker wrote:
> > > > > As can be seen above, the kernel package does not create symlinks in
> > > > > /boot. It creates symlinks in /, but as it is possible (and sometimes even
> > > > > necessary, e.g. with encrypted root) to have /boot on a seperate filesystem,
> > > > > these are unusable in a boot script.
> > > >
> > > > Hrm, I thought if /boot was separate the symlink would be made in /boot,
> > > > so /vmlinuz of the boot device (whether that was / or /boot) was always
> > > > valid. Seems like I was wrong -- I have two systems with separate /boot,
> > > > and one has the symlinks in / the other in /boot (and I only looked at
> > > > the second last time around). I think I must have some tweaks
> > > > to /etc/kernel-img.conf (specifically to link_in_boot) which I'd
> > > > forgotten about, sorry for that.
> > > >
> > > > This does make me wonder if f-k with your patch needs to be more careful
> > > > about overwriting /boot/vmlinuz in case it is a symlink.
> > >
> > > The official kernel packages will put symlinks in boot if you put:
> > >
> > > link_in_boot = yes
> > >
> > > in /etc/kernel-img.conf. I believe the Debian installer does that for
> > > some architectures.
> >
> > Both the systems I was referring to were x86 so I suppose I've been
> > messing with one of them at some point (or maybe the default has
> > changed).
> >
> > But yes, you are right, I can see that the base-installer package has a
> > debconf key for link_in_boot which is defaulted based on architecture.
> > It's true by default and false for alpha, i386, amd64, ia64, mips,
> > mipsel and m68k (see base-installer/debian/templates-arch).
> >
> > AFAICT it should end up true for an armhf installation, but that is
> > contradicted by what Karsten is seeing. Perhaps because the necessary
> > kernel isn't in the archive yet so it is being fixed up by hand after
> > the fact, which misses out on the d-i tailoring?
>
> Hello,
>
> sorry for the confusion I have caused - with the information
> above it now gets clear why we see different behaviour. My tests
> have been run on my development system, which has originally been
> debootstrapped by hand, so there was no d-i that could have
> altered the kernel package behaviour which appears to be not to
> put symlinks in /boot by default.
>
> I had tested both a setup with /boot on the root filesystem as
> well as /boot being on a seperate partition, and I had also
> counterchecked my amd64 box, which showed exactly the same
> behaviour, but I had not thought of the possibility that
> specifically an armhf system being installed by d-i could behave
> differently in this regard from both a manually debootstrapped
> armhf system as well as from a d-i-installed amd64 system.
Yeah, it didn't occur to me either. It was particularly unfortunate (or
furtunate?) that I first looked at an amd64 machine in a non-default
configuration!
> So this means that on an armhf system set up by d-i, the symlinks
> are actually in place where we need them for the boot scripts.
FWIW I confirmed last night that running through d-i on a cubietruck I
ended up with the links in /boot.
> I
> am very short on time at the moment, so I can't work on the
> topic now, but I'll look into it again some time later this week.
Great, I think things should be a lot simpler now we can rely on the
symlinks being in a useful place!
FWIW at some point I think I should add a second kernel postinst hook to
flash kernel which populates /boot/dtb-$version and a default dtb
symlink to it, which will simplify things even further I think, but that
needn't block the approach you were taking (the usual copy the dtb
approach).
Ian.
Reply to: