Re: Uploading linux (4.3.1-1)
Lennart Sorensen wrote on 2015-12-07 15:12: > > Hmm, dropping 586 made me think GeodeLX would stop working, but a bit > if research indicates it does work with the 686 kernel these days. Whew! But I think Geode LX doesn't work with 686. I have one so I will test it in the next week with the new kernel. --- Have a nice day. Joachim (Germany) pgpu62AKAmrLz.pgp Description: Digitale Signatur von OpenPGP
new nfs-utils package 1.3.3 - already tested
Hello kernel team, after many problems with the nfs-utils in Testing I went the hard way and made a Debian package from the newest version 1.3.3. I also looked to the (old) package in Ubuntu and have tried to merge the source patches of Debian and Ubuntu. After many tests and changes I got a package which make a good job in my local network for two days. I hope you can use my results which you find here: http://www.joonet.de/sources/nfs-utils/debian/ --- Have a nice day. Joachim (Germany) pgphbZnua78mG.pgp Description: Digitale Signatur von OpenPGP
detecting architecture from vmlinuz
Hello, [ I am not subscribed to debian-kernel ] I have found a problem in the bootloader lilo because lilo compute the uncompressed size of vmlinuz (-> vmlinux) with an algorithm which is false for especially the amd64 architecture. My question: is there a way to detect the right architecture only from the compressed file vmlinuz to compute the size of the uncompressed file vmlinux depending on the architecture? Or does anyone know another (quick) way for reading the real size of vmlinux without uncompressing vmlinuz? (Reason: It make no sense for each detection to uncompress the vmlinuz file, which is need to know how much memory is need for the kernel). Have a nice day, Joachim (Germany) signature.asc Description: PGP signature
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
Hello William, perhaps you have read the recent email from Ben (see below). It would be important to update the lilo package to support these recent requirements to prepare LILO for Squeeze before it will get stable. Do you have the intention to update the lilo package to integrate some scripts for these recent requirements? Have a nice day, Joachim (Germany) --- Ben Hutchings wrote on 2010-06-28 03:02: > I propose the following policy for squeeze and later releases. This > affects all Linux kernel, initramfs builder and boot loader packages, > and the installer. > > I regret that this is happening so late in the release cycle, but > currently a kernel update can easily leave the system unbootable and > this does need to be addressed before release and I want to do so in a > way that is reasonably clean and maintainable. > > --- > 1. Packages for boot loaders that need to be updated whenever the files > they load are modified (i.e. those that store a block list) must install > hook scripts in /etc/kernel/postinst.d and /etc/kernel/postrm.d, which > will be called on installation/upgrade and removal of kernel packages, > respectively. > > The arguments given to all kernel hook scripts are the kernel ABI > version (the string that uname -r reports) and the absolute path to the > kernel image. The environment variable DEB_MAINT_PARAMS will contain > the arguments given to the kernel maintainer script, single-quoted. > > Since these boot loaders should be updated as the last step during > installation/upgrade and removal, hook scripts for boot loaders must be > named using the prefix 'zz-' and no other packages may use this prefix > or one that sorts later by the rules used by run-parts. A postrm hook > script should warn but exit with code 0 if the boot loader configuration > file still refers to the kernel image that has been removed. > > 2. Packages for boot loaders that need to be updated whenever the files > they load are modified must also install hook scripts in > /etc/mkinitramfs/post-update.d. Initramfs builders must call these > scripts using run-parts after they create, update or delete an > initramfs. The arguments given to these hook scripts are the kernel ABI > version and the absolute path to the initramfs image. > > 3. Initramfs builders must complete their work before returning from the > kernel postinst hook script. [initramfs-tools currently uses a trigger > to defer this because it can also be invoked twice, but this means it > also has to know how to update specific boot loaders.] > > 4. During a kernel package installation, upgrade or removal, various > boot loader hooks may be invoked (in this order): > > a. A postinst_hook or postrm_hook command set by the user or the >installer in /etc/kernel-img.conf > b. A hook script in /etc/mkinitramfs/post-update.d > c. A hook script in /etc/kernel/postinst.d or .../postrm.d > > To avoid unnecessary updates, the hooks invoked at step a and b may > check whether $DPKG_MAINTSCRIPT_PACKAGE begins with 'linux-image-' and > do nothing in this case. [Is this sensible or is it too 'clever'?] > > 5. Kernel and initramfs builder packages must not invoke boot loaders > except via hooks. If /etc/kernel-img.conf contains an explicit > 'do_bootloader = yes', kernel package maintainer scripts should warn > that this is now ignored. > > 6. The installer must not define do_bootloader, postinst_hook or > postrm_hook in /etc/kernel-img.conf. > --- > > I'm particularly interested to hear whether there are any upgrade issues > I have not addressed. > > Ben. > signature.asc Description: PGP signature
Re: Call for Testing: initramfs-tools 0.97
Michael Prokop wrote on 2010-06-18 23:48: > we - the initramfs-tools maintainers in Debian - want to provide a > solid initramfs-tools version for squeeze. The new release 0.97 is > expected to fix many longstanding problems. It would be great if we > could receive feedback from testers. > > The new release is available from Debian/unstable and is expected to > install without problems in at least lenny, squeeze and sid: > > > http://cdn.debian.net/debian/pool/main/i/initramfs-tools/initramfs-tools_0.97_all.deb > SHA256:56eb56d472d0dd24c8f2fd030222586e258ec882b716f02d114865cef9c19639 > > No matter how your partition layout looks like (rootfs on lvm, > crypto, sw-raid,...), if you're booting on physical hardware or a > virtualized system (Xen, openvz, kvm,...) - please give it a shot > and report any possible problems. I have checked the scripts and I was very happy to see that lilo is furthermore supported by initramfs-tools (script update-initramfs). Can I be sure that this support stay in your package? Because of changes in some other packages this would be nearly an existential question. FYI: Lilo have again an upstream developer - myself. If you have some hints for better work together with your package so feel free to send me a mail. Have a nice day, Joachim (Germany) signature.asc Description: PGP signature
Re: [RFC] Updating boot loaders in lenny and squeeze
Hello, Ben Hutchings wrote on 2010-06-19 03:55: > However, given that route B is present in both lenny and squeeze (and > even in etch, I think) there is no good reason for packages not to rely > on it now. (Well, except lack of documentation.) All boot loader > packages that fall into case 1 or 2 should be installing hook scripts, > but currently only extlinux does. I intend to remove the vestigial code > for route A, and file bugs on all boot loaders in case 1 or 2 that do > not use route B. It seems this is the first step for optimizing lilo. I have checked the sources for extlinux (package syslinux) and the scripts appears to be simple. > In case 1, the boot loader should also be called by update-initramfs > when it is called outside of kernel package installation and removal. > This is normally covered by route D, but this seems a little fragile. I I have tested this behaviour with a hook script for update-initramfs. There is still a problem: Until now in the script is a check about which bootloader is active. Only if no grub is installed then the script starts lilo after install/update/remove of initrd's. But this feature shall go away and then a hook script for update-initramfs is a good solution (in /etc/initramfs-tools/hooks/). Over all - thanks for you very detailed information. Now I think the lilo package can better maintained again. Have a nice day, Joachim (Germany) signature.asc Description: PGP signature
Bug#505609: loader varialbe in kernel maintainer scripts
Ben Hutchings wrote on 2010-06-18 02:02:
> On Thu, 2010-06-17 at 20:37 -0400, Stephen Powell wrote:
> > On Thu, 17 Jun 2010 18:11:04 -0400 (EDT), Ben Hutchings wrote:
:
:
> > And how would one go about setting this "loader" variable?
> > The "loader" variable is not documented in the man page for
> > /etc/kernel-img.conf in Lenny, which appears to be the closest thing
> > there is to documentation for the variables supported by official
> > Debian stock kernel images. Nevertheless, at your suggestion, I tried
> > putting
> >
> >loader = lilo
> >
> > in /etc/kernel-img.conf. ("do_bootloader = yes" was also set.) Then I
> > issued
> >
> >dpkg-reconfigure linux-image-2.6.26-2-686
> >
> > There was no evidence from the output that lilo was run.
> [...]
>
> I'm sorry, you're right. Most of the other variables at the top of the
> postinst script can be overridden by /etc/kernel-img.conf, but not this
> one. Given that, I think you are right that the 'historical' bootloader
> setting should be restored in an update to lenny.
Now I am a little confused. How is the recommended procedure for using the
LILO bootloader within squeeze/sid ?
How I understand the normal installation of lilo package have the result,
that lilo doesn't be started after an kernel update (and also after update
of initramfs-tools ?).
What must I config on my squeeze machine that lilo bootloader will be
automatically updated after kernel update?
Fondest regards,
Joachim Wiedorn
signature.asc
Description: PGP signature
