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

2010-07-05 Thread Brendon Higgins
Alesh Slovak wrote (Mon, 5 Jul 2010):
 On 07/05/2010 09:22 AM, Brendon Higgins wrote:
  The test -e command is protected by an , so a failure will not
  trigger an early exit and all files will be correctly removed.
  
  I guess you're right. But I tried the script with exit 0 added at the
  last line and it failed anyway. I added echo blah statements to find
  where it was aborting, and it seemed to be at that test statement. When
  I changed it to an if ... fi clause, the problem ceased.
 
 That's odd, our testing went just fine.

Something really odd seems to be going on. It works without errors when I try 
this:
awk '{print $2}' $STATE_DIR/clean-files \
| while read file; do
echo ha
test -e ${DESTDIR}$file  rm -f ${DESTDIR}$file
echo ho
done

However, if I comment out the echo ho line, it fails. It's like the result 
of the test on that last line is erroneously propagating as the result of the 
loop, or something.

 Can you tell me what shell you are using?

/bin/sh links to dash. I just updated to the latest in unstable - problem 
remains. Users see bash.

I also noticed that both files listed in clean-files actually exist, both 
before 
and after I run update-initramfs. But the rm shouldn't return an error, and 
even if it does, adding an echo command after it shouldn't fix it. At least, I 
don't see why.

Really weird. :-S

Peace,
Brendon



-- 
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/201007052019.36084.blhigg...@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

2010-07-05 Thread Alesh Slovak

On 07/05/2010 07:19 PM, Brendon Higgins wrote:

Something really odd seems to be going on. It works without errors when I try
this:
awk '{print $2}' $STATE_DIR/clean-files \
 | while read file; do
 echo ha
 test -e ${DESTDIR}$file  rm -f ${DESTDIR}$file
 echo ho
done

However, if I comment out the echo ho line, it fails. It's like the result
of the test on that last line is erroneously propagating as the result of the
loop, or something.
You're right, but it is not erroneous. According to the bash manual page it is 
correct behaviour.


The documentation for while states that the exit status of the while and 
until commands is the exit status of the last do list command executed, or zero 
if none was executed.


With regards to the  operator, the manual states that the return status of 
AND and OR lists is the exit status of the last command executed in the list.


This together means that the while loop was inheriting the failed status of 
the test command and causing the script to exit with a failed status.


The documentation for if states that the exit status is the exit status of 
the last command executed, or zero if no condition tested true.


That explains why using an if statement makes the script work as expected.

I couldn't find anything in the dash manual page about all this but it seems to 
be working in the same way.


This behaviour appears to be a relatively recent change.


I also noticed that both files listed in clean-files actually exist, both before
and after I run update-initramfs. But the rm shouldn't return an error, and
even if it does, adding an echo command after it shouldn't fix it. At least, I
don't see why.
The files in clean-files exist on your file system, but the script checks for 
and erases these files from the initrd file system (i.e. DESTDIR), and not from 
your regular file system.


So I think we've finally cleared this up. Thanks for all your help Brendon. It's 
really appreciated.


We'll be releasing an updated iscan-data package as soon as we can. I'll reply 
here with the details when we do.


Happy scanning,
--
Alesh SlovakLinux Team -- AVASYS Corporation
alesh.slo...@avasys.jp  http://avasys.jp



--
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/4c328da0.9010...@avasys.jp



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

2010-07-04 Thread Alesh Slovak

On 07/03/2010 10:24 AM, Brendon Higgins wrote:

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.


I had thought the same at first, but according to the bash man page, the `-e` 
option exits immediately if any *untested* command fails. A similar statement 
exists in the dash man page as well.


The test -e command is protected by an , so a failure will not trigger an 
early exit and all files will be correctly removed.



Happy scanning,
--
Alesh SlovakLinux Team -- AVASYS Corporation
alesh.slo...@avasys.jp  http://avasys.jp



--
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/4c3116ab.3000...@avasys.jp



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

2010-07-04 Thread Brendon Higgins
Alesh Slovak wrote (2010-07-05 09:18):
 On 07/03/2010 10:24 AM, Brendon Higgins wrote:
  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.
 
 I had thought the same at first, but according to the bash man page, the
 `-e` option exits immediately if any *untested* command fails. A similar
 statement exists in the dash man page as well.
 
 The test -e command is protected by an , so a failure will not
 trigger an early exit and all files will be correctly removed.

I guess you're right. But I tried the script with exit 0 added at the last 
line and it failed anyway. I added echo blah statements to find where it was 
aborting, and it seemed to be at that test statement. When I changed it to an 
if ... fi clause, the problem ceased.

So I don't know why it was doing that.

Peace,
Brendon



-- 
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/201007051022.56651.blhigg...@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

2010-07-04 Thread Alesh Slovak

On 07/05/2010 09:22 AM, Brendon Higgins wrote:

The test -e command is protected by an , so a failure will not
trigger an early exit and all files will be correctly removed.


I guess you're right. But I tried the script with exit 0 added at the last
line and it failed anyway. I added echo blah statements to find where it was
aborting, and it seemed to be at that test statement. When I changed it to an
if ... fi clause, the problem ceased.

That's odd, our testing went just fine.

Can you tell me what shell you are using?

Happy scanning,
--
Alesh SlovakLinux Team -- AVASYS Corporation
alesh.slo...@avasys.jp  http://avasys.jp



--
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/4c312ea8.6090...@avasys.jp



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

2010-07-02 Thread Brendon Higgins
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.


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

2010-07-01 Thread Michael Prokop
* Alesh Slovak alesh.slo...@avasys.jp [Thu Jul 01, 2010 at 11:46:03AM +0900]:
 On 06/30/2010 07:25 PM, Michael Prokop wrote:
 We are working on new initramfs-tools version which should display
 the source of the problem then, I'll be investigating on the iscan
 issue in more detail as well and report back.

 Thanks to all for your help tracking this down. I've found the problem.
 It was indeed related to the fact that the new version of initramfs-tools 
 runs the hook scripts under errexit.

 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.

 I'll try to get a fixed version of iscan-data out as soon as I can.

Great, thanks for reporting back.

I'll make sure users know which script fails so we can track and
debug such issues easier.

regards,
-mika-


signature.asc
Description: Digital signature


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

2010-06-30 Thread Andreas Neudecker
Package: initramfs-tools
Version: 0.97
Severity: normal

Hi.

Same problem occured here during upgrade from 0.96 to 0.97.
Now, I am not even sure the machine will boot properly next time as apparently
rebuilding the initramfs failed.

r...@halucigenia:~# sh -x /var/lib/dpkg/info/initramfs-tools.postinst
+ set -e
+ [ ! -e /etc/initramfs-tools/modules ]
+ [ x != xtriggered ]
+ dpkg --compare-versions  ge 1.14.5ubuntu10~~
+ DPKG_MAINTSCRIPT_PACKAGE= update-initramfs -u
update-initramfs: Generating /boot/initrd.img-2.6.32-5-686
update-initramfs: failed for /boot/initrd.img-2.6.32-5-686

Eventually I found the notice in a previous post of this thread saying iscan
was the culprit.
I purged iscan, but the problem remained.
I purged iscan-data, too. Now, finally, it was possible to upgrade initramfs-
tools successfully.

I have emailed Epson support to inform them of the interference of their
drivers with the Debian system.

Regards

Andreas



-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 8.0M Jun 25 18:23 /boot/initrd.img-2.6.32-5-686
-- /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686 
root=UUID=69fd34e6-38c8-4a8b-86b8-581daf85ec5d ro quiet

-- resume
RESUME=UUID=e9012356-b8c2-473e-9547-fa87854b56b2
-- /proc/filesystems
ext3
fuseblk

-- lsmod
Module  Size  Used by
vboxnetadp  5118  0 
vboxnetflt 12579  0 
vboxdrv   126509  2 vboxnetadp,vboxnetflt
acpi_cpufreq4943  0 
cpufreq_userspace   1480  0 
cpufreq_stats   1940  0 
cpufreq_conservative 4018  0 
cpufreq_powersave602  0 
ppdev   4058  0 
lp  5570  0 
parport22554  2 ppdev,lp
sco 5857  2 
bridge 32987  0 
stp  996  1 bridge
bnep7444  2 
rfcomm 25167  0 
l2cap  21705  6 bnep,rfcomm
crc16   1027  1 l2cap
bluetooth  36327  6 sco,bnep,rfcomm,l2cap
binfmt_misc 4907  1 
uinput  4796  1 
fuse   43758  1 
loop9757  0 
snd_hda_codec_intelhdmi 9027  1 
snd_hda_codec_via  19285  1 
snd_hda_intel  16703  4 
snd_hda_codec  46002  3 
snd_hda_codec_intelhdmi,snd_hda_codec_via,snd_hda_intel
snd_hwdep   4054  1 snd_hda_codec
snd_pcm_oss28671  0 
snd_mixer_oss  10461  2 snd_pcm_oss
snd_pcm47214  3 snd_hda_intel,snd_hda_codec,snd_pcm_oss
snd_seq_midi3576  0 
snd_rawmidi12505  1 snd_seq_midi
arc4 974  2 
snd_seq_midi_event  3684  1 snd_seq_midi
ecb 1405  2 
snd_seq35463  3 snd_seq_midi,snd_seq_midi_event
ath9k 238333  0 
mac80211  123258  1 ath9k
ath 6014  1 ath9k
snd_timer  12258  2 snd_pcm,snd_seq
snd_seq_device  3673  3 snd_seq_midi,snd_rawmidi,snd_seq
uvcvideo   45226  0 
cfg80211   87601  3 ath9k,mac80211,ath
i915  219952  2 
drm_kms_helper 18305  1 i915
snd34363  18 
snd_hda_codec_intelhdmi,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_rawmidi,snd_seq,snd_timer,snd_seq_device
soundcore   3450  2 snd
rfkill 10264  3 bluetooth,cfg80211
videodev   25545  1 uvcvideo
drm   112020  3 i915,drm_kms_helper
v4l1_compat10250  2 uvcvideo,videodev
snd_page_alloc  5045  2 snd_hda_intel,snd_pcm
i2c_algo_bit3497  1 i915
pcspkr  1207  0 
asus_laptop11090  0 
serio_raw   2916  0 
led_class   1757  2 ath9k,asus_laptop
i2c_core   12696  5 i915,drm_kms_helper,videodev,drm,i2c_algo_bit
tpm_tis 5496  0 
video  14605  1 i915
psmouse44653  0 
ac  1640  0 
battery 3782  0 
processor  26599  3 acpi_cpufreq
button  3598  1 i915
tpm 8137  1 tpm_tis
tpm_bios3569  1 tpm
output  1204  1 video
evdev   5609  24 
ext3   94204  2 
jbd32169  1 ext3
mbcache 3762  1 ext3
sg 15968  0 
sr_mod 10770  0 
cdrom  26487  1 sr_mod
sd_mod 25869  4 
crc_t10dif  1012  1 sd_mod
usbhid 27980  0 
hid50629  1 usbhid
uhci_hcd   16057  0 
ahci   27246  3 
thermal 9206  0 
libata115665  1 ahci
ehci_hcd   27763  0 
scsi_mod  101401  4 sg,sr_mod,sd_mod,libata
thermal_sys 9378  3 video,processor,thermal
atl1e  23144  0 
usbcore   

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

2010-06-30 Thread Michael Prokop
* Andreas Neudecker zap...@gmx.net [Wed Jun 30, 2010 at 12:05:37PM +0200]:

 Same problem occured here during upgrade from 0.96 to 0.97.
 Now, I am not even sure the machine will boot properly next time as apparently
 rebuilding the initramfs failed.

[...]

 Eventually I found the notice in a previous post of this thread saying iscan
 was the culprit.
 I purged iscan, but the problem remained.
 I purged iscan-data, too. Now, finally, it was possible to upgrade initramfs-
 tools successfully.

We are working on new initramfs-tools version which should display
the source of the problem then, I'll be investigating on the iscan
issue in more detail as well and report back.

regards,
-mika-


signature.asc
Description: Digital signature


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

2010-06-30 Thread Alesh Slovak

On 06/30/2010 07:25 PM, Michael Prokop wrote:

* Andreas Neudeckerzap...@gmx.net  [Wed Jun 30, 2010 at 12:05:37PM +0200]:


Same problem occured here during upgrade from 0.96 to 0.97.
Now, I am not even sure the machine will boot properly next time as apparently
rebuilding the initramfs failed.


Another iscan maintainer here. I am currently looking into this issue.


I purged iscan, but the problem remained.
I purged iscan-data, too. Now, finally, it was possible to upgrade initramfs-
tools successfully.


Starting with iscan 2.25 we've moved bits of the iscan package to a new package, 
iscan-data. This was done for various reasons, mostly to do with ease of 
maintenance. The initramfs hook was moved to the new iscan-data package.


Since iscan depends on iscan-data, both will need to be uninstalled in order to 
be able to successfully upgrade mkinitramfs-tools. People with iscan 2.24 or 
older installed, which does not use iscan-data will just need to uninstall iscan.


Happy scanning,
--
Alesh SlovakLinux Team -- AVASYS Corporation
alesh.slo...@avasys.jp  http://avasys.jp



--
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/4c2bddc7.1050...@avasys.jp



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

2010-06-30 Thread Alesh Slovak

On 06/30/2010 07:25 PM, Michael Prokop wrote:

We are working on new initramfs-tools version which should display
the source of the problem then, I'll be investigating on the iscan
issue in more detail as well and report back.


Thanks to all for your help tracking this down. I've found the problem.
It was indeed related to the fact that the new version of initramfs-tools runs 
the hook scripts under errexit.


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.


I'll try to get a fixed version of iscan-data out as soon as I can.

Thanks again.

Happy scanning,
--
Alesh SlovakLinux Team -- AVASYS Corporation
alesh.slo...@avasys.jp  http://avasys.jp



--
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/4c2c016b.5020...@avasys.jp