Re: Proposed changes to initramfs-tools hook scripts
On Wed, 30 Jun 2010, Stephen Powell wrote: Max, As promised, here are my proposed changes to the initramfs-tools hook scripts. /etc/kernel/postinst.d/initramfs-tools: http://www.wowway.com/~zlinuxman/kernel/postinst.d/initramfs-tools /etc/kernel/postrm.d/initramfs-tools: http://www.wowway.com/~zlinuxman/kernel/postrm.d/initramfs-tools I release the changes under the same license as currently used. I did not include the scripts or patches in-line in my e-mail because my e-mail client has the nasty habit of expanding tabs, inserting extra line breaks, etc. So I up-loaded the files to my web site and included links to them in this e-mail. Changes: (1) Does not create an initial RAM file system image for a custom kernel created by make-kpkg if one was not requested by the --initrd flag of make-kpkg. (2) Redirects STDOUT to STDERR when invoking update-initramfs. (Avoids output being swallowed by debconf's redirection of STDOUT.) (3) Postinst.d version always exits with status code zero, even if an error occurs attempting to delete the initramfs. thank you very much. applied your 3 changes to branch maks/hooks on http://git.debian.org/?p=kernel/initramfs-tools.git;a=summary please review before I'd merge into master for next upload. I'm not sure if the indirection to STDERR is needed for make deb-pkg, but it shouldn't hurt there? you may want to have a look at for initramfs-tools dev http://git.debian.org/?p=kernel/initramfs-tools.git;a=blob_plain;f=docs/maintainer-notes.html;h=eeceafdfc498bd6585328d1eeb52e6e454d524ee;hb=HEAD changes in git send-email or online git repo are easier to handle. Although not strictly within your jurisdiction, I will also send you another e-mail soon with links to my proposed boot loader hook script for lilo and zipl. I'd like you to take a look at it to make sure that everything is going to flow together smoothly. I'm talking about the kernel hook script at this point, not the initramfs hook script. okay cool. -- maks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100702062045.ga4...@stro.at
Processed: Re: Bug#587754: linux-image-2.6.32-5-686-bigmem: dpkg failed dependency problems prevent configuration of linux-image
Processing commands for cont...@bugs.debian.org: reassign 587754 grub Bug #587754 [linux-2.6] linux-image-2.6.32-5-686-bigmem: dpkg failed dependency problems prevent configuration of linux-image Bug reassigned from package 'linux-2.6' to 'grub'. Bug No longer marked as found in versions 2.6.32-15. stop Stopping processing here. Please contact me if you need assistance. -- 587754: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587754 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.127805259227143.transcr...@bugs.debian.org
Bug#587754: linux-image-2.6.32-5-686-bigmem: dpkg failed dependency problems prevent configuration of linux-image
reassign 587754 grub stop On Fri, Jul 02, 2010 at 10:01:11AM +0530, B Raveendra Reddy wrote: This is not the complete output. You removed the important parts. Bastian I am sorry. This is my first post. Here is the complete output. I am not able to install any kernel. I hope this will help you. - Setting up linux-image-2.6.32-5-686-bigmem (2.6.32-15) ... Running depmod. Running update-initramfs. update-initramfs: Generating /boot/initrd.img-2.6.32-5-686-bigmem This kernel does not seem to support TuxOnIce user interface, skipping... initrd.img(/boot/initrd.img-2.6.32-5-686-bigmem ) points to /boot/initrd.img-2.6.32-5-686-bigmem (/boot/initrd.img-2.6.32-5-686-bigmem) -- doing nothing at /var/lib/dpkg/info/linux-image-2.6.32-5-686-bigmem.postinst line 400. vmlinuz(/boot/vmlinuz-2.6.32-5-686-bigmem ) points to /boot/vmlinuz-2.6.32-5-686-bigmem (/boot/vmlinuz-2.6.32-5-686-bigmem) -- doing nothing at /var/lib/dpkg/info/linux-image-2.6.32-5-686-bigmem.postinst line 400. Running update-grub. Searching for GRUB installation directory ... found: /boot/grub User postinst hook script [update-grub] exited with value 1 grub error. dpkg: error processing linux-image-2.6.32-5-686-bigmem (--configure): subprocess installed post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of linux-image-2.6-686-bigmem: linux-image-2.6-686-bigmem depends on linux-image-2.6.32-5-686-bigmem; however: Package linux-image-2.6.32-5-686-bigmem is not configured yet. dpkg: error processing linux-image-2.6-686-bigmem (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: linux-image-2.6.32-5-686-bigmem linux-image-2.6-686-bigmem Setting up linux-image-2.6.32-5-686-bigmem (2.6.32-15) ... Running depmod. Running update-initramfs. update-initramfs: Generating /boot/initrd.img-2.6.32-5-686-bigmem This kernel does not seem to support TuxOnIce user interface, skipping... initrd.img(/boot/initrd.img-2.6.32-5-686-bigmem ) points to /boot/initrd.img-2.6.32-5-686-bigmem (/boot/initrd.img-2.6.32-5-686-bigmem) -- doing nothing at /var/lib/dpkg/info/linux-image-2.6.32-5-686-bigmem.postinst line 400. vmlinuz(/boot/vmlinuz-2.6.32-5-686-bigmem ) points to /boot/vmlinuz-2.6.32-5-686-bigmem (/boot/vmlinuz-2.6.32-5-686-bigmem) -- doing nothing at /var/lib/dpkg/info/linux-image-2.6.32-5-686-bigmem.postinst line 400. Running update-grub. Searching for GRUB installation directory ... found: /boot/grub User postinst hook script [update-grub] exited with value 1 dpkg: error processing linux-image-2.6.32-5-686-bigmem (--configure): subprocess installed post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of linux-image-2.6-686-bigmem: linux-image-2.6-686-bigmem depends on linux-image-2.6.32-5-686-bigmem; however: Package linux-image-2.6.32-5-686-bigmem is not configured yet. dpkg: error processing linux-image-2.6-686-bigmem (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: linux-image-2.6.32-5-686-bigmem linux-image-2.6-686-bigmem regards, ravi -- http://www.imsc.res.in B. Raveendra Reddy | email: r...@imsc.res.in The Institute of Mathematical Sciences | phone: (91)44-2254 3222 Chennai 600 113 |(91)44-2448 7845 (Res) India | fax : (91)44-2254 1586 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.1.10.1007020953270.3...@as100.imsc.res.in -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100702062726.go9...@baikonur.stro.at
Bug#587887: linux-base: please suppress useless debconf messages on first install
package: linux-base
version: 2.6.32-15
severity: wishlist
tags: patch
Hi,
first of all: thank you all for maintaining linux-2.6 - you're doing an
awesome job!
h01ger hi. i'm using .32.bpo on lenny, together with linux-base. so far so
good, works great. but i have an issue with automated installs (with d-i and
preseeding): linux-base informs me that /etc/fstab contains an entry
(/etc/scd0 iirc) which might not work in future versions. i couldnt care less
and would like to get rid of this warning,as it prevents fully automated
installations
bwh^ h01ger: I put a heuristic in there to work out whether this is a fresh
installation or upgrade
bwh^ h01ger: Maybe you can suggest how to improve it
bwh^ (the problem is that linux-base did not exist in lenny, so we cannot
check whether the package itself is being upgraded)
bwh^ Of course you should also be able to preseed the answer
h01ger i tried, using what debconf-get-selections |grep linux-base gave me
after an installation, but that didnt work
bwh^ weird
# make linux-base install quietly
#
# Boot loader configuration check needed
linux-base linux-base/disk-id-manual-boot-loader error
# Configuration files still contain deprecated device names
linux-base linux-base/disk-id-manual error
# Apply configuration changes to disk device IDs?
linux-base linux-base/disk-id-convert-plan-no-relabel boolean true
# Opdater diskenheds-id'er i systemkonfigurationen?
linux-base linux-base/disk-id-convert-auto boolean true
# Apply configuration changes to disk device IDs?
linux-base linux-base/disk-id-convert-plan boolean true
h01ger bwh, i wonder if your test fails as there were already .26 packages
installed...
h01ger ha! if /var/log/installer doesnt exist, its a fresh install. bingo
see attached patch
h01ger bwh, do you want a wishlist bug about this?
bwh^ h01ger: Yes, file a wishlist bug, please
cheers,
Holger
1578a1579,1581
if !(-d '/var/log/installer') {
return 0;
}
signature.asc
Description: This is a digitally signed message part.
Bug#587608: Sorted out this bug
Package: initramfs-tools Version: 0.97 Severity: normal Hello, Dear Maks, It's a long time since we last talked together. I've sorted out the bug, thought I can't explain why my system was broken in such a way to explose this bug. Please, read on. The only thing I did was to upgrade initramfs-tools from version 0.94.4 to version 0.97 , as the following dpkg.log line shows: 2010-06-30 12:51:11 upgrade initramfs-tools 0.94.4 0.97 All went good, and triggers went right. I made this update the usual way, through aptitude. I've investigated and reached the following conclusion: For some reason, there was no COMPRESS=... stanza in my /etc/initramfs-tools/initramfs.conf configuration file. It is very strange, because I've never ever tried to modify this. Creating an initrd with initramfs-tools 0.94.4 succeeded because this version is resilient to the missing COMPRESS=... stanza. In the contrary, creating an initrd with initramfs-tools 0.97 failed because this version relies on the stanza COMPRESS=... which was missing on my system. That explains why the bug triggered on upgrade from version 0.94.4 to version 0.97 of the initramfs-tools package. Here folows my interpretation of why my system was missing the COMPRESS=... stanza in the initramfs.conf configuration file: Ages ago, I was in need of modifying this coniguration file, just the MODULES=... stanza in fact. I often swapped from MODULES=most to MODULES=dep, and vice versa, because either I had trouble to make lilo boot with large initrds, or I didn't get the good set of modules in to boot. (both happened alternatively) I believe, thought, it is quite some time now, that my initramfs.conf configuration file has returned to a sane state WRT this MODULES=... stanza, because it was monthes ago that I last needed such trickery. It appears very likely that some older version of initramfs-tools didn't have a COMPRESS=... stanza in its configuration file. And for some reason, APT/DPKG messed things up on successive upgrades of initramfs-tools, and did not replace the initramfs.conf configuration file with its updated version. I believe that APT/DPKG didn't warn me that I had a modified local version of the initramfs.conf configuration file. I remember clearly, however, that APT/DPKG warned me that I had a modified update-initramfs.conf configuration file, and I directed it to keep my local version which only differed from the official version by the modified update_initramfs=no stanza, instead of update_initramfs=yes. So, I still can't explain why my initramfs.conf configuration file was still missing the COMPRESS=... stanza. Even more strange is that reportbug warned me that I had a modified update-initramfs.conf file, but didn't talk about my then modified initramfs.conf file either. This missing stanza has survived at least two upgrades of initramfs-tools : from pre- 0.94.4 to 0.94.4 , and from 0.94.4 to 0.97 ; without me being warned, and the bug only triggered when using the 0.97 version because this particular version depends on the COMPRESS variable to be set properly, as I said above. I can't figure out why APT/DPKG didn't warn me that I had a modified local version of initramfs.conf . All that I know is that NOW, APT/DPKG warns me if I modify /etc/initramfs-tools/initramfs.conf before upgrading initramfs-tools from version 0.94.4 to version 0.97 . Note that it is strange that initramfs-tools 0.97 depends on the COMPRESS variable to be set properly in /etc/initramfs-tools/initramfs.conf, while the 0.94.4 version does not, especially that both versions embed a COMPRESS=gzip stanza. That's all. In hope my report will prove useful. Sincerely, Valentin QUEQUET -- Package-specific info: -- initramfs sizes lrwxrwxrwx 1 root root 51 Feb 16 12:09 /boot/initrd.img-2.6.29.4-reiser4-um-custom-0001 - /usr/bin/initrd.img-2.6.29.4-reiser4-um-custom-0001 lrwxrwxrwx 1 root root 79 Feb 16 12:09 /boot/initrd.img-2.6.29.4-reiser4-um-custom-0001.udev_and_cryptsetup_updated - /usr/bin/initrd.img-2.6.29.4-reiser4-um-custom-0001.udev_and_cryptsetup_updated -rw-r--r-- 1 root root 13M Jun 8 18:07 /boot/initrd.img-2.6.32-5-686 -rw-r--r-- 1 root root 13M Jun 8 18:08 /boot/initrd.img-2.6.32-5-686-bigmem -rw-r--r-- 1 root root 14M May 21 02:22 /boot/initrd.img-2.6.33-2-686 -rw-r--r-- 1 root root 14M May 21 02:23 /boot/initrd.img-2.6.33-2-686-bigmem -rw-r--r-- 1 root root 14M May 6 01:43 /boot/initrd.img-2.6.33-3.dmz.2-liquorix-686 -rw-r--r-- 1 root root 14M Feb 19 16:10 /boot/initrd.img-2.6.33-rc8-git1-custom-0001 lrwxrwxrwx 1 root root 45 Feb 16 12:04 /boot/initrd.img-2.6.33-rc8-um-custom-0001 - /usr/bin/initrd.img-2.6.33-rc8-um-custom-0001 -rw-r--r-- 1 root root 15M May 30 10:36 /boot/initrd.img-2.6.34-0.dmz.5-liquorix-686 -rw--- 1 root root 14M Jul 2 10:17 /boot/initrd.img-2.6.34-1-686 -rw-r--r-- 1 root root 46K Jun 30 14:01 /boot/initrd.img-2.6.34-1-686-bigmem.list -rw-r--r-- 1 root root 14M Jun 8 17:46
Bug#587905: linux-image-2.6.32-5-openvz-amd64: Starting VZ container on ext4 panics with: BUG: unable to handle kernel NULL pointer dereference
Package: linux-2.6 Version: 2.6.32-15 Severity: normal Hi! This is a fresh squeeze setup, with root-fs and vz-home on ext4 partitions. After creating a fresh OpenVZ container, and a vzctl start $VEID, the kernel Oopsed. Doing the same, but with DISK_QUOTA=no works fine, so I suspect there's a problem with quotas on ext4. Christian Log from the Oops: [ 1241.171110] BUG: unable to handle kernel NULL pointer dereference at (null) [ 1241.171164] IP: [(null)] (null) [ 1241.171191] PGD 31a655067 PUD 319a6d067 PMD 0 [ 1241.171225] Oops: 0010 [#1] SMP [ 1241.171253] last sysfs file: /sys/devices/virtual/vc/vcsa6/uevent [ 1241.171284] CPU 0 [ 1241.171306] Modules linked in: vzethdev vznetdev simfs vzrst vzcpt vzdquota vzmon vzdev ip6t_REJECT ip6table_mangle ip6table_filter ip6_tables xt_tcpudp xt_length xt_hl xt_tcpmss xt_TCPMSS iptable_mangle iptable_filter xt_multiport xt_limit xt_dscp ipt_REJECT ip_tables x_tables sd_mod crc_t10dif bridge stp radeon ttm tpm_tis tpm drm_kms_helper snd_pcm snd_timer ipmi_si snd drm ipmi_msghandler i2c_algo_bit i2c_core soundcore hpwdt snd_page_alloc tpm_bios psmouse serio_raw hpilo container evdev pcspkr button power_meter processor ext4 mbcache jbd2 crc16 dm_mod sg sr_mod cdrom ata_generic usbhid hid usb_storage uhci_hcd ata_piix thermal libata cciss ehci_hcd usbcore thermal_sys nls_base bnx2 scsi_mod [last unloaded: scsi_wait_scan] [ 1241.171801] Pid: 1855, comm: vzctl Not tainted 2.6.32-5-openvz-amd64 #1 belyayev ProLiant DL360 G6 [ 1241.171851] RIP: 0010:[] [(null)] (null) [ 1241.171883] RSP: 0018:880319af7d20 EFLAGS: 00010246 [ 1241.171911] RAX: a0367880 RBX: 88031dcf7cb0 RCX: 000c [ 1241.171943] RDX: 88031a5f3c00 RSI: 3000 RDI: 88031dcf7cb0 [ 1241.171975] RBP: 0001 R08: 0003 R09: 8803190a7cb0 [ 1241.172007] R10: 88031dcf7cb0 R11: R12: [ 1241.172039] R13: 88031dcf7c00 R14: 88031dcf7fa8 R15: 0003 [ 1241.172072] FS: 7f84baf69700() GS:88000da0() knlGS: [ 1241.172120] CS: 0010 DS: ES: CR0: 80050033 [ 1241.172148] CR2: CR3: 00031a679000 CR4: 06f0 [ 1241.172181] DR0: DR1: DR2: [ 1241.172213] DR3: DR6: 0ff0 DR7: 0400 [ 1241.172246] Process vzctl (pid: 1855, veid=0, threadinfo 880319af6000, task 88031bb8a000) [ 1241.172294] Stack: [ 1241.172315] a0199066 ea000c532f40 88031a5f0c00 [ 1241.172354] 0 ea000c532f40 88031dcf7dd0 [ 1241.172412] 0 880319af7dd8 810bf35b [ 1241.172503] Call Trace: [ 1241.172548] [a0199066] ? ext4_da_invalidatepage+0x150/0x16c [ext4] [ 1241.172584] [810bf35b] ? truncate_inode_page+0x45/0x84 [ 1241.172615] [810bf444] ? truncate_inode_pages_range+0xaa/0x2a2 [ 1241.172652] [a016ecb3] ? jbd2_journal_stop+0x20b/0x21e [jbd2] [ 1241.172686] [a0362113] ? vzquota_inode_data+0x3b/0xa3 [vzdquota] [ 1241.172725] [a019cfb2] ? ext4_delete_inode+0x0/0x246 [ext4] [ 1241.172758] [a0362375] ? vzquota_inode_init_call+0x3a/0x6d [vzdquota] [ 1241.172812] [a019d00f] ? ext4_delete_inode+0x5d/0x246 [ext4] [ 1241.172851] [a019cfb2] ? ext4_delete_inode+0x0/0x246 [ext4] [ 1241.172889] [a019cfb2] ? ext4_delete_inode+0x0/0x246 [ext4] [ 1241.172921] [81104408] ? generic_delete_inode+0xd4/0x160 [ 1241.172953] [810fc9e6] ? do_unlinkat+0xe2/0x134 [ 1241.172985] [810327a4] ? do_page_fault+0x266/0x282 [ 1241.173016] [81011a1b] ? device_not_available+0x1b/0x20 [ 1241.173047] [81010c12] ? system_call_fastpath+0x16/0x1b [ 1241.173077] Code: Bad RIP value. [ 1241.173108] RIP [(null)] (null) [ 1241.173134] RSP 880319af7d20 [ 1241.173158] CR2: [ 1241.173554] ---[ end trace e5ba4ab053972af6 ]--- [ 1241.175522] BUG: unable to handle kernel NULL pointer dereference at (null) [ 1241.175658] IP: [(null)] (null) [ 1241.175751] PGD 31a0aa067 PUD 319912067 PMD 0 [ 1241.175915] Oops: 0010 [#2] SMP [ 1241.176041] last sysfs file: /sys/devices/virtual/vc/vcsa6/uevent [ 1241.176103] CPU 4 [ 1241.176191] Modules linked in: vzethdev vznetdev simfs vzrst vzcpt vzdquota vzmon vzdev ip6t_REJECT ip6table_mangle ip6table_filter ip6_tables xt_tcpudp xt_length xt_hl xt_tcpmss xt_TCPMSS iptable_mangle iptable_filter xt_multiport xt_limit xt_dscp ipt_REJECT ip_tables x_tables sd_mod crc_t10dif bridge stp radeon ttm tpm_tis tpm drm_kms_helper snd_pcm snd_timer ipmi_si snd drm ipmi_msghandler i2c_algo_bit i2c_core soundcore hpwdt snd_page_alloc tpm_bios psmouse serio_raw hpilo container evdev pcspkr button power_meter processor ext4 mbcache jbd2 crc16 dm_mod sg sr_mod cdrom
Bug#545517: Intel/KMS/suspend-to-disk bug still present on 2.6.34
Hi Vincent,
On Mon, Jun 14, 2010 at 22:15:17 +0200, Vincent Danjean wrote:
Since the introduction of KMS, suspend-to-disk never works reliably
on my laptop. Todays, it is so unstable that I do not try it. The
biggest problem is that, when it does not work, the session is restored
but (I think) memory corruption occurs. So the symptom can differ from
time to time.
My classical symptom is applications crashing or refusing to be
load (with a segv in libc when trying to run ls for example).
In these cases, I immediately hard-switch-off the laptop so that
in-memory corruption was not writen-back on disk (I had several
difficult fsck before I do that).
I'm not sure that this is related to KMS but it begins to occurs when
KMS has been introduced and (in the first time, I do not recheck recently),
I have no problems when I disabled KMS.
#534422 can be linked to this bug.
This bug is also reported to xorg:
https://bugs.freedesktop.org/show_bug.cgi?id=23836
This may be fixed by commit 985b823b919273fe1327d56d2196b4f92e5d0fae
(included below).
Can you test it?
commit 985b823b919273fe1327d56d2196b4f92e5d0fae
Author: Linus Torvalds torva...@linux-foundation.org
Date: Fri Jul 2 10:04:42 2010 +1000
drm/i915: fix hibernation since i915 self-reclaim fixes
Since commit 4bdadb9785696439c6e2b3efe34aa76df1149c83 (drm/i915:
Selectively enable self-reclaim), we've been passing GFP_MOVABLE to the
i915 page allocator where we weren't before due to some over-eager
removal of the page mapping gfp_flags games the code used to play.
This caused hibernate on Intel hardware to result in a lot of memory
corruptions on resume. See for example
http://bugzilla.kernel.org/show_bug.cgi?id=13811
Reported-by: Evengi Golov (in bugzilla)
Signed-off-by: Dave Airlie airl...@redhat.com
Tested-by: M. Vefa Bicakci bic...@superonline.com
Cc: sta...@kernel.org
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Cc: Hugh Dickins hugh.dick...@tiscali.co.uk
Signed-off-by: Linus Torvalds torva...@linux-foundation.org
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9ded3da..0743858 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2239,7 +2239,7 @@ i915_gem_object_get_pages(struct drm_gem_object *obj,
mapping = inode-i_mapping;
for (i = 0; i page_count; i++) {
page = read_cache_page_gfp(mapping, i,
- mapping_gfp_mask (mapping) |
+ GFP_HIGHUSER |
__GFP_COLD |
gfpmask);
if (IS_ERR(page))
Cheers,
Julien
signature.asc
Description: Digital signature
Bug#586133: Same here with 2.6.32
I have found the same problem. The system waits for a keyboard input activity to boot further. Also I have found that it happens during shutdown also. Also this happens more when you disable Periodic SMI option in the BIOS. Kushal Koolwal I do blog at http://blogs.koolwal.net/ _ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2
Bug#587887: linux-base: please suppress useless debconf messages on first install
On Fri, 2010-07-02 at 11:12 +0200, Holger Levsen wrote: [...] h01ger bwh, i wonder if your test fails as there were already .26 packages installed... h01ger ha! if /var/log/installer doesnt exist, its a fresh install. bingo see attached patch We can't use this test. Older installations don't have such a directory. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Processed: tagging 587887
Processing commands for cont...@bugs.debian.org: tags 587887 - patch Bug #587887 [linux-base] linux-base: please suppress useless debconf messages on first install Removed tag(s) patch. thanks Stopping processing here. Please contact me if you need assistance. -- 587887: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587887 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.127810108412295.transcr...@bugs.debian.org
Bug#545517: Intel/KMS/suspend-to-disk bug still present on 2.6.34
Hi, On 02/07/2010 16:16, Julien Cristau wrote: On Mon, Jun 14, 2010 at 22:15:17 +0200, Vincent Danjean wrote: Since the introduction of KMS, suspend-to-disk never works reliably on my laptop. [...] This may be fixed by commit 985b823b919273fe1327d56d2196b4f92e5d0fae (included below). Hourra ! Can you test it? Not for now (I'm traveling without possibly restoring my system from backups) but the described symptoms and the explanations seem to fit with my experiments. Since two days, I was trying again suspend-to-disk with the new (from experimental) intel video driver. I succeeded in two or three rounds of suspend-to-disk but - I was finding strange that a user driver can corrupt kernel memory so badly - I sometimes succeed in doing several rounds of suspend-to-disk before triggering the bug (and corrupting my disks :-( ) If this fix is confirmed, I think the patch should be backported/applied in the Debian kernel Regards, Vincent -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c2e4dcf.8050...@debian.org
Re: Proposed changes to initramfs-tools hook scripts
On Fri, 02 Jul 2010 02:20:45 -0400 (EDT), maximilian attems wrote: On Wed, 30 Jun 2010, Stephen Powell wrote: Max, As promised, here are my proposed changes to the initramfs-tools hook scripts. ... thank you very much. applied your 3 changes to branch maks/hooks on http://git.debian.org/?p=kernel/initramfs-tools.git;a=summary please review before I'd merge into master for next upload. I'll take a look at those tonight, the Lord willing. I'm not sure if the indirection to STDERR is needed for make deb-pkg, but it shouldn't hurt there? It all depends on whether debconf is active or not. If it is, then it's necessary. If it's not, it won't hurt anything. you may want to have a look at for initramfs-tools dev http://git.debian.org/?p=kernel/initramfs-tools.git;a=blob_plain;f=docs/maintainer-notes.html;h=eeceafdfc498bd6585328d1eeb52e6e454d524ee;hb=HEAD changes in git send-email or online git repo are easier to handle. I'll take a look at that too. There are so many new things to learn all at once! -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874427008.133057.1278106852146.javamail.r...@md01.wow.synacor.com
Processed: tagging 584130
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 584130 + pending Bug #584130 [linux-2.6] linux-image-2.6.32-5-amd64: please enable CONFIG_KPROBES Added tag(s) pending. End of message, stopping processing here. Please contact me if you need assistance. -- 584130: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584130 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.12781070187501.transcr...@bugs.debian.org
Processed: severity of 586133 is important
Processing commands for cont...@bugs.debian.org: severity 586133 important Bug #586133 [linux-2.6] linux-image-2.6.32-5-amd64: Boot process pauses indefinitely waiting for keyboard activity Severity set to 'important' from 'critical' thanks Stopping processing here. Please contact me if you need assistance. -- 586133: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586133 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.127810894619667.transcr...@bugs.debian.org
Bug#587418: linux-image-2.6.32-5-686: using old IDE driver fails, probably due to missing ide_pci_generic module
On Fri, 2010-07-02 at 03:28 +0100, Russell Marks wrote: Ben Hutchings b...@decadent.org.uk wrote: On Tue, 2010-06-29 at 03:35 +0100, Russell Marks wrote: hdparm still works with libata-based drivers, so you should not need to build a custom kernel. As you might imagine, hdparm was the first thing I tried. It seems not all of hdparm's features work with libata-based drivers, in particular I can't disable/enable DMA with it: r...@cartman:2005:/home/russudo hdparm -d 0 /dev/sda /dev/sda: setting using_dma to 0 (off) HDIO_SET_DMA failed: Inappropriate ioctl for device HDIO_GET_DMA failed: Inappropriate ioctl for device r...@cartman:2006:/home/russudo hdparm -d 0 /dev/hda /dev/hda: No such file or directory r...@cartman:2007:/home/rus Sorry, I thought most hdparm features would still work. You can still disable DMA by setting a module option for libata. Put Or by using a kernel command-line option (e.g. libata.dma=0 which I'm using for now). But with hdparm I could turn it on and off at run-time, which is useful on one particular machine I use, and which I don't believe is possible now. I think if changes to the kernel package are partly breaking another package, which I've demonstrated is happening here, that seems like it should count as a bug in Debian. Maybe hdparm or even sdparm is more to blame, I don't know, but I think this has to be a regression somewhere doesn't it? OK, sure, it's a regression. It is unlikely to be fixed, though, as there is very little reason to control this at run-time. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Processed: tagging 569012
Processing commands for cont...@bugs.debian.org: tags 569012 - fixed-upstream Bug #569012 [linux-2.6] linux-image-2.6.32-1-amd64: Freezes and memory corruption Removed tag(s) fixed-upstream. thanks Stopping processing here. Please contact me if you need assistance. -- 569012: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=569012 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.127810983024135.transcr...@bugs.debian.org
Bug#587789: marked as done (linux-image-2.6-686: netfilters clamp-mss-to-pmtu sets bad MSS when non was set before)
Your message dated Fri, 02 Jul 2010 23:28:52 +0100 with message-id 1278109732.4878.70.ca...@localhost and subject line Re: Bug#587789: linux-image-2.6-686: netfilters clamp-mss-to-pmtu sets bad MSS when non was set before has caused the Debian Bug report #587789, regarding linux-image-2.6-686: netfilters clamp-mss-to-pmtu sets bad MSS when non was set before to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 587789: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587789 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: linux-image-2.6-686 Version: 2.6.26+17+lenny1 Severity: important Hi, Netfilters clamp-mss-to-pmtu (as used in iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu) sets MSS in packets that had no MSS set before. So instead of sending packets of standard TCP MSS 536 Bytes to a host that didn't set a MSS at all, packets with a potentially higher MSS (like 1452 on my DSL connection) will be sent to that host. That might fail if the host only accepts packets with a MSS of 536 (like http://research.microsoft.com). If that host also doesn't send a ICMP fragmentation needed packet (like research.microsoft.com ...) the connection will fail. Clamp-mss-to-pmtu really shouldn't set a MSS if none was set before. RFC 879 says HOSTS MUST NOT SEND DATAGRAMS LARGER THAN 576 OCTETS UNLESS THEY HAVE SPECIFIC KNOWLEDGE THAT THE DESTINATION HOST IS PREPARED TO ACCEPT LARGER DATAGRAMS. This means that the standard MTU is 576 and the standard MSS 536 and any server not setting a MSS can expect to only receive packages with a MSS of 536 bytes. If the clamping sets a MSS 536 connections might fail. I stumbled upon this problem in debian bug #541658[1] ([iceweasel] cannot open research.microsoft.com - only worth reading for entertainment purposes) and, after that bug was closed, analysed it in my blog[2] until a friend of mine found out why the page loads when clamping mss to pmtu is disabled or restricted to a range (like with iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:1536 -j TCPMSS --clamp-mss-to-pmtu) but doesn't load with simple clamping. His really great and detailed analysation of the problem may be seen at [3]. He also looked into the kernel code (net/netfilter/xt_TCPMSS.c) and found the kind of contradicting comments Never increase MSS, even when setting it, as doing so results in problems for hosts that rely on MSS being set correctly. (line 93) and MSS Option not found ?! add it.. (line 116). So instead of just leaving a packet without MSS option untouched a new MSS, that might be much greater than the default 536, is set, even though the guy who wrote that seemed to be aware that MSS may not be increased. This bug most probably affects all kernel version from at least 2.6.26 (probably also much older versions) up to now. It seems like also some hardware-routers that probably use Linux are affected. Cheers, - Daniel -- System Information: Debian Release: 5.0.5 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6-686 depends on: ii linux-image-2.6.26-2-686 2.6.26-24 Linux 2.6.26 image on PPro/Celeron linux-image-2.6-686 recommends no packages. linux-image-2.6-686 suggests no packages. -- no debconf information ---End Message--- ---BeginMessage--- On Thu, 2010-07-01 at 18:43 +0200, Daniel Gibson wrote: Package: linux-image-2.6-686 Version: 2.6.26+17+lenny1 Severity: important Hi, Netfilters clamp-mss-to-pmtu (as used in iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu) sets MSS in packets that had no MSS set before. The documentation says that TCPMSS sets the MSS option, unconditionally, so this behaviour is correct. [...] He also looked into the kernel code (net/netfilter/xt_TCPMSS.c) and found the kind of contradicting comments Never increase MSS, even when setting it, as doing so results in problems for hosts that rely on MSS being set correctly. (line 93) and MSS Option not found ?! add it.. (line 116). So instead of just leaving a packet without MSS option untouched a new MSS, that might be much greater than the default 536, is set, even though the guy who wrote that seemed to be aware that MSS may not be increased. This bug most probably affects all kernel version from at least
Bug#569012: marked as done (linux-image-2.6.32-1-amd64: Freezes and memory corruption)
Your message dated Fri, 02 Jul 2010 23:31:13 +0100
with message-id 1278109873.4878.71.ca...@localhost
and subject line Re: linux-image-2.6.32-1-amd64: Freezes and memory corruption
has caused the Debian Bug report #569012,
regarding linux-image-2.6.32-1-amd64: Freezes and memory corruption
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
569012: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=569012
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: linux-2.6
Version: 2.6.32-6
Severity: critical
After running 2.6.32 (as well as 2.6.31 and 2.6.30) for several minutes,
computer freezes completely. Network or alt-sysrq-b do not work.
Further investigation showed that data is being corrupted while reading
or writing files.
Corruption on reading is easily reproduced with debsums (it fails on
random files), corruption on writing happened at least once (under
2.6.32-trunk-amd64) and looks like:
@@ -952522,14 +952522,14 @@
00e88cb0 6d c5 a3 fa 5a 65 87 7c 83 a4 ee ce a9 2e b9 5f |m...Ze.|..._|
00e88cc0 e1 bf 23 e7 1d 2e b6 2f e7 11 ff df e4 3c fa f7 |..#/...|
00e88cd0 f6 e5 3c fc bf 37 e7 41 77 12 1d 37 79 0c 17 4d |7.Aw..7y..M|
-00e88ce0 ee db 1a 93 5d e7 92 5d 7f 35 39 cf 5d 8b 8c f7 |]..].59.]...|
-00e88cf0 39 6c 55 14 9e ba 55 ab fc a5 84 06 95 b1 e4 5b |9lU...U[|
-00e88d00 6e 05 5e db f7 dc 15 1b 83 4b e5 7b bc 36 74 c5 |n.^..K.{.6t.|
-00e88d10 05 12 1e 4c c9 34 39 4b a6 64 fa 53 83 67 4a 2b |...L.49K.d.S.gJ+|
-00e88d20 c9 e5 99 6d a6 8c 7a 1c 9b a3 57 8a ab e5 cc d6 |...m..z...W.|
-00e88d30 b2 49 1d 9d de 48 54 20 65 93 d4 c8 4a 9d 23 25 |.I...HT e...J.#%|
-00e88d40 c2 94 44 97 e0 92 68 5f 01 04 85 9c 63 aa dd 17 |..D...h_c...|
-00e88d50 72 ee 03 54 bb e3 45 d7 60 e6 37 92 0d cc b4 af |r..T..E.`.7.|
+00e88ce0 ee db 1a 93 5d e7 b0 48 7f 15 76 35 18 80 e3 b6 |]..H..v5|
+00e88cf0 78 7e a3 c3 9e 03 54 fb 77 85 14 09 15 7d 31 be |x~T.w}1.|
+00e88d00 9b 0d 40 8e 3c a7 7b e4 0d 2e 17 d0 a3 18 4f 87
|@..{...O.|
+00e88d10 56 d8 75 24 54 94 65 39 77 58 e3 5c 01 34 8b a6 |V.u$T.e9wX.\.4..|
+00e88d20 e4 f9 e4 2a 26 21 ef b0 9a 90 b3 b0 f8 f3 42 76 |...*!Bv|
+00e88d30 ff ae 1b 80 15 63 49 b4 e9 b5 96 c3 0f df 18 25 |.cI%|
+00e88d40 1f 65 b0 b4 3e 8c 9e 3c 33 75 e2 78 19 c3 2a 05 |.e3u.x..*.|
+00e88d50 ae 4d 36 e8 c2 38 cc 97 cf 49 6f 5a 3c 6f 09 90 |.M6..8...IoZo..|
00e88d60 45 75 9e e2 2e c5 29 91 d7 3a d1 79 ae e3 92 09 |Eu)..:.y|
00e88d70 56 d7 a4 18 92 b1 d7 42 68 50 04 1c 86 8c 04 96 |V..BhP..|
00e88d80 13 56 e9 d7 b2 2a 6d 43 a0 b9 ff da dc e0 e0 ed |.V...*mC|
The system has radeon video card, but DRI is disabled and radeon kernel
module is not loaded. I tried to disable ethernet, firewire, jmicron,
sound, C1E Support, but this did not help, though after blacklisting
asus_atk0110 it took longer time to get random errors from debsums.
Debsums failures, random segfaults and total freezing can also be
reproduced under single-user mode. There are no messages on console when
system freezes.
Under 2.6.26 there is no sign of these problems, computer only suffers
from #518643.
-- Package-specific info:
** Version:
Linux version 2.6.32-1-amd64 (Debian 2.6.32-6) (b...@decadent.org.uk) (gcc
version 4.3.4 (Debian 4.3.4-6) ) #1 SMP Mon Feb 1 19:11:44 UTC 2010
** Command line:
BOOT_IMAGE=/vmlinuz-2.6.32-1-amd64 root=/dev/mapper/main-root ro
** Not tainted
** Kernel log:
[4.013522] md: linear personality registered for level -1
[4.017728] md: multipath personality registered for level -4
[4.021853] md: raid0 personality registered for level 0
[4.026819] md: raid1 personality registered for level 1
[4.030585] async_tx: api initialized (async)
[4.031173] xor: automatically using best checksumming function: generic_sse
[4.049501]generic_sse: 10182.000 MB/sec
[4.049529] xor: using function: generic_sse (10182.000 MB/sec)
[4.117508] raid6: int64x1 2378 MB/s
[4.185506] raid6: int64x2 2967 MB/s
[4.253524] raid6: int64x4 2296 MB/s
[4.321516] raid6: int64x8 1838 MB/s
[4.389500] raid6: sse2x14679 MB/s
[4.457501] raid6: sse2x25288 MB/s
[4.525503] raid6: sse2x47914 MB/s
[4.525531] raid6: using algorithm sse2x4 (7914 MB/s)
[4.529401] md: raid6 personality registered for level 6
[4.529430] md: raid5 personality registered for level 5
[4.529459] md: raid4 personality registered for level 4
[4.550751] md: raid10
Bug#587789: closed by Ben Hutchings b...@decadent.org.uk (Re: Bug#587789: linux-image-2.6-686: netfilters clamp-mss-to-pmtu sets bad MSS when non was set before)
You need to have this argument with the upstream developers, not with me. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#587789: closed by Ben Hutchings b...@decadent.org.uk (Re: Bug#587789: linux-image-2.6-686: netfilters clamp-mss-to-pmtu sets bad MSS when non was set before)
Debian Bug Tracking System schrieb: This is an automatic notification regarding your Bug report which was filed against the linux-image-2.6-686 package: #587789: linux-image-2.6-686: netfilters clamp-mss-to-pmtu sets bad MSS when non was set before It has been closed by Ben Hutchings b...@decadent.org.uk. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Ben Hutchings b...@decadent.org.uk by replying to this email. Betreff: Re: Bug#587789: linux-image-2.6-686: netfilters clamp-mss-to-pmtu sets bad MSS when non was set before Von: Ben Hutchings b...@decadent.org.uk Datum: Fri, 02 Jul 2010 23:28:52 +0100 An: 587789-d...@bugs.debian.org An: 587789-d...@bugs.debian.org On Thu, 2010-07-01 at 18:43 +0200, Daniel Gibson wrote: Package: linux-image-2.6-686 Version: 2.6.26+17+lenny1 Severity: important Hi, Netfilters clamp-mss-to-pmtu (as used in iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu) sets MSS in packets that had no MSS set before. The documentation says that TCPMSS sets the MSS option, unconditionally, so this behaviour is correct.Never increase MSS, even when setting it, as doing so The code explicitly says Never increase MSS, even when setting it, as doing so results in problems for hosts that rely on MSS being set correctly. So the MSS option is *not* set unconditionally by --clamp-mss-pmtu. The documentation doesn't explicitly say that, though. To set the MSS to a fixed value --set-mss should be used, I guess. (Explicitly set MSS option to specified value) No MSS set (at a TCP packet) implies the default MSS of 536 as specified by RFC 879. So TCPMSS should in that case either set a MSS of 536 (e.g. before the oldmss newmss check, so if PMTU returned a even lower MSS it is set to that lower value) or at least leave the MSS untouched. The documentation says This target is used to overcome criminally braindead ISPs or servers which block ICMP Fragmentation Needed or ICMPv6 Packet Too Big packets. So, if a host (implicitly, in conformance to the RFC) expects packets of default size (MSS 536) and the braindead ISP (or server-/ firewall-admin), blocks the (according to the RFC optional) ICMP Fragmentation Needed packets, the PMTU will not return the correct MTU (of 536) but the MTU of your DSL connection or whatever. TCPMSS is meant to fix exactly this case (blocked ICPM packets), but the author apparently only thought of the case that the server sets a MSS that's to big for the client, so the client must fix that by setting a lower MSS - but not the case that a server expects a smaller MSS (that happens to be the standard MSS) without explicitly saying so. Regards, - Daniel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c2e70c1.70...@gmail.com
Bug#587763: linux-image-2.6.32-5-amd64: scary messages from JBD when manipulating quotas on ext4
On Thu, 2010-07-01 at 15:29 +0200, Laurent Bonnaud wrote: Package: linux-2.6 Version: 2.6.32-15 Severity: important Hi, here is how to reproduce this bug: 1. set up quotas on an ext4 filesystem 2. use edquota to change the quotas of some user Actual result: the kernel outputs this scary message: [ 399.792052] JBD: Spotted dirty metadata buffer (dev = sdb1, blocknr = 34816). There's a risk of filesystem corruption in case of system crash. Expected result: - no scary message - no filesystem corruption - changed quotas A patch has been proposed here: http://www.spinics.net/lists/linux-ext4/msg19302.html This bug has also been reported here: https://bugzilla.redhat.com/show_bug.cgi?id=578674 [...] That proposed patch seems to have been contentious and has not been applied upstream. I think you will need to revive the discussion with the upstream developers. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#587789: linux-image-2.6-686: netfilters clamp-mss-to-pmtu sets bad MSS when non was set before
Ben Hutchings schrieb: You need to have this argument with the upstream developers, not with me. Ben. Ok. The bug is reported at http://bugzilla.netfilter.org/show_bug.cgi?id=662 - Daniel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c2e7a5c.3020...@gmail.com
Bug#586554: update-initramfs fails to generate initrd.img-2.6.32-5-686 in Debian testing when upgrading from 0.96 to 0.97
Hi Alesh,
Alesh Slovak wrote (Thursday 01 July 2010):
If the very last file that iscan's hook script checks for in DESTDIR
doesn't exist, the `test -e` call fails and the script ends with a failed
status even though nothing really went wrong. A simple `exit 0` on the
last line fixes this.
It's actually not that simple. Running the iscan hook script with set -e
means that the script will abort with an error status as soon as the test -e
fails for any file in the clean-files list. Adding exit 0 at the end of the
script won't fix that, because the script will never reach that point anyway.
Additionally, this means that the script does not remove all the existing files
listed in clean-files that come after the first file that doesn't exist.
Probably the easiest solution is to just turn that troublesome test -e line
into an if ... fi clause, e.g.:
if test -e ${DESTDIR}$file; then rm -f ${DESTDIR}$file; fi
or something similar.
You might have realised this already, but I felt that it's better to be safe
than sorry. :-)
Peace,
Brendon
signature.asc
Description: This is a digitally signed message part.
