On Thu, 24 Feb 2005, Dawood Morady Garawand wrote:
Or perhaps resume2=swap:/dev/hda2?!!
It just doesn't matter whether you add the "swap:" before the device or if you use "resume" or "resume2" - it all works if you only have a working grub entry: The removal of my newly baken 2.6.10 kernel package just removed the /vmlinuz symlink (instead of replacing it by the /vmlinuz.old or whatever). So this part of the problem is solved and was caused by my own stupidity.
But the other part of the problem is, that the "normal" boot kernel entry now just resumes from SwSusp2 instead of doing a new boot as it did before. We might discuss about the sense of the attempt to boot from scratch after a SwSuspend but it just worked before and I tried to uses that (more or less for testing purpose).
I found out that the journals of the ext3fs are not completely written before the SwSusp2 which seems to be the reason for my fsck problems with kernel 2.6.10 - I might just have mixed up something. Fiddling around with this I just found out the 1742th way how to destroy your boot partition: I tried booting a Debian packaged kernel (2.6.8) which "solved" the fsck errors on the SwSuspended box and afterwards tried again my own kernel (2.6.9) which tried to resume from SwSusp and obviousely found a different state on the disk and did some other "repairing" steps which left me with a broken /bin/mount and some other broken files in /bin (perhaps more). I'm currently doint an "apt-get --reinstall install <everything>" ...
So after this excurse about another elegant method to break your system: IMHO it is a bug that the file system is left in an inconsistent state when doing a SwSuspend. How can I prevent this?
Kind regards
Andreas.
-- http://fam-tille.de
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
