> On Tue, Aug 28, 2001 at 12:52:12PM +0100, Richard Hirst wrote: > > I know this is a problem when rebooting during installation, but > > I'm not sure that I've seen it during normal reboots after install. > > It is on my list of things to fix though.
Current tests indicate that a file system is busy and therefore not cleanly unmounted on reboot 1) at the end of stage 1 install 2) at the end of stage 2 install 3) on a installed system, if you run debootstrap to create a chroot 4) on a installed system under other circumstances, see below.. I can provoke the problem as follows: a) install a new system, rebooting at end of stage 2 b) dpkg -i <some.deb> - I used lsof.deb c) reboot, should be clean d) remove /var/lib/dpkg/available* e) create an empty /var/lib/dpkg/available f) dpkg -i <same.deb> g) the empty /var/lib/dpkg/available has been moved to available-old and a new available file created h) note the inode number of available-old (ls -i) i) rm /var/lib/dpkg/available-old j) reboot reboot will complain that / is busy, and on the reboot there will be one error "deleted inode has non-zero dtime", and the inode number will be that empty available-old you deleted earlier. Experiments in a chroot indicate that if instead of creating an empty available file, you create one with just a '\n' in it, then there isn't a problem. There are no unexpected processes hanging around before the reboot; dpkg has gone, there are no zombies, etc. I can't think of any way dpkg could legally provoke this behaviour, so I'm guessing that there is a bug somewhere that dpkg just happens to provoke. All suggestions welcome! Richard
