* [linux-lvm] Removing a very old physical drive - revisited
@ 2009-10-27 17:27 Nicholas Robinson
2009-10-28 1:29 ` malahal
0 siblings, 1 reply; 9+ messages in thread
From: Nicholas Robinson @ 2009-10-27 17:27 UTC (permalink / raw)
To: linux-lvm
Like a moth to a flame, I am having another go at removing a physical
drive (30G) from my one and only volgroup.
I left it last night having recovered my system after pvmove created a
phantom lv that was too big to fit on the pv.
Tonight, I tried plugging a usb external 80G drive and doing a pvcreate
on it. This worked fine.
I then vgextended my volgroup to include this new device thinking the
free space would encourage pvmove to work and it would need to be in the
volgroup. This also appears to have worked.
Finally, the dreaded pvmove command that trashed my system last night.
At least it doesn't seem to have harmed anything tonight, but it still
hasn't worked. I've put a line of asterisks where I think the errors
are. Presumably, the second is a consequence of the first. Should I have
executed some dmsetup command before doing the pvmove as some googling
might suggest?
Thank you for any help you can give me.
Nick
# pvmove -vv /dev/sdb2 /dev/sda2
Setting global/locking_type to 1
File-based locking selected.
Setting global/locking_dir to /var/lock/lvm
Getting target version for mirror
Getting target version for mirror
Getting driver version
/dev/sdb2: lvm2 label detected
/dev/ram0: No label detected
/dev/dm-0: No label detected
/dev/ram1: No label detected
/dev/sda1: No label detected
/dev/dm-1: No label detected
/dev/ram2: No label detected
/dev/sda2: lvm2 label detected
/dev/ram3: No label detected
/dev/ram4: No label detected
/dev/ram5: No label detected
/dev/ram6: No label detected
/dev/ram7: No label detected
/dev/ram8: No label detected
/dev/ram9: No label detected
/dev/ram10: No label detected
/dev/ram11: No label detected
/dev/ram12: No label detected
/dev/ram13: No label detected
/dev/ram14: No label detected
/dev/ram15: No label detected
/dev/sdb1: No label detected
/dev/sdd1: No label detected
/dev/sdd2: No label detected
/dev/sdd3: lvm2 label detected
Finding volume group "VolGroup00"
Locking /var/lock/lvm/V_VolGroup00 WB
/dev/sdb2: lvm2 label detected
/dev/sda2: lvm2 label detected
/dev/sdd3: lvm2 label detected
Archiving volume group "VolGroup00" metadata (seqno 37).
Expiring archive /etc/lvm/archive/VolGroup00_00024.vg
Creating logical volume pvmove0
Inserting layer pvmove0 for segments of LogVol00 on /dev/sdb2
Inserting /dev/sdb2:0-856 of VolGroup00/LogVol00
Stack LogVol00:0[0] on LV pvmove0:0
Adding LogVol00:0 as an user of pvmove0
Inserting /dev/sdb2:887-887 of VolGroup00/LogVol00
Stack LogVol00:857[0] on LV pvmove0:857
Adding LogVol00:857 as an user of pvmove0
Moving 858 extents of logical volume VolGroup00/LogVol00
Inserting layer pvmove0 for segments of LogVol01 on /dev/sdb2
Locking LV
EdAJKPEfRrbzqXIS8XJAyjzthn0vqAOgLPxYrNE62mL8uhMs0OvZNIEWM6GlBD4E (R)
Finding volume group for uuid
EdAJKPEfRrbzqXIS8XJAyjzthn0vqAOgLPxYrNE62mL8uhMs0OvZNIEWM6GlBD4E
Found volume group "VolGroup00"
Updating volume group metadata
Locking LV
EdAJKPEfRrbzqXIS8XJAyjzthn0vqAOgLPxYrNE62mL8uhMs0OvZNIEWM6GlBD4E (W)
Finding volume group for uuid
EdAJKPEfRrbzqXIS8XJAyjzthn0vqAOgLPxYrNE62mL8uhMs0OvZNIEWM6GlBD4E
/dev/sdb2: lvm2 label detected
/dev/sda2: lvm2 label detected
/dev/sdd3: lvm2 label detected
Found volume group "VolGroup00"
Finding volume group for uuid
EdAJKPEfRrbzqXIS8XJAyjzthn0vqAOgLPxYrNE62mL8uhMs0OvZNIEWM6GlBD4E
Stack LogVol00:0[0] on LV pvmove0:0
Adding LogVol00:0 as an user of pvmove0
Stack LogVol00:857[0] on LV pvmove0:857
Adding LogVol00:857 as an user of pvmove0
Stack LogVol00:0[0] on LV pvmove0:0
Adding LogVol00:0 as an user of pvmove0
Stack LogVol00:857[0] on LV pvmove0:857
Adding LogVol00:857 as an user of pvmove0
Stack LogVol00:0[0] on LV pvmove0:0
Adding LogVol00:0 as an user of pvmove0
Stack LogVol00:857[0] on LV pvmove0:857
Adding LogVol00:857 as an user of pvmove0
Found volume group "VolGroup00"
/dev/sdb2: read_ahead is 256 sectors
Locking memory
Suspending VolGroup00-LogVol00 (253:0) with device flush
Locking LV
EdAJKPEfRrbzqXIS8XJAyjzthn0vqAOgo3NFX2qrFUu5HyCI5r7p0sFe2tWrcSHC (R)
Finding volume group for uuid
EdAJKPEfRrbzqXIS8XJAyjzthn0vqAOgo3NFX2qrFUu5HyCI5r7p0sFe2tWrcSHC
Stack LogVol00:0[0] on LV pvmove0:0
Adding LogVol00:0 as an user of pvmove0
Stack LogVol00:857[0] on LV pvmove0:857
Adding LogVol00:857 as an user of pvmove0
Stack LogVol00:0[0] on LV pvmove0:0
Adding LogVol00:0 as an user of pvmove0
Stack LogVol00:857[0] on LV pvmove0:857
Adding LogVol00:857 as an user of pvmove0
Stack LogVol00:0[0] on LV pvmove0:0
Adding LogVol00:0 as an user of pvmove0
Stack LogVol00:857[0] on LV pvmove0:857
Adding LogVol00:857 as an user of pvmove0
Found volume group "VolGroup00"
Setting activation/mirror_region_size to 512
Creating VolGroup00-pvmove0
Loading VolGroup00-pvmove0 table
**********************************************************************
device-mapper: reload ioctl failed: No such device or address
Temporary pvmove mirror activation failed.
Removing layer pvmove0 for segments of LogVol00
Remove LogVol00:0[0] from the top of LV pvmove0:0
LogVol00:0 is no longer a user of pvmove0
Remove LogVol00:857[0] from the top of LV pvmove0:857
LogVol00:857 is no longer a user of pvmove0
Removing layer pvmove0 for segments of LogVol01
Locking LV
EdAJKPEfRrbzqXIS8XJAyjzthn0vqAOgLPxYrNE62mL8uhMs0OvZNIEWM6GlBD4E (W)
Finding volume group for uuid
EdAJKPEfRrbzqXIS8XJAyjzthn0vqAOgLPxYrNE62mL8uhMs0OvZNIEWM6GlBD4E
/dev/sdb2: lvm2 label detected
/dev/sda2: lvm2 label detected
/dev/sdd3: lvm2 label detected
Stack LogVol00:0[0] on LV pvmove0:0
Adding LogVol00:0 as an user of pvmove0
Stack LogVol00:857[0] on LV pvmove0:857
Adding LogVol00:857 as an user of pvmove0
Stack LogVol00:0[0] on LV pvmove0:0
Adding LogVol00:0 as an user of pvmove0
Stack LogVol00:857[0] on LV pvmove0:857
Adding LogVol00:857 as an user of pvmove0
Stack LogVol00:0[0] on LV pvmove0:0
Adding LogVol00:0 as an user of pvmove0
Stack LogVol00:857[0] on LV pvmove0:857
Adding LogVol00:857 as an user of pvmove0
Found volume group "VolGroup00"
Finding volume group for uuid
EdAJKPEfRrbzqXIS8XJAyjzthn0vqAOgLPxYrNE62mL8uhMs0OvZNIEWM6GlBD4E
Found volume group "VolGroup00"
Locking LV
EdAJKPEfRrbzqXIS8XJAyjzthn0vqAOgo3NFX2qrFUu5HyCI5r7p0sFe2tWrcSHC (W)
Finding volume group for uuid
EdAJKPEfRrbzqXIS8XJAyjzthn0vqAOgo3NFX2qrFUu5HyCI5r7p0sFe2tWrcSHC
Stack LogVol00:0[0] on LV pvmove0:0
Adding LogVol00:0 as an user of pvmove0
Stack LogVol00:857[0] on LV pvmove0:857
Adding LogVol00:857 as an user of pvmove0
Stack LogVol00:0[0] on LV pvmove0:0
Adding LogVol00:0 as an user of pvmove0
Stack LogVol00:857[0] on LV pvmove0:857
Adding LogVol00:857 as an user of pvmove0
Stack LogVol00:0[0] on LV pvmove0:0
Adding LogVol00:0 as an user of pvmove0
Stack LogVol00:857[0] on LV pvmove0:857
Adding LogVol00:857 as an user of pvmove0
Found volume group "VolGroup00"
Finding volume group for uuid
EdAJKPEfRrbzqXIS8XJAyjzthn0vqAOgo3NFX2qrFUu5HyCI5r7p0sFe2tWrcSHC
Found volume group "VolGroup00"
Suspending VolGroup00-pvmove0 (253:2) with device flush
Unlocking LV
EdAJKPEfRrbzqXIS8XJAyjzthn0vqAOgo3NFX2qrFUu5HyCI5r7p0sFe2tWrcSHC
Finding volume group for uuid
EdAJKPEfRrbzqXIS8XJAyjzthn0vqAOgo3NFX2qrFUu5HyCI5r7p0sFe2tWrcSHC
Found volume group "VolGroup00"
Resuming VolGroup00-pvmove0 (253:2)
**********************************************************************
device-mapper: resume ioctl failed: Invalid argument
Unable to resume VolGroup00-pvmove0 (253:2)
Unlocking LV
EdAJKPEfRrbzqXIS8XJAyjzthn0vqAOgLPxYrNE62mL8uhMs0OvZNIEWM6GlBD4E
Finding volume group for uuid
EdAJKPEfRrbzqXIS8XJAyjzthn0vqAOgLPxYrNE62mL8uhMs0OvZNIEWM6GlBD4E
Found volume group "VolGroup00"
Getting target version for linear
Getting target version for striped
Loading VolGroup00-LogVol00 table
Resuming VolGroup00-LogVol00 (253:0)
Unlocking memory
Removing /dev/VolGroup00/LogVol00
Linking /dev/VolGroup00/LogVol00
-> /dev/mapper/VolGroup00-LogVol00
Locking LV
EdAJKPEfRrbzqXIS8XJAyjzthn0vqAOgo3NFX2qrFUu5HyCI5r7p0sFe2tWrcSHC (NL)
Finding volume group for uuid
EdAJKPEfRrbzqXIS8XJAyjzthn0vqAOgo3NFX2qrFUu5HyCI5r7p0sFe2tWrcSHC
Found volume group "VolGroup00"
Locking memory
Removing VolGroup00-pvmove0 (253:2)
Unlocking memory
Unlocking LV
EdAJKPEfRrbzqXIS8XJAyjzthn0vqAOgo3NFX2qrFUu5HyCI5r7p0sFe2tWrcSHC
Finding volume group for uuid
EdAJKPEfRrbzqXIS8XJAyjzthn0vqAOgo3NFX2qrFUu5HyCI5r7p0sFe2tWrcSHC
Found volume group "VolGroup00"
Removing temporary pvmove LV
Writing out final volume group after pvmove
Creating volume group backup "/etc/lvm/backup/VolGroup00" (seqno
40).
Creating volume group backup "/etc/lvm/backup/VolGroup00" (seqno
40).
Unlocking /var/lock/lvm/V_VolGroup00
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [linux-lvm] Removing a very old physical drive - revisited
2009-10-27 17:27 [linux-lvm] Removing a very old physical drive - revisited Nicholas Robinson
@ 2009-10-28 1:29 ` malahal
2009-10-28 7:17 ` Nicholas Robinson
0 siblings, 1 reply; 9+ messages in thread
From: malahal @ 2009-10-28 1:29 UTC (permalink / raw)
To: linux-lvm
Nicholas Robinson [npr@bottlehall.co.uk] wrote:
>
> Nick
>
> # pvmove -vv /dev/sdb2 /dev/sda2
You can just specify 'pvmove -vv /dev/sdb2' to allow it to allocate on
your new disk as well or you can do
'pvmove -vv /dev/sdb2 /dev/sda2 /dev/<yourNewPVname>' to allow it to
allocate on the new PV as well. What distro and what version of LVM and
device package are you using. Someone may help if you post it to
dm-devel mailing list.
Thanks, Malahal.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [linux-lvm] Removing a very old physical drive - revisited
2009-10-28 1:29 ` malahal
@ 2009-10-28 7:17 ` Nicholas Robinson
2009-10-28 16:07 ` malahal
0 siblings, 1 reply; 9+ messages in thread
From: Nicholas Robinson @ 2009-10-28 7:17 UTC (permalink / raw)
To: LVM general discussion and development
Hi Malahal
Thanks for your reply. I don't really want to use the new/temporary disc
long-term, it seems that pvmove needs space to create a mirror-lv whilst
it is working and it seemed possible that the original problem was that
this extra space wasn't there.
# pvscan
PV /dev/sdb2 VG VolGroup00 lvm2 [27.75 GB / 960.00 MB free]
PV /dev/sda2 VG VolGroup00 lvm2 [314.97 GB / 30.84 GB free]
PV /dev/sdd3 VG VolGroup00 lvm2 [52.50 GB / 52.50 GB free]
Total: 3 [395.22 GB] / in use: 3 [395.22 GB] / in no VG: 0 [0 ]
This shows that sda2 has enough PEs free to take sdb2 ultimately and
sdd3 should have enough space to hold any sensible mirror lv.
I am using an upgraded Fedora 11 installation (from Fedora 8 using
preupgrade) with lvm version
LVM version: 2.02.48 (2009-06-30)
Library version: 1.02.33 (2009-06-30)
Driver version: 4.14.0
I will try a posting to dm-devel as you suggest.
Thanks
Nick
On Tue, 2009-10-27 at 18:29 -0700, malahal@us.ibm.com wrote:
> Nicholas Robinson [npr@bottlehall.co.uk] wrote:
> >
> > Nick
> >
> > # pvmove -vv /dev/sdb2 /dev/sda2
>
> You can just specify 'pvmove -vv /dev/sdb2' to allow it to allocate on
> your new disk as well or you can do
> 'pvmove -vv /dev/sdb2 /dev/sda2 /dev/<yourNewPVname>' to allow it to
> allocate on the new PV as well. What distro and what version of LVM and
> device package are you using. Someone may help if you post it to
> dm-devel mailing list.
>
> Thanks, Malahal.
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [linux-lvm] Removing a very old physical drive - revisited
2009-10-28 7:17 ` Nicholas Robinson
@ 2009-10-28 16:07 ` malahal
2009-10-28 23:21 ` Nicholas Robinson
0 siblings, 1 reply; 9+ messages in thread
From: malahal @ 2009-10-28 16:07 UTC (permalink / raw)
To: linux-lvm
Nicholas Robinson [npr@bottlehall.co.uk] wrote:
> Hi Malahal
>
> Thanks for your reply. I don't really want to use the new/temporary disc
> long-term, it seems that pvmove needs space to create a mirror-lv whilst
> it is working and it seemed possible that the original problem was that
> this extra space wasn't there.
As far as I know, you don't need extra space. The temporary mirror is
created to copy the data. I believe, it creates a corelog mirror and
should NOT need extra space. Let us hope someone responds from the
dm-devel list!
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [linux-lvm] Removing a very old physical drive - revisited
2009-10-28 16:07 ` malahal
@ 2009-10-28 23:21 ` Nicholas Robinson
2009-10-29 4:01 ` Nicholas Robinson
0 siblings, 1 reply; 9+ messages in thread
From: Nicholas Robinson @ 2009-10-28 23:21 UTC (permalink / raw)
To: LVM general discussion and development
i haven't had any replies from dm-devel mailing list so I tried pvmove
onto my external usb drive - i.e.
pvmove /dev/sdb2 /dev/sdc3
It is working so far! So, the device-mapper error must refer
to /dev/sda2 rather than the source disc as I'd assumed. I'm not sure
where this will leave me. My guess is that trying to pvmove from the usb
drive to the new disc will give the same error.
I don't really want the usb drive hanging off the front of my server,
but it will be nice to get rid of the old disc. Maybe I'll just have to
buy a new disc.
Nick
On Wed, 2009-10-28 at 09:07 -0700, malahal@us.ibm.com wrote:
> Nicholas Robinson [npr@bottlehall.co.uk] wrote:
> > Hi Malahal
> >
> > Thanks for your reply. I don't really want to use the new/temporary disc
> > long-term, it seems that pvmove needs space to create a mirror-lv whilst
> > it is working and it seemed possible that the original problem was that
> > this extra space wasn't there.
>
> As far as I know, you don't need extra space. The temporary mirror is
> created to copy the data. I believe, it creates a corelog mirror and
> should NOT need extra space. Let us hope someone responds from the
> dm-devel list!
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [linux-lvm] Removing a very old physical drive - revisited
2009-10-28 23:21 ` Nicholas Robinson
@ 2009-10-29 4:01 ` Nicholas Robinson
2009-10-29 19:04 ` malahal
0 siblings, 1 reply; 9+ messages in thread
From: Nicholas Robinson @ 2009-10-29 4:01 UTC (permalink / raw)
To: LVM general discussion and development
The pvmove worked, I've moved the boot to the new disc, so my old disc
is now effectively redundant. The problem is that, as I suspected, I
can't pvmove off my usb drive!
I spotted these messages in /var/log/messages
Oct 29 03:44:06 oak kernel: device-mapper: table: device 8:2 too small
for target
Oct 29 03:44:06 oak kernel: device-mapper: table: 253:0: linear:
dm-linear: Device lookup failed
Oct 29 03:44:06 oak kernel: device-mapper: ioctl: error adding target to
table
Oct 29 03:46:15 oak kernel: device-mapper: table: device 8:2 too small
for target
Oct 29 03:46:15 oak kernel: device-mapper: table: 253:0: linear:
dm-linear: Device lookup failed
Oct 29 03:46:15 oak kernel: device-mapper: ioctl: error adding target to
table
They seem to occur whenever I do a pvmove involving my new disc - the
partition used in the volume group.
I have successfully removed and re-created the swap volume, just to see
if this might help. I hasn't!
# dmsetup table
VolGroup00-lv_swap: 0 1966080 linear 8:2 593887616
VolGroup00-LogVol00: 0 56229888 linear 8:35 384
VolGroup00-LogVol00: 56229888 593887232 linear 8:2 384
Nick
On Wed, 2009-10-28 at 23:21 +0000, Nicholas Robinson wrote:
> i haven't had any replies from dm-devel mailing list so I tried pvmove
> onto my external usb drive - i.e.
>
> pvmove /dev/sdb2 /dev/sdc3
>
> It is working so far! So, the device-mapper error must refer
> to /dev/sda2 rather than the source disc as I'd assumed. I'm not sure
> where this will leave me. My guess is that trying to pvmove from the usb
> drive to the new disc will give the same error.
>
> I don't really want the usb drive hanging off the front of my server,
> but it will be nice to get rid of the old disc. Maybe I'll just have to
> buy a new disc.
>
> Nick
>
> On Wed, 2009-10-28 at 09:07 -0700, malahal@us.ibm.com wrote:
> > Nicholas Robinson [npr@bottlehall.co.uk] wrote:
> > > Hi Malahal
> > >
> > > Thanks for your reply. I don't really want to use the new/temporary disc
> > > long-term, it seems that pvmove needs space to create a mirror-lv whilst
> > > it is working and it seemed possible that the original problem was that
> > > this extra space wasn't there.
> >
> > As far as I know, you don't need extra space. The temporary mirror is
> > created to copy the data. I believe, it creates a corelog mirror and
> > should NOT need extra space. Let us hope someone responds from the
> > dm-devel list!
> >
> > _______________________________________________
> > linux-lvm mailing list
> > linux-lvm@redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-lvm
> > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [linux-lvm] Removing a very old physical drive - revisited
2009-10-29 4:01 ` Nicholas Robinson
@ 2009-10-29 19:04 ` malahal
2009-10-30 1:48 ` Nicholas Robinson
0 siblings, 1 reply; 9+ messages in thread
From: malahal @ 2009-10-29 19:04 UTC (permalink / raw)
To: linux-lvm
Nicholas Robinson [npr@bottlehall.co.uk] wrote:
> The pvmove worked, I've moved the boot to the new disc, so my old disc
> is now effectively redundant. The problem is that, as I suspected, I
> can't pvmove off my usb drive!
>
> I spotted these messages in /var/log/messages
>
> Oct 29 03:44:06 oak kernel: device-mapper: table: device 8:2 too small
> for target
> Oct 29 03:44:06 oak kernel: device-mapper: table: 253:0: linear:
> dm-linear: Device lookup failed
> Oct 29 03:44:06 oak kernel: device-mapper: ioctl: error adding target to
> table
device 8:2 is /dev/sda2. Some one is trying to use /dev/sda2 with
incorrect values (start sector or length). This looks odd and this
happens only when you try 'pvmove' on the USB disk. What does the
pvdisplay on /dev/sda2 report its size (PV Size and is that accurate).
It maybe incorrect....
Thanks, Malahal.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [linux-lvm] Removing a very old physical drive - revisited
2009-10-29 19:04 ` malahal
@ 2009-10-30 1:48 ` Nicholas Robinson
2009-10-30 2:04 ` malahal
0 siblings, 1 reply; 9+ messages in thread
From: Nicholas Robinson @ 2009-10-30 1:48 UTC (permalink / raw)
To: LVM general discussion and development
On Thu, 2009-10-29 at 12:04 -0700, malahal@us.ibm.com wrote:
> Nicholas Robinson [npr@bottlehall.co.uk] wrote:
> > The pvmove worked, I've moved the boot to the new disc, so my old disc
> > is now effectively redundant. The problem is that, as I suspected, I
> > can't pvmove off my usb drive!
> >
> > I spotted these messages in /var/log/messages
> >
> > Oct 29 03:44:06 oak kernel: device-mapper: table: device 8:2 too small
> > for target
> > Oct 29 03:44:06 oak kernel: device-mapper: table: 253:0: linear:
> > dm-linear: Device lookup failed
> > Oct 29 03:44:06 oak kernel: device-mapper: ioctl: error adding target to
> > table
>
> device 8:2 is /dev/sda2. Some one is trying to use /dev/sda2 with
> incorrect values (start sector or length). This looks odd and this
> happens only when you try 'pvmove' on the USB disk. What does the
> pvdisplay on /dev/sda2 report its size (PV Size and is that accurate).
> It maybe incorrect....
>
> Thanks, Malahal.
>
Hi Malahal
In the absence of fixing the underlying problem, I've renamed the
volgroup and removed the 30GB disc that was the original aim of the
exercise! I thought I was getting somewhere, but now the server won't
boot by itself, I have to use a rescue disc and then chroot and start
the critical services manually. It is something to do with the change in
device name from /dev/sda to /dev/sdc, but I can't see why. It gets to
the point where it should be trying to mount the volgroup and then hangs
without any diagnostic. Everything looks okay in /etc/fstab.
I am confused about grub.conf as the (hd0,0) is wrong, given that
device.map lists /dev/sdc as hd1, but swapping grub.conf to specify
hd1,0 to match device.map fails with invalid disc or similar and using
map (...) statements to swap them over or changing device.map don't work
either.
I always used to think the biggest advantage of linux over windows was
that when it failed it told you why. It hasn't been too helpful in
recent days.
I think I will copy everything off the disc tomorrow, reinstall fedora
11 on it from scratch (having removed the usb drive!!!) and then
restore. Life's too short.
The total PE multiplied by the pe size looks right.
Thanks
Nick
[root@oak ~]# pvdisplay
--- Physical volume ---
PV Name /dev/sdc2
VG Name vg_oak
PV Size 315.00 GB / not usable 31.81 MB
Allocatable yes
PE Size (KByte) 32768
Total PE 10079
Free PE 987
Allocated PE 9092
PV UUID tXBnAO-0D0U-yLvg-XhaA-vEw3-Niz7-p23dAt
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [linux-lvm] Removing a very old physical drive - revisited
2009-10-30 1:48 ` Nicholas Robinson
@ 2009-10-30 2:04 ` malahal
0 siblings, 0 replies; 9+ messages in thread
From: malahal @ 2009-10-30 2:04 UTC (permalink / raw)
To: linux-lvm
Nicholas Robinson [npr@bottlehall.co.uk] wrote:
> Hi Malahal
>
> In the absence of fixing the underlying problem, I've renamed the
> volgroup and removed the 30GB disc that was the original aim of the
> exercise! I thought I was getting somewhere, but now the server won't
> boot by itself, I have to use a rescue disc and then chroot and start
> the critical services manually. It is something to do with the change in
> device name from /dev/sda to /dev/sdc, but I can't see why. It gets to
> the point where it should be trying to mount the volgroup and then hangs
> without any diagnostic. Everything looks okay in /etc/fstab.
>
> I am confused about grub.conf as the (hd0,0) is wrong, given that
> device.map lists /dev/sdc as hd1, but swapping grub.conf to specify
> hd1,0 to match device.map fails with invalid disc or similar and using
> map (...) statements to swap them over or changing device.map don't work
> either.
(hd0,0) is the first partition on the first disk found by your BIOS. It
maybe slightly different from how the OS sees the disks. Device.map is
generated by BIOS but it never uses it as far as I know. You can run
'grub' from shell and find out which disk has the 'boot' code.
> I always used to think the biggest advantage of linux over windows was
> that when it failed it told you why. It hasn't been too helpful in
> recent days.
The software tries to tell you why it failed if it failed. You seem to
be getting into a hang here and it is harder for the software to tell
you what went wrong. You have the option of changing the source code and
instrumenting in Linux if you know what to do. :-(
> I think I will copy everything off the disc tomorrow, reinstall fedora
> 11 on it from scratch (having removed the usb drive!!!) and then
> restore. Life's too short.
I agree.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2009-10-30 2:05 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-10-27 17:27 [linux-lvm] Removing a very old physical drive - revisited Nicholas Robinson
2009-10-28 1:29 ` malahal
2009-10-28 7:17 ` Nicholas Robinson
2009-10-28 16:07 ` malahal
2009-10-28 23:21 ` Nicholas Robinson
2009-10-29 4:01 ` Nicholas Robinson
2009-10-29 19:04 ` malahal
2009-10-30 1:48 ` Nicholas Robinson
2009-10-30 2:04 ` malahal
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).