[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Not clean reboots

> 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!


Reply to: