Re: Support for sunxi-based ARM systems in d-i
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.
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. 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.
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: