Re: Bug#468075: this bug/#468075 - sudo: system freeze
reassign 468075 linux-image-2.6.24-1-686 found 468075 2.6.24-4 thanks Hello kernel maintainers, Please see this bug log regarding a soft lockup. A root processes looping around time() is sufficient to make the system unusable. Mar 21 13:06:39 libra kernel: BUG: soft lockup - CPU#0 stuck for 2s! [bash:2363] Mar 21 13:06:39 libra kernel: Mar 21 13:06:39 libra kernel: Pid: 2363, comm: bash Not tainted (2.6.24-1-686 #1) Mar 21 13:06:39 libra kernel: EIP: 0060:[c0113c77] EFLAGS: 00200286 CPU: 0 Mar 21 13:06:39 libra kernel: EIP is at flush_tlb_page+0x3f/0x62 Mar 21 13:06:39 libra kernel: EAX: 080f55e8 EBX: 080f55e8 ECX: cf5663d4 EDX: cf4bf9b0 Mar 21 13:06:39 libra kernel: ESI: cf5cd900 EDI: cf5663d4 EBP: c10780a0 ESP: ce15de6c Mar 21 13:06:39 libra kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Mar 21 13:06:39 libra kernel: CR0: 8005003b CR2: 080f55e8 CR3: 0f5ce000 CR4: 06d0 Mar 21 13:06:39 libra kernel: DR0: DR1: DR2: DR3: Mar 21 13:06:39 libra kernel: DR6: 4ff0 DR7: 0400 Mar 21 13:06:39 libra kernel: [c01663f3] do_wp_page+0x3cb/0x4d4 Mar 21 13:06:39 libra kernel: [c016730f] __pte_alloc+0x8d/0x9a Mar 21 13:06:39 libra kernel: [c0165c8b] vm_normal_page+0xd/0x3e Mar 21 13:06:39 libra kernel: [c016791b] copy_page_range+0x2e2/0x383 Mar 21 13:06:39 libra kernel: [c0167981] copy_page_range+0x348/0x383 Mar 21 13:06:39 libra kernel: [c01682a7] handle_mm_fault+0x609/0x685 Mar 21 13:06:39 libra kernel: [c01099ca] sched_clock+0x8/0x18 Mar 21 13:06:39 libra kernel: [c0103044] __switch_to+0x9d/0x11d Mar 21 13:06:39 libra kernel: [c011bf45] do_page_fault+0x1f7/0x592 Mar 21 13:06:39 libra kernel: [c0123ec5] do_fork+0x120/0x1cc Mar 21 13:06:39 libra kernel: [c012f3e6] sys_rt_sigprocmask+0x4b/0xc7 Mar 21 13:06:39 libra kernel: [c011bd4e] do_page_fault+0x0/0x592 Mar 21 13:06:39 libra kernel: [c02bdc32] error_code+0x72/0x78 Mar 21 13:06:39 libra kernel: [c02b] unix_mkname+0x4d/0x6f Mar 21 13:08:36 libra kernel: BUG: soft lockup - CPU#0 stuck for 2s! [strace:2485] Mar 21 13:08:36 libra kernel: Mar 21 13:08:36 libra kernel: Pid: 2485, comm: strace Not tainted (2.6.24-1-686 #1) Mar 21 13:08:36 libra kernel: EIP: 0060:[c012022f] EFLAGS: 0282 CPU: 0 Mar 21 13:08:36 libra kernel: EIP is at finish_task_switch+0x25/0x81 Mar 21 13:08:36 libra kernel: EAX: c1207940 EBX: ce37f740 ECX: ce19a030 EDX: ce19a000 Mar 21 13:08:36 libra kernel: ESI: EDI: ce19a030 EBP: 0008 ESP: cd0b5f50 Mar 21 13:08:36 libra kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Mar 21 13:08:36 libra kernel: CR0: 8005003b CR2: b7804000 CR3: 0df7 CR4: 06d0 Mar 21 13:08:36 libra kernel: DR0: DR1: DR2: DR3: Mar 21 13:08:36 libra kernel: DR6: 4ff0 DR7: 0400 Mar 21 13:08:36 libra kernel: [c02bc7aa] schedule+0x588/0x5ec Mar 21 13:08:36 libra kernel: [c0248cae] input_proc_handlers_open+0x8/0xc Mar 21 13:08:36 libra kernel: [c012b977] sys_ptrace+0x7c/0x83 Mar 21 13:08:36 libra kernel: [c0103f76] work_resched+0x5/0x26 Mar 21 13:08:40 libra kernel: BUG: soft lockup - CPU#0 stuck for 2s! [strace:2485] Mar 21 13:08:40 libra kernel: Mar 21 13:08:40 libra kernel: Pid: 2485, comm: strace Not tainted (2.6.24-1-686 #1) Mar 21 13:08:40 libra kernel: EIP: 0060:[c02bda19] EFLAGS: 0206 CPU: 0 Mar 21 13:08:40 libra kernel: EIP is at _spin_unlock_irqrestore+0xa/0x13 Mar 21 13:08:40 libra kernel: EAX: 0206 EBX: ECX: 0206 EDX: 0200 Mar 21 13:08:40 libra kernel: ESI: ce19a030 EDI: EBP: cd0b4000 ESP: cd0b5f7c Mar 21 13:08:40 libra kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Mar 21 13:08:40 libra kernel: CR0: 8005003b CR2: b77c1000 CR3: 0df7 CR4: 06d0 Mar 21 13:08:40 libra kernel: DR0: DR1: DR2: DR3: Mar 21 13:08:40 libra kernel: DR6: 4ff0 DR7: 0400 Mar 21 13:08:40 libra kernel: [c01220bf] wait_task_inactive+0x45/0x62 Mar 21 13:08:40 libra kernel: [c012b8f5] ptrace_check_attach+0xa1/0xa7 Mar 21 13:08:40 libra kernel: [c012b944] sys_ptrace+0x49/0x83 Mar 21 13:08:40 libra kernel: [c0103ed6] syscall_call+0x7/0xb On Fri, Mar 21, 2008 at 07:14:15AM -0700, Daniel Burrows wrote: On Thu, Mar 20, 2008 at 12:24:17PM -0400, Justin Pryzby [EMAIL PROTECTED] was heard to say: On Wed, Mar 19, 2008 at 06:31:13PM -0700, Daniel Burrows wrote: Most likely some critical part of your X session wanted to access the disk, and it was blocked out by apt. I'm not sure how to confirm this; on Windows there are ways of monitoring file accesses across the system (so you could see which programs were contending with apt for the disk and how long they got blocked), but I don't know of any equivalent for Linux. I don't think it's disk IO related. Having run this command very often, all my Packages files are cached at various layers, and (despite having a not-recent machine with a slow disk and only 256MB RAM
Bug#460194: this bug/#460194 - aptitude: freezes desktop for four seconds when launched with sudo
#460194 - aptitude: freezes desktop for four seconds when launched with sudo http://bugs.debian.org./460194 I can reproduce this problem readily. You said you were using 2.6.24-rc, but that the problem occured with older kernels. How old? I'm not able to reproduce it with 2.6.22. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
`basename $f` and ${f##*/}
Hi everyone,
After reading /usr/share/initramfs-tools/hook-functions, I wanted to
comment that `basename $foo` is often replaced with the (posix)
shell expansion ${foo##*/} which expands to the value of foo with the
longest prefix matching shell wildcard */ stripped (but doesn't
modify foo). There's also # for the shortest match, %% for the
longest suffix, and % for the shortest suffix. I usually refer to
dash(1) for these things.
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: update-initramfs, chroots ro /boot, and debian-live (Re: d-l and /boot ro)
On Mon, Sep 03, 2007 at 08:57:41PM +0200, Daniel Baumann wrote: maximilian attems wrote: well update-initramfs checks if there is a readable /proc/mounts, so if /proc is !mounted everything si fine. that's what i stated.. but it's ugly to mount, do stuff, unmount, update initramfs, mount, do stuff, and unmount again. it would be, probably, better if update-initramfs could handle read-only /boot. Unfortunately the problem is that it *does* handle ro boot, as a special case (and not chroot). Perhaps it should also test `stat -c '%i' /boot` = `stat -c '%i' /proc/1/root/boot` or some such other chroot indicator. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: update-initramfs, chroots ro /boot, and debian-live (Re: d-l and /boot ro)
On Mon, Sep 03, 2007 at 10:36:56PM +0200, maximilian attems wrote: On Mon, Sep 03, 2007 at 03:28:00PM -0400, Justin Pryzby wrote: On Mon, Sep 03, 2007 at 08:57:41PM +0200, Daniel Baumann wrote: maximilian attems wrote: well update-initramfs checks if there is a readable /proc/mounts, so if /proc is !mounted everything si fine. that's what i stated.. but it's ugly to mount, do stuff, unmount, update initramfs, mount, do stuff, and unmount again. it would be, probably, better if update-initramfs could handle read-only /boot. Unfortunately the problem is that it *does* handle ro boot, as a special case (and not chroot). Perhaps it should also test `stat -c '%i' /boot` = `stat -c '%i' /proc/1/root/boot` or some such other chroot indicator. so could you reexplain what your request is, cool thanks. I'm wondering whether initramfs should have some more checks before exiting without doing anything. In particular whether it should check for a chroot. I'm not sure either way, but I think I agree with Daniel it would be a kludge to solve this within debian-live. It would be something like: . unmounting and remounting proc and manually rather than automatically calling update-initramfs (since otherwise dpkg and who knows what else will be run without /proc); or, . trying to hide from initramfs that the external /boot is ro. i'll try to rephrase you have chroot where /proc is mounted, where the exterior /boot is ro. thus no initramfs is generated inside of the chroot? Right. The readonly boot is specific to me (but could happen anywhere). The chroot with mounted /proc is normal debian-live build process. why is proc mounted? For the same reason it has to be mounted outside the chroot: things fail in obscure ways when it isn't. Within the chroot dpkg runs maintainer scripts which run next to everything. Here, IIRC, update-initramfs is being run by a kernel installation. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
update-initramfs, chroots ro /boot, and debian-live (Re: d-l and /boot ro)
On Tue, Aug 28, 2007 at 09:13:00PM +0200, Daniel Baumann wrote: Justin Pryzby wrote: Check update-initramfs, which reads from proc/mounts, which makes the scripts not completely hostfs agnostic. ummm.. bad one that, thanks for pointing it out. someone has a good idea about that? actually, at the time where update-initramfs is run, we should not mount /proc, but that's going to be a bit nasty to mount/unmount it just before and after lh_chroot_hacks. Should u-i check if it's in a chroot before testing for ro root (I don't know). I tried briefly bind mounting dev/null over proc/mounts but made some kind of process specific proc/PID/mounts instead.. initramfs people, see thread starting at: http://lists.alioth.debian.org/pipermail/debian-live-devel/2007-August/002075.html Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: crashme test affects linux=2.6.17.2+
On Thu, Jan 11, 2007 at 10:30:43AM +0100, maximilian attems wrote: On Thu, Jan 11, 2007 at 12:35:38AM -0500, Justin Pryzby wrote: The testcase given by crashme.c (crashme +2000.80 666 100 1:10:30 2) seems to have effects which shouldn't be possible for an unprivledged process (PID1/2 respawn too fast..). This affects linux-image-2.6.17-2-686 2.6.17-8 but does not affect linux-image-2.6.18-1-686 2.6.18-1. Was this a known problem? Can someone provide a reference for it? 2.6.18 is the supported kernel for etch. we haven't put any work on 2.6.17 since long, please migrate. Of course; I was just trying to narrow the range of changelogs to read. I also saw the problem on 2.6.16, but I'm not sure even if this is a useful way of checking.. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
crashme test affects linux=2.6.17.2+
Hi, The testcase given by crashme.c (crashme +2000.80 666 100 1:10:30 2) seems to have effects which shouldn't be possible for an unprivledged process (PID1/2 respawn too fast..). This affects linux-image-2.6.17-2-686 2.6.17-8 but does not affect linux-image-2.6.18-1-686 2.6.18-1. Was this a known problem? Can someone provide a reference for it? Thanks Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391619: this bug/#391619: p{re,ost}insts' comments contradict each other
reopen 391619 retitle 391619 initramfs-tools: preinst fragment is never run severity 391619 important kthx There is a real problem here. preinst is never called with a 'configure argument: http://www.us.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-mscriptsinstact -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392101: initramfs-tools: conffile prompt
Package: initramfs-tools Severity: normal Version: 0.82 I was presented with a diff while dist-upgrading. I didn't make any component of the changes, so I shouldn't have been prompted. --- /etc/initramfs-tools/initramfs.conf 2006-02-20 16:55:50.0 -0500 +++ /etc/initramfs-tools/initramfs.conf.dpkg-new2006-07-20 14:49:22.0 -0400 @@ -17,14 +17,12 @@ MODULES=most +# BUSYBOX: [ y | n ] +# +# Use busybox if available. # -# RESUME: [ /dev/hda2 | /dev/sdb2 ] -# -# optional - set the swap partition to resume from. -# cat /proc/swaps | egrep ^/dev should show possible candidates. -# The command line of your boot loader will override this setting. -#RESUME= +BUSYBOX=y # # NFS Section of the config. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376008: initramfs-tools: conffile prompt
On Mon, Jul 03, 2006 at 09:56:38PM +0200, maximilian attems wrote: On Mon, Jul 03, 2006 at 03:37:04PM -0400, Justin Pryzby wrote: found 376008 0.66 reopen 376008 thanks This isn't fixed yet, and (I suspect) is the cause of a conffile prompt during this upgrade. preinst: sed -i -e s/RESUME=.*/#RESUME=/ /etc/initramfs-tools/initramfs.conf this code is gone postinst: sed -i \ -e 's/mkinitrd/mkinitramfs/g' \ -e '/^ide-generic/d' \ -e '/^ide-disk/d' \ -e '/^ext2/d' \ -e '/^ext3/d' \ /etc/initramfs-tools/modules this is _first_ time install, we migrate the settings from mkinitrd. not a modification of an conffile as we weren't installed previously. ../status: /etc/initramfs-tools/initramfs.conf d69c47df9b52f41ce38ce59a788b9cdc initramfs-tools.list:/etc/initramfs-tools/initramfs.conf initramfs-tools.conffiles:/etc/initramfs-tools/initramfs.conf ../status: /etc/initramfs-tools/modules 93a8919fa71d3e00419b98f4b102f4d0 initramfs-tools.list:/etc/initramfs-tools/modules initramfs-tools.conffiles:/etc/initramfs-tools/modules would you please check the version against this bug was closed! upload said fixed in 0.67. Oops, you're right. I didn't realize this was todays upload, so installed from unstable and assumed the version was latest. I think the migration from mkinitrd should happen in preinst, not in postinst. In preinst it isn't a conffile, and this is where typical conffile migration (move,remove,etc) strategies exist. In postinst, it *is* a conffile, and must not be modified. At the very least it should be protected with an f=/etc/initramfs-tools/modules if [ ! -e $f ] [ ! -L $f ]; then -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376008: initramfs-tools: conffile prompt
close 376008 0.67 thanks On Mon, Jul 03, 2006 at 11:09:40PM +0200, maximilian attems wrote: clone 376008 -1 retitle -1 mkinitrd migration needs to be done in preinst notfound 376008 0.67 You want close [version]; notfound just cancels a 'found'. stop On Mon, Jul 03, 2006 at 04:50:44PM -0400, Justin Pryzby wrote: On Mon, Jul 03, 2006 at 09:56:38PM +0200, maximilian attems wrote: snipp would you please check the version against this bug was closed! upload said fixed in 0.67. Oops, you're right. I didn't realize this was todays upload, so installed from unstable and assumed the version was latest. ok so we agree that the issue of modifying /etc/initramfs-tools/initramfs.conf aka bug #376008 is fixed. so marking your initial bugreport as fixed. I think the migration from mkinitrd should happen in preinst, not in postinst. In preinst it isn't a conffile, and this is where typical conffile migration (move,remove,etc) strategies exist. In postinst, it *is* a conffile, and must not be modified. At the very least it should be protected with an well it is a very theoretical conffile as we didn't exist previously and no one ships that, but you are right. dpkg will prompt on the current upgrade if you do it in preinst, but it will not do so until the next upgrade if you do it in postinst. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376008: initramfs-tools: conffile prompt
On Mon, Jul 03, 2006 at 04:50:44PM -0400, pryzbyj wrote: On Mon, Jul 03, 2006 at 09:56:38PM +0200, maximilian attems wrote: On Mon, Jul 03, 2006 at 03:37:04PM -0400, Justin Pryzby wrote: found 376008 0.66 reopen 376008 thanks This isn't fixed yet, and (I suspect) is the cause of a conffile prompt during this upgrade. Here's the diff; is there any way you can prevent this? --- /etc/initramfs-tools/modules2005-12-28 14:39:52.0 -0500 +++ /etc/initramfs-tools/modules.dpkg-new 2006-03-26 04:52:26.0 -0500 @@ -1,12 +1,9 @@ -# /etc/mkinitramfs/modules: Kernel modules to load for initrd. +# List of modules that you want to include in your initramfs. # -# This file should contain the names of kernel modules and their arguments -# (if any) that are needed to mount the root file system, one per line. -# Comments begin with a `#', and everything on the line after them are ignored. +# Syntax: module_name [args ...] # -# You must run mkinitramfs(8) to effect this change. # -# Examples: +# This might be good choices: # -# ext2 -# wd io=0x300 +# raid1 +# sd_mod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376008: initramfs-tools: preinst modifies conffile, postinst requires /u/s/doc/
Package: initramfs-tools Version: 0.60 Severity: serious initramfs-tools.preinst modifies the conffile /etc/mkinitramfs/conf.d/resume: sed -i -e s/RESUME=.*/#RESUME=/ /etc/mkinitramfs/initramfs.conf ../status: /etc/mkinitramfs/initramfs.conf d69c47df9b52f41ce38ce59a788b9cdc initramfs-tools.list:/etc/mkinitramfs/initramfs.conf initramfs-tools.conffiles:/etc/mkinitramfs/initramfs.conf initramfs-tools.preinst depends on the existence of /u/s/d/, which the etch release notes require to be removable: if [ ! -e /etc/mkinitramfs/modules ]; then cp /usr/share/doc/initramfs-tools/examples/modules /etc/mkinitramfs/ fi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368043: initramfs-tools: postinstall script can require /usr/share/doc/
Package: initramfs-tools Version: 0.60 Severity: important Justification: Packages must not require the existance of any files in /usr/share/doc in order to function. http://release.debian.org/etch_rc_policy.txt The postinstall script does: |if [ ! -e /etc/mkinitramfs/modules ]; then |cp /usr/share/doc/initramfs-tools/examples/modules /etc/mkinitramfs/ |fi This code gets called on a dpkg-reconfigure, and can fail if the admin has removed /etc/mkinitramfs/modules: |$ sudo dpkg-reconfigure initramfs-tools |cp: cannot stat `/usr/share/doc/initramfs-tools/examples/modules': No such file or directory -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361515: linux-doc-2.6.16: copyright and README.Debian are redundant; the latter is outdated
Package: linux-doc-2.6.16
Version: 2.6.16-5
Severity: minor
zdiff -u /usr/share/doc/linux-doc-2.6.16/{copyright,README.Debian.gz}
There are a minimal number of changes, but the files are redundant. A
single file should provide all of the up to date information.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
linux-image-2.6.14-2 fails to purge
Hello debian-kernel, I recently updated to linux-image-2.6.15-1, and now I want to remove linux-image-2.6.14-2, but the postinst hangs reading from a pipe during the call to purge(). I'm presently in state Config-files, and I don't know how to debug it further. Surely the package should be purgable, but I don't know if its worth filing a bug, since the package is removed anyway. Please Cc: me. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344544: provides man9/ but no manpages in this
reassign 344544 linux-doc-2.6.15 close 344544 2.6.15-7 thanks How is one supposed to keep current documentation packages installed, anyway? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352633: initramfs-tools: update-initramfs grammar: s/was/has/;
Package: initramfs-tools
Version: 0.51
Severity: minor
mild_panic ${initramfs} was been altered. Cannot update.
^
s/was/has/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344544: linux-doc: provides man9/ but no manpages in this package
Package: linux-doc-2.6.14 Version: 2.6.14-4 Severity: minor $ dpkg -L linux-doc-2.6.14 |grep man9 /usr/share/man/man9 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344374: linux-image: error message missing words/variables/parameters
Package: linux-image-2.6.14-2-686 Version: 2.6.14-6 Severity: normal x Error running the boot loader in test mode. x x x x An error occurred while running the boot loader in test mode. A log is x x available in /var/log/lilo_log.11026. Please edit /etc/.conf manually x x and re-run , or make other arrangements to boot your machine. x the boot loader ___ in test mode /etc/___.conf re-run ___, or make -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343424: linux-doc-2.6.14: s/varios/various/ typo in long description
Package: linux-doc-2.6.14 Version: 2.6.14-4 Severity: minor Please s/varios/various/ in the long description. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311357: Debian and astronomy (was: Re: Bug#311357: Upgrade of 386 version of the 2.6.8 kernel breaks via-rhine)
Are you an astronomy user of Debian? Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308724: CAN-2005-1263: ELF core dump privilege elevation
Package: kernel-source-2.6.8 Severity: grave Tags: security patch Justification: user security hole http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.11.9 The relevent changes for this CAN appear to be solely in ./fs/binfmt_elf.c. There is also a memset in ./drivers/char/drm/drm_ioctl.c which should probably be added, among lots of other should-be-fixed things. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299875: ppp: out-of-memory 30min after LCP terminated by peer
Okay. Do I correctly understand that kernel patch + downgrade solves your problem? And, if you have *just* the kernel patch, /usr/sbin/pppd hangs, but doesn't crash the system? Thanks, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300314: kernel bug
submitter 300314 Bluefuture [EMAIL PROTECTED] thanks Are you using a Dell laptop? The Linux 2.6.8 Changelog mentions a fix for ALSA with a Dell. (But, you said it crashed under 2.6.8; thought I'd ask anyway.) Knowing your machine type and sound card might help; the kernel changelogs mention a number of quirks updates. And, sorry, I have to ask again: Can you confirm the whole system really froze? Like, even a remote ssh session would be disconnected, and it didn't respond to ping, etc.? Would you be able to test 2.6.9? I'm curious when the problem was fixed. 2.6.9 seems to have a massive ALSA update, so it may well be fixed there. This will help find where the fix is (since Sarge will ship with 2.6.8, a fix needs to be applied before release). You referred to the latest alsa driver. Do you mean a userspace alsa driver? As best I know, all of the alsa drivers are in the kernel, but you referred to 2.6.10 AND latest alsa. Thanks, Justin References [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=300314 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300314: kernel bug
close 300314 thanks On Sat, Mar 19, 2005 at 02:20:27AM +0100, Bluefuture wrote: Il giorno ven, 18-03-2005 alle 18:43 -0500, Justin Pryzby ha scritto: On Sat, Mar 19, 2005 at 01:18:07AM +0100, Bluefuture wrote: 2.6.10 and the latest user space alsa (alsa-base). Okay. alsa-base is just configuration files. Did you have alsa compiled into the kernel bzImage, or did you use modules? I had the default kernel installed. I had tried also to start horgand with the latest 2.6.8 kernel and it doesn't freeze the system anymore. In 2.6.10 i had switched horgand configuration for output to jack so when i rebooted in 2.6.8 it was still setted on jack output (default after horgand installation was alsa). I need to reboot again with alsa setted in horgand or is it improbably? I'm not sure; I don't know anything about these programs, and I was just following up on the bug because of a potential kernel security problem. In the period from bugs reporting to today, when i had tried to sucessfull start horgand i had also upgrade my motherboard firmware. There are many factors to try to exactly reproduce this bugs. If at report time it was identified as a kernel bugs i could did more test, but actually is very hard to reproduce it. Indeed; I just noticed that the bug report is kind of old. It would be good if you could try to reproduce it. I'll close the kernel bug for now, and reopen it if you find that you can reproduce the crash. Thanks, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
