I love cutting and pasting to and from my xterm. This time however I cut and pasted a preceding space from the directory name I was trying to rm -fr. Thus I ended up doing rm -fr ./ mydir. Goodbye home dir.
I quickly shut down and imaged the hard drive onto another server. Doing a little research I discovered I could mount the image using a loopback device. I wanted to try running foremost or some other tool to see what I could recover.
I got the loopback working and can see all the partitions in the image. Since its a volume managed device I'm now stuck. I can see the partitions but I can't think of how to get around the lvm part to mount them and see the actual contents. I'm not that lvm proficient quite yet.
Does anybody have any hits? Anybody maybe have some experience making this type of mistake and have some advice on trying to recover the data from it?
And yes, I am now in the process of implementing a backup system :(
TIA - Tod
I got the loopback working and can see all the partitions in the image. Since its a volume managed device I'm now stuck. I can see the partitions but I can't think of how to get around the lvm part to mount them and see the actual contents. I'm not that lvm proficient quite yet.
I used the following to figure it out. http://tldp.org/HOWTO/LVM-HOWTO/
You'll probably need to do /sbin/vgscan to figure out the lvm name then run
/sbin/vgchange -a y; mount /dev/VolGroup00/LogVol00 /mnt/whatever
can't remember how I arrived at VolGroup00/LogVol00 but think there is an explanation in the how-to
Shawn
On Tue, 13 Feb 2007 19:25:41 -0500 Tod tod@stthomasepc.org wrote:
Thus I ended up doing rm -fr ./ mydir. Goodbye home dir.
Create a file named -i in your home directory to prevent this from happening in the future.
On Tuesday 13 February 2007, Frank Cox wrote:
On Tue, 13 Feb 2007 19:25:41 -0500
Tod tod@stthomasepc.org wrote:
Thus I ended up doing rm -fr ./ mydir. Goodbye home dir.
Create a file named -i in your home directory to prevent this from happening in the future.
How does this prevent that happening?
linuxmaillists@charter.net wrote:
On Tuesday 13 February 2007, Frank Cox wrote:
On Tue, 13 Feb 2007 19:25:41 -0500
Tod tod@stthomasepc.org wrote:
Thus I ended up doing rm -fr ./ mydir. Goodbye home dir.
Create a file named -i in your home directory to prevent this from happening in the future.
How does this prevent that happening?
Because rm takes the -i file as an option.
-i, --interactive prompt before any removal
For example:
mkdir ~/TEST cd ~/TEST touch -- -i touch test touch test2 touch test3 rm -fr *
And see what happens. :-)
On 13Feb2007 20:39, linuxmaillists@charter.net linuxmaillists@charter.net wrote: | On Tuesday 13 February 2007, Frank Cox wrote: | > On Tue, 13 Feb 2007 19:25:41 -0500 | > | > Tod tod@stthomasepc.org wrote: | > > Thus I ended up doing rm -fr ./ mydir. Goodbye home | > > dir. | > | > Create a file named -i in your home directory to prevent | > this from happening in the future. | | How does this prevent that happening?
In short, it doesn't.
What it does do is help with "rm *" or the like. The "-i" will be included in the expansion of "*", fortuitously at the front. And so rm's -i mode will kick in and you'll be asked to confirm.
Tip for the unwary: the most common single keystroke error is pressing <return>. I habitually pause, briefly, before pressing return to eyeball important commands like rm.
It wouldn't have helped the OP, because the <return> as (presumably) included in his paste...
I'll add my $.02 to the "I don't have any suggestions to you for recovering your data, but here's what I do to prevent me from shooting myself in the foot" discussion....
I use the fact that, in bash, "!$" means "whatever was the last argument on the previous command. So, if I want to get rid of a bunch of files, I typically do:
$ ls *~ <list of a bunch of files pops out here> $ rm !$
Incidentally, this also prevents the mistake of accidentally putting a space between the "*" and the "~" :-)
In your case, where you wanted to get rid of ./mydir, I would have done: $ ls -d ./mydir $ rm -rf !$
--wpd
On 14/02/07, Patrick Doyle wpdster@gmail.com wrote:
I'll add my $.02 to the "I don't have any suggestions to you for recovering your data, but here's what I do to prevent me from shooting myself in the foot" discussion....
I use the fact that, in bash, "!$" means "whatever was the last argument on the previous command. So, if I want to get rid of a bunch of files, I typically do:
$ ls *~
<list of a bunch of files pops out here> $ rm !$
Incidentally, this also prevents the mistake of accidentally putting a space between the "*" and the "~" :-)
In your case, where you wanted to get rid of ./mydir, I would have done: $ ls -d ./mydir $ rm -rf !$
This might just be the single most useful tip that I've seen on this list in the two years that I've been subscribed. Thanks for that!
Dotan Cohen
http://lyricslist.com/lyrics/artist_albums/642/tal_bachman.html http://datip.com
On Wed, Feb 14, 2007 at 05:24:03PM +0200, Dotan Cohen wrote:
On 14/02/07, Patrick Doyle wpdster@gmail.com wrote:
In your case, where you wanted to get rid of ./mydir, I would have done: $ ls -d ./mydir $ rm -rf !$
This might just be the single most useful tip that I've seen on this list in the two years that I've been subscribed. Thanks for that!
If you like that, you'll love what happens when you hit ALT-period in bash -- it recalls and displays the value of last argument to the previous command. Subsequent uses of ALT-period recall the last argument to previous commands.
You might also find the environment variable $_ useful. It serves the same purpose as !$, but works even if you've disabled bang-expansion.
On 14/02/07, kodis@mail630.gsfc.nasa.gov kodis@mail630.gsfc.nasa.gov wrote:
On Wed, Feb 14, 2007 at 05:24:03PM +0200, Dotan Cohen wrote:
On 14/02/07, Patrick Doyle wpdster@gmail.com wrote:
In your case, where you wanted to get rid of ./mydir, I would have done: $ ls -d ./mydir $ rm -rf !$
This might just be the single most useful tip that I've seen on this list in the two years that I've been subscribed. Thanks for that!
If you like that, you'll love what happens when you hit ALT-period in bash -- it recalls and displays the value of last argument to the previous command. Subsequent uses of ALT-period recall the last argument to previous commands.
You might also find the environment variable $_ useful. It serves the same purpose as !$, but works even if you've disabled bang-expansion.
That is good. I'll start googling these combination. Thanks.
Dotan Cohen
http://what-is-what.com/what_is/drm.html http://lyricslist.com/lyrics/artist_albums/403/placebo.html
Tod wrote:
Does anybody have any hits? Anybody maybe have some experience making this type of mistake and have some advice on trying to recover the data from it?
Welcome to LVM Hell.
Here is how I was able to get to my underlying filesystem by throwing out LVM:
http://www.redhat.com/archives/fedora-list/2006-June/msg03297.html
After you make it out of LVM Hell, I am afraid I have no idea about your chances for file recovery. I guess it is going to depend on how fast the "quickly shut down" part was.
-Andy
Tod wrote:
[snip]
I got the loopback working and can see all the partitions in the image. Since its a volume managed device I'm now stuck. I can see the partitions but I can't think of how to get around the lvm part to mount them and see the actual contents. I'm not that lvm proficient quite yet.
I tossed FC4 when I discovered that it installs LVM by default. LVM is IMO worse than useless. I see no advantages for me, and I see problems (like yours, for example) looming in the future.
Does anybody have any hits? Anybody maybe have some experience making this type of mistake and have some advice on trying to recover the data from it?
Sorry, no.
And yes, I am now in the process of implementing a backup system :(
Well, live and learn.
I suggest that, when you get yourself back on your feet, you not use LVM.
Mike
Mike McCarty schreef:
Tod wrote:
[snip]
I got the loopback working and can see all the partitions in the image. Since its a volume managed device I'm now stuck. I can see the partitions but I can't think of how to get around the lvm part to mount them and see the actual contents. I'm not that lvm proficient quite yet.
I tossed FC4 when I discovered that it installs LVM by default. LVM is IMO worse than useless. I see no advantages for me, and I see problems (like yours, for example) looming in the future.
I would have to agree on this, for our servers we use freebsd because it does not have lvm and it's very easy to add drives etc. Would it not be a good idea to add a checkbox in the installer wich says yes automic partitioning but no lvm.
I once added a harddrive in my pc asuming it would just get mounted (being an ex mac user). Then I must have done something wrong in lvm and everything stopped working. I did have a backup but it was not a good experience.
Does anybody have any hits? Anybody maybe have some experience making this type of mistake and have some advice on trying to recover the data from it?
Sorry, no.
And yes, I am now in the process of implementing a backup system :(
Well, live and learn.
I suggest that, when you get yourself back on your feet, you not use LVM.
Mike
On Wed, Feb 14, 2007 at 20:17:30 +0100, bram bram@diomedia.be wrote:
Would it not be a good idea to add a checkbox in the installer wich says yes automic partitioning but no lvm.
I think doing the custom layout covers that case adequately. I think for the case where you let anaconda do it, having lvm so you can change things later easily makes sense. If you don't want LVM, then you really should pick the partition layout yourself.
Bruno Wolff III wrote:
On Wed, Feb 14, 2007 at 20:17:30 +0100, bram bram@diomedia.be wrote:
Would it not be a good idea to add a checkbox in the installer wich says yes automic partitioning but no lvm.
I think doing the custom layout covers that case adequately. I think for the
No, it does not. The *default* install should not be something that is worse than useless to the *average* user.
case where you let anaconda do it, having lvm so you can change things later easily makes sense. If you don't want LVM, then you really should pick the partition layout yourself.
I disagree most strongly with this position. The default install should not be one which is inappropriate for most situations, as is LVM in its current state. Have you studied reliability theory?
Anyway, we're getting into topic drift.
Mike
On Wed, 2007-02-14 at 13:49 -0600, Mike McCarty wrote:
Bruno Wolff III wrote:
On Wed, Feb 14, 2007 at 20:17:30 +0100, bram bram@diomedia.be wrote:
Would it not be a good idea to add a checkbox in the installer wich says yes automic partitioning but no lvm.
I think doing the custom layout covers that case adequately. I think for the
No, it does not. The *default* install should not be something that is worse than useless to the *average* user.
The average user does not accidentally delete their home directory by incorrectly cut and paste into an xterm window.
The average user who cares about backup uses something like rsync (or even tar) to do so regularly, so that restoration in case of accident is cake.
The advanced user uses something like amanda so that restoration is cake.
LVM is a godsend. Learn how to use it.
I hated it too when it first appeared. Then I read the docs and said "Wow, this is kick ass".
case where you let anaconda do it, having lvm so you can change things later easily makes sense. If you don't want LVM, then you really should pick the partition layout yourself.
I disagree most strongly with this position. The default install should not be one which is inappropriate for most situations, as is LVM in its current state. Have you studied reliability theory?
LVM allows easy resizing of partitions, something you can not safely do with ext2 partitions without LVM. LVM avoids the need to completely back up and restore a drive because the average user was not psychic enough to know how things should be laid out to be space efficient 2 years post install.
LVM allows you to leave lots of unused space so that you can use it where you need it when you need it without having to fuss with mount points and figuring out how to make the mount points integrate most effectively into your file system.
-=-
If I were to change Anaconda w/ respect to LVM - these are the changes I would make:
1) VolGroup00 would only be used as a last resort. It is better IMHO to name it after the hostname - IE Atlantis00
That avoids fstab issues (that also existed with the old LABEL=/mountpoint scheme)
However, Anaconda doesn't know the hostname before it sets up partitioning. So that suggestion belongs in the dock.
2) Should not default to one big LV
It should default when space allows to a 6GiB / and a 10GiB /home - and default to leaving the rest of the available PEs unused
3) Default PE size should IMHO be 4MB not 32MB. I know a larger PE means you can join lots of PVs into one massive VG but a VG should only span multiple PVs if you have a good hardware raid setup, so a smaller default PE size is probably better suited for most Fedora installs.
Michael A Peters wrote:
LVM allows easy resizing of partitions, something you can not safely do with ext2 partitions without LVM. LVM avoids the need to completely back up and restore a drive because the average user was not psychic enough to know how things should be laid out to be space efficient 2 years post install.
LVM allows you to leave lots of unused space so that you can use it where you need it when you need it without having to fuss with mount points and figuring out how to make the mount points integrate most effectively into your file system.
This is true, but it's a curious thing: these cures are for diseases caused by fragmenting the storage space into fixed closed partition-subworlds in the first place. You can get the same joy in your life by just having a single fully sized / partition and none of this complex stuff piled upon constricting stuff delivering nothing going on.
LVM has its uses, but since most machines I actually touch are laptops nowadays, it has no use at all in that scenario -- once you realize that you can "fix" your partitioned storage headaches by tossing your 1980's style partitions completely. Just say "no" to the "Real Admins Use Partitions" merchants.
-Andy
On Thu, 2007-02-15 at 15:50 +0000, Andy Green wrote:
Michael A Peters wrote:
LVM allows easy resizing of partitions, something you can not safely do with ext2 partitions without LVM. LVM avoids the need to completely back up and restore a drive because the average user was not psychic enough to know how things should be laid out to be space efficient 2 years post install.
LVM allows you to leave lots of unused space so that you can use it where you need it when you need it without having to fuss with mount points and figuring out how to make the mount points integrate most effectively into your file system.
This is true, but it's a curious thing: these cures are for diseases caused by fragmenting the storage space into fixed closed partition-subworlds in the first place. You can get the same joy in your life by just having a single fully sized / partition and none of this complex stuff piled upon constricting stuff delivering nothing going on.
Unfortunately there is no way to do a clean install while preserving some data if it is all one partition.
By using LVM I can make a separate /srv and /home and do clean installs when new versions of Fedora come out w/o needing to restore the data on those volumes from backup.
Clean installs are really preferable for me as I've had too many weird things result from doing upgrades. Especially when some packages change how configuration files in /etc should be written (IE apcupsd bit me that way once - since I had configured the file, updating rather than clean install resulted in a broken configuration as the old config file was preserved)
Michael A Peters wrote:
On Thu, 2007-02-15 at 15:50 +0000, Andy Green wrote:
Michael A Peters wrote:
LVM allows easy resizing of partitions, something you can not safely do with ext2 partitions without LVM. LVM avoids the need to completely back up and restore a drive because the average user was not psychic enough to know how things should be laid out to be space efficient 2 years post install.
LVM allows you to leave lots of unused space so that you can use it where you need it when you need it without having to fuss with mount points and figuring out how to make the mount points integrate most effectively into your file system.
This is true, but it's a curious thing: these cures are for diseases caused by fragmenting the storage space into fixed closed partition-subworlds in the first place. You can get the same joy in your life by just having a single fully sized / partition and none of this complex stuff piled upon constricting stuff delivering nothing going on.
Unfortunately there is no way to do a clean install while preserving some data if it is all one partition.
"No way?" I didn't try it, but booting to runlevel 1 and rm -rf /usr /boot before booting into the installation media for the "clean" install of FC(n+1) should get you to the same place. Without having to chafe on pointless restrictions and a huge workaround software stack between you and your storage during the 9 months between needing to do that.
Are there any other reasons to have partitions and LVM on boxes with one storage device and no possibility for internal expansion?
-Andy
On Thu, 2007-02-15 at 17:37 +0000, Andy Green wrote:
Michael A Peters wrote:
On Thu, 2007-02-15 at 15:50 +0000, Andy Green wrote:
Michael A Peters wrote:
LVM allows easy resizing of partitions, something you can not safely do with ext2 partitions without LVM. LVM avoids the need to completely back up and restore a drive because the average user was not psychic enough to know how things should be laid out to be space efficient 2 years post install.
LVM allows you to leave lots of unused space so that you can use it where you need it when you need it without having to fuss with mount points and figuring out how to make the mount points integrate most effectively into your file system.
This is true, but it's a curious thing: these cures are for diseases caused by fragmenting the storage space into fixed closed partition-subworlds in the first place. You can get the same joy in your life by just having a single fully sized / partition and none of this complex stuff piled upon constricting stuff delivering nothing going on.
Unfortunately there is no way to do a clean install while preserving some data if it is all one partition.
"No way?" I didn't try it, but booting to runlevel 1 and rm -rf /usr /boot before booting into the installation media for the "clean" install of FC(n+1) should get you to the same place.
If /usr/local is not a separate partition that is unmounted first, that would get you into some trouble. You probably would also want to wipe /etc and /var (though if you haven't moved apache, mysql, etc data to /srv first that may also get you into trouble with lost data)
Without having to chafe on pointless restrictions and a huge workaround software stack between you and your storage during the 9 months between needing to do that.
Are there any other reasons to have partitions and LVM on boxes with one storage device and no possibility for internal expansion?
I found in nice when installing TeXLive. Since TeXLive is self contained, I just created a new /texlive partition so I don't have to wipe it. I suppose though that such data would also be preserved if removing /usr /etc /var /lib /bin manually.
I would boot off a knoppix CD rather than boot into run level 1 to do it though if I was going to do that. For me, it's just easier to keep use separate logical volumes.
Another advantage of separate logical volumes / partitions - you can make a new partition to install the new OS into so you can boot into the old OS if you need to (IE when something critical is broken in new release). I do that on my desktop, but not my laptop. I don't install a new Fedora on my laptop until everything I need works on the Desktop.
Michael A Peters wrote:
"No way?" I didn't try it, but booting to runlevel 1 and rm -rf /usr /boot before booting into the installation media for the "clean" install of FC(n+1) should get you to the same place.
If /usr/local is not a separate partition that is unmounted first, that would get you into some trouble. You probably would also want to wipe /etc and /var (though if you haven't moved apache, mysql, etc data to /srv first that may also get you into trouble with lost data)
Fair enough, although the issues with what to keep and what to destroy down /var or /etc are the same if they are on their own partition or all on /. These are problems with trying to integrate a "clean install" concept into a living system rather than anything else. With the right list on the rm -rf line it will emulate whatever the partitioning would have achieved.
Are there any other reasons to have partitions and LVM on boxes with one storage device and no possibility for internal expansion?
I found in nice when installing TeXLive. Since TeXLive is self
Well I didn't know TeX was that difficult to handle it basically needed its own OS ;-)
Another advantage of separate logical volumes / partitions - you can make a new partition to install the new OS into so you can boot into the old OS if you need to (IE when something critical is broken in new release). I do that on my desktop, but not my laptop. I don't install a new Fedora on my laptop until everything I need works on the Desktop.
When I have to use the one Windows app that still needs XP, I do it in Vmware, without partitioning my storage device for it. If you want to install XP and Linux on the same drive without virtualization then I guess you have to make two partitions, but it doesn't make you fragment the linux one any further than / and swap.
-Andy
When I have to use the one Windows app that still needs XP, I do it in Vmware, without partitioning my storage device for it. If you want to install XP and Linux on the same drive without virtualization then I guess you have to make two partitions, but it doesn't make you fragment the linux one any further than / and swap.
I disagree. I think there are good reasons to have multiple linux partitions.
On my laptop I have one XP partition (lets ignore this). One /boot partition of 100M, two partitions of 10G and the rest (about 30G as /home)
Currently I have FC6 installed on one of the 10G partitions, using the /boot and /home partitions. The other 10G partition is mounted as /data and use for temp storage of this and that.
when a new FC comes along, say FC7, I will clear out /data, backup the current content of /boot and then do a clean install on that partition. During the install tjhe partition that FC6 mounts as /data is used as / (and the FC6 /parition mounted as say /fc6) .
After this, assuming the FC7 installed worked I can boot into my new clean FC7. I then, by hand add back to /boot the entries needed to boot to my old FC6 system.
After doing this I effectively have a triple boot system, winXP, FC6 and FC7.
Once I am happy FC7 is OK, I can delete FC6 and reuse that partition.
In you scheme, with one linux partition you cannoty do a clean FC7 install without first deleting FC6. What if FC7 does work in some way ? In my scheme I still have FC6 which I can go back to, whilst the problems with FC7 are fixed. With yours you do not.
I don't presently use LVM, mainly because it was not around when I first started using this system (FC1 or so). However, now I probably would as it would allow me to resize the partitions easily (for instance if I found 10G was not enough for /) something I cannot do at the moment with the standard partitions.
Chris
Chris Jones wrote:
I disagree. I think there are good reasons to have multiple linux partitions.
Okay...
In you scheme, with one linux partition you cannoty do a clean FC7 install without first deleting FC6. What if FC7 does work in some way ? In my scheme I still have FC6 which I can go back to, whilst the problems with FC7 are fixed. With yours you do not.
In the unlikely event I found myself with a system so trashed by a proposed later FC(n), I would simply nuke the dirs containing the bad OS and reinstall FC(n-1) doing a non-upgrade install.
I don't presently use LVM, mainly because it was not around when I first started using this system (FC1 or so). However, now I probably would as it would allow me to resize the partitions easily (for instance if I found 10G was not enough for /) something I cannot do at the moment with the standard partitions.
Yes, again this is only because you are using multiple Linux partitions though, which while you are welcome to it as a strategy and lifestyle choice, is a curious reason for LVM having such value as to be the global default, when for boxes that can only ever have one drive it is simpler to have one partition and no LVM and zero problems caused by artificial discontiguities in your storage.
-Andy
Hi
In the unlikely event I found myself with a system so trashed by a proposed later FC(n), I would simply nuke the dirs containing the bad OS and reinstall FC(n-1) doing a non-upgrade install.
At which point you *won't* have an FC(n-1) system the same as your previous one, since you will have lost all the various updates and system changes you had made :)
I don't presently use LVM, mainly because it was not around when I first started using this system (FC1 or so). However, now I probably would as it would allow me to resize the partitions easily (for instance if I found 10G was not enough for /) something I cannot do at the moment with the standard partitions.
Yes, again this is only because you are using multiple Linux partitions though, which while you are welcome to it as a strategy and lifestyle choice, is a curious reason for LVM having such value as to be the global default, when for boxes that can only ever have one drive it is simpler to have one partition and no LVM and zero problems caused by artificial discontiguities in your storage.
I guess we just disagree. To me is plain obvious that multiple partitions and LVM are good things, and I am glad it is by default what is used by the installer. I guess you disagree and that fine, good even, since if we all agreed on everything life would be much duller :)
Chris
Chris Jones wrote:
Hi
In the unlikely event I found myself with a system so trashed by a proposed later FC(n), I would simply nuke the dirs containing the bad OS and reinstall FC(n-1) doing a non-upgrade install.
At which point you *won't* have an FC(n-1) system the same as your previous one, since you will have lost all the various updates and system changes you had made :)
I will be able to keep all the "system changes" I choose: updates can be reapplied and a copy of cat /var/log/rpmpkgs will show me what else I need to recover. Keeping my home dir and the bulk of /var will mean it is of limited horror as well. However, I have been using Fedora since before FC1, only once did I get into a pickle that required nukage, that was trying to come off Development and back to the previous FCn.
I guess we just disagree. To me is plain obvious that multiple partitions and LVM are good things, and I am glad it is by default what is used by the installer. I guess you disagree and that fine, good even, since if we all agreed on everything life would be much duller :)
;-) I think you might come to disagree too if you get faced with a broken drive and are kept away from the filesystem by an LVM wrapper that is only there for reasons that are very esoteric indeed at that moment. Each to his own, but hopefully there is food for thought on this thread when it comes to giving advice to others.
-Andy
At which point you *won't* have an FC(n-1) system the same as your previous one, since you will have lost all the various updates and system changes you had made :)
I will be able to keep all the "system changes" I choose: updates can be reapplied and a copy of cat /var/log/rpmpkgs will show me what else I need to recover. Keeping my home dir and the bulk of /var will mean it is of limited horror as well. However, I have been using Fedora since before FC1, only once did I get into a pickle that required nukage, that was trying to come off Development and back to the previous FCn.
I also have never had to completely abandon any RH/FC(n) release (I also have been doing this for a while, since about RH8 on my current laptop I think) but several times I have found that whilst FC(n) ran OKish, not everything I needed worked straight away, such as X or wireless. The point when the kernel went from 2.4.X to 2.6.X was particularly interesting. This happened more in the early days when my hardware was relatively new - not so now. However, I still find it VERY useful to be able to live with 2 FC releases at the SAME time, whilst sorting out any problems with the newer one.
I guess we just disagree. To me is plain obvious that multiple partitions and LVM are good things, and I am glad it is by default what is used by the installer. I guess you disagree and that fine, good even, since if we all agreed on everything life would be much duller :)
;-) I think you might come to disagree too if you get faced with a broken drive and are kept away from the filesystem by an LVM wrapper that is only there for reasons that are very esoteric indeed at that moment.
I agree this is one potential downside to LVM, but personally I don't think this con out-weights the many pros, IMHO. ( Also I suspect eventually the tools will be developed to deal with this, as LVM becomes more widely used, so this con will become a non-issue, but this is just speculation... )
Each to his own, but hopefully there is food for thought on
this thread when it comes to giving advice to others.
Indeed. Let people read our comments and make up their own mind.
Chris
On Thu, 2007-02-15 at 17:37 +0000, Andy Green wrote:
Are there any other reasons to have partitions and LVM on boxes with one storage device and no possibility for internal expansion?
I don't see much point of using LVM on a PC that can't possibly have more than one hard drive, but partitions do still have their uses. You can mount certain things using file systems more efficient for the purpose, you can mount certain things with protective restrictions (such as noexec, nodev, etc.), and so on...
Tim wrote:
On Thu, 2007-02-15 at 17:37 +0000, Andy Green wrote:
Are there any other reasons to have partitions and LVM on boxes with one storage device and no possibility for internal expansion?
I don't see much point of using LVM on a PC that can't possibly have more than one hard drive, but partitions do still have their uses. You can mount certain things using file systems more efficient for the purpose, you can mount certain things with protective restrictions (such as noexec, nodev, etc.), and so on...
I guess that's a real benefit if you want to customize your fstab accordingly. But I also guess few users who have multi partitions are doing this. I think it is common mainly because it is the orthodoxy that admins with hair on their chest do it.
BTW I learnt on this list a year or two ago from someone that noexec can't be understood as generically stopping execution of anything from that mountpoint and can be a false comfort indeed. Try this:
$ cp /bin/ls . $ chmod -x ./ls $ ls -l ./ls -rw-r--r-- 1 user user 93560 Feb 16 11:01 ./ls $ ./ls bash: ./ls: Permission denied $ /lib/ld-linux.so.2 ./ls ...
/tmp isn't nodev by default either, but you can change that if you were hardening it all up I suppose. Point taken then, but it is pretty specialized and maybe not a reason for everyone to get LVM by default.
-Andy
Andy Green:
Are there any other reasons to have partitions and LVM on boxes with one storage device and no possibility for internal expansion?
Tim:
I don't see much point of using LVM on a PC that can't possibly have more than one hard drive, but partitions do still have their uses. You can mount certain things using file systems more efficient for the purpose, you can mount certain things with protective restrictions (such as noexec, nodev, etc.), and so on...
Andy Green:
I guess that's a real benefit if you want to customize your fstab accordingly. But I also guess few users who have multi partitions are doing this. I think it is common mainly because it is the orthodoxy that admins with hair on their chest do it.
The obvious other things, like mounting /boot, /usr, and so on, as read-only, puts one or two exploit vectors out the window, without ever having to mess with SELinux, as well. ;-) If you're of a similar vintage.
/tmp isn't nodev by default either, but you can change that if you were hardening it all up I suppose. Point taken then, but it is pretty specialized and maybe not a reason for everyone to get LVM by default.
I took things as being two questions... Using multiple partitions, rather than just one or two; with LVM being a separate issue (those partitions could be part of LVM or something else), and LVM being pointless on a system that could only have one drive, anyway (such as most laptops, and a lot of the small desktop cases).
Another issue against LVM is trying to repair a system if it goes wonky. If your first LVM drive goes wonky, everything else goes with it. And it doesn't seem ameniable to fsck. I was getting errors that seemed rather fatal, fsck couldn't help with the LVM disk. But I wiped and re-set up without LVM, and that disk drive passed all the error checks I could throw at it.
Then there's the fun and games of trying to put one LVM disk into another box to read stuff from the drive. Dealing with two like-named volume groups seems even worse that coping with like-named volume labels.
Then there's the fun and games of trying to put one LVM disk into another box to read stuff from the drive. Dealing with two like-named volume groups seems even worse that coping with like-named volume labels.
Been bitten by this too. I ended up putting the disk back in the box it came from and renaming the volume group from rootvg to <hostname>vg, which is a practice I've followed ever since.
Regards,
Chris
Andy Green wrote:
bash: ./ls: Permission denied $ /lib/ld-linux.so.2 ./ls ...
Try that on a rawhide system. There was a kernel bad which Linus finally fixed in the 2.6.19 (or .20?) kernels.
Partitions are terribly useful. There several useful mount flags:
noatime, noexec, nodev, nosuid
By using several partitions (I always have /, /boot, /tmp, /home, /var, /var/tmp, /usr) I have fine grained control over setting these flags without affecting existing programs.
This is in addition to have partitions like / and /boot on RAID1 partitions while not being burdened to do this for all the system.
If anything, people should use more partitions, not less.
Ulrich Drepper wrote:
Hi Ulrich -
Try that on a rawhide system. There was a kernel bad which Linus finally fixed in the 2.6.19 (or .20?) kernels.
It isn't "fixed" on the current FC6 2.6.19 kernel FWIW.
Partitions are terribly useful. There several useful mount flags:
noatime, noexec, nodev, nosuid
...
If anything, people should use more partitions, not less.
Why should fracturing your storage like a broken mirror have anything to do with application of what are basically ACLs. Why is smashing the mirror into more smaller pieces any kind of good idea. Partitions in the sense of reserving chunks of storage can only mean that you mismanage your storage in one section or another and run short. The only situation that is optimal is everything sharing a single allocation. It seems to me it is another "bad" that in order to get the granular ACL benefits you mention, for some reason you currently have to use a stupid static reservation scheme.
-Andy
Today Andy Green did spake thusly:
Ulrich Drepper wrote:
Hi Ulrich -
Try that on a rawhide system. There was a kernel bad which Linus finally fixed in the 2.6.19 (or .20?) kernels.
It isn't "fixed" on the current FC6 2.6.19 kernel FWIW.
Partitions are terribly useful. There several useful mount flags:
noatime, noexec, nodev, nosuid
...
If anything, people should use more partitions, not less.
Why should fracturing your storage like a broken mirror have anything to do with application of what are basically ACLs. Why is smashing the mirror into more smaller pieces any kind of good idea. Partitions in the sense of reserving chunks of storage can only mean that you mismanage your storage in one section or another and run short. The only situation that is optimal is everything sharing a single allocation. It seems to me it is another "bad" that in order to get the granular ACL benefits you mention, for some reason you currently have to use a stupid static reservation scheme.
If you have a runaway process that randomly creates a massive log on /var it won't hose the system.
Same for /tmp
If you decide to add another drive it's very easy.
If you wish to only allocate x amount of space to /home and be warned when you're running out of space it's also trivial.
It's easy to add another drive and move the partition.
It's far easier to do a clean install and keep all your data in your /home partition (for upgrades or if you're rooted)
In my case, I triple boot XP, Vista and FC6, I have a seperate partition for data that's writeable by all three OSen
Mostly, in my server, I have one partition per drive, as I'd not trust something like lvm not to eat all my data by mistake after an update...
Scott van Looy wrote:
If you have a runaway process that randomly creates a massive log on /var it won't hose the system.
If that runaway process isn't running as root, it won't hose your system anyway due to the 5% default ext2/3 root-only reservation.
Same for /tmp
See above. You can reboot into your broken system and clean it out -- and let's face it, it is a broken system if root processes are filling the filesystem. It's broken even if the filesystem has an artificial limit.
If you decide to add another drive it's very easy.
Yes, it's very easy to put both halves of the the single filesystem you unwisely stretched across two physical devices at twice the risk. LVM only makes sense when used on top of a raided substrate.
If you wish to only allocate x amount of space to /home and be warned when you're running out of space it's also trivial.
Yes, this system makes it trivial to keep running out of space in /home when you have plenty of space on the drive.
It's easy to add another drive and move the partition.
*shrug* I can move partitions.
It's far easier to do a clean install and keep all your data in your /home partition (for upgrades or if you're rooted)
Already covered in this thread: if you choose to worship the "clean install" god, it is no more difficult to boot into runlevel 1 (A <space> 1 <enter>) before the install and nuke the dirs you regard as deprecated. Less difficult than spending every day under the hammer of the pointless no-space-when-there-is-plenty demon.
In my case, I triple boot XP, Vista and FC6, I have a seperate partition for data that's writeable by all three OSen
Well, I don't: I just have a Fedora / partition, and I guess most users of Fedora are the same.
Mostly, in my server, I have one partition per drive, as I'd not trust something like lvm not to eat all my data by mistake after an update...
Sounds like we agree on something!
-Andy
Michael A Peters wrote:
On Wed, 2007-02-14 at 13:49 -0600, Mike McCarty wrote:
Bruno Wolff III wrote:
On Wed, Feb 14, 2007 at 20:17:30 +0100, bram bram@diomedia.be wrote:
Would it not be a good idea to add a checkbox in the installer wich says yes automic partitioning but no lvm.
I think doing the custom layout covers that case adequately. I think for the
No, it does not. The *default* install should not be something that is worse than useless to the *average* user.
The average user does not accidentally delete their home directory by incorrectly cut and paste into an xterm window.
I don't know how many times this statement has been proven wrong in my experience. I have had to restore many directory trees from "average users" accidentally putting a space where they intended a single directory name.
Yes, not by "cut and paste" but by typo.
The rest of the stuff you wrote is opinionated, hence not really arguable. You love LVM. I won't argue that. I won't allow statements of fact to stand unchallenged.
The average user clobbers all kinds of stuff. Most restores of data I have done have not been as a result of hardware failure, but of average users deleting something accidentally.
Mike
bram wrote:
I tossed FC4 when I discovered that it installs LVM by default. LVM is IMO worse than useless. I see no advantages for me, and I see problems (like yours, for example) looming in the future.
I would have to agree on this, for our servers we use freebsd because it does not have lvm and it's very easy to add drives etc. Would it not be a good idea to add a checkbox in the installer wich says yes automic partitioning but no lvm.
You can fiddle with the automatic partitioning choices in Anaconda, the last time I did it I recall I deleted the LVM line without deleting the ext3 stuff inside it, and with that one step it then was what I wanted, the ext3 part replaced the deleted LVM line without having to regenerate the ext3 part. So it is already pretty simple at install time IIRC to nuke LVM. Kickstart no doubt lets you automate that choice too.
LVM does have its uses binding really large storage arrays that are already raided. I made some large servers from 12 SATA drives like that. But I agree with both of you, I think you should have to select it at install time, not deselect it. I can see why people think they're doing a good deed there in the case someone adds another drive later, but they are also bringing pain into the world if you need to get down on the filesystem in a crisis, needless pain in the case of a laptop drive that will never be expanded with permanent storage. And even the good deed is questionable if the substrate was not raided to start with, the chance of destroying the entire filesystem increases with each drive you spread it over...
-Andy
Mike McCarty wrote:
Tod wrote:
[snip]
I got the loopback working and can see all the partitions in the image. Since its a volume managed device I'm now stuck. I can see the partitions but I can't think of how to get around the lvm part to mount them and see the actual contents. I'm not that lvm proficient quite yet.
I tossed FC4 when I discovered that it installs LVM by default. LVM is IMO worse than useless. I see no advantages for me, and I see problems (like yours, for example) looming in the future.
I for one like LVM. Until I can get multi-Terabyte drives, LVM is the best way to go. As with any issue, there are pros and cons. At least with LVM, I don't have to spend time moving this and that and linking drives around when things get full.
On 2/13/07, Tod tod@stthomasepc.org wrote:
I love cutting and pasting to and from my xterm. This time however I cut and pasted a preceding space from the directory name I was trying to rm -fr. Thus I ended up doing rm -fr ./ mydir. Goodbye home dir.
I quickly shut down and imaged the hard drive onto another server. Doing a little research I discovered I could mount the image using a loopback device. I wanted to try running foremost or some other tool to see what I could recover.
I got the loopback working and can see all the partitions in the image. Since its a volume managed device I'm now stuck. I can see the partitions but I can't think of how to get around the lvm part to mount them and see the actual contents. I'm not that lvm proficient quite yet.
Does anybody have any hits? Anybody maybe have some experience making this type of mistake and have some advice on trying to recover the data from it?
And yes, I am now in the process of implementing a backup system :(
TIA - Tod
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Hi Tod!
For what it is worth I get a lot of hits googling "Linux file recovery" or "Linux file recovery free" yields a lot of hits (too many). "Linux file recovery Helix" (Helix is a Knoppix based computer forensics distribution) results are also interesting.
Good Hunting!
Tod