FC4 partition is of type 'unknown'

Moebius · 02-26-2006, 11:27 AM

So I installed Fedora Core 4 on my extra 60GB hard drive as a second OS to windows. Now my windows drive is full and I'm only using like 10GB of the linux drive so I want to resize it and make half of it NTFS to use with windows. Problem is, when I use parted it says the partition type is unknown and it won't let me resize. The boot partition works fine however. They should both be ext3.

Code:

(parted) print
Disk geometry for /dev/hda: 0.000-57241.898 megabytes
Disk label type: msdos
Minor    Start       End     Type      Filesystem  Flags
1          0.031     99.914  primary   ext3        boot
2         99.914  57241.898  primary               lvm
(parted) resize 2 99.914 20000
Error: Could not detect file system.

And with fdisk:

Code:

Command (m for help): p

Disk /dev/hda: 60.0 GB, 60022480896 bytes
16 heads, 63 sectors/track, 116301 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1   *           1         203      102280+  83  Linux
/dev/hda2             204      116301    58513392   8e  Linux LVM

I've also tried Partition Magic in Windows and it gives me the same result.

Does FC4 do something strange and special with the partition tables? Does anyone else have this problem? What are my options for fixing it?

acid_kewpie · 02-26-2006, 11:34 AM

if it's the partition and not the filesystem, you can easily just change the type flag in fdisk. you won't endanger your data or anything.

Moebius · 02-26-2006, 01:04 PM

I supposed I should have looked into that LVM thing. Apparently Fedora Core uses Logical Volume Management ever since FC3 so thats why it doesn't understand it. I'm having a hell of a time trying to figure out how to reduce the partition (volume?), but it seems to be quite easy to expand it.

This is my understanding so far. I have to reduce the size of the file system inside the volume and then I can reduce the volume itself. Supposedly I can reduce the filesystem with this command, but it's only meant to work with ext2. What about ext3???

Code:

resize2fs /dev/my_vol_grp/my_logical_vol 1G

I tied using parted on /dev/my_vol_grp/my_logical_vol, but it wouldn't have any of that. So this is my first question - how do I reduce the size of an ext3 filesystem which is inside of a logical volume?

Then once that is reduced, I can reduce the size of the logical volume itself using:

Code:

lvreduce -L 1G /dev/my_vol_grp/my_logical_vol

Now the other trick is finding a live-CD from which I can do this, since I can't resize the filesystems that I'm currently running from. Apparently KNOPPIX forgot to include the LVM2 stuff so thats out. My second question is, then - what livecd or other trick can I use to resize these things that my system is installed on?

haertig · 02-26-2006, 01:21 PM

Be sure to backup your important Linux files before resizing things! Backup is recommended for any resizing tool on any OS platform.

Quote:

Originally Posted by Moebius

Apparently KNOPPIX forgot to include the LVM2 stuff so thats out.

From Knoppix, open a terminal window. Then:

Code:

$ su
# modprobe dm-mod
# apt-get update
# apt-get install lvm-common lvm2
# lndir /lib/lvm-200/ /usr/sbin/
# vgscan
# vgchange -a y

Now you have LVM2 on Knoppix.

[edit]
Changed the lndir command above to add trailing slashs after lvm-200 and sbin.
[/edit]

Alternately, Kanotix includes LVM2 already. I have had problems with Kanotix locking up on me several times whereas Knoppix has always been rock steady stable for me. YMMV.

Moebius · 02-26-2006, 06:05 PM

OK I think I got LVM working in knoppix, but I'm not able to resize the partition. resize2fs says it couldn't find a valid filesystem superblock.

Code:

root@0[knoppix]# vgscan
  Reading all physical volumes.  This may take a while...
  /dev/sdc: open failed: No medium found
  Found volume group "VolGroup00" using metadata type lvm2
root@0[knoppix]# vgchange -a y
  2 logical volume(s) in volume group "VolGroup00" now active
root@0[knoppix]# resize2fs /dev/VolGroup00/LogVol0 20G -p
resize2fs 1.38 (30-Jun-2005)
resize2fs: No such file or directory while trying to open /dev/VolGroup00/LogVol0
Couldn't find valid filesystem superblock.

haertig · 02-26-2006, 07:05 PM

Quote:

Originally Posted by Moebius

No such file or directory while trying to open /dev/VolGroup00/LogVol0

Is there a /dev/VolGroup00/LogVol0?

Code:

# ls -l /dev/VolGroup00/LogVol0

You may need to run vgmknodes if it's missing.

Moebius · 02-26-2006, 08:01 PM

OK, the problem was that /dev/VolGroup00/LogVol0 isn't the real location of it - its just a link to /dev/mapper/VolGroup00-LogVol00. But what I discovered is that there are actually two logical volumes. I'm not sure what the second one is and it's not /boot because that is an actual, proper partition at the front of the disk.

But I don't want to screw anything up, so when I resize the filesystem on the first logical volume and then resize the first logical volume itself, will it also move the starting location of the second logical volume? And that will create all the extra space in between?

haertig · 02-26-2006, 08:53 PM

Quote:

Originally Posted by Moebius

OK, the problem was that /dev/VolGroup00/LogVol0 isn't the real location of it - its just a link to /dev/mapper/VolGroup00-LogVol00.

That's not a problem ... that's normal.

Quote:

But what I discovered is that there are actually two logical volumes. I'm not sure what the second one is and it's not /boot because that is an actual, proper partition at the front of the disk.

Run lvdisplay to list all logical volumes. Then you can look in /etc/fstab to see where they are mounted (not the /etc/fstab that Knopix is using - that's only in ram - but the /etc/fstab on your harddisk.

Quote:

But I don't want to screw anything up, so when I resize the filesystem on the first logical volume and then resize the first logical volume itself, will it also move the starting location of the second logical volume? And that will create all the extra space in between?

I have not reduced any filesystems, LVs, VGs, or partitions personally so I can't give you any info or guarantees on this operation. I've expanded them many times, just never reduced. I'd consider reducing somewhat dangerous, and would want a backup first.

Moebius · 02-26-2006, 09:39 PM

OK, I've managed to reduce the size of the filesystem and the logical volume, but the volume group and physical volume are still their original size. I think what I have to do is run vgreduce, but its telling me that /dev/hda2 is still in use.

Code:

root@0[knoppix]# vgreduce VolGroup00 -v -a
    Finding volume group "VolGroup00"
  /dev/hdd: open failed: Read-only file system
    Using all physical volume(s) in volume group
  Physical volume "/dev/hda2" still in use

root@0[knoppix]# lvscan
  inactive          '/dev/VolGroup00/LogVol00' [20.81 GB] inherit
  inactive          '/dev/VolGroup00/LogVol01' [1.94 GB] inherit

root@0[knoppix]# lvdisplay
  --- Logical volume ---
  LV Name                /dev/VolGroup00/LogVol00
  VG Name                VolGroup00
  LV UUID                xPozGo-49ff-QRXI-tUKV-LYD2-gsDN-nnu3z1
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                20.81 GB
  Current LE             666
  Segments               1
  Allocation             inherit
  Read ahead sectors     0
  Block device           254:0

  --- Logical volume ---
  LV Name                /dev/VolGroup00/LogVol01
  VG Name                VolGroup00
  LV UUID                2e5ro2-GxLN-5qHM-ZE0N-qSZt-eQX0-bUrqlY
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                1.94 GB
  Current LE             62
  Segments               1
  Allocation             inherit
  Read ahead sectors     0
  Block device           254:1

root@0[knoppix]# vgdisplay
  --- Volume group ---
  VG Name               VolGroup00
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  6
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               55.78 GB
  PE Size               32.00 MB
  Total PE              1785
  Alloc PE / Size       728 / 22.75 GB
  Free  PE / Size       1057 / 33.03 GB
  VG UUID               pTb2y3-0LH7-VjE7-47Dt-0m7n-9veV-8EZoxP

The status on the volume group even says its resizeable. I found numerous references to being unable to reduce because physical extents were still in use, but google didn't seem to find much about the physical volume itself still being in use.

haertig · 02-26-2006, 11:25 PM

Quote:

Originally Posted by Moebius

The status on the volume group even says its resizeable. I found numerous references to being unable to reduce because physical extents were still in use, but google didn't seem to find much about the physical volume itself still being in use.

Uh oh. Now I see a problem. The only way you can resize a volume group is to remove one of it's (unused) physical volumes. The size of a volume group is the sum of the sizes of it's physical volumes. But if your volume group only has one physical volume, you can't remove that (unless it's empty, which is not your situation). That's why you're getting the error when you try vgreduce. The only PV you have is hda1, and it's not empty, so you can't remove it to shrink the VG.

This was the obvious end result when I look closedly at what you said in your very first post. Unfortunately I jumped in after the third post in the thread and started advising on how to reduce a logical volume, which is what you were asking at that point. I only skimmed your first post and failed to notice that you only have one PV, thus a vgreduce would not be possible.

Your only hope would be to shrink the PV. There is no LVM command to shrink a PV that I'm aware of. Nor am I aware of any external (non-LVM) commands the shrink the PV (partition). You've already noted that neither parted or Partition Magic know how to do it.

I've run out of ideas. I think you may be down to backing up your data stored on LVM, scrapping and recreating your PV's from scratch, and then restoring. Hopefully somebody else will weight in with a better solution.

Moebius · 02-27-2006, 12:12 AM

yeah I figured that out shortly after I posted last. It's just unbelieveable that no one would think of adding such a feature as resize to LVM. Almost every other partition/filesystem has that. And I can't imagine it would be a hard thing to do. In fact, I bet if Partition Magic or parted had enough motivation to do it, it could be just as easy as resizing any other partition.

In any case, I've given up and copied the important things and reformatted.

Thanks for the help, haertig.

haertig · 02-27-2006, 10:06 AM

Quote:

Originally Posted by Moebius

It's just unbelieveable that no one would think of adding such a feature as resize to LVM.

Probably because at some point you have to leave the logical world and move to the physical world. The LVM folks evidently did this at the physical volume layer. Most people probably consider a physical volume to be a physical harddisk. Since a physical disk can't be resized there is no pvresize command. You and I and many others have substituted partitions for harddisks at the PV layer. We are adding one more logical layer to what the designers planned for.