Bug#525516: udev: eth0 stopped working - renamed to eth3 (driver: e100)
Hi Marco,
Sorry for the delay in my response. I tried s/ATTR/SYSFS/ on my eth0
rule, removing the new one, and it worked perfectly at next reboot (as
expected).
I left the rules for the other devices unchanged so I can verify that
the SYSFS-ATTR change is correctly performed on next upgrade. Anyway, I
do not use those devices anymore.
Wondering if the solution would be that simple... What would happen if a
new rule had already been generated, and it is not removed as I did
myself? Which one would get matched? The old one or the new one?
Kind regards,
--
Antonio Fiol
Marco d'Itri escribió:
On Apr 25, Antonio Fiol anto...@fiol.es wrote:
ATTR and an added ATTR{type}==1). If I understand this correctly, the
missing ATTR{type} would match any ATTR{tpye} so it's not that. Then
it must be that udev stopped understanding the SYSFS syntax ??
Interesting, SYSFS{} is supposed to be still supported.
Please check if rules like this work or not (remove the new ones):
ACTION==add, SUBSYSTEM==net, DRIVERS==?*, ATTR{address}==00:0f:ea:3e:40:84,
NAME=eth0
s/SYSFS/ATTR/g in the user-generated rules files looks like a good idea
anyway, I need to write some code to do it.
Also it might be related to the upstream change from from v135 to v136:
require non-SYSFS_DEPRECATED 2.6.20+ kernel. Since v129 (which I never
It is not.
On Apr 25, Yann Dirson ydir...@altern.org wrote:
This looks the same as 521521, claimed fix in 0.140, but I'm running
But it is something totally different.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525516: udev: eth0 stopped working - renamed to eth3 (driver: e100)
Package: udev
Version: 0.141-1
Severity: important
After upgrading udev from 0.125-7 to 0.141-1 with the rest of available
upgrades, and rebooting, my eth0 (plain ethernet, not wireless) got
renamed to eth3, and thus stopped working.
There seems to have been a change in udev rules checking, as this was
present in persistent net rules:
# PCI device 8086:1050 (e100)
ACTION==add, SUBSYSTEM==net, DRIVERS==?*,
SYSFS{address}==00:0f:ea:3e:40:84, NAME=eth0
# FireWire host adapter 000fea0a00394e04 (/class/net/eth1)
ACTION==add, SUBSYSTEM==net, DRIVERS==?*,
SYSFS{address}==00:0f:ea:0a:00:39:4e:04, NAME=eth1
# PCI device 1814:0201 (rt2500)
ACTION==add, SUBSYSTEM==net, DRIVERS==?*,
SYSFS{address}==00:11:09:bf:05:d8, NAME=ra0
# USB device 0421:044f (rndis_host)
SUBSYSTEM==net, DRIVERS==?*, ATTR{address}==00:14:a7:dc:d1:3a,
NAME=eth2
Apparently, the first line did not match (why?) and the following one
got created:
# PCI device 0x8086:0x1050 (e100)
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==00:0f:ea:3e:40:84, ATTR{type}==1, KERNEL==eth*,
NAME=eth3
I've seen differences between rules attributes (most notably SYSFS -
ATTR and an added ATTR{type}==1). If I understand this correctly, the
missing ATTR{type} would match any ATTR{tpye} so it's not that. Then
it must be that udev stopped understanding the SYSFS syntax ??
Please do not suggest me to clean up the file. I already know how to do
that. What I am saying is the upgrade broke my system, while it should
have taken care of any needed changes.
Looks related to the first change on version 0.140-2.
Also it might be related to the upstream change from from v135 to v136:
require non-SYSFS_DEPRECATED 2.6.20+ kernel. Since v129 (which I never
had) a warning is printed about that, and I looked for it, and it is
actually present. Does this mean that my Debian packaged kernel is
somehow obsolete? This is possible, as it appears like there is a new
kernel package available. But if this is the problem, a dependency is
missing somewhere ;-)
Thank you very much for any advice. If I can do any testing for you, I
will be happy to do it.
Antonio Fiol
-- Package-specific info:
-- /etc/udev/rules.d/:
/etc/udev/rules.d/:
total 120
lrwxrwxrwx 1 root root19 oct 27 2005 025_libgphoto2.rules -
../libgphoto2.rules
lrwxrwxrwx 1 root root22 ene 15 2006 025_logitechmouse.rules -
../logitechmouse.rules
-rw-r--r-- 1 root root 1137 oct 1 2008 65_dmsetup.rules
-rw-r--r-- 1 root root 698 sep 25 2006 70-persistent-cd.rules
-rw-r--r-- 1 root root 920 abr 25 08:07 70-persistent-net.rules
lrwxrwxrwx 1 root root16 abr 18 23:15 libmtp8.rules - ../libmtp8.rules
lrwxrwxrwx 1 root root19 sep 17 2005 z60_alsa-utils.rules -
../alsa-utils.rules
lrwxrwxrwx 1 root root15 ene 15 2006 z60_hdparm.rules -
../hdparm.rules
-rw-r--r-- 1 root root 5354 mar 17 10:27 z60_hplip.rules
-rw-r--r-- 1 root root 1914 nov 16 2007 z60_libccid.rules
-rw-r--r-- 1 root root 2656 ene 3 2008 z60_libpisock9.rules
-rw-r--r-- 1 root root 1742 mar 29 12:38 z60_libsane-extras.rules
-rw-r--r-- 1 root root 72908 mar 4 16:26 z60_libsane.rules
-rw-r--r-- 1 root root 3363 mar 17 08:52 z60_openct.rules
-rw-r--r-- 1 root root 6658 oct 31 13:54 z60_xserver-xorg-input-wacom.rules
-- /sys/:
/sys/block/hda/dev
/sys/block/hda/hda1/dev
/sys/block/hda/hda2/dev
/sys/block/hda/hda3/dev
/sys/block/hda/hda4/dev
/sys/block/hda/hda5/dev
/sys/block/hda/hda6/dev
/sys/block/hdc/dev
/sys/block/ram0/dev
/sys/block/ram10/dev
/sys/block/ram11/dev
/sys/block/ram12/dev
/sys/block/ram13/dev
/sys/block/ram14/dev
/sys/block/ram15/dev
/sys/block/ram1/dev
/sys/block/ram2/dev
/sys/block/ram3/dev
/sys/block/ram4/dev
/sys/block/ram5/dev
/sys/block/ram6/dev
/sys/block/ram7/dev
/sys/block/ram8/dev
/sys/block/ram9/dev
/sys/block/sda/dev
/sys/block/sda/sda1/dev
/sys/block/sdb/dev
/sys/block/sdc/dev
/sys/block/sdd/dev
/sys/block/sde/dev
/sys/class/bsg/0:0:0:0/dev
/sys/class/bsg/0:0:0:1/dev
/sys/class/bsg/0:0:0:2/dev
/sys/class/bsg/0:0:0:3/dev
/sys/class/bsg/1:0:0:0/dev
/sys/class/hidraw/hidraw0/dev
/sys/class/hidraw/hidraw1/dev
/sys/class/input/input0/event0/dev
/sys/class/input/input1/event1/dev
/sys/class/input/input2/event2/dev
/sys/class/input/input3/event3/dev
/sys/class/input/input4/event4/dev
/sys/class/input/input5/event5/dev
/sys/class/input/input6/event6/dev
/sys/class/input/input6/mouse0/dev
/sys/class/input/mice/dev
/sys/class/misc/agpgart/dev
/sys/class/misc/cpu_dma_latency/dev
/sys/class/misc/device-mapper/dev
/sys/class/misc/fuse/dev
/sys/class/misc/hpet/dev
/sys/class/misc/network_latency/dev
/sys/class/misc/network_throughput/dev
/sys/class/misc/psaux/dev
/sys/class/misc/snapshot/dev
/sys/class/misc/tun/dev
/sys/class/ppdev/parport0/dev
/sys/class/printer/lp0/dev
/sys/class/rtc/rtc0/dev
/sys/class/sound/adsp/dev
/sys/class/sound/audio/dev
/sys/class/sound/controlC0/dev
/sys/class/sound/dsp/dev
/sys/class/sound/mixer/dev
/sys/class/sound/pcmC0D0c/dev
/sys
Bug#450691: gnome-icon-theme: emblem-special lost
Package: gnome-icon-theme Version: 2.20.0-1 Severity: normal The icon for emblem Special was present in 2.14 and is not present in 2.20. This makes all files having that emblem selected to lose -at least visually- that information. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.15-1-686-smp (SMP w/2 CPU cores) Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages gnome-icon-theme depends on: ii hicolor-icon-theme0.10-1 default fallback theme for FreeDes ii librsvg2-common 2.18.2-1 SAX-based renderer library for SVG gnome-icon-theme recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425109: nautilus: Metadata not moved alongside folder
Package: nautilus Version: 2.14.3-11+b1 Severity: normal I used emblems to mark a series of photos in a folder. Then I moved the folder (using nautilus, not with plain mv command line). The folder at the destination place had lost all the emblems. I closed it. By looking into ~/.nautilus/metafiles I saw an XML file corresponding to the original location. I renamed it to correspond to the new location, and then the emblems appeared when I reopened the new location. I think the metafiles should be renamed when moving folders or copied when copying them (this part not tested). Yours sincerely, -- Antonio Fiol -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.15-1-686-smp (SMP w/2 CPU cores) Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages nautilus depends on: ii desktop-file-utils 0.11-1Utilities for .desktop files ii gnome-control-center 1:2.14.2-7utilities to configure the GNOME d ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libatk1.0-01.12.4-3 The ATK accessibility toolkit ii libbonobo2-0 2.14.0-4 Bonobo CORBA interfaces library ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libeel2-2.14 2.14.3-5 Eazel Extensions Library (for GNOM ii libesd00.2.36-3 Enlightened Sound Daemon - Shared ii libexif12 0.6.13-5 library to parse EXIF files ii libgail-common 1.8.11-4 GNOME Accessibility Implementation ii libgail17 1.8.11-4 GNOME Accessibility Implementation ii libgconf2-42.16.1-1 GNOME configuration database syste ii libglade2-01:2.6.0-4 library to load .glade files at ru ii libglib2.0-0 2.12.4-2 The GLib library of C routines ii libgnome-desktop-2 2.14.3-2 Utility library for loading .deskt ii libgnome2-02.16.0-2 The GNOME 2 library - runtime file ii libgnomecanvas2-0 2.14.0-2 A powerful object-oriented display ii libgnomeui-0 2.14.1-3 The GNOME 2 libraries (User Interf ii libgnomevfs2-0 1:2.14.2-7GNOME virtual file-system (runtime ii libgtk2.0-02.8.20-7 The GTK+ graphical user interface ii libnautilus-extension1 2.14.3-11+b1 libraries for nautilus components ii liborbit2 1:2.14.7-0.1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.14.8-5 Layout and rendering of internatio ii libpopt0 1.10-3lib for parsing cmdline parameters ii librsvg2-2 2.14.4-2 SAX-based renderer library for SVG ii libstartup-notification0 0.9-1 library for program launch feedbac ii libx11-6 2:1.0.3-7 X11 client-side library ii libxml22.6.27.dfsg-1 GNOME XML library ii nautilus-data 2.14.3-11 data files for nautilus ii shared-mime-info 0.19-2FreeDesktop.org shared MIME databa Versions of packages nautilus recommends: ii desktop-base 4.0.1 common files for the Debian Deskto ii eject2.1.4-4 ejects CDs and operates CD-Changer ii fam 2.7.0-12File Alteration Monitor ii libgnomevfs2-extra 1:2.14.2-7 GNOME virtual file-system (extra m ii librsvg2-common 2.14.4-2SAX-based renderer library for SVG ii nautilus-cd-burner 2.14.3-8+b1 CD Burning front-end for Nautilus -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318456: gallery: Allowed memory size exhausted when upgrading album
Package: gallery Severity: normal When upgrading an album with 655 photos, gallery exhausted the 8Mb available memory. Turning up available memory solved the problem, but I had to struggle to discover the reason for the failure, as no kind of error message was displayed. Probably, available memory could be checked at gallery set-up time (or even in postinst), and this could avoid users a lot of hassle when upgrading with moderately big albums. Thank you very much. -- Antonio Fiol -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295414: gdm: could use less memory while the session is running
Package: gdm Version: 2.6.0.6-1 Severity: wishlist Hello, I have seen that while the session is running, gdm is still consuming about 17Mb memory. But it is not doing anything but waiting for the session to finish. Couldn't anything be done to avoid such a waste for small systems? Suggestion: Refactor the graphical part (using lots of libs) out from the waiting process. I do not know if that is feasible, but if possible it would be nice. Yours, Antonio Fiol -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.8 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages gdm depends on: ii adduser 3.59Add and remove users and groups ii debconf 1.4.45 Debian configuration management sy ii dpkg 1.10.27 Package maintenance system for Deb ii eterm [x-terminal-emulat 0.9.2-8 Enlightened Terminal Emulator ii gksu 1.2.3-2 graphical frontend to su ii gnome-session2.8.1-5 The GNOME 2 Session Manager ii gnome-terminal [x-termin 2.8.2-1 The GNOME 2 terminal emulator appl ii libart-2.0-2 2.3.17-1Library of functions for 2D graphi ii libatk1.0-0 1.8.0-4 The ATK accessibility toolkit ii libattr1 2.4.21-1Extended attribute shared library ii libaudiofile00.2.6-5 Open-source version of SGI's audio ii libbonobo2-0 2.8.1-1 Bonobo CORBA interfaces library ii libbonoboui2-0 2.8.1-1 The Bonobo UI library ii libbz2-1.0 1.0.2-5 high-quality block-sorting file co ii libc62.3.2.ds1-20GNU C Library: Shared libraries an ii libcroco30.6.0-2 a generic Cascading Style Sheet (C ii libesd0 0.2.35-2Enlightened Sound Daemon - Shared ii libgconf2-4 2.8.1-4 GNOME configuration database syste ii libgcrypt11 1.2.0-11LGPL Crypto library - runtime libr ii libglade2-0 1:2.4.2-1 library to load .glade files at ru ii libglib2.0-0 2.6.2-1 The GLib library of C routines ii libgnome-keyring00.4.1-1 GNOME keyring services library ii libgnome2-0 2.8.0-6 The GNOME 2 library - runtime file ii libgnomecanvas2-02.8.0-1 A powerful object-oriented display ii libgnomeui-0 2.8.0-3 The GNOME 2 libraries (User Interf ii libgnomevfs2-0 2.8.3-11The GNOME virtual file-system libr ii libgnutls11 1.0.16-13 GNU TLS library - runtime library ii libgpg-error01.0-1 library for common error values an ii libgsf-1 1.11.1-1Structured File Library - runtime ii libgtk2.0-0 2.6.2-3 The GTK+ graphical user interface ii libice6 4.3.0.dfsg.1-10 Inter-Client Exchange library ii libjpeg626b-9The Independent JPEG Group's JPEG ii liborbit21:2.10.5-0.1libraries for ORBit2 - a CORBA ORB ii libpam-modules 0.76-22 Pluggable Authentication Modules f ii libpam-runtime 0.76-22 Runtime support for the PAM librar ii libpam0g 0.76-22 Pluggable Authentication Modules l ii libpango1.0-01.8.0-3 Layout and rendering of internatio ii libpopt0 1.7-5 lib for parsing cmdline parameters ii librsvg2-2 2.8.1-2 SAX-based renderer library for SVG ii libselinux1 1.20-1 SELinux shared libraries ii libsm6 4.3.0.dfsg.1-10 X Window System Session Management ii libtasn1-2 0.2.10-4Manage ASN.1 structures (runtime) ii libwrap0 7.6.dbs-6 Wietse Venema's TCP wrappers libra ii libx11-6 4.3.0.dfsg.1-10 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-10 X Window System miscellaneous exte ii libxml2 2.6.16-2GNOME XML library ii metacity [x-window-manag 1:2.8.8-1 A lightweight GTK2 based Window Ma ii multi-gnome-terminal [x- 1.6.2-10Enhanced the GNOME Terminal ii wmaker [x-window-manager 0.91.0-7NeXTSTEP-like window manager for X ii xbase-clients4.3.0.dfsg.1-10 miscellaneous X clients ii xlibs4.3.0.dfsg.1-11 X Keyboard Extension (XKB) configu ii xterm [x-terminal-emulat 4.3.0.dfsg.1-10 X terminal emulator ii zlib1g 1:1.2.2-4 compression library - runtime -- debconf information: gdm/daemon_name: /usr/bin/gdm * shared/default-x-display-manager: gdm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject
Bug#290248: libclamav1: False negatives (user can fool scanner)
Stephen Gran wrote: This one time, at band camp, Antonio Fiol said: I am using clamd in STREAM mode in every case. I have found a way of fooling the scanner to give a false negative: If the user sends a BIG file (bigger than the limit) with a virus near the end (outside the limit), it will get cut, and the virus will not be found. IMO, the scanner should detect this as an exceptional situation, and react by saying: stream: ERROR:Size-limit-exceeded FOUND Or any other informative string. Upstream's response is that you should set your MTA limits for message size to be the same as your settings for stream size, so that you can just reject over size messages outright. Apparently that means they don't want to accept your patch :( Just a minute! I don't have any MTA! Our use of the clamav antivirus is related to a completely different app. There is no e-mail involved. The logic is that the Archive related options and ArchiveBlockMax are to prevent against archive bombs. But it is trivially easy to control the size of the data being fed to clamav, unlike knowing in advance the content that will go through. I agree on that. But I disagree on the fact that the antivirus administrator (and thus, the person responsible for his system saying: No virus found using pattern file XYZ) may be, and will most likely be, in our case, not in charge for the configuration of the application, which, for now, does not even control the size of the data, as it has no specific requirement on data size. Of course the app could be modified to handle data size. But IMHO, if the size limit is something related to the antivirus system, the limit should be (only) configured on the antivirus system. To upstream: I beg you reconsider your position, having read the above. And thank you all anyway for your attention. smime.p7s Description: S/MIME Cryptographic Signature
Bug#289475: dvbackup: still no good results
Package: dvbackup Version: 0.0.4rj1-5 Followup-For: Bug #289475 Hello, I have not yet managed to get good results. - I have tried setting buffers higher (8192), and results improve. - rsbepC finds unrecoverable errors when decoding. - I tried to cascade rsbepC twice (to introdude more redundancy, if possible). But rsbepC is not fast enough on my computer to decode it in real time. - rsbep (assembler version) is not included in the package. - Compiling a rsbep from source allowed me to decode most of the backup. - At the end, an unrecoverable *tar* error happened. - I will investigate further. Yours, Antonio Fiol -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.8 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages dvbackup depends on: ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libdv-bin 0.103-2 software library for DV format dig ii libpopt01.7-5lib for parsing cmdline parameters ii zlib1g 1:1.2.2-4compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289475: dvbackup: still no good results
Robert Joerdens wrote: - rsbepC finds unrecoverable errors when decoding. Did you use and see the underrun frames? I used the proposed command line, which has the underrun frame in it. I have NOT seen the frame on the camera. Might be bad tape. I once bought high quality DV tape for twice the price of regular stuff and error rates really improved. Camera is a JVC GR-DX77, and tape is a TDK DV60, and I am still using SP. I will not try LP until SP works perfectly. And even then, I am not sure. - I tried to cascade rsbepC twice (to introdude more redundancy, if possible). But rsbepC is not fast enough on my computer to decode it in real time. No. cascading rsbep should not help much. Right. - rsbep (assembler version) is not included in the package. Hmmm. THat's a bug. I have to fix that. Could you file a bug to remind me? I saw that in configure, there is a line saying: i?86-*) In my case, the variable value was just i386. I simply changed it to: i?86*) and it worked. Not the best way to do it, most certainly, but I am not an expert in build systems. - At the end, an unrecoverable *tar* error happened. Hm. no idea. MAybe some overflow. Are you just using tar -t or really tar -x ? I had used tar -t. Should that matter? - I will investigate further. Good. THanks a lot. A few ideas: try different tapes and maybe not tar but a simple dd. Well, for the tapes, I could not do it today. This is my last try: $ tar cpsvv cordoba-300kbps-128kbps.avi *mp3 *wav ceros | ~/dvbackup-0.0.4rj1/rsbep | dvbackup --verbose --prefix 300 --set-backup-title Prueba2 80Mb | dvconnect --send --underrun-data /usr/share/dvbackup/underrun-pal.dv --buffers 250 -k 32 --device /dev/video1394/0 -- - WARNING: Cannot set RR-scheduler -rw-r--r-- fiol/fiol 80933786 2005-01-08 10:18:04 cordoba-300kbps-128kbps.avi -r-xr-xr-x fiol/fiol 2924394 2005-01-06 10:31:01 10 - Track 10.mp3 -r-xr-xr-x fiol/fiol 3410413 2005-01-06 10:31:08 17 - Track 17.mp3 -r--r--r-- fiol/fiol 6906903 2004-03-21 17:20:25 danzavientre1-03.wav.mp3 -r-xr-xr-x fiol/fiol 1035166 2005-01-06 10:38:32 Recuerdos de la Alhambra - 06 - Endecha. Andante.mp3 -r-xr-xr-x fiol/fiol 1104791 2005-01-06 10:38:33 Recuerdos de la Alhambra - 08 - La Mariposa. Allegro vivace.mp3 -r-xr-xr-x fiol/fiol 2981932 2005-01-06 10:38:35 Recuerdos de la Alhambra - 09 - Recuerdos de la Alhambra. And.mp3 -rw-r--r-- fiol/fiol 37610540 2005-01-05 18:55:17 audio1.wav -rw-r--r-- fiol/fiol 49407020 2005-01-05 20:05:47 audio2.wav -rw-r--r-- fiol/fiol 1975724 2005-01-06 12:05:58 pasodoble.wav -rw-r--r-- fiol/fiol 1048576 2005-01-17 07:48:33 ceros And then, I decode it in parts: $ dvconnect --device /dev/video1394/0 backup WARNING: Cannot set RR-scheduler Broken frame0 (size = 138240)! The broken frame does not seem important to me: I think it is the first frame. And anyway, when I do everything together, this appears before the prefix, and then it starts decoding data. So this step is OK. [EMAIL PROTECTED]:/audio/tmp/video$ cat backup | dvbackup --decode --verbose backup2 Found prefix zone of backup: 'Prueba2 80Mb' Beginning new backup: 'Prueba2 80Mb' Processing address 29080881 of backup 'Prueba2 80Mb' Checksum failed: 126121540 != 1535738940 Processing address 216491003 of backup 'Prueba2 80Mb' Reached EOF: Total length: 216572100! Well, there is a single checksum failed. It should not be that bad... $ cat backup2 | ~/dvbackup-0.0.4rj1/rsbep -d -v /dev/null Violación de segmento.0.4rj1/rsbep: errors corrected: 0 uncorrectable blocks: 03659860253 Well, this is not exactly what appears. What appears (rsbep.log) is attached. $ cat backup2 | ~/dvbackup-0.0.4rj1/rsbep -d -v /dev/null 2 rsbep.log Violación de segmento Which means segmentation fault... Using rsbepC gives very similar results, with different counts of uncorrectable blocks. But... Shouldn't a single checksum error be very easily correctable? Thank you very much. Antonio Fiol PS: ~/dvbackup-0.0.4rj1/ is the directory where I ... apt-get source dvbackup cd dvbackup-0.0.4rj1 ... modify configure as stated above ... debian/rules build /home/fiol/dvbackup-0.0.4rj1/rsbep: errors corrected: 0 uncorrectable blocks: 255 /home/fiol/dvbackup-0.0.4rj1/rsbep: errors corrected: 0 uncorrectable blocks: 223 /home/fiol/dvbackup-0.0.4rj1/rsbep: errors corrected: 0 uncorrectable blocks: 765 /home/fiol/dvbackup-0.0.4rj1/rsbep: errors corrected: 0 uncorrectable blocks: 1700950898 /home/fiol/dvbackup-0.0.4rj1/rsbep: errors corrected: 0 uncorrectable blocks: -1073807248 /home/fiol/dvbackup-0.0.4rj1/rsbep: errors corrected: 0 uncorrectable blocks: 1073835912 /home/fiol/dvbackup-0.0.4rj1/rsbep: errors corrected: 0 uncorrectable blocks: 4 /home/fiol/dvbackup-0.0.4rj1/rsbep: errors corrected: 0 uncorrectable blocks: 1074124592 /home/fiol/dvbackup-0.0.4rj1/rsbep: errors corrected: 0 uncorrectable blocks: 0 /home/fiol/dvbackup-0.0.4rj1/rsbep: errors corrected: 0
