Otavio Salvador wrote:
Frederik Schueler [EMAIL PROTECTED] writes:
Please point me to other places, where this will cause breakage, and I
will help fixing it.
AFAIK, you'll need to fix base-installer too.
Also debian-cd.
--
see shy jo
signature.asc
Description: Digital signature
- * Remove some unncessary debug logging.
+ * Remove some unncessary debug logging.
+ * Support initramfs-tools renaming its confdir by testing which directory
+exists. Required moving some code around so it runs only after
+initramfs-tools is installed.
- -- Joey Hess [EMAIL PROTECTED
Thiemo Seufer wrote:
It will AFAICS break all remaining d-i with 2.4 because those try to
install a 2.4 kernel from testing by default.
Frans, Joey, what is your opinion about this?
I suppose it's a good reason to do a d-i release w/o 2.4 before dropping
the kernel. (The GPL is another good
from glibc:
* Bumped the minimum kernel to 2.4.1 instead of 2.4.0 as there are some
important new features in this version. Thanks to Petr Salinger for
noticing me.
So it needs to use LD_ASSUME_KERNEL=2.4.1.
--
see shy jo
signature.asc
Description: Digital signature
all
Version: 0.1.84.1
Distribution: unstable
Urgency: high
Maintainer: Debian kernel team debian-kernel@lists.debian.org
Changed-By: Joey Hess [EMAIL PROTECTED]
Description:
initrd-tools - tools to create initrd image for prepackaged Linux kernel
Closes: 364338
Changes:
initrd-tools (0.1.84.1
Hi Ted.. to summarize what needs doing for this bug,
/usr/share/initrd-tools/scripts/e2fsprogs currently contains
LD_ASSUME_KERNEL=2.4. This needs to change to LD_ASSUME_KERNEL=2.4.1
--
see shy jo
signature.asc
Description: Digital signature
retitle 364338 LD_ASSUME_KERNEL is broken
tag 364338 d-i
severity 364338 serious
confirmed 364338
reassign 364338 initrd-tools
thanks
Here's a sh -x trace of mkinitrd running on a 2.4 kernel and failing:
++ LD_ASSUME_KERNEL=2.4
++ ldd /sbin/modprobe
I tried just removing the LD_ASSUME_KERNEL=2.4 setting from
/usr/sbin/mkinitrd, and also from
/usr/share/initrd-tools/scripts/e2fsprogs, which also sets it, and
that seems to work ok on both 2.4 and 2.6 (generating initrd for 2.4
kernel).
--
see shy jo
signature.asc
Description: Digital
Package: initramfs-tools
Version: 0.59b
Severity: normal
-k [version] Specify kernel version or ALL
The actual string that is used to specific all kernels is all,
not ALL
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500,
dann frazier wrote:
If for no other reason, upstream release process changes will likely
make this much more difficult. As I'm sure you know, 2.6 is being
actively developed indefinitely, as opposed to the previous method of
branching off and stabalising a development tree. Since there is no
I just wanted to comment on the 2.4 is deprecated thing. Just because
the kernel team is muttering[1] about not supporting the 2.4 kernel does
not mean that Debian as a project has decided not to support users using
their own versions of this kernel. As Steve notes in #361024, we have to
support
maximilian attems wrote:
ohci_hcd has seen some work lately, can you still reproduce that
with 2.6.16?
Still seeing it with this kernel:
Linux dragon 2.6.16-1-686 #1 Tue Mar 28 15:44:45 UTC 2006 i686 GNU/Linux
--
see shy jo
signature.asc
Description: Digital signature
Package: initramfs-tools
Version: 0.57b
Severity: normal
-k [version] Specify kernel version or ALL
But -k ALL doesn't work, it tries to operate on a kernel version ALL.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (1,
(Your use of the term udeb kernels is confusing and innaccurate. d-i
does not use different kernels than anything else.)
Max Vozeler wrote:
1. The version of linux-headers in unstable is sometimes ahead of
the udeb kernel-image packages, like right now (2.6.15/2.6.16).
Only because the
Jurij Smakov wrote:
* Automatic rebuilds (configurable) on kernel updates. Nothing fancy, just
a transparent way to figure out whether the currently installed
kernel module source is compatible with the new kernel, and attempt
rebuild and installation, if neccessary.
The thing I really
maximilian attems wrote:
what about blacklisting in /etc/modprobe.d/blacklist
than mkinitramfs won't load it.
That works, although I then have to add it to /etc/modules so it's
loaded during normal boot.
--
see shy jo
signature.asc
Description: Digital signature
maximilian attems wrote:
i don't know hibernate, whatfor is it needed?
does suspend to disk work without it by
# echo disk /sys/power/state
Hibernate takes care of the user side of software suspend, stuff like
taking down and restoring ethernet interfaces and removing modules that
cannot
Package: initramfs-tools
Version: 0.48
Severity: normal
On my laptop, a Fujutsu P-2110 lifebook, if I use softwre suspend
(version 1; to disk), when resuming the initramfs loads ohci_hcd before
starting the resume process. When the hibernate program then tries to
load ohci_hcd (which does not
Nathanael Nerode wrote:
Second, the issues with the installer
--
Your analysis of the modules that would be needed by the installer does
not take all possible installation methods and hardware combinations
into account, notably missing a) network cards b)
Sven Luther wrote:
Indeed. The d-i team usually says no outright to any kind of proposal of
this kind, so it is up to the kernel team to come up with an implementation
which convinces them :) The release team deserves to be informed about the
possibility though.
Cite message-ids or irc logs
Sven Luther wrote:
And have you added stable-security into the equation ? Your choices of back in
april are in part responsible for the abysmal situation in stable-security
with regard to kernels during these past months.
Pedantically speaking, fjp made no d-i release decisions last April.
If
Sven Luther wrote:
Obviously, from a kernel maintainer perpespective, the one that makes more
sense is the latest one we are working on, which will always be the more
actively maintained one and as a consequence the one of more interest to the
users, not to mention the fact that for the users
Frans Pop wrote:
Also, using 2.6.12/14/15 in Sarge (volatile) IMO means that the kernel
team will need to commit to maintaining that version with regard to
security updates, just as for 2.6.8.
Continuously making the latest kernel available for Sarge through volatile
IMO is not an option,
Frans Pop wrote:
Hmm. I think it is on the same level as offering static network
configuration over DHCP or, maybe better, (not) loading some modules
during hardware detection.
The main advantage of the patch as I see it is its flexibility: it allows
both us and derivatives to set things
Package: linux-image-2.6.14-2-386
Version: 2.6.14-6
Severity: normal
I'm in the habit of using alt-left arrow or alt-right arrow to move
between virtual consoles at the linux console.
With this kernel, if I am in tty1 and I alt-left, I get to a blank
console (with a cursor at the top). If I then
I also see this bug, using initramfs-tools 0.44 and
linux-image-2.6.14-2-386 (2.6.14-6).
It's puzzling that the changelog for this version of the kernel
claims to have dropped the module ide patch, but all the ide modules
including ide-disk, ide-generic and the ide/pci/* modules, are still there
maximilian attems wrote:
could you try the attached hook file,
please place it under /usr/share/initramfs-tools/scripts/init-premount/
and recreate the initramfs: update-initramfs -u
hope it works,
Yes, works ok here too.
--
see shy jo
signature.asc
Description: Digital signature
maximilian attems wrote:
initrd-tools loads _all_ ide driver and lets them fight out:
the ones which don't unload stay.
initrd-tools loads ide-generic last, AFAIK this makes it only take over
and disable DMA if no other module supports the hardware.
the bad side effect of a winning
Horms wrote:
Holger kindly reminded me on IRC yesterday that its been
a long time since a new 2.4.27 was uploaded into Sarge.
He pointed out that there are a number of valuable fixes
in SVN.
Is there any reason why you're sticking with 2.4.27+patches rather than
following the 2.4 series
Thought I'd document the process of updating d-i's kernel udebs from
2.6.12 to 2.6.14, since there's been various speculation about how
automatable this is.
1. Installed 2.6.14 kernel deb.
2. Ran find in the old and new kernel modules directories and diffed
the list to find added/removed
Frans Pop wrote:
Both initrd generators have limitations in what they currently support. We
may have to either always install both, or include logic that
pre-installs one or the other depending on the situation.
Based on http://wiki.debian.org/InitrdReplacementOptions I didn't see
any items
Sven Luther wrote:
Also, we have perl-base in base, or used to at least, would yaird not be able
to depend on perl-base only ?
yaird uses at lest the following perl modules which are not currently
present in perl-base but are in perl:
./Image.pm:use File::Copy;
./Pack.pm:use File::Temp;
On
Sven Luther wrote:
Ok, but who will chose which will be the default one ? The d-i team, or the
kernel team ?
It's more important to make a choice than what the choice is.
d-i chose between lilo and grub before; we did it by listening to what
users wanted and looking at which worked best
Jonas Smedegaard wrote:
Initramfs-tools May produce too big images for some arches. This needs
to be verified and documented (Sven seems most knowledgable about this).
Yaird needs sysfs on running system so cannot be used from a 2.4
system. This may not be an issue to d-i.
Yaird does not
This bug seems to be full of discussion of sarge, and was closed until
3.0.14a-4 didn't make the cut for sarge. Does it also affect etch and
sid? If not, could you close it for those, so we can stop tracking it as
a security issue for them?
--
see shy jo
signature.asc
Description: Digital
I reviewed base-installer for use of kernel-image-2.6.* metapackages.
It's still used by amd64, arm, m68k, mips, and mipsel:
[EMAIL PROTECTED]:~/src/d-i/packages/base-installer/kernelgrep kernel-image *
alpha.sh: echo kernel-image-$version-$SMP
amd64.sh: echo
Horms wrote:
for several reasons[*] it looks like we are going to need
to spin a fresh 2.6.12. Can someone in d-i comment on if
a fresh 2.6.12 entering testing in the next week or so will
case pain?
I don't anticipate any real pain.
--
see shy jo
signature.asc
Description: Digital
Grant Grundler wrote:
Netboot install uses a different initrd than the regular install?
If you define regular as from CD, then yes.
To do a basic install, one needs to load the drivers that control storage.
Given the size problems with the initrd, I find it hard to believe
that sym2 driver
Grant Grundler wrote:
I realize now that the 2.6.12 cat /proc/ioports output in this
bug (332962) doesn't list sym53c8xx driver.
Is there maybe something fundemental wrong with module loading?
ie can sym53c8xx driver be loaded?
I'm booting 2.6.12 with the d-i netboot install image, and since
Package: linux-image-2.6.12-1-parisc64
Severity: normal
Tags: d-i
I run daily installation tests with d-i on a hppa a500 machine. This no longer
works now that d-i has been updated to use this kernel version. It seems that
this version of the kernel does not support the onboard ethernet card. d-i
2.6.8 in Debian:
bison:~# cat /proc/ioports
- : LBA I/O Port
0040-007f : Hewlett-Packard Company Diva Serial [GSP] Multiport UART
0040-0047 : serial(auto)
0080-00ff : Digital Equipment Corporation DECchip 21142/43
0080-00ff : tulip
- Forwarded message from Grant Grundler [EMAIL PROTECTED] -
From: Grant Grundler [EMAIL PROTECTED]
Date: Sun, 9 Oct 2005 15:14:42 -0600
To: Joey Hess [EMAIL PROTECTED]
Cc: Debian Bug Tracking System [EMAIL PROTECTED],
debian-hppa@lists.debian.org
Subject: Re: tulip module
- Forwarded message from Kyle McMartin [EMAIL PROTECTED] -
From: Kyle McMartin [EMAIL PROTECTED]
Date: Sun, 9 Oct 2005 17:13:21 -0400
To: Grant Grundler [EMAIL PROTECTED]
Cc: Joey Hess [EMAIL PROTECTED], debian-hppa@lists.debian.org
Subject: Re: tulip module no longer works on a500
User
Grant Grundler wrote:
Can you post the entire console boot log someplace?
Here you go. Also, see my other mail to the bug report for some fairly
damning /proc/ioports stuff.
http://dilab.debian.net:800/~joey/d-i/logs/hppa/bison-dns-server-d-i-26.log
I'd try acenic, but the module is not in the
Sven Luther wrote:
Why would it break the beta ? since we should now be using the meta packages
everywhere, and the 2.6.13 should add no new dependency, the only problem i
would see is the inclusion of kernel packages in the distribution media, and
their dependencies (yaird and/or
Sven Luther wrote:
Joey, what are the estimated schedule for a release ?
I don't know. Why does the powerpc image build fail with E: Couldn't
find package firewire-core-modules-2.6.12-1-powerpc-miboot-di, since
linux-kernel-di-powerpc-2.6 only provides
Here's the best patch I've been able to find for this so far.
--
see shy jo
--- linux/arch/i386/kernel/apm.c.seg2005-03-27 13:10:45.0 -0800
+++ linux/arch/i386/kernel/apm.c2005-03-28 10:30:24.0 -0800
@@ -327,7 +327,7 @@ extern int (*console_blank_hook)(int);
* Save
FWIW, this is still reproducible using 2.6.12-6.
--
see shy jo
signature.asc
Description: Digital signature
Horms wrote:
On Thu, Sep 22, 2005 at 08:10:10AM +0200, Joey Hess wrote:
Here's the best patch I've been able to find for this so far.
This is completely weird, any ideas why this hasn't shown up before?
Apparently it's known breakage caused by the new binutils that I guess
only just reached
Horms wrote:
Ok, that makes sense. Let me know if the build completes and if so
I'll add it to the tree.
Build completed. Kernel seems ok.
--
see shy jo
signature.asc
Description: Digital signature
Package: initrd-tools
Version: 0.1.82
Severity: normal
If I am in /boot and I run mkinitrd -o foo 2.4.27, then I expect it to
output to a file foo in the current directory. Instead it writes the
output file somewhere inside the temporary tree, which is deleted when
mkinitrd exits. Only if I run
Horms wrote:
On Thu, Sep 15, 2005 at 01:05:41PM +1000, Geoff Crompton wrote:
Package: linux-2.6
Severity: important
Ref http://www.securityfocus.com/bid/14793
The kernel team is aware of this issue, and fixes are in the kernel
teams svn at svn.debian.org.
I created this
Sven Luther wrote:
Is this not the moment to modify the way our kernel .udeb packages are built,
It's not a prerequisite for getting a working release of d-i for etch. I
think our users are more interested in being able to install using the
new kernel.
Also, i propose that we rename the
Lennart Sorensen wrote:
Well doing a list of the modules in the current linux-image-2.6.12 on
i386, and then deleting from the list sound, and netfilter and anything
else obviously not needed and probably a few things that would be
needed, I got down to just under 400 modules. Probably most
Sven Luther wrote:
On Wed, Sep 14, 2005 at 11:04:27AM -0400, Joey Hess wrote:
Lennart Sorensen wrote:
Well doing a list of the modules in the current linux-image-2.6.12 on
i386, and then deleting from the list sound, and netfilter and anything
else obviously not needed and probably
Sven Luther wrote:
Mmm, why is this tripple need of holding udeb state necessary ?
Well, look at the code to main-menu, anna, and udpkg..
Would not solving this go a great way for diminishing general memory
usage anyway ?
No, this is not the current high water mark for memory usage in d-i.
Sven Luther wrote:
Nope, but i don't think there is a real problem in making d-i kernel
.udebs working for d-i, if said kernels already worked outside of d-i.
It's odd that you say this when you have just finished tracking down
#327891, which is a perfect example of the kind of issue that can
Sven Luther wrote:
Currently the modules are grouped per hand in .udebs, partly artificially,
partly because they belong to some wide group, and the dependencies are
handled by hand.
THe above statement is incorrect. Read
/usr/share/kernel-wedge/commands/copy-modules or even the documentation
Sven Luther wrote:
Which was a missing .udeb indeed
No it wasn't:
| Added nls_utf8 to fs-common-modules (Closes: #327891).
introduced by a change in the hfsplus module, or by a change in d-i. That
said, this is orthogonal to the issues discussed here. Also notice that if we
had
Marco d'Itri wrote:
Thinking again about this: an hotplug udeb is not be strictly needed,
because current versions of udev already provide the hotplug multiplexer.
The hotplug package currently provides:
- a firmware loader hotplug agent
- support for hotplug of network devices
- coldplug
Frans Pop wrote:
- We do however assume we can keep on using the oldfashioned initrd
support for booting d-i, so it would be nice if you were not too quick
in disabling/modularizing needed filesystem support in kernel configs
for 2.6.13.
We do intend to switch to initrdfs for d-i
Sven Luther wrote:
(CCing debian-release, as this may concern them, or they might have input, so
i hope they will also pick up the hppa flavour rename hint above, oh, and we
should kill all 2.6.8 and 2.6.11 packages from etch and sid now).
No, existing kernels that are a) sources of udebs of
Sven Luther wrote:
So, the installer needs to be fixed ASAP.
Getting a useable kernel into testing is a prerequsite for making the
installer use it, not the other way around.
In other words, the changes you recently made to base-installer for
powerpc to make it install the new kernel that is
Package: kernel-image-2.4.27-sparc
Version: 2.4.27-9
Severity: important
Tags: d-i
* Change default ramdisk size for sparc to 16,384K to accomodate a fatter
d-i initrd for netboot installs.
(Joshua Kwan)
This change has been made for the 2.6 kernel, but 2.4 is still using the old
8 mb
Here is a strace -s 4096 -xx as requested.
--
see shy jo
execve(/bin/ip, [\x69\x70, \x72\x6f\x75\x74\x65, \x61\x64\x64,
\x64\x65\x66\x61\x75\x6c\x74, \x76\x69\x61,
\x31\x39\x32\x2e\x31\x36\x38\x2e\x32\x2e\x31], [/* 10 vars */]) = 0
uname({sys=Linux, node=, ...}) = 0
brk(0)
Jeroen van Wolffelaar wrote:
This will break a lot packages depending on one of those, including but
not limited to things like linux-kernel-di-hppa-2.6, pwc,
user-mode-linux, kernel-headers-2.6-generic (alpha), etc etc.
Since kernel-lastest in testing still points to 2.6.8, it will also
break
Package: linux-image-2.6.12-1-386
Version: 2.6.12-1
Severity: normal
Tags: d-i
My main d-i test machine is a proliant DL360, and I'm running d-i on it.
With the 2.6.12 kernel I get a new kernel oops when the ide-generic
module is loaded.
Aug 5 22:20:44 kernel: SvrWks CSB5: IDE controller at
dann frazier wrote:
hey Joey,
We're wondering if its safe to prepare kernel images for
security.debian.org with an ABI change. We have at least one set of
patches for a security vulnerability that will affect all 2.6 archs.
Would that break d-i? Seems to me that it shouldn't, since the
What a mess.
Looks to me like the only real options for dealing with with bug for
sarge are:
- revert the powerpc change in debian/rules, downgrade bug as not RC
or
- re-upload initrd tools as an arch any package
--
see shy jo
signature.asc
Description: Digital signature
dann frazier wrote:
On Thu, 2005-05-12 at 10:50 -0400, Joey Hess wrote:
Horms wrote:
ia64: version in Sarge: 2.6.8-12
http://svn.debian.org/wsvn/kernel/trunk/kernel/ia64/kernel-image-2.6.8-ia64-2.6.8/debian/changelog?op=filerev=0sc=0
Will -14 will be an ABI change from -12
Horms wrote:
ia64: version in Sarge: 2.6.8-12
http://svn.debian.org/wsvn/kernel/trunk/kernel/ia64/kernel-image-2.6.8-ia64-2.6.8/debian/changelog?op=filerev=0sc=0
Will -14 will be an ABI change from -12 or not?
m68k: version in Sarge: 2.6.8-12
Horms wrote:
Thanks, this fix is in SVN.
Do you know if it has a CAN number assigned, I have been unable to find one?
If you've not guessed already, it's CAN-2005-0749 ;-)
--
see shy jo
signature.asc
Description: Digital signature
Andreas Barth wrote:
[What changes to d-i need to be done for a security upload?]
Besides building the udebs, if the abi changes we have to update rootskel,
base-installer, and the debian-installer build system.
The d-i changes are only finalized with the next point release - but well,
that
Andres Salomon wrote:
Cons:
- Does not address issues with d-i udebs and abi changes at all.
- It becomes impossible to include third-party modules in d-i, since we
have no precompiled modules for them anymore.
--
see shy jo
signature.asc
Description: Digital signature
Otavio Salvador wrote:
|| On Thu, 24 Mar 2005 12:05:05 -0500
|| Joey Hess [EMAIL PROTECTED] wrote:
jh Andres Salomon wrote:
Cons:
jh - Does not address issues with d-i udebs and abi changes at all.
jh - It becomes impossible to include third-party modules in d-i, since we
jh have
Andres Salomon wrote:
Right. My suggestion doesn't address d-i issues. We have two
options, it seems; the modules that are downloaded from a debian mirror
can either be versioned to support multiple ABIs (either by package name,
or by including multiple versions of modules in the package)
Joey Hess wrote:
Suppose that sarge releases and you buy a copy of the official sarge
businesscard CD image for your wallet. Or you burn a set of floppies.
Correction: businesscard does not have this problem; only installs from
floppy and netboot (and netboot mini-iso) does.
--
see shy jo
Otavio Salvador wrote:
Will work if you use a meta-package in base-installer for it, don't will?
I'm talking about ABI mersion mismatches between installer initrds and
kernel udebs, not in kernel debs.
--
see shy jo
signature.asc
Description: Digital signature
Eric Evans wrote:
I have successfully installed Sarge on an identical machine, (Dell 2850,
Perc 4e/Di RAID adapter), using todays daily build[1].
The megaraid2 module is loaded by both the installer, and the installed
kernel.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=300763
Did
Geoff Crompton wrote:
Package: kernel-source-2.6.8
Version: 2.6.8-13
Severity: critical
Justification: root security hole
There is a local integer overflow vulnerability in the sys_epoll_wait()
call. See following for detail:
http://www.securityfocus.com/bid/12763/
Apologies if already
Reopened this bug because AFAIK it still applies to 2.4.27. (And
probably a few other kernel versions too.)
--
see shy jo
signature.asc
Description: Digital signature
Just a quick note to say that I think we have all the kernels in place
that we want for d-i rc3, so if you've been holding off on some kernel
update (such as fixing any of the many security holes) to avoid
destabalising rc3, you can go ahead with it now.
--
see shy jo
signature.asc
Josselin Mouette wrote:
When you install an alsa-modules package for the 2.4 kernel, you get
alsa-base per the dependencies. However, when you install sarge with a
2.6 kernel, alsa-base doesn't end up being installed. The result is that
for most sound cards, both OSS and ALSA modules end up
Ok, the important distinction to draw is security fixes that involve ABI
changes vs those that do not. As long as the ABI remains the same, it's
relatively easy to get fixed debs in, and to update the installer to use
them. Not even a lot of coordination is required, we can update each
arch
After 1.5 months of mails, I guess this will be the last such mail sent
to the kernel team. However, I understand that some new security hole
may need yet another kernel ABI change. If that's true, the sooner we
find out about that the better, though judging from experience, updating
to a -3 abi
Matthew Wilcox wrote:
I think de4x5 should be a driver of last resort. Tulip should always
be preferred to drive a given piece of hardware. I wouldn't shed any
tears if we stopped shipping de4x5 by default -- it's caused no end of
problems on parisc and ia64.
OTOH it's the only module that
Matthew Wilcox wrote:
On Mon, Feb 14, 2005 at 01:09:43PM -0500, Joey Hess wrote:
Matthew Wilcox wrote:
I think de4x5 should be a driver of last resort. Tulip should always
be preferred to drive a given piece of hardware. I wouldn't shed any
tears if we stopped shipping de4x5
Steve Langasek wrote:
hppa
2.4 now updated, but we dropped it.
2.6 has abiname; still not updated, update is in kernel team svn.
[This is likely to block d-i rc3 until the new hppa 2.6 kernels
with the new abiname are available.]
Updated 2.6.8 in sid, needs an
I think it's best to defer any thought of switching d-i to a newer
kernel until after rc3. At the moment rc3 is nearly ready (except for
some missing kernel abiname updates), and I don't see any reason why we
cannot get it released within the month. Switching kernels is sure to
take longer than
Joey Hess wrote:
Before we can release d-i rc3 we need all the kernels updated with at
least some security fixes, notably the ones that change the kernel
module ABI, and we need to update things to reflect the new kernel
abiname. Here's my understanding of the current status of that:
Update
Horms wrote:
By my calculations that is 3am on Saturday morning in Japan,
I am not sure I will be in an appropriate state to be having meetings
at that time.
It's noon here, I may be awake for the meeting, if so I will attend. No
promises however.
My 2c worth here is that frankly 2.6 is
dann frazier wrote:
I pointed this out on IRC, but just to make sure it hits the list...
Turning of PREEMPT will change the module ABI. ia64 also has PREEMPT
turned on in 2.6.8 (following suit w/ x86), and I've left it on for this
reason.
Guys, if you change the ABI on me again right now, I
severity 291362 serious
reassign 291362 initrd-tools
thanks
Lupe Christoph wrote:
Kernel installation (2.4.27) failed because the initrd could not be
generated. dmsetup is missing.
Root is on a DM device, but dmsetup not installed
Failed to create initrd image.
Same happens with 2.6.8.
Before we can release d-i rc3 we need all the kernels updated with at
least some security fixes, notably the ones that change the kernel
module ABI, and we need to update things to reflect the new kernel
abiname. Here's my understanding of the current status of that:
i386
2.4 and 2.6
clone 289155 -1
reassign -1 kernel-source-2.4.27
thanks
Moritz Muehlenhoff wrote:
I haven't found a patch for 2.6 yet, a patch for 2.4 is available in
the 2.4 Bitkeeper branch.
Cloning a bug for 2.4 since it's also vulnerable.
--
see shy jo
signature.asc
Description: Digital signature
Looking at how these proposed fixes would affect d-i and existing rc2
images:
a. If the SONAME is left unchanged and the new ABI remains, and things
are updated to use the new ABI:
- Installs from a rc2 netinst CD will keep working, but you'll get a
kernel with the old ABI. Installs
Joey Hess wrote:
b. If the SONAME is increased and the ABI changes reverted for -1:
For some reason I based this on the mistaken assumption of -1 packages
staying in the archive after -2 entered it. Updated version for -1 going
away semi-immediatly:
- All rc2 images will keep working
Package: kernel-image-2.4.27-alpha
Version: 2.4.27-4
[EMAIL PROTECTED]:~/kernel-image-2.4.27-alpha-2.4.27$ dpkg-checkbuilddeps
dpkg-checkbuilddeps: Unmet build dependencies: kernel-tree-2.4.27-6
[EMAIL PROTECTED]:~/kernel-image-2.4.27-alpha-2.4.27$ su -c 'apt-get install
kernel-tree-2.4.27-6'
This bug is release critical. Please do not downgrade it. (But thanks for
reopening it.)
--
see shy jo
signature.asc
Description: Digital signature
Package: kernel-image-2.4.27-1-386
Version: 2.4.27-6
Severity: grave
Tags: d-i
Loading a module from the -2 version of this package when the -6 version
of the kernel is running fails for at least all the ide chipset modules
and for the ide generic module, with many missing symbols:
~ # uname -a
101 - 200 of 219 matches
Mail list logo
