Package: dpkg
Version: 1.15.5.6
Severity: important

[ For debian-dpkg, see
https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/512096 for a
description of the problem, basically a configuration script is empty
/broken due to data loss and the recovery needs manual intervention ]

Le mardi 26 janvier 2010, Jean-Baptiste Lallement a écrit :
> What could be done ? Some suggestions:
> - package manager : try to unpack the archive again in order to
> overwrite the faulty files, if it's not found fetch then unpack the
> archive, and try performing the requested operation again. If that
> fails, then really cancel the installation. But the package manager
> need to know it's an "exec format error" and that's not easy due to
> the comments above. Another option could be to ask to the user if he
> wants to try the workaround.
> - dpkg : add a 'force' option to 'vanish' the package if the removal
> script fails during a removal and/or configuration purging ( with a
> BIG RED warning that it can seriously damage the user's installation)
> instead of running abort-remove or leaving the package half-installed.
> But I don't know the dpkg internals to know if it's a valid option.

I would suggest that dpkg detects the error and brings back the
package state to half-installed forcing the package manager to
unpack it again.

It seems to me that the error code ENOEXEC is sufficiently specific (and it
could be associated to a check of the file length if needed) for this to
be reasonable.

BTW, I think it would have been wise to include the upstream dpkg
maintainers in the discussion from the start, you're lucky that I'm
following ubuntu-devel...

We would also be glad if some people could volunteer to triage dpkg bugs
on launchpad and make sure we have everything filed in the Debian BTS.

Cheers,
--
Raphaël Hertzog -+- http://www.ouaza.com

Freexian : des développeurs Debian au service des entreprises
http://www.freexian.com


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Hi!

On Wed, 2010-01-27 at 09:15:52 +0100, Raphael Hertzog wrote:
> Package: dpkg
> Version: 1.15.5.6
> Severity: important

> [ For debian-dpkg, see
> https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/512096 for a
> description of the problem, basically a configuration script is empty
> /broken due to data loss and the recovery needs manual intervention ]

Ugh, that page is scary, there's a ton of duplicate bugs.

> I would suggest that dpkg detects the error and brings back the
> package state to half-installed forcing the package manager to
> unpack it again.
>
> It seems to me that the error code ENOEXEC is sufficiently specific (and it
> could be associated to a check of the file length if needed) for this to
> be reasonable.

I'd rather fix the problem that's causing those files to be 0 length.
That should generally never happen, I'm assuming they might just need an
fsync on the directory, which we are not doing at all in general, there
might be some fsyncs on files missing too. What's the difference in
Ubuntu that causes all these reporters to suffer such error, I had never
seen that one before, and it's not been reported in our BTS either. Are
all those reporters using ext4 or ubifs? Anything else different from
Debian you might be aware of?

thanks,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Mon, 2010-02-08 at 05:09 +0100, Guillem Jover wrote:

> I'd rather fix the problem that's causing those files to be 0 length.
> That should generally never happen, I'm assuming they might just need an
> fsync on the directory, which we are not doing at all in general, there
> might be some fsyncs on files missing too. What's the difference in
> Ubuntu that causes all these reporters to suffer such error, I had never
> seen that one before, and it's not been reported in our BTS either. Are
> all those reporters using ext4 or ubifs? Anything else different from
> Debian you might be aware of?

ext4 is the default filesystem in Ubuntu.

-Rob

ext4 is default only if you are doing a fresh install.* If you are upgrading from Jaunty, you will still have ext3, I believe.

WeatherGod

On Mon, Feb 8, 2010 at 12:49 AM, Robert Collins <robertc@robertcollins.net> wrote:


On Mon, 2010-02-08 at 05:09 +0100, Guillem Jover wrote:



> I'd rather fix the problem that's causing those files to be 0 length.

> That should generally never happen, I'm assuming they might just need an

> fsync on the directory, which we are not doing at all in general, there

> might be some fsyncs on files missing too. What's the difference in

> Ubuntu that causes all these reporters to suffer such error, I had never

> seen that one before, and it's not been reported in our BTS either. Are

> all those reporters using ext4 or ubifs? Anything else different from

> Debian you might be aware of?



ext4 is the default filesystem in Ubuntu.



-Rob


--

Ubuntu-bugsquad mailing list

Ubuntu-bugsquad@lists.ubuntu.com

https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad

2010/2/8 Benjamin Root <ben.v.root@gmail.com>:
> ext4 is default only if you are doing a fresh install.* If you are upgrading
> from Jaunty, you will still have ext3, I believe.
>
>From duplicates the problem appeared in 9.04 with slightly more
reports in 9.10. Only 4 reports are filed against an earlier release.


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

2010/2/8 Guillem Jover <guillem@debian.org>:
> I'd rather fix the problem that's causing those files to be 0 length.
> That should generally never happen, I'm assuming they might just need an
> fsync on the directory, which we are not doing at all in general, there
> might be some fsyncs on files missing too. What's the difference in
> Ubuntu that causes all these reporters to suffer such error, I had never
> seen that one before, and it's not been reported in our BTS either. Are
> all those reporters using ext4 or ubifs? Anything else different from
> Debian you might be aware of?
>

This is a problem with ext4 and some missing fsync.
I'm able to reproduce it on a VM with an ext4 fs and the following test:

# apt-get install hello; sleep 20; echo b > /proc/sysrq-trigger
[simulates a system crash]
After reboot both installation and removal scripts are 0 bytes. You
will notice that hello.list was correctly written to disk.
$ ls -l /var/lib/dpkg/info/hello.*
-rw-r--r-- 1 root root 323 2010-02-09 00:42 /var/lib/dpkg/info/hello.list
-rwxr-xr-x 1 root root 0 2009-08-15 19:17 /var/lib/dpkg/info/hello.postinst
-rwxr-xr-x 1 root root 0 2009-08-15 19:17 /var/lib/dpkg/info/hello.prerm

If you replay the test but adding a sync before the system crash:
# apt-get install hello; sync; echo b > /proc/sysrq-trigger
After reboot the files are fine:
$ ls -l /var/lib/dpkg/info/hello.*
-rw-r--r-- 1 root root 323 2010-02-09 00:46 /var/lib/dpkg/info/hello.list
-rwxr-xr-x 1 root root 103 2009-08-15 19:17 /var/lib/dpkg/info/hello.postinst
-rwxr-xr-x 1 root root 74 2009-08-15 19:17 /var/lib/dpkg/info/hello.prerm

If I adjust /proc/sys/vm/dirty_expire_centisecs to be below the sleep
time, ( for exemple 1000 in the test above ) then data are correctly
written to disk.

So, some fsyncs should fix it.

--
Sincerely,

- JB


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org