Jonathan, here's my take on these questions: (a) I wasn't thinking along the lines of the system being "aware" of whether it was properly shut down or not, although I believe the infrastructure is already in place for this to be possible (i.e. "Ubuntu recorded a successful boot" on startup, and how the GRUB menu now pops up automatically on boot if the system was not properly shut down beforehand). I'd rather not have a "repair" option be limited to these circumstances, however, at least not without carefully thinking through when else it might be needed. (Ideally, a root prompt would only come up if the system is hosed in a non-trivial way.)
My thought was more along the lines of being aware why the mount failed. Was the filesystem/journal corrupted? Did the fsck auto-preening fail? Is the kernel giving I/O errors? Was the device just not there? You do things differently, depending on what the failure mode is. (I believe mountall is doing all the fsck'ing in addition to the mounting, so it would be aware of what's going on.) The real wildcard would be the bad-controller case, where the filesystem on disk is sound but it gets garbled when read, and sensible writes to the disk turn into destructive ones. But is this really a factor? For one, it's not a terribly common failure mode, as far as I'm aware. Two, if fsck would damage the disk, then presumably, so would normal system activity. Three... even if fsck does completely hose the disk in this rare scenario, should that mean that we really can't do any better than drop the user into a root shell on mount failure? It comes down to risk management---getting in a car entails a risk of a fatal traffic accident, but for most people, the benefits outweigh the risks. I think a similar logic would apply here. (b) There's no guarantee that "fsck -y" is always going to be safe. There's no guarantee that it'll get things back into a usable state; heck, it might make the corruption worse. But of all the more involved filesystem-recovery tools and techniques that you're aware of, how feasible is it for a computer-phobic user to resort to any of them? How feasible is it for said user to take the system to a big-name electronics store, whose techs only know Windows, and have them do it? Or post on ubuntuforums.org, and be walked through the whole process, hands-on? (Remember, my dad didn't even know that r...@hostname:~# was a prompt.) Heck, if "fsck -y" doesn't fix the problem, *I* wouldn't know what else to do, and I work professionally with Linux. (For my part, I would just consider the filesystem a total loss, and blow it away. I'd only figure out the more advanced recovery stuff if there were something _really_ important on it.) I say "fsck -y" instead of just "fsck", too, because... unless I'm _really_ intimate with my filesystems, am I really going to know whether I should fix the block count for group #37, but not #52? Very, very few people are ever going to have a reason to say "n" to any of fsck's prompts. (By the way, just to correct what seems like a misperception... the damaged filesystem in this case was not one on a VirtualBox virtual disk file, but the Linux root filesystem on the laptop's physical hard drive. I don't disagree with the wisdom of making an image-copy of the filesystem before attempting repair, and then using a more conventional approach if that fails---the problem is, in this kind of situation, that's not feasible. In practical terms, it's no better than declaring the filesystem a total loss.) (c) I wasn't aware that -y wasn't universally supported. But yeah, an auto-repair option can be limited to certain filesystem types. If someone installs Ubuntu on a MINIX filesystem, then, well, they're on their own :-3 -- Need newbie-friendly alternative to maintenance shell when mount fails https://bugs.launchpad.net/bugs/489474 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
