Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
1.Gradually I will add the physical partitions to LVM. Is it necessary to keep /boot on a physical partition? (That's what I read somewhere)
2. Also, I've been reading about RAID. Is it possible to include a NAS to a RAID array? At the moment my NAS works as an ftp server. If it is possible, would it make any sense in terms of file access/write speed (when compared to local drives)?
3. I just want to confirm: there's no way I could convert sda6 and sda7 to LVM without losing the data on them, is there?
Can I copy those partitions to LVM space?
(1) Far as I know, boot has to be on a partition lilo or grub can read, which doesn't include LVM, yet
(2) Interesting idea, I'm sure you could get mdadm to include (almost)anything on a RAID set, but I think you'd better allow for delay times on reads and writes. I'm thinking this is not a great idea though, if it's a backup plan. As I'm sure you know, RAID is not backup. But it might be fun.
(3) I don't see why you couldn't mount the LVM partitions as well as the other partitions separately and copy over whatever you want, including the whole file system, then add them to LVM. Of course you might be space constrained and have to use your backup. But maybe I'm not understanding the question.
(3) I don't see why you couldn't mount the LVM partitions as well as the other partitions separately and copy over whatever you want, including the whole file system, then add them to LVM. Of course you might be space constrained and have to use your backup. But maybe I'm not understanding the question.
So, I could copy my fedora on sda7 to a newly created logical volume. The only thing I'd have to do is to update grub entries.
vol1 / centos1 (with /boot partition outside lvm)
vol2 /usr centos1
vol3 /var centos1
vol5 /tmp centos1
vol4 /home centos1
vol5 swap
vol6 / fedora (the whole system on one partition - copied from sda6)
vol7 / centos2 (the whole system on one partition - copied from sda7)
free space ( used to be sda6 and 7)
Now I'm trying to update the grub on centos1 with no luck. Is there any way to boot fedora and centos2 or does EACH system have to have /boot partition outside LVM?
I apologize; I did not realize you wanted to multiboot off of one LVM system. Interesting, but I don't see why you can't make it work.
I wouldn't think you'd have to reinstall grub, just change the menu.ls
I think that the different distros could share a /boot partition, if you are very careful that their boot files such as the kernel and initrd are not over written by each other. So they'll each need a different name, like vmlinuz-centos, vmlinuz-fedora, initrd-fedora etc. then I'd setup menu.lst with a different entry for each with a different specification of root=/dev/whatever the approprate volume name is.
You might need to remake the initrds for each of the distros to make sure that LVM is started appropriately. I'm out of my depth on that one, as each distro seems to load its file system differently and allow modification of its initrd differently.
Last edited by mostlyharmless; 06-25-2008 at 11:30 AM.
The first instance of Centos works (that's the one with /boot outside of lvm)
In F9 and Centos2 I agree that:
Code:
root (hd0,1)
will return an error.
As you said, I'd have to share the /boot partition, however, what exactly would I have to do? Copy the files from fedora /boot to /boot on the first partition? (Obviously making sure that the names of the files are not overlapping). I don't really understand how it would work.
You copy over the files over to the /boot partition without the names overlapping. The menu.lst changes so that all of the entries have root(hd0,0); as I'm sure you know grub's "root" is just the place where it finds the kernel, and has nothing to do with the root file system.
The hard part is modifying the initrd of the non-LVM aware distros Fedora 9 and CentOS2; I would imagine that the initrd in your original CentOS sets up the LVM, finds the volumes and mounts them appropriately (/ on vol1 of the LVM, /boot on /dev/sda1 /usr on vol2 etc.). You will have to modify the other two initrds to do the same; ie. mount / on vol6 and vol7, respectively with /boot on /dev/sda1. I (kindof)know how to do that for Slackware, but I'm not familiar with the differences for the other two distros. If nothing else, I remember reading somewhere that there is a way to mount the cpio archive initrd.gz as a file system using the loop device, modifying it, and saving it, which might be easier than trying to rebuild it without the native OSes up and running.
thanks, however I messed it up big time I couldn't boot any of the systems. Although it was recoverable, I decided to sort out my laptop and perform fresh installations. As I upload every new file (docs, music, etc) to my NAS on a daily basis, I did not have any problem with data loss.
regards
sycamorex
Can I ask why you want to do this? You are probably going to have all sorts of fun when you do an update, and what's the benefit - a few fewer partitions?
The real benefit of LVM is that you can add new physical volumes in to a logical partition - ie increase a filesystem without additional mount points. You seem to be doing the opposite.
How many physical volumes are behind what you are doing?
I've already started the installation - it's my laptop - so I'm not likely to add any additional drives. However, as I appreciate the benefits of lvm, what I'm planning to do is to backup my main box and change the partition system to lvm (it makes much more sense on the main computer where I have a few drives)
Actually, I've got a question regarding installing new systems on lvm.
Provided that I have one /boot partition, I can then create LVM and install some distros (I'll mount /boot on the /boot without formatting the filesystem on /boot so that the files from different distros could coexist - the kernel files will probably not clash as centos 5.1, fedora 9, slackware 12.1 use different kernels 2.6.18, 2.6.25, 2.6.21 respectively. Is it going to work?
Well, it's like billymayday implied, the purpose of LVM, usually, is to combine physical volumes into a single filesystem without additional mount points. When you're installing different distros, you really want to keep their file systems separate. So while I don't think it'd be impossible to do what you plan, it might not be the best thing to try. Really, LVM isn't the issue here; the question is - can you install several distros on one file system and hide each of them from each other.
My vote: 4 distros = 4 partitions or more. If you want LVM for something else (say, LUKS encryption), each distro can do LVM on its own partition. Basically I'd treat each distro as its own OS, just as if you were installing Microsoft Windows and BSD and Solaris....
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.