On Sat, 9 May 2009 18:42:15 -0400
Theodore Tso <ty...@mit.edu> wrote:

> On Sat, May 09, 2009 at 06:22:00PM -0400, Andres Salomon wrote:
> > Creating a zero-length /etc/mtab file doesn't work if, for some
> > reason, /etc is mounted read-only.  Having a fully supported and
> > supportable system isn't always available.  If resize2fs is going to
> > stipulate that the filesystem that it's shrinking is not mounted,
> > then users are going to use it in things like recovery cds and
> > initramfs's.
> 
> You said you had an initramfs mounted, remember?   
> 
> And as I said, if /etc is mounted read-only, then it's almost certain
> that / is mounted read-only, and an off-line shrink using resize2fs is
> not safe to run on a mounted filesystem.  (Also, if /etc is mounted
> read-only, there normally is an /etc/mtab file.)

I'm talking about the general case; an initramfs *or* a recovery cd.
If I'd had one handy, I probably would've used that instead of breaking
into the initramfs.

The presumption that the user can fix it by copying over an /etc/mtab
doesn't make sense to me.  Why not just let the user do what they want
to do, rather than telling them how to work around the problem?

> 
> The real problem here is that initramfs isn't including a proper
> /etc/mtab file --- but it's an initramfs, which means you can fix it,
> by definition.
> 
> A much simpler and safer solution, instead of trying to subvert
> resize2fs safety mechanisms, is to fix the initramfs scripts to create
> the /etc/mtab file in the first place.

The initramfs doesn't *need* an /etc/mtab, and you assume a sane
environment that might not exist.


> 
> > I like my tools to get out of the way and allow me to what I want to
> > do.  That's why I use free software (transparency and hackability).
> > I'm fine w/ all kinds of warnings to tell the user that they
> > shouldn't continue, so long as they are also told of a way to
> > actually continue.
> 
> Well, it's free software, so if you want to disable the safety
> mechanisms, you have the freedom to do it.  Call me silly, but I'm the
> sort of person that believes in showing people the right way to use a
> table saw, and *not* accepting a suggestion to ship table saws with an
> documented way of subverting the safety guards that (for example)
> tries to prevent people from sawing their fingers off.
> 
> What's wrong with fixing the initramfs tools to create a proper
> /etc/mtab file?  
> 

Absolutely nothing, until someone's using the tool on a non-debian
system whose initramfs (or recovery cd) doesn't create /etc/mtab.


> > > For example, we could have a script fragment that checks for the
> > > existence of a file which matches the
> > > pattern /on-initrd-*.tar.gz, and if one or more such files
> > > exists, they are copied to the initrd, and then the root
> > > filesystem is unmountd, and one by one, the on-initrd-*.tar.gz
> > > files are unpacked and the /on-initrd script contained in the
> > > tar.gz file is executed.
> > > 
> > > This could be used to perform an off-line shrink of the root
> > > partition, by having the user request such a thing, and then
> > > rebooting, and having it happen automatically.  It could also be
> > > used to add or remove a journal safely, as well as repack and
> > > optimize directories (e2fsck -fD).
> > 
> > Sounds like additional unnecessary complexity to me.
> 
> But it's easier and safer for users to use.  Teaching users that's
> it's OK to use "force" options scares the hell out of me.
> 
> Trust me.  Most Linux users, from numerical standpoint, are stupid.
> This isn't like it was ten years ago.  
> 

That's fine.  Most Linux users should be using a nice GUI to resize the
filesystem and partition, since fdisk is another dangerous tool that
can horribly break things.

Currently, the tool is teaching users that it's fragile and prone to
mysterious breakage.


> There's a reason why lawnmowers have safety mechanisms that stop the
> blade from spinning if one of the wheels is lifted off the ground.  It
> turns out some number of idiots were trying to pick up a lawnwomer and
> use it to trip their hedges, and then when they dropped the lawnmower
> on their leg(s), they lost a foot.  Oops.  They were then able to find
> a lawyer who was able to successfully sue the lawnmower manufacturer
> for negligence (which is its own problem, and speaks to the US legal
> system).  This just goes to prove what H. L. Mencken once stated:
> 
>     Nobody ever went broke underestimating the intelligence of the
>     American people
> 
> Unfortunately, this tends to be true world-wide, not just for the
> general American Public....
> 
>                                               - Ted
> 
> 
> 

That's what your original check is for; if the filesystem is mounted,
complain.  If it can't figure out what filesystems are mounted,
complain.  That's enough of a safety measure.  If the user really
really wants to be able to resize the fs, then they should be able to.
Whether it's through a '-f' option, or a different option to not check
filesystems, or it's with a message that tells users to create
'/etc/mtab', it's all the same; so long as there's *something* that
keeps one from having to grovel through the source to figure out what's
going on.

If you really feel that telling the user to copy /etc/mtab is the
solution, so be it.  I find it a rather odd solution, but it would fix
my original complaint.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to