2014-03-16 9:40 GMT-06:00 Dale <rdalek1...@gmail.com>: > Jc García wrote: > > > Is there some way to avoid this in the future without disabling file >> system check for /? >> > > Again, maybe UUIDs. > > > I tried that once and grub didn't like it. May need to see if things have > improved in that area since. > > > For grub2 works fine for me, but the issue here was after grub had done its job, is the way dracut or more accurately the initrd, was trying to mount partitions before calling init. Not sure at all, but the fstab inside the initrd would have had something to do, so maybe, setting UUIDs in fstab and reconstructing the initrd, might prevent the issue from happening again.
> >> Another related LVM question. I have some partitions on LVM. If I >> moved the drives to another system, would the new LVMs be found on the >> new system or is there some magic involved to find and get them >> mounted? Example. My /home is on its own LVM partition. If I moved >> the drive that has that on it, would the new system see it or would I >> have to do something to make it see it? I suspect and wouldn't want it >> to mount automatically. I'd just want to be able to see it and mount it >> if needed. Sort of a question I have always wondered about. >> >> > > On my experience as long, as udev and lvm are running on the receiving > system, they should be found and placed for access under /dev, not mounted > automatically. > if for some reason it doesnt happen, its easy to do a 'pvscan' to see if > the physical volume is recognized, and if it is, 'vgchange -ay > volume_group_name ' activates all LVs. > > >> Thanks much. >> >> Dale >> >> :-) :-) >> >> > That's my thinking to but I have never had the chance to test it. I > figured the info is stored on the drive and moves wherever the drives goes > as long as LVM is running. > I think it's metadata stored in the PV. > > Thanks much. > > Dale > > :-) :-) > > -- > I am only responsible for what I said ... Not for what you understood or how > you interpreted my words! > >
