[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#760553: debian-installer: changing from guided to manual with LVM results in corrupt LVM metadata



Package: debian-installer
Version: debian-7.6.0-amd64-netinst.iso
Severity: important

hi,

I've set Version: to the ISO I used for install as I'm not sure what version of
d-i that correlates to, nor whether this is a bug fixed since.

I recently performed an install and opted for guided - use LVM initially. When
presented with the results, I was not satisfied (I didn't want the entire
device filled up with a root LV - see also #651280) so I went back to manual and
started over: I deleted each LV and the partition housing the PV, then created a
new (smaller) partition for the LV and re-created the LVs.

The GPT partition table I ended up with is as follows

> Model: ATA ST1000LM024 HN-M (scsi)
> Disk /dev/sdb: 1000GB
> Sector size (logical/physical): 512B/4096B
> Partition Table: gpt
> Disk Flags: 
> 
> Number  Start   End     Size    File system  Name                  Flags
>  1      1049kB  512MB   511MB   fat32        EFI System Partition  boot, esp
>  2      512MB   768MB   256MB   ext2                               msftdata
>  3      768MB   10.8GB  10.0GB                                     lvm
>  4      10.8GB  10.9GB  132MB   fat16        FREEDOS               msftdata

Note that I created partition #4 via parted post-installation (an
experiment which failed: UEFI-boot for BIOS flashing is a no-go).

However, I have just noticed that the LVM volume has corrupt metadata:

> # vgs
>   VG      #PV #LV #SN Attr   VSize   VFree  
>   qusp_vg   1   2   0 wz--n- 930.80g 921.49g
> # pvs
>   PV                    VG      Fmt  Attr PSize   PFree  
>   /dev/sdb3             qusp_vg lvm2 a--  930.80g 921.49g

Note that the above shows that it thinks the PV is approx 1T in size,
but as parted shows, it's only ~10G.

I was just about to create a new LV but if I had done so, I believe it would
have started to overwrite partition #4 above and resulted in corruption.

'pvscan' didn't cure the issue, but 'pvresize' seems to have got things
to where they should be

> # pvresize /dev/sdb3
>  Physical volume "/dev/sdb3" changed
>  1 physical volume(s) resized / 0 physical volume(s) not resized

I think the problem appears to be within d-i/partman and handling of deleting PVs
or deleting partitions upon which PVs are stored.


Reply to: