lvm

[Peter Larsen]

On Sun, 2012-03-04 at 21:17 +0100, Reindl Harald wrote: 
> Am 04.03.2012 21:13, schrieb Peter Larsen:
> > Only on systems that are dual-booted does
> > partitions make sense. With Grub2 we can now have a single partition for
> > everything - and the reason we have the partition table is due to the
> > bios needs during boot.
> 
> is this a joke?

Nope.

> 
> you really want to install a OS and put systema nd data on the same
> partition? do this if you want but do not tell anybody this is a
> smart setup-design!

Have you looked at a Fedora installation since F12? That's the default
setup. Your full OS and home and /var and /lib etc. are all on the same
LVM physical partition. The only reason /boot is separate is due to
legacy grub didn't support ext3 or 4, and that some very old bios's have
some limitations on where the boot partition can be and what size it can
have. With grub2 we now can boot directly from an LVM or MD device -
there's no longer a need to separate system out.  I for one cannot get
why you distinguish between them. Whether the offset comes from a
partition table or an LVM map, the result is the same - it's located on
the same device and very very close to the root partition. 

> 
> if anything goes terrible wrong with your OS you want to care about
> your data? your decision! most people would not if they have
> any knowledge

Tell me how your data is separated from your OS - and remember to
include your logs, security settings, raid settings etc in that. They
all live on the same PARTITION on a standard Fedora install.

I think you're confusing a partition with a volume. 



-- 
Best Regards
  Peter Larsen

Wise words of the day:
Oh, I've seen copies [of Linux Journal] around the terminal room at The Labs.
	-- Dennis Ritchie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20120304/ee692ca9/attachment.sig>