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
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
All suggestions welcome!