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. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1399454195.3014.220.ca...@kazak.uk.xensource.com
