Re: bits from the release team
Sorry for the long mail, but i believe there is something important all the way done, so if you cannot be bothered to read it all; please go down to the point marked *IMPORTANT*. On Tue, Jan 03, 2006 at 10:05:04PM -0800, Steve Langasek wrote: > You have been harranguing the ftp team to approve new upstream kernels Wrong, i have asked Gannef to do it quicker NEW handling, and i told him about this as soon as i found out about the 2.6.15 kernel release, since i believe infomring folk early is good courtesy if you want them to do stuff for you, as they can then more easily fit it in their schedule. Notice that NEW handling is also important in this case, since the autobuilders will build out of incoming, but not out of NEW, and since kernels are rather long in building, this is an additional delay. I may have been more insistent, and thus more dissapointed when it failed to happen the same day, for the 2.6.14 release, since this one culminated an intense work session of the whole debian-kernel team to make the 2.6.12->2.6.14 transition with initrd-tools going away and co happen. We are speaking of 2 to 3 weeks of intense work on the -rc serie, which culminated in the release, with the claimed aim to do 0-day uploads which many many believed was not possible, and it didn't happen not for technical reasons, but for bureaucratic details. You would feal the same, but on a larger scale when you where about to announce the release, and you couldn't for some stupid reason fully not under your control and you believe it is an unnecessary issue. Can you honestly say we wouldn't hear you rant about it afterward ? But again, this is the second time this happens, so as soon as i knew, i informed Ganneff, and didn't harrangue or demand or whatever, just informed. I _did_ rant about the not-really-need for NEW in these cases, but that is unrelated. > through the NEW queue before they've even been uploaded -- for an amazing > false optimization that burns good will with your fellow developers. Even Yes, and we are all volunteers, the preparation of a release like the 2.6.14 one had demanded effort and sacrifice from about a dozen persons, do you not think it burns good will to work on this if you fail to achieve your stated goal for bureaucratic details, i know my motivation fell a bit when we did indeed miss dinstall. > if udebs *were* being built from the same linux-2.6 source package, this > doesn't address the real reason why it's important to freeze the kernel > early: *the kernel is a core component of everyone's system and detecting > regressions takes a long time*. Anything that requires a reboot cycle or an How long a time ? A month, two month, four month ? And what is the cost balance between backporting all those fixes from the new version, and simply using the new version. Also, with the new approach of building -rc releases in experimental, we have easily another month or so of time to test the kernels, and the possibility to correct at least part of the issues in upstream before even the release. But sure, there are issues, but i don't believe they are as time consuming as you make them. > installation test in order for users to detect bugs is going to need a > longer testing period than other packages; the only way to ensure this > happens is by freezing it early, i.e., around the same time as the toolchain > packages for which we have the same problem of figuring out whether a new > version is better or worse. Bah, ... I can guarantee you users are quick in testing new kernels, part of them are, and we test them ourself also and run them, so major issues are found early. we knew about the powerpc debconf/postinst script fuckage before he package left incoming, altough there was no way to stop it from entering the archive, and the bug reports came in very very shortly after dinstall. > The underlying assumption in your plea for a shorter kernel freeze is "newer > is better". But people who accept this assumption unconditionally don't > *run* Debian stable; so neither should we base our freeze timeline on an Bah, they run stable with sid/experimental or self built kernels, which is the sanest thing to do, especially given the messy kernel stable security situation, which i warned you about in april. > unconditional acceptance of it. Newer isn't necessarily better, but it is > necessarily *different*, which is the enemy of stability. No. the kernel evolves, but more importantly issues get fixed. There are some newer breakage that may slip in, but all in all the fixing amount overweights the breakage introduced, and this breakage can be fixed, so i will have to disagree with this. But i believe the point is elsewhere, with our current plan, we will always have two release candidates in the archive, or a single good quality release candidate. All i ask, and i believe all agree on that, is that the freeze date and the choice of kernel is done solely on the quality and testing of the kernel,
Re: bits from the release team
On Wed, Jan 04, 2006 at 08:58:09AM +0100, Andreas Barth wrote: > well, the kernel is definitly about the same level as the toolchain and > standard/base - changes can have very easily impact on the installer, > and it is not an option to remove the package if it is broken. Nope, still it is more in the cqtegory of general base than essential toolchain, but as you said, it is only a week. > > > > > N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze] > > > > > N-45 = Wed 18 Oct 06: general freeze [about 2 months after base > > > > > freeze, d-i RC] > > > > > N = Mon 4 Dec 06: release [1.5 months for the general freeze] > > > > > > > > We will have a kernel which is outdated by two versions at release time > > > > with > > > > this plan, since there are about 1 kernel upstream release every 2 > > > > month. > > > > > > Well, if we want to release with a newer kernel, we need to make sure > > > d-i doesn't stumble over it. Experience tells us that there are enough > > > > What experience ? > > I was speaking about the installer. And usually there are lots of > last-minute changes that need to go in - not only new languages, but > lots of other small minor, but still important bug fixes. Indeed. I claim that the installer experience gained during the last steps of the sarge release is worthless for the current situation, as the kernel situation is lightyears from what it was back then. Failing on your part to aknowledge this would be a negation or dismissal of the work done by the kernel team during these past 6 month or so, and i would personally feel offended, and i believe others will too, if you do this. It is as if i was takign the boot-floppies experience to take conclusions on the current installer. > > > Also, the kernel will be outdated sooner or later anyways - so, if after > > > one year the kernel is 12 or 14 months old is not too much a difference. > > > > Hehe, me runs sid kernels installed almost as is on all my sarge systems > > indeed, just with rebuild yaird and mininmally backported udev. > > Well, but then an older kernel doesn't hurt you? :P Imagine an installer with a known remote security exploit, which brings up the network early in the install process. This is microsoftian kind of practice, and i want nothing to do with it, nor my name associated with it, and i believe the same for you. Still we did, if i remember well, such a kernel in the sarge installer, solely because the infrastructure didn't allow us to fix it in a timely fashion. This is understandable mere month or weeks before the sarge release, but inexcusable at this point of the release process. > > Indeed, but you have only the sarge experience to go by, and taking the > > sarge > > experience on this is hardly fair to the huge amount the kernel team has > > devoted to streamline the process. > > Of course, we have seen that the kernel build process is way more mature > now. Nobody doubts that. and that is an euphemism. Still there is doubt about the ability of the kernel team to be able to think how this maturity can be extended beyond the kernel team, and there where harsh words about our ability voiced also, which i think are displaced. so, altough people can't honestly say they doubt it, some still think they know better with regard to kernel matters, and don't hesitate to patronize us on this. > > Also, i don't really believe joeyh and fjp > > are really the relevant maintainers with regard to the debian kernel and its > > application, since they lack the vision of how things could go better, or > > more > > thruthfully, probably lack the time and motivation to think really about the > > issue, and why should they, it is the kernel team jobs :) > > Well, they are definitly the relevant people for the installer. And, > frankly speaking, at least I have good experience with both of them. For the installer, sure, but the generation of the d-i kernel .udebs is only marginally of their relevance, and furthermore they don't want the responsability associated with it, and as proof i can show you that joeyh upgraded kernel-wedge and the x86 d-i module udebs, but didn't touch all the other architectures, defaulting it upto the porters, which are the exact same guys doing the kernel packages. So joeyh and fjp can't have it both way. And furthermore this is to make their live easier, so they have more time to concentrate on more important and core d-i work. > > d-i is only a part of the problem anyway, and i believe the less > > problematic. > > out-of-tree modules and third-party patches are a worse mess. > > Hm, which out-of-tree modules do you consider to be release critical, > i.e. we cannot release without them? Well, i guess once we kick the non-free firmware modules into the non-free part of linux-2.6, you will reconsider that, or if there are out-of-tree network or disk drivers. I would say that most of the wlan out-of-tree drivers already qualify. Frien
Bug#345913: linux-source-2.6.15: fails to compile linux bcm43xx driver
Package: linux-source-2.6.15 Version: 2.6.15-1 Severity: wishlist Hi, It's not really a bug report. Using the same .config, I can compile the linux bcm43xx driver ( ftp://ftp.berlios.de/pub/bcm43xx/snapshots/ ) for vanilla kernel 2.6.15. But the compilation fails for debian kernel source. Best regards, Bin -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-ds060102-20060103 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages linux-source-2.6.15 depends on: ii binutils 2.16.1cvs20051214-1 The GNU assembler, linker and bina ii bzip21.0.2-11high-quality block-sorting file co Versions of packages linux-source-2.6.15 recommends: ii gcc 4:4.0.2-2 The GNU C compiler ii libc6-dev [libc-dev] 2.3.5-11 GNU C Library: Development Librari ii make 3.80+3.81.b4-1 The GNU version of the "make" util -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317581: kernel-image-2.6.11-1-k7: kernel oops while reading udf disk
Am Dienstag, 3. Januar 2006 23:24 schrieb [EMAIL PROTECTED]: > On Tue, Jan 03, 2006 at 08:09:45PM +0100, David Schmitt wrote: > > Could you please retest this with a current linux image? > > I'm on self built kernel-image-2.6.14 and everything seems OK. > (Same burner but different, freshly formated disc...) > > > 2.6.15 will enter unstable tomorrow. > > Hmm... I wanted to wait a few days before upgrading to 2.6.15, it's a > huge six-meg patch, but ok I'll test that package as soon as it will be > available on ftp.pl.debian.org. No need to hurry now :) If you feel your problem is resolved, you can send a mailto:[EMAIL PROTECTED] to close this bug report. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Bug#345374: linux-image-2.6.14-2-686: I too have this problem
bingo. that fixed it. so is this a yaird bug? or is it piix's fault?--garrett try to use initramfs-tools?dma should work out of the box.--maks
Bug#345918: linux-2.6: modules do not install to correct folder in /lib/modules
Package: linux-2.6 Version: 2.6.15 When using make module_install with the makefile that comes with the kernel (/lib/modules/2.6.15-1-686/build/Makefile) modules are not installed into the correct location in /lib/modules. They build fine but are then installed to /lib/modules/2.6.15 instead of /lib/modules/2.6.15-1-686. I have seen this with tp_smapi module (http://tpctl.sourceforge.net/), and the zaptel module (available in unstable) built using m-a. Richard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345374: linux-image-2.6.14-2-686: I too have this problem
On Wed, Jan 04, 2006 at 01:29:52AM -0800, Garrett Mclean wrote: > bingo. that fixed it. so is this a yaird bug? or is it piix's fault? I believe it is an ide-generic / piix bug, which initramfs-tools works around, and yaird tries to work around but fails. I don't believe the workaround is the right solution though, so i think it would be best if you just cloned this bug report ans reassigned it to yaird. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345918: linux-2.6: modules do not install to correct folder in /lib/modules
On Wed, Jan 04, 2006 at 09:39:48AM +, Richard Burton wrote: > Package: linux-2.6 > Version: 2.6.15 > > When using make module_install with the makefile that comes with the kernel > (/lib/modules/2.6.15-1-686/build/Makefile) modules are not installed into > the correct location in /lib/modules. They build fine but are then > installed to /lib/modules/2.6.15 instead of /lib/modules/2.6.15-1-686. > > I have seen this with tp_smapi module (http://tpctl.sourceforge.net/), and > the zaptel module (available in unstable) built using m-a. Congratulations, you are the first to file a bug report against linux 2.6.15 :) Could you tell us exactly what you do to build the module, and check if this is not a bug in m-a or your module ? The official recomended way of building modules is to build inside the module tree with KSRC=/lib/modules/2.6.15-1-686/build, is this the way you do it ? Did it work for the official 2.6.14-[12] debian kernels ? Did it work for another kernel ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345918: linux-2.6: modules do not install to correct folder in /lib/modu
Congratulations, you are the first to file a bug report against linux
2.6.15 :)
Yay ;-)
Could you tell us exactly what you do to build the module, and check if
this
is not a bug in m-a or your module ?
The official recomended way of building modules is to build inside the
module
tree with KSRC=/lib/modules/2.6.15-1-686/build, is this the way you do it ?
Here are a couple of extracts from the tp_smapi makefile which should show
how it's done (I use 'make install' to drive this):
KVER := $(shell uname -r)
KDIR := /lib/modules/$(KVER)/build
PWD := $(shell pwd)
MDIR := drivers/firmware
...
modules: $(patsubst %.o,%.c,$(TP_MODULES))
$(MAKE) -C $(KDIR) M=$(PWD) modules
...
install: modules
rm -f /lib/modules/$(KVER)/kernel/$(MDIR)/{tp_base,tp_smapi}.ko
$(MAKE) -C $(KDIR) M=$(PWD) modules_install
depmod -a
Did it work for the official 2.6.14-[12] debian kernels ? Did it work for
another kernel ?
No, it was the same at 2.6.14, don't know about earlier than that.
Also worth noting is that it looks from the makefile (the rm before the
make, using MDIR) as though the modules should get installed in
/lib/modules/2.6.15-1-686/kernel/drivers/firmware, but they actually end up
in /lib/modules/2.6.15-1/extras, not sure if that's another build system
problem, or if it is an issue with the makefile though???
Richard.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345918: linux-2.6: modules do not install to correct folder in /lib/modu
On Wed, Jan 04, 2006 at 10:50:19AM +, Richard Burton wrote:
>
> >Congratulations, you are the first to file a bug report against linux
> >2.6.15 :)
>
> Yay ;-)
>
> >Could you tell us exactly what you do to build the module, and check if
> >this
> >is not a bug in m-a or your module ?
> >The official recomended way of building modules is to build inside the
> >module
> >tree with KSRC=/lib/modules/2.6.15-1-686/build, is this the way you do it ?
>
> Here are a couple of extracts from the tp_smapi makefile which should show
> how it's done (I use 'make install' to drive this):
>
> KVER := $(shell uname -r)
> KDIR := /lib/modules/$(KVER)/build
> PWD := $(shell pwd)
> MDIR := drivers/firmware
> ...
> modules: $(patsubst %.o,%.c,$(TP_MODULES))
>$(MAKE) -C $(KDIR) M=$(PWD) modules
> ...
> install: modules
>rm -f /lib/modules/$(KVER)/kernel/$(MDIR)/{tp_base,tp_smapi}.ko
>$(MAKE) -C $(KDIR) M=$(PWD) modules_install
We use $(MAKE) KSRC=/lib/modules/$(KVER)/build to build and install, i
believe. have you seen other modules and can you confirm they don't break or
something such ? I know there are a couple of them that work, and i thus
believe upto a point that it is a bug in this module, as well as a lack of
correct documentation on our part probably.
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345934: Can not be installed: postinst fails
Package: linux-image-2.6.15-1-686 Version: 2.6.15-1 Severity: grave Setting up linux-image-2.6.15-1-686 (2.6.15-1) ... Running depmod. Finding valid ramdisk creators. Using mkinitrd.yaird to build the ramdisk. initrd.img(/boot/initrd.img-2.6.15-1-686) points to /boot/initrd.img-2.6.15-1-686 (/boot/initrd.img-2.6.15-1-686) -- doing nothing at /var/lib/dpkg/info/linux-image-2.6.15-1-686.postinst line 579. vmlinuz(/boot/vmlinuz-2.6.15-1-686) points to /boot/vmlinuz-2.6.15-1-686 (/boot/vmlinuz-2.6.15-1-686) -- doing nothing at /var/lib/dpkg/info/linux-image-2.6.15-1-686.postinst line 579. Running postinst hook /sbin/update-grub. Searching for GRUB installation directory ... found: /boot/grub dpkg: error processing linux-image-2.6.15-1-686 (--configure): subprocess post-installation script returned error exit status 128 dpkg: dependency problems prevent configuration of linux-image-2.6-686: linux-image-2.6-686 depends on linux-image-2.6.15-1-686; however: Package linux-image-2.6.15-1-686 is not configured yet. dpkg: error processing linux-image-2.6-686 (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of linux-image-686: linux-image-686 depends on linux-image-2.6-686; however: Package linux-image-2.6-686 is not configured yet. dpkg: error processing linux-image-686 (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: linux-image-2.6.15-1-686 linux-image-2.6-686 linux-image-686 E: Sub-process /usr/bin/dpkg returned an error code (1) E: Some packages could not be upgraded. -- System Information: Debian Release: testing/unstable Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-2-686 Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8) Versions of packages linux-image-2.6.15-1-686 depends on: ii module-init-tools 3.2.2-1tools for managing Linux kernel mo ii yaird [linux-initramfs-tool] 0.0.12-3 Yet Another mkInitRD Versions of packages linux-image-2.6.15-1-686 recommends: pn libc6-i686 (no description available) -- debconf information: linux-image-2.6.15-1-686/postinst/kimage-is-a-directory: * linux-image-2.6.15-1-686/preinst/overwriting-modules-2.6.15-1-686: false linux-image-2.6.15-1-686/postinst/depmod-error-initrd-2.6.15-1-686: false linux-image-2.6.15-1-686/postinst/bootloader-error-2.6.15-1-686: linux-image-2.6.15-1-686/postinst/bootloader-test-error-2.6.15-1-686: linux-image-2.6.15-1-686/preinst/lilo-has-ramdisk: linux-image-2.6.15-1-686/preinst/failed-to-move-modules-2.6.15-1-686: linux-image-2.6.15-1-686/postinst/old-system-map-link-2.6.15-1-686: true linux-image-2.6.15-1-686/preinst/abort-install-2.6.15-1-686: linux-image-2.6.15-1-686/preinst/abort-overwrite-2.6.15-1-686: linux-image-2.6.15-1-686/preinst/bootloader-initrd-2.6.15-1-686: true linux-image-2.6.15-1-686/prerm/would-invalidate-boot-loader-2.6.15-1-686: true linux-image-2.6.15-1-686/preinst/lilo-initrd-2.6.15-1-686: true linux-image-2.6.15-1-686/postinst/old-initrd-link-2.6.15-1-686: true linux-image-2.6.15-1-686/postinst/old-dir-initrd-link-2.6.15-1-686: true linux-image-2.6.15-1-686/preinst/already-running-this-2.6.15-1-686: linux-image-2.6.15-1-686/preinst/initrd-2.6.15-1-686: linux-image-2.6.15-1-686/postinst/depmod-error-2.6.15-1-686: false linux-image-2.6.15-1-686/postinst/create-kimage-link-2.6.15-1-686: true linux-image-2.6.15-1-686/prerm/removing-running-kernel-2.6.15-1-686: true linux-image-2.6.15-1-686/preinst/elilo-initrd-2.6.15-1-686: true -- Juhapekka "naula" Tolvanen * http colon slash slash iki dot fi slash juhtolv "She turns me on. She makes me real. I have to apologize for the way I feel." Nine Inch Nails -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345918: linux-2.6: modules do not install to correct folder in /lib/modu
> KDIR := /lib/modules/$(KVER)/build
> modules: $(patsubst %.o,%.c,$(TP_MODULES))
>$(MAKE) -C $(KDIR) M=$(PWD) modules
> ...
> install: modules
>rm -f /lib/modules/$(KVER)/kernel/$(MDIR)/{tp_base,tp_smapi}.ko
>$(MAKE) -C $(KDIR) M=$(PWD) modules_install
We use $(MAKE) KSRC=/lib/modules/$(KVER)/build to build and install, i
believe. have you seen other modules and can you confirm they don't break
or
something such ?
I'm sorry but I'm not quite sure what you mean.
I've tried changing the above make calls to these:
$(MAKE) KSRC=$(KDIR) modules
$(MAKE) KSRC=$(KDIR) M=$(PWD) modules
$(MAKE) KSRC=$(KDIR) -C $(KDIR) M=$(PWD) modules
only the last of the 3 will build, and that still installs to the wrong
place again.
The original method does build fine, so I think for the most part make is
finding it's way into the right places, it's just the install step that uses
the wrong kernel name string for it's installation directory in
/lib/modules, so I'd think that however KSRC works we'd end up with the same
problem?
As I say I'm not sure that I've understood the KSRC variable, or quite where
to use it, so you may well be right about it.
Doing a bit of digging, I see that it comes down to the value of MODLIB in
/usr/src/linux-headers-2.6.15-1-686/scripts/Makefile.modinst, this appears
to come from $KERNELRELEASE, which appears to be made up of
$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)$(LOCALVERSION)
Calling 'make -C /lib/modules/2.6.15-1-686/build kernelrelease' shows the
kernel release as 2.6.15, but shouldn't this show 2.6.15-1-686, (which is
defined for UTS_RELEASE in version.h)?
Richard.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
* Sven Luther | I believe it has also an influence on the place where the source package is | ohold (alioth svn repo over whatever strange stuff ubuntu uses), and they said | we should use their system. yeah, git, really strange stuff in the world of Linux kernel development. Available from rsync://rsync.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git (or http://www.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git/) -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345918: linux-2.6: modules do not install to correct folder in /lib/modu
On Wed, Jan 04, 2006 at 11:40:25AM +, Richard Burton wrote:
> >> KDIR := /lib/modules/$(KVER)/build
> >> modules: $(patsubst %.o,%.c,$(TP_MODULES))
> >>$(MAKE) -C $(KDIR) M=$(PWD) modules
> >> ...
> >> install: modules
> >>rm -f /lib/modules/$(KVER)/kernel/$(MDIR)/{tp_base,tp_smapi}.ko
> >>$(MAKE) -C $(KDIR) M=$(PWD) modules_install
> >
> >We use $(MAKE) KSRC=/lib/modules/$(KVER)/build to build and install, i
> >believe. have you seen other modules and can you confirm they don't break
> >or
> >something such ?
>
> I'm sorry but I'm not quite sure what you mean.
> I've tried changing the above make calls to these:
> $(MAKE) KSRC=$(KDIR) modules
> $(MAKE) KSRC=$(KDIR) M=$(PWD) modules
> $(MAKE) KSRC=$(KDIR) -C $(KDIR) M=$(PWD) modules
> only the last of the 3 will build, and that still installs to the wrong
> place again.
>
> The original method does build fine, so I think for the most part make is
> finding it's way into the right places, it's just the install step that
> uses the wrong kernel name string for it's installation directory in
> /lib/modules, so I'd think that however KSRC works we'd end up with the
> same problem?
>
> As I say I'm not sure that I've understood the KSRC variable, or quite
> where to use it, so you may well be right about it.
>
> Doing a bit of digging, I see that it comes down to the value of MODLIB in
> /usr/src/linux-headers-2.6.15-1-686/scripts/Makefile.modinst, this appears
> to come from $KERNELRELEASE, which appears to be made up of
> $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)$(LOCALVERSION)
>
> Calling 'make -C /lib/modules/2.6.15-1-686/build kernelrelease' shows the
> kernel release as 2.6.15, but shouldn't this show 2.6.15-1-686, (which is
> defined for UTS_RELEASE in version.h)?
Well. ...
can you give the output of :
dpkg -l | grep linux-header
Please, the issue may be related to you not having the right header package
installed, or the header package being buggy, but i believe the first to be
the case. You need the per flavour linux-header package, which should include
a configured .config file, settign the $KERNELRELEASE variable to the right
thing, somwhere in this chain something may be wrong, either on your part or
ours.
Another try is :
apt-get source -b pwc
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Wed, Jan 04, 2006 at 12:39:09PM +0100, Tollef Fog Heen wrote: > * Sven Luther > > | I believe it has also an influence on the place where the source package is > | ohold (alioth svn repo over whatever strange stuff ubuntu uses), and they > said > | we should use their system. > > yeah, git, really strange stuff in the world of Linux kernel Ah, could, it used to be bazar thingy, or arch previously, which is one of the most non-friendly tools out there. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
also sprach Brian Nelson <[EMAIL PROTECTED]> [2006.01.04.0043 +0100]: > Why don't we use RHEL's kernel, or collaborate with them to maintain a > stable kernel tree, or something? I doubt RH has the same concept of stability as we do, and I surely don't want a plethora of potentially untested or buggy hardware support patches in my productive kernels. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver! gentoo: for when you finally find out that overclocking can kill your processor. signature.asc Description: Digital signature (GPG/PGP)
Bug#321409: hda: dma_timer_expiry: dma status == 0x21
[EMAIL PROTECTED] wrote: > OK, I've attached the requested information. I still have 2.6.14-2, > though, I can resubmit when .15 arrives. 2.6.15-1-686-smp just arrived. New outputs attached. H Linux version 2.6.15-1-686-smp (Debian 2.6.15-1) ([EMAIL PROTECTED]) (gcc version 4.0.3 20051201 (prerelease) (Debian 4.0.2-5)) #1 SMP Tue Jan 3 10:19:10 UTC 2006 BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 0010 - 4feaa000 (usable) BIOS-e820: 4feaa000 - 5000 (reserved) BIOS-e820: fec1 - fec2 (reserved) BIOS-e820: feda - fee0 (reserved) BIOS-e820: ffb0 - 0001 (reserved) 382MB HIGHMEM available. 896MB LOWMEM available. On node 0 totalpages: 327338 DMA zone: 4096 pages, LIFO batch:0 DMA32 zone: 0 pages, LIFO batch:0 Normal zone: 225280 pages, LIFO batch:31 HighMem zone: 97962 pages, LIFO batch:31 DMI 2.3 present. ACPI: RSDP (v000 DELL ) @ 0x000fdf00 ACPI: RSDT (v001 DELLCPi R 0x27d4070e ASL 0x0061) @ 0x4fef ACPI: FADT (v001 DELLCPi R 0x27d4070e ASL 0x0061) @ 0x4fef0400 ACPI: DSDT (v001 INT430 SYSFexxx 0x1001 MSFT 0x010e) @ 0x ACPI: PM-Timer IO Port: 0x808 Allocating PCI resources starting at 6000 (gap: 5000:aec1) Built 1 zonelists Kernel command line: root=/dev/hda3 ro Local APIC disabled by BIOS -- you can enable it with "lapic" mapped APIC to d000 (01a42000) Initializing CPU#0 PID hash table entries: 4096 (order: 12, 65536 bytes) Detected 1399.098 MHz processor. Using pmtmr for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1293308k/1309352k available (1490k kernel code, 14880k reserved, 535k data, 176k init, 391848k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 2799.04 BogoMIPS (lpj=1399520) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 512 CPU: After generic identify, caps: a7e9f9bf 0180 CPU: After vendor identify, caps: a7e9f9bf 0180 CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 1024K CPU: After all inits, caps: a7e9f9bf 0040 0180 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. mtrr: v2.0 (20020519) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. ACPI: setting ELCR to 0200 (from 0800) CPU0: Intel(R) Pentium(R) M processor 1400MHz stepping 05 SMP motherboard not detected. Local APIC not detected. Using dummy APIC emulation. Brought up 1 CPUs checking if image is initramfs... it is Freeing initrd memory: 1044k freed NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xfc96e, last bus=1 PCI: Using configuration type 1 ACPI: Subsystem revision 20050902 ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI: Probing PCI hardware (bus 00) ACPI: Assume root bridge [\_SB_.PCI0] bus is 0 Boot video device is :00:02.0 PCI quirk: region 0800-087f claimed by ICH4 ACPI/GPIO/TCO PCI quirk: region 0880-08bf claimed by ICH4 GPIO PCI: Ignoring BAR0-3 of IDE controller :00:1f.1 PCI: Transparent bridge - :00:1e.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 9 10 *11) ACPI: PCI Interrupt Link [LNKB] (IRQs 5 7) *11 ACPI: PCI Interrupt Link [LNKC] (IRQs 9 10 *11) ACPI: PCI Interrupt Link [LNKD] (IRQs 5 7 9 10 *11) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIE._PRT] Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: PnP ACPI: found 13 devices PnPBIOS: Disabled by ACPI PNP PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report pnp: 00:01: ioport range 0x4d0-0x4d1 has been reserved pnp: 00:01: ioport range 0x800-0x805 could not be reserved pnp: 00:01: ioport range 0x808-0x80f could not be reserved pnp: 00:02: ioport range 0xf400-0xf4fe has been reserved pnp: 00:02: ioport range 0x806-0x807 has been reserved pnp: 00:02: ioport range 0x810-0x85f could not be reserved pnp: 00:02: ioport range 0x860-0x87f has been reserved pnp: 00:02: ioport range 0x880-0x8bf has been reserved pnp: 00:02: ioport range 0x8c0-0x8df has been reserved pnp: 00:07: ioport range 0x900-0x97f h
Re: bits from the release team
On Wed, Jan 04, 2006 at 12:23:31AM -0200, Felipe Augusto van de Wiel (faw) wrote: > Perhaps the idea of maintain a kernel with other distros is not bad, > if Ubuntu shows up as a candidate, I would like to add Progeny, Linspire, > Xandros, "DCC Alliance Fan Club" and also other Debian Derivatives. I really > don't know if it is possible to mix RH, Debian, SuSE, Slackware and > other distros to maintain the same kernel, but certainly should be possible > to get all Debian (and Debian based/derivative) playing together. :-) Different distros have different target audiences so this may not be easy. Often fixing a driver bug for one class of users breaks it for an other class of users so it is quite possible that different distros want different bugs to be fixed/left alone. Also, other distros (e.g. RedHat) already found out the hard way that diverging too much from upstream costs a lot. So unless you find someone to pay the maintainers of such a forked kernel, it will not work out in the long term. > If you give it a quick look (and a quick try), we will have more > users testing the same kernel, which means more feedback, we will have > more developers working to get it stable and working to get it secure. > Probably even upstream get benefits from this model and sounds like a very > good way to work together, even to try to integrate outside patches and > backporting things. =) Dave Jones (Fedora) and Greg KH (Gentoo) already posted a much better idea on l-k: make packages from daily -git snapshots available for distro testers, so bugs like the past udev breakages are found _before_ the next official kernel version is released. Packaging at least -rc kernels for unstable might be a good idea for Debian too. That would provide more testing coverage for -rc releases, and this is what upstream needs the most. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345918: linux-2.6: modules do not install to correct folder in /lib/modu
> Calling 'make -C /lib/modules/2.6.15-1-686/build kernelrelease' shows the > kernel release as 2.6.15, but shouldn't this show 2.6.15-1-686, (which is > defined for UTS_RELEASE in version.h)? can you give the output of : dpkg -l | grep linux-header [EMAIL PROTECTED]:~$ dpkg -l | grep linux-header ii linux-headers-2.6-686 2.6.15-1 Architecture-specific header files for Linux ii linux-headers-2.6.14-2 2.6.14-7 Common header files for Linux kernel 2.6.14 ii linux-headers-2.6.14-2-686 2.6.14-7 Header files for Linux kernel 2.6.14 on PPro ii linux-headers-2.6.15-1 2.6.15-1 Common header files for Linux kernel 2.6.15 ii linux-headers-2.6.15-1-686 2.6.15-1 Header files for Linux kernel 2.6.15 on PPro [EMAIL PROTECTED]:~$ Please, the issue may be related to you not having the right header package installed, or the header package being buggy, but i believe the first to be the case. You need the per flavour linux-header package, which should include a configured .config file, settign the $KERNELRELEASE variable to the right thing, somwhere in this chain something may be wrong, either on your part or ours. Seems to be no mention of the version number (except a comment) in the .config files: [EMAIL PROTECTED]:~# locate .config | grep 2.6.15 | xargs grep 2.6.15 /usr/src/linux-headers-2.6.15-1-686/.config:# Linux kernel version: 2.6.15-1-686 /usr/src/linux-headers-2.6.15-1/.config:# Linux kernel version: 2.6.15-1 /var/lib/dpkg/info/linux-image-2.6.15-1-686.config:my $version = "2.6.15-1-686"; Another try is : apt-get source -b pwc I had to install kernel-package and linux-headers-2.6.14 (which pulled in headers for all kinds of x86 cpus i don't have) to get this to pass the dependancy check, but it still failed to build. And it appears it was trying to build using the headers for k7, not 686 too. That package seems messed up, probably not the best one to test with. Richard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Wed, Jan 04, 2006 at 01:51:17PM +0100, Gabor Gombas wrote: > > Packaging at least -rc kernels for unstable might be a good idea for > Debian too. That would provide more testing coverage for -rc releases, > and this is what upstream needs the most. the -rc kernels are build in experimental, staging area for unstable and without any potential d-i breakage. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345949: initramfs-tools: mkinitramfs does not copy klibc library
Package: initramfs-tools
Version: 0.47.1
Severity: grave
Justification: renders package unusable
Hi,
After upgrade my system and installing a new kernel my system would fail while
booting because the initramfs image was missing the klibc library.
The last version of libklibc has moved the library from /usr/lib/klibc/lib to
/lib and mkinitramfs does not look there.
Attached is a patch which fixes this.
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (500,
'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-3-test
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8)
Versions of packages initramfs-tools depends on:
ii busybox 1:1.01-4 Tiny utilities for small and embed
ii cpio 2.6-10 GNU cpio -- a program to manage ar
ii klibc-utils 1.1.14-2 small statically-linked utilities
ii udev 0.079-1/dev/ and hotplug management daemo
initramfs-tools recommends no packages.
-- no debconf information
--- initramfs-tools-0.47/mkinitramfs2005-12-31 14:19:44.0 +0100
+++ initramfs-tools-0.47.1/mkinitramfs 2006-01-04 14:20:24.0 +0100
@@ -159,7 +159,11 @@
# symlinks.
ln -s /usr/lib/klibc/bin/* ${DESTDIR}/bin
-ln -s /usr/lib/klibc/lib/klibc-*.so ${DESTDIR}/lib
+if [ -e /lib/klibc-*.so ] ; then
+ln -s /lib/klibc-*.so ${DESTDIR}/lib
+else
+ln -s /usr/lib/klibc/lib/klibc-*.so ${DESTDIR}/lib
+fi
copy_exec /usr/share/initramfs-tools/init /init
cp -a /usr/share/initramfs-tools/scripts/* "${DESTDIR}/scripts"
for f in $(cd ${CONFDIR}/scripts && \
Bug#343686: debsums: checksums mismatch + bug #343048 again
Maximilian Attems wrote: > severity 343686 normal > tags 343686 moreinfo > tags 343686 unreproducible > stop > > downgrading severity as kernel-package doesn't yet build with debsums. > > can you please tell how you hooked debsums into your image? > perhaps you are invoking debsums in apt's post install hook? > or in the kernels post install hook? > > -- > maks > Hello Maks, This is triggered when I try to use reportbug to report a kernel bug. [EMAIL PROTECTED]:~/00sys/deb$ reportbug Please enter the name of the package in which you have found a problem, or type 'other' to report a more general problem. > linux-image-2.6.15-rc5-686 *** Welcome to reportbug. Use ? for help at prompts. *** Using 'LUK ShunTim <[EMAIL PROTECTED]>' as your from address. Detected character set: ISO-8859-1 Please change your locale if this is incorrect. Getting status for linux-image-2.6.15-rc5-686... Verifying package integrity... There may be a problem with your installation of linux-image-2.6.15-rc5-686; the following files appear to be missing or changed: debsums: checksum mismatch linux-image-2.6.15-rc5-686 file /lib/modules/2.6.15-rc5-686/modules.pcimap debsums: checksum mismatch linux-image-2.6.15-rc5-686 file /lib/modules/2.6.15-rc5-686/modules.dep debsums: checksum mismatch linux-image-2.6.15-rc5-686 file /lib/modules/2.6.15-rc5-686/modules.ieee1394map debsums: checksum mismatch linux-image-2.6.15-rc5-686 file /lib/modules/2.6.15-rc5-686/modules.usbmap debsums: checksum mismatch linux-image-2.6.15-rc5-686 file /lib/modules/2.6.15-rc5-686/modules.isapnpmap debsums: checksum mismatch linux-image-2.6.15-rc5-686 file /lib/modules/2.6.15-rc5-686/modules.inputmap debsums: checksum mismatch linux-image-2.6.15-rc5-686 file /lib/modules/2.6.15-rc5-686/modules.seriomap debsums: checksum mismatch linux-image-2.6.15-rc5-686 file /lib/modules/2.6.15-rc5-686/modules.alias debsums: checksum mismatch linux-image-2.6.15-rc5-686 file /lib/modules/2.6.15-rc5-686/modules.symbols Do you still want to file a report [y|N|q|?]? q Regards, ST -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
* Gabor Gombas wrote: > Packaging at least -rc kernels for unstable might be a good idea for > Debian too. That would provide more testing coverage for -rc releases, > and this is what upstream needs the most. We already had some -rc releases in experimental for 2.6.14 and 2.6.15. Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343686: debsums: checksums mismatch + bug #343048 again
hello luk! On Wed, Jan 04, 2006 at 09:50:15PM +0800, LUK ShunTim wrote: > > This is triggered when I try to use reportbug to report a kernel bug. ok reportbug checks if there are debsums for a packet, currently we don't add them so i'm still curious where do you get them from? please post the output of apt-cach show linux-image-2.6.15-rc5-686 cat /var/lib/dpkg/info/linux-image-2.6.15-rc5-686.postint dpkg -L linux-image-2.6.15-rc5-686 maybe than we have a hint of how you got that? regards -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345949: initramfs-tools: mkinitramfs does not copy klibc library
tags 345949 pending stop On Wed, Jan 04, 2006 at 02:41:45PM +0100, Arjan Oosting wrote: > > Hi, > > After upgrade my system and installing a new kernel my system would fail > while > booting because the initramfs image was missing the klibc library. > The last version of libklibc has moved the library from /usr/lib/klibc/lib to > /lib and mkinitramfs does not look there. > Attached is a patch which fixes this. indeed sorry for the trouble. why on earth did my test work, anyway fix will be uploaded soonest. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343686: debsums: checksums mismatch + bug #343048 again
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 4 Jan 2006 15:28:04 +0100 Maximilian Attems <[EMAIL PROTECTED]> wrote: > On Wed, Jan 04, 2006 at 09:50:15PM +0800, LUK ShunTim wrote: > > > > This is triggered when I try to use reportbug to report a kernel > > bug. > > ok reportbug checks if there are debsums for a packet, > currently we don't add them so i'm still curious where do you get them > from? > > please post the output of > apt-cach show linux-image-2.6.15-rc5-686 > cat /var/lib/dpkg/info/linux-image-2.6.15-rc5-686.postint > dpkg -L linux-image-2.6.15-rc5-686 > > maybe than we have a hint of how you got that? The output of "debconf-show debsums" is probably more interesting. And perhaps read the description associated with the question asked when running "dpkg-reconfigure debsums". I suspect this to be a non-bug... - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDu98Gn7DbMsAkQLgRAjDIAKCS+973LQFA6a1dNXvQ30QF9JpgTACfRfcX D4VYt2m9fOmAIriFr6/sORo= =N8S7 -END PGP SIGNATURE-
Bug#345949: initramfs-tools: mkinitramfs does not copy klibc library
On Wed, Jan 04, 2006 at 03:19:47PM +0100, Maximilian Attems wrote: > > indeed sorry for the trouble. > why on earth did my test work, anyway fix will be uploaded soonest. > as quick workaround install libklibc-dev, then current initramfs-tools work too. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processing of initramfs-tools_0.48_i386.changes
initramfs-tools_0.48_i386.changes uploaded successfully to localhost along with the files: initramfs-tools_0.48.dsc initramfs-tools_0.48.tar.gz initramfs-tools_0.48_all.deb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#345864: problems with hdparm and udev during boot
priority 345864 important reassign 345864 linux-image-2.6-14-2-686 thanks This one time, at band camp, Marco d'Itri said: > On Jan 04, Stephen Gran <[EMAIL PROTECTED]> wrote: > > > Marco, can you take a look at > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345864 and see what you > > think? > Blame the kernel. When the event is sent, the drive is supposed to be > ready to be used. OK, reassigning it to the kernel guys. Kernel-team: I have amde this bug priority important, because I feel like generating udev events before the deivce is actually usable makes udev even less reliable. If you disagree about the priority or whatever, feel free to handle it as you see fit. I must also note that the submitter is not using a Debian kernel, and I do not know if there are Debian patches to handle udev events better. If you don't feel like this is your problem, feel free to reassign it back and we'll find a way to kludge around it or something. Take care, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#274924: nm256 - system freeze on recording
Hi David, On Mon, Jan 02, 2006 at 09:19:45PM +0100, David Schmitt wrote: > Hi Florian! > > Can you reproduce the problem with a current kernel (testing: 2.6.12, > unstable: 2.6.14)? well, things have changed a little bit, but just a bit... using either kernel, I now get an error message with rec/sox: [EMAIL PROTECTED]:~$ rec alsa14.wav Send break (control-c) to end recording sox: Failed reading /dev/dsp: Invalid audio buffer size 0 I then tried 'cat /dev/dsp > rec.file'; the first time with 2.6.14-2-686 the system froze just like before, but then when I tried with 2.6.12 and later again with 2.6.14 I get the message "cat: /dev/dsp: Input/output error" on stdout and there are a few lines in /var/log/syslog: Jan 5 00:40:32 localhost kernel: sound: DMA buffer(2) == NULL Jan 5 00:40:32 localhost kernel: Device NM256, chn=out Jan 5 00:40:32 localhost kernel: NM256: Read request too small; 0 Jan 5 00:40:32 localhost kernel: Sound: DMA (input) timed out - IRQ/DRQ config error? Jan 5 00:40:37 localhost last message repeated 9 times (this is the same for /dev/dsp1, but for /dev/dspW, I only get the error message to stdout, not the log entries...) I don't know what you make of this, so... > > If yes, could you please post the output of the following commands: > > lsmod > lspci > lspci -n > dmesg > This is a Dell Latitude LS notebook on 2.6.14 = [EMAIL PROTECTED]:~$ lsmod Module Size Used by visor 19084 0 usbserial 31208 1 visor fan 4580 0 thermal13352 0 processor 22684 1 thermal ipv6 267552 12 pcmcia 40732 2 firmware_class 10528 1 pcmcia ide_cd 43588 0 cdrom 40928 1 ide_cd nm256_audio75772 2 sound 80332 3 nm256_audio soundcore 9792 3 sound ac975152 1 nm256_audio joydev 9920 0 i2c_piix4 8816 0 uhci_hcd 33296 0 3c59x 41640 0 parport_pc 36868 0 shpchp 99492 0 mii 5568 1 3c59x parport37256 1 parport_pc i2c_core 22128 1 i2c_piix4 usbcore 127680 4 visor,usbserial,uhci_hcd pci_hotplug28628 1 shpchp intel_agp 24188 1 agpgart35720 1 intel_agp yenta_socket 28332 2 rsrc_nonstatic 14208 1 yenta_socket pcmcia_core43120 3 pcmcia,yenta_socket,rsrc_nonstatic rtc12600 1 floppy 62596 0 ext3 144008 1 jbd56756 1 ext3 mbcache 9316 1 ext3 ide_disk 18784 3 ide_generic 1120 0 [permanent] generic 4356 0 [permanent] piix 10436 0 [permanent] ide_core 130752 5 ide_cd,ide_disk,ide_generic,generic,piix evdev 9600 1 mousedev 11584 1 psmouse39684 0 [EMAIL PROTECTED]:~$ lspci :00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03) :00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) :00:07.0 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02) :00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) :00:07.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01) :00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) :00:0a.0 CardBus bridge: Texas Instruments PCI1211 :00:0d.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) :00:10.0 Communication controller: Agere Systems WinModem 56k (rev 01) :01:00.0 VGA compatible controller: Neomagic Corporation NM2200 [MagicGraph 256AV] (rev 20) :01:00.1 Multimedia audio controller: Neomagic Corporation NM2200 [MagicMedia 256AV Audio] (rev 20) [EMAIL PROTECTED]:~$ lspci -n :00:00.0 0600: 8086:7190 (rev 03) :00:01.0 0604: 8086:7191 (rev 03) :00:07.0 0680: 8086:7110 (rev 02) :00:07.1 0101: 8086:7111 (rev 01) :00:07.2 0c03: 8086:7112 (rev 01) :00:07.3 0680: 8086:7113 (rev 03) :00:0a.0 0607: 104c:ac1e :00:0d.0 0200: 10b7:9200 (rev 78) :00:10.0 0780: 11c1:0448 (rev 01) :01:00.0 0300: 10c8:0005 (rev 20) :01:00.1 0401: 10c8:8005 (rev 20) [EMAIL PROTECTED]:~$ dmesg Linux version 2.6.14-2-686 (Debian 2.6.14-7) ([EMAIL PROTECTED]) (gcc version 4.0.3 20051201 (prerelease) (Debian 4.0.2-5)) #1 Wed Dec 28 18:21:03 UTC 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000eb000 - 0010 (reserved) BIOS-e820: 0010 - 07ff (usable) BIOS-e820: 07ff - 07fffc00 (ACPI data)
Re: bits from the release team
On Wed, Jan 04, 2006 at 02:26:51PM +0100, Maximilian Attems wrote: > the -rc kernels are build in experimental, staging area for unstable > and without any potential d-i breakage. Ah, nice, I did not notice it. Perhaps it should get some more publicity to attract more testers :-) Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345864: problems with hdparm and udev during boot
On 1/4/06, Marco d'Itri <[EMAIL PROTECTED]> wrote: > On Jan 04, Stephen Gran <[EMAIL PROTECTED]> wrote: > > > Marco, can you take a look at > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345864 and see what you > > think? > Blame the kernel. When the event is sent, the drive is supposed to be > ready to be used. > I don't think that is the kernel problem. I have downgraded my kernel to 2.6.12, 2.6.12.3, 2.6.13 and with version of hdparm and udev in sid I still was seeing the same errors in dmesg. With regards, Remigiusz Świc
Bug#345918: linux-2.6: modules do not install to correct folder in /lib/modu
tags 345918 confirmed thanks I've reproduced that problem locally and will have a look at it tonight. Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
Sven Luther wrote: > For the installer, sure, but the generation of the d-i kernel .udebs is only > marginally of their relevance, and furthermore they don't want the > responsability associated with it, and as proof i can show you that joeyh > upgraded kernel-wedge and the x86 d-i module udebs, but didn't touch all the > other architectures, defaulting it upto the porters, which are the exact same > guys doing the kernel packages. So joeyh and fjp can't have it both way. Um, I maintain kernel-wedge and linux-kernel-di-i386*. Not having access to every other architecture out there, and with some of the architectures that I do have access to suffering from unaddressed kernel bugs (ie #332962) that make my hardware for them useless for testing new d-i releases, as well as being limited to modem speeds, makes it difficult to maintain anything more. If you take a closer look at the commits in question, my changes were limited to kernel-wedge, which means the maintainers for other arches benefit from them. Probably the packages for other architectures can be updated with just a rebuild and simple testing, although it can be very hard to tell, since what hardware is common on which architectures, and thus which udebs it should go into, is not always easy to determine if you're not intamately familiar with the architecture. Which is a good reason to have maintainers who are, instead of me. Saying that this means I lack responsibility and am only interested in taking the easy way out is, again, insulting. -- see shy jo signature.asc Description: Digital signature
Bug#345918: linux-2.6: modules do not install to correct folder in /lib/modu
On Wed, Jan 04, 2006 at 09:56:29AM -0800, Jurij Smakov wrote: > tags 345918 confirmed > thanks > > I've reproduced that problem locally and will have a look at it tonight. I think Bastian blank also investigated, and it may (or not) be fixed in SVN. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Wed, Jan 04, 2006 at 01:11:00PM -0500, Joey Hess wrote: > Sven Luther wrote: > > For the installer, sure, but the generation of the d-i kernel .udebs is only > > marginally of their relevance, and furthermore they don't want the > > responsability associated with it, and as proof i can show you that joeyh > > upgraded kernel-wedge and the x86 d-i module udebs, but didn't touch all the > > other architectures, defaulting it upto the porters, which are the exact > > same > > guys doing the kernel packages. So joeyh and fjp can't have it both way. > > Um, I maintain kernel-wedge and linux-kernel-di-i386*. Not having access > to every other architecture out there, and with some of the There is absolutely no need for any architecture access to simply repackage the modules into an .udeb. Absolutely no need. > architectures that I do have access to suffering from unaddressed kernel > bugs (ie #332962) that make my hardware for them useless for testing new > d-i releases, as well as being limited to modem speeds, makes it > difficult to maintain anything more. So, what do you think d-i is so special that it deserve special attention, and should not fall in the common case of debian kernel bugs ? Maybe you will in the future start building your own kernels too ? It is just damn repackaging, nobody asks you to test anything at all. > If you take a closer look at the commits in question, my changes were > limited to kernel-wedge, which means the maintainers for other arches > benefit from them. Probably the packages for other architectures can be > updated with just a rebuild and simple testing, although it can be very this has not been the case in the past, and you should simply have rebuilt and uploaded them or something. > hard to tell, since what hardware is common on which architectures, and > thus which udebs it should go into, is not always easy to determine if Indeed, which is why it is not needed to duplicate that process twice, once when the kernel port maintainer choses which config option to include and which not, and twice when you chose to include those modules in the .udebs or not. > you're not intamately familiar with the architecture. Which is a good > reason to have maintainers who are, instead of me. None, except for modules concerning the powerpc64 hypervisor and virtual scsi stuff, of the upgrades that i did for powerpc since the sarge release needed that kind of intimate knowledge. And all the changes i did, where mirrored on x86 or something, and i lost maybe 2 hours or so each time time which i could have spent doing useful work. > Saying that this means I lack responsibility and am only interested in > taking the easy way out is, again, insulting. No, but you cannot deny that both you and Franz have been ranting against the porters not taking their duty seriously in the past, and this is one area where you could make their time more worthwhile, but chose not to. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
kernel upgrade error
I'm trying to upgrade my Debian sarge 3.1 kernel 2.4 to the 2.6. Using aptitude install kernel-image-xx.xx.xxx when I rebooted the system hung at the prompt of sbin/init:432: cannot open dev/console: no such file. I then used a knoppix 4.0 cd to boot from and mounted the root partition and issued the command MAKEDEV updates and again the system just hung there on one occassion after issuing the command MAKEDEV updates and it returned to the prompt I then issued the command MAKEDEV console. When I got the prompt back I then issued the command mknod -m 660 /dev/console c 5 1and mknod -m 660 /dev/null c 1 3. These returned an access denied on all the files. 1) how do I upgrade the kernel to the 2.6 stable version 2) can this be done using apt-get? or 3) can the above be fixed Thanks Jon L. Miller, ASE, CNS, CLS, MCNE, CCNA Director/Sr Systems Consultant MMT Networks Pty Ltd http://www.mmtnetworks.com.au Resellers for: Novell Gold Partner, Cisco Partner, Peopletelecom, Westnet, Sophos Anti-Virus, "I don't know the key to success, but the key to failure is trying to please everybody." -Bill Cosby
Bug#346028: linux-2.6: Hangs while attempting to purge
Package: linux-2.6 Severity: serious Justification: Won't uninstall cleanly It hangs on this line of the postrm script: my $ret = purge(); I can get it to work by deleting this line. Perhaps this is because a debconf routine is being called after "stop" has been called? I don't know, but anyway it's a serious bug. This bug appears in linux-image-2.6.14-2-686 and linux-image-2.6.15-1-686, and I assume in other flavours as well. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346028: linux-2.6: Hangs while attempting to purge
Nathanael Nerode wrote: Package: linux-2.6 Severity: serious Justification: Won't uninstall cleanly It hangs on this line of the postrm script: my $ret = purge(); I can get it to work by deleting this line. Perhaps this is because a debconf routine is being called after "stop" has been called? I don't know, but anyway it's a serious bug. This bug appears in linux-image-2.6.14-2-686 and linux-image-2.6.15-1-686, and I assume in other flavours as well. Hi Nathanael. I can confirm this problem, in fact i have also filed a bug against it: see #344767. Regards. Cesare. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346028: linux-2.6: Hangs while attempting to purge
On Thu, Jan 05, 2006 at 12:34:06AM +0100, Cesare Leonardi wrote: > Nathanael Nerode wrote: > >Package: linux-2.6 > >Severity: serious > >Justification: Won't uninstall cleanly > > > > > >It hangs on this line of the postrm script: > > > >my $ret = purge(); > > > >I can get it to work by deleting this line. Perhaps this is because a > >debconf routine is being called after "stop" has been called? I don't > >know, > >but anyway it's a serious bug. > > > >This bug appears in linux-image-2.6.14-2-686 and linux-image-2.6.15-1-686, > >and I assume in other flavours as well. > > Hi Nathanael. > I can confirm this problem, in fact i have also filed a bug against it: > see #344767. Hi both of you, ... It would be great if you could confirm the exact version of those two packages, and could provide us some log of what is happening, as this bug report doesn't seem to be very informative. This issue should have been fixed in linux-image-2.6.15-1-686 though, so we really need to find out what did go wrong. Also, could you please give us the output of ls -lR /etc/kernel, and append it to the bug report ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346028: linux-2.6: Hangs while attempting to purge
Sven Luther wrote: It would be great if you could confirm the exact version of those two packages, and could provide us some log of what is happening, as this bug report doesn't seem to be very informative. For me, i have provided information in bug #344767, as i explained in the previous message: versions, logs, ecc. This issue should have been fixed in linux-image-2.6.15-1-686 though, so we really need to find out what did go wrong. I haven't tested 2.6.15 because it isn't available in my mirror yet. But the Nathanael posts tell us that the problem is still present in the latest kernel. As soon as it will be available on the mirror i use, i'll test 2.6.15. Also, could you please give us the output of ls -lR /etc/kernel, and append it to the bug report ? Do you mean this? $ ls -lR /etc/kernel-* -rw-r--r-- 1 root root 179 2005-09-11 20:55 /etc/kernel-img.conf -rw-r--r-- 1 root root 1006 2005-11-08 00:35 /etc/kernel-pkg.conf Regards. Cesare. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
how to use initrd command
I'm attempting to upgrade Debian 3.1 kernel version 2.4 to the latest 2.6 version. I understand I need to add a initrd command somewhere in this. How do I pass this command and when (a link to a document would be a big help). Thanks Jon
Re: how to use initrd command
On Thu, 2006-01-05 at 10:12 +0800, Jon Miller wrote: > I'm attempting to upgrade Debian 3.1 kernel version 2.4 to the latest 2.6 > version. I understand I need to add a initrd command somewhere in this. How > do I pass this command and when (a link to a document would be a big help). > > Thanks > > Jon > > I followed the instructions on this document. However I have to say that I think the document is rather poorly written. -- Glenn Meehan <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#344767: Bug#346028: linux-2.6: Hangs while attempting to purge
Cesare Leonardi wrote: I haven't tested 2.6.15 because it isn't available in my mirror yet. But the Nathanael posts tell us that the problem is still present in the latest kernel. As soon as it will be available on the mirror i use, i'll test 2.6.15. Ok, 2.6.15 is arrived. I've tryed to install linux-image-2.6.15-1-486 (version 2.6.15-1), then to purge it and the operation failed. But now, it doesn't hang as stated in the bug reports, but fails with an error: (Reading database ... 83162 files and directories currently installed.) Removing linux-image-2.6.15-1-486 ... Running postrm hook /sbin/update-grub . Searching for GRUB installation directory ... found: /boot/grub The link /vmlinuz is a damaged link Removing symbolic link vmlinuz Unless you used the optional flag in lilo, you may need to re-run lilo The link /initrd.img is a damaged link Removing symbolic link initrd.img Unless you used the optional flag in lilo, you may need to re-run lilo Purging configuration files for linux-image-2.6.15-1-486 ... Running postrm hook /sbin/update-grub . Searching for GRUB installation directory ... found: /boot/grub dpkg: error processing linux-image-2.6.15-1-486 (--purge): subprocess post-removal script returned error exit status 128 Errors were encountered while processing: linux-image-2.6.15-1-486 E: Sub-process /usr/bin/dpkg returned an error code (1) A package failed to install. Trying to recover: Press return to continue. But since the "486" flavour is a new entry, i've also tryed linux-image-2.6.15-1-686-smp, which i know was failing during purge (while i was investigating for bug #344767, i had also tested linux-image-2.6.14-2-686-smp (2.6.14-6), and it hanged like the others): the purge operation for 2.6.15-686-smp failed like 486 flavour: (Reading database ... 83105 files and directories currently installed.) Removing linux-image-2.6.15-1-686-smp ... Running postrm hook /sbin/update-grub . Searching for GRUB installation directory ... found: /boot/grub The link /vmlinuz is a damaged link Removing symbolic link vmlinuz Unless you used the optional flag in lilo, you may need to re-run lilo The link /initrd.img is a damaged link Removing symbolic link initrd.img Unless you used the optional flag in lilo, you may need to re-run lilo Purging configuration files for linux-image-2.6.15-1-686-smp ... Running postrm hook /sbin/update-grub . Searching for GRUB installation directory ... found: /boot/grub dpkg: error processing linux-image-2.6.15-1-686-smp (--purge): subprocess post-removal script returned error exit status 128 Errors were encountered while processing: linux-image-2.6.15-1-686-smp E: Sub-process /usr/bin/dpkg returned an error code (1) A package failed to install. Trying to recover: Press return to continue. Some information about my system: - Debian Sid - linux-image-2.6.15-1-686 (2.6.15-1) - yaird (0.0.12-3) - initrd-tools (0.1.84) - grub (0.97-2) - libc6 (2.3.5-11) - libc6-i686 (2.3.5-11) Regards. Cesare. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345918: Possible solution
Hi, I've looked at this bug and it appears that nothing is wrong with linux-headers. "Nothing is wrong" in that case means that we did not introduce any bugs compared to the previous versions, I've verified that zaptel driver behaves the same way under 2.6.14. It appears that most of the packages containing the source of third-party modules and using module-assistant prefer to install the modules into the package themselves, relying on the KVERS variable, which contains full version of the kernels (2.6.15-1-686 in this case). Some modules (like zaptel), however, use the modules_install target from the upstream Makefile, and that results in the problems described in the bug report. Since currently we don't have a clear policy on packaging the kernel modules (even though incidents like this get me more and more motivated to start working on one), it is arguable whether it's a bug of linux-headers or the zaptel-source package. I think we should be flexible and support both ways for installation, especially taking into account that the fix is pretty easy: adding a file 'localversion' containing the string -1-686 to the /usr/src/linux-headers-2.6.15-1-686/ directory fixes the problem. I'll bring up the issue on debian-kernel and see whether there will be any objections to such a change. Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337974: i2o controller probe failed err -110
Max: maximilian attems wrote: use initramfs-tools this shouldn't fail: apt-get install initramfs-tools add to /etc/kernel-img.conf ramdisk = /usr/sbin/mkinitramfs /usr/sbin/mkinitrd good luck ;) I patched up my /etc/lvm/lvm.config and now the kernel package installs clean. It won't successfully boot, however. It hangs with: ... Waiting for /sys/block/sdb/dev ... /sys/block/sdb/dev seems to be down ... The /dev/sdb device is where my root filesystem is at. Not quite sure why the kernel can't find it... Any ideas? b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337974: i2o controller probe failed err -110
Max: maximilian attems wrote: use initramfs-tools this shouldn't fail: apt-get install initramfs-tools add to /etc/kernel-img.conf ramdisk = /usr/sbin/mkinitramfs /usr/sbin/mkinitrd good luck ;) One other thing. When I try to --purge the package, I get this: # dpkg --purge linux-image-2.6.14-2-k7 (Reading database ... 206960 files and directories currently installed.) Removing linux-image-2.6.14-2-k7 ... Searching for GRUB installation directory ... found: /boot/grub . The link /vmlinuz is a damaged link Removing symbolic link vmlinuz Unless you used the optional flag in lilo, you may need to re-run lilo The link /initrd.img is a damaged link Removing symbolic link initrd.img Unless you used the optional flag in lilo, you may need to re-run lilo Purging configuration files for linux-image-2.6.14-2-k7 ... Searching for GRUB installation directory ... found: /boot/grub . ... and it just hangs there. b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#344767: Bug#346028: linux-2.6: Hangs while attempting to purge
On Thu, Jan 05, 2006 at 03:51:54AM +0100, Cesare Leonardi wrote: > Cesare Leonardi wrote: > >I haven't tested 2.6.15 because it isn't available in my mirror yet. But > >the Nathanael posts tell us that the problem is still present in the > >latest kernel. > >As soon as it will be available on the mirror i use, i'll test 2.6.15. > > Ok, 2.6.15 is arrived. > I've tryed to install linux-image-2.6.15-1-486 (version 2.6.15-1), then > to purge it and the operation failed. But now, it doesn't hang as stated > in the bug reports, but fails with an error: Indeed, this is a grub RC bug, which need to fix their grub-update call from /etc/kernel/*.d/grub or whatever scripts. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how to use initrd command
On Thu, Jan 05, 2006 at 10:12:06AM +0800, Jon Miller wrote: > I'm attempting to upgrade Debian 3.1 kernel version 2.4 to the latest 2.6 > version. I understand I need to add a initrd command somewhere in this. How > do I pass this command and when (a link to a document would be a big help). apt-get install initramfs-tools linux-image-2.6.15-1- should do all you need, provided you have set do_initrd or whatever it is to yes in /etc/kernel-img.conf. man kernel-img.conf for details. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337974: i2o controller probe failed err -110
On Wed, Jan 04, 2006 at 10:58:43PM -0600, Bill Gatliff wrote: > Max: > > maximilian attems wrote: > > >use initramfs-tools this shouldn't fail: > >apt-get install initramfs-tools > > > >add to /etc/kernel-img.conf > >ramdisk = /usr/sbin/mkinitramfs /usr/sbin/mkinitrd > > > >good luck ;) > > > > > > > > One other thing. When I try to --purge the package, I get this: > > # dpkg --purge linux-image-2.6.14-2-k7 > (Reading database ... 206960 files and directories currently installed.) > Removing linux-image-2.6.14-2-k7 ... > Searching for GRUB installation directory ... found: /boot/grub . > The link /vmlinuz is a damaged link > Removing symbolic link vmlinuz > Unless you used the optional flag in lilo, > you may need to re-run lilo > The link /initrd.img is a damaged link > Removing symbolic link initrd.img > Unless you used the optional flag in lilo, > you may need to re-run lilo > Purging configuration files for linux-image-2.6.14-2-k7 ... > Searching for GRUB installation directory ... found: /boot/grub . > > ... and it just hangs there. Known grub bug, try playing with /etc/kernel/postrm.d/grub or whatever script is responsible for this. The workaround fix is for grub-update to do output to stderr and not stdout, i believe, being exclusively ppc, i have not much knowledge or interest in grub. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337974: i2o controller probe failed err -110
On Wed, Jan 04, 2006 at 10:58:43PM -0600, Bill Gatliff wrote: > Max: > > maximilian attems wrote: > > >use initramfs-tools this shouldn't fail: > >apt-get install initramfs-tools > > > >add to /etc/kernel-img.conf > >ramdisk = /usr/sbin/mkinitramfs /usr/sbin/mkinitrd > > > >good luck ;) > > > > > > > > One other thing. When I try to --purge the package, I get this: > > # dpkg --purge linux-image-2.6.14-2-k7 > (Reading database ... 206960 files and directories currently installed.) > Removing linux-image-2.6.14-2-k7 ... > Searching for GRUB installation directory ... found: /boot/grub . > The link /vmlinuz is a damaged link > Removing symbolic link vmlinuz > Unless you used the optional flag in lilo, > you may need to re-run lilo > The link /initrd.img is a damaged link > Removing symbolic link initrd.img > Unless you used the optional flag in lilo, > you may need to re-run lilo > Purging configuration files for linux-image-2.6.14-2-k7 ... > Searching for GRUB installation directory ... found: /boot/grub . > > ... and it just hangs there. Oh, and BTW, this is : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=344767 Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#344767: Bug#346028: linux-2.6: Hangs while attempting to purge
reassign 344767 grub thanks On Thu, Jan 05, 2006 at 01:19:17AM +0100, Cesare Leonardi wrote: > Sven Luther wrote: > >It would be great if you could confirm the exact version of those two > >packages, and could provide us some log of what is happening, as this bug > >report doesn't seem to be very informative. > > For me, i have provided information in bug #344767, as i explained in > the previous message: versions, logs, ecc. I have now looked at this bug report, and it is indeed probable that it is a bug in grub, who wants to write to stdout, which plays hell with the new kernel-package debconfified due to messing up the debconf protocol. Since policy mandates debconf for interaction, this is a RC grub bug, and a proposed fix is have grub-updates output info on stderr instead. There were some bugs we redirected to the grub guys, but i can't find them in the BTS anymore, so reasigning the 344767 bug report to them. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345918: Possible solution
On Wed, Jan 04, 2006 at 08:30:11PM -0800, Jurij Smakov wrote: > Hi, > > I've looked at this bug and it appears that nothing is wrong with > linux-headers. "Nothing is wrong" in that case means that we did not > introduce any bugs compared to the previous versions, I've verified that > zaptel driver behaves the same way under 2.6.14. > > It appears that most of the packages containing the source of third-party > modules and using module-assistant prefer to install the modules into the > package themselves, relying on the KVERS variable, which contains full > version of the kernels (2.6.15-1-686 in this case). Some modules (like > zaptel), however, use the modules_install target from the upstream > Makefile, and that results in the problems described in the bug report. > Since currently we don't have a clear policy on packaging the kernel > modules (even though incidents like this get me more and more motivated to > start working on one), it is arguable whether it's a bug of linux-headers > or the zaptel-source package. I think we should be flexible and support > both ways for installation, especially taking into account that the fix is > pretty easy: adding a file 'localversion' containing the string -1-686 to > the /usr/src/linux-headers-2.6.15-1-686/ directory fixes the problem. I'll > bring up the issue on debian-kernel and see whether there will be any > objections to such a change. As said, i believe Bastian Blank was working on implementing just that last night. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346028: linux-2.6: Hangs while attempting to purge
On Thu, Jan 05, 2006 at 01:19:17AM +0100, Cesare Leonardi wrote: > Sven Luther wrote: > >It would be great if you could confirm the exact version of those two > >packages, and could provide us some log of what is happening, as this bug > >report doesn't seem to be very informative. > > For me, i have provided information in bug #344767, as i explained in > the previous message: versions, logs, ecc. Ah, looking at this one now. > >This issue should have been fixed in linux-image-2.6.15-1-686 though, so we > >really need to find out what did go wrong. > > I haven't tested 2.6.15 because it isn't available in my mirror yet. But > the Nathanael posts tell us that the problem is still present in the > latest kernel. But it should not, which is why it is important to investigate. 2.6.14-2 is no more in the archive as of today, and thus no longer relevant. For information, i had this problem on powerpc, where the debconfified mkvmlinuz package used debconf script in the /etc/kernel way described below, but we fixed it last week, and the new 2.6.15-1 kernel build depend on at least the 10.028 or 10.029 kernel-package version with this fixed. So, either it is a new problem, or somehow the version Nathanael has built was done so using an older kernel-package which was buggy. > As soon as it will be available on the mirror i use, i'll test 2.6.15. Thanks. > >Also, could you please give us the output of ls -lR /etc/kernel, and > >append it > >to the bug report ? > > Do you mean this? > $ ls -lR /etc/kernel-* > -rw-r--r-- 1 root root 179 2005-09-11 20:55 /etc/kernel-img.conf > -rw-r--r-- 1 root root 1006 2005-11-08 00:35 /etc/kernel-pkg.conf No, the kernel-packahe generated postinst and co script have support for script hooks, found under /etc/kernel/postinst.d/ and co, i want to know what exactly you have there, because it is probable that some random third party hook (like grub-update call maybe) causes this problem. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how to use initrd command
On 1/5/06, Jon Miller <[EMAIL PROTECTED]> wrote: > I'm attempting to upgrade Debian 3.1 kernel version 2.4 to the latest 2.6 > version. I understand I need to add a initrd command somewhere in this. How > do I pass this command and when (a link to a document would be a big help). > > Thanks > > Jon > > Recommended reading : http://kernel-handbook.alioth.debian.org/index.html -- Cheers, Maxim Vexler (hq4ever). Do u GNU ?
