Sorry, I'm very new to bug triaging so I'm not sure of the etiquette and if this is a place to reply, but I'm experienced the same problem for a relative of mine and it makes debugging/support a problem. On an aside, I wonder if there is a place for on lauchpad/forums for 'supporting family members' etc.
Dan Fish > 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 [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
