LinuxQuestions.org
Support LQ: Use code LQ3 and save $3 on Domain Registration
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - General
User Name
Password
Linux - General This Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.

Notices

Reply
 
LinkBack Search this Thread
Old 02-26-2006, 11:27 AM   #1
Moebius
Member
 
Registered: Dec 2002
Location: Milwaukee, WI
Distribution: Ubuntu, Kubuntu, Debian, CentOS
Posts: 216

Rep: Reputation: 30
FC4 partition is of type 'unknown'


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?

Last edited by Moebius; 02-26-2006 at 11:35 AM.
 
Old 02-26-2006, 11:34 AM   #2
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,345

Rep: Reputation: 1945Reputation: 1945Reputation: 1945Reputation: 1945Reputation: 1945Reputation: 1945Reputation: 1945Reputation: 1945Reputation: 1945Reputation: 1945Reputation: 1945
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.
 
Old 02-26-2006, 01:04 PM   #3
Moebius
Member
 
Registered: Dec 2002
Location: Milwaukee, WI
Distribution: Ubuntu, Kubuntu, Debian, CentOS
Posts: 216

Original Poster
Rep: Reputation: 30
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?

Last edited by Moebius; 02-26-2006 at 01:06 PM.
 
Old 02-26-2006, 01:21 PM   #4
haertig
Senior Member
 
Registered: Nov 2004
Distribution: Debian, Ubuntu, LinuxMint, Slackware, SysrescueCD
Posts: 1,950

Rep: Reputation: 279Reputation: 279Reputation: 279
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.

Last edited by haertig; 02-26-2006 at 01:27 PM.
 
Old 02-26-2006, 06:05 PM   #5
Moebius
Member
 
Registered: Dec 2002
Location: Milwaukee, WI
Distribution: Ubuntu, Kubuntu, Debian, CentOS
Posts: 216

Original Poster
Rep: Reputation: 30
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.
 
Old 02-26-2006, 07:05 PM   #6
haertig
Senior Member
 
Registered: Nov 2004
Distribution: Debian, Ubuntu, LinuxMint, Slackware, SysrescueCD
Posts: 1,950

Rep: Reputation: 279Reputation: 279Reputation: 279
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.
 
Old 02-26-2006, 08:01 PM   #7
Moebius
Member
 
Registered: Dec 2002
Location: Milwaukee, WI
Distribution: Ubuntu, Kubuntu, Debian, CentOS
Posts: 216

Original Poster
Rep: Reputation: 30
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?

Last edited by Moebius; 02-26-2006 at 08:02 PM.
 
Old 02-26-2006, 08:53 PM   #8
haertig
Senior Member
 
Registered: Nov 2004
Distribution: Debian, Ubuntu, LinuxMint, Slackware, SysrescueCD
Posts: 1,950

Rep: Reputation: 279Reputation: 279Reputation: 279
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.
 
Old 02-26-2006, 09:39 PM   #9
Moebius
Member
 
Registered: Dec 2002
Location: Milwaukee, WI
Distribution: Ubuntu, Kubuntu, Debian, CentOS
Posts: 216

Original Poster
Rep: Reputation: 30
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.
 
Old 02-26-2006, 11:25 PM   #10
haertig
Senior Member
 
Registered: Nov 2004
Distribution: Debian, Ubuntu, LinuxMint, Slackware, SysrescueCD
Posts: 1,950

Rep: Reputation: 279Reputation: 279Reputation: 279
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.
 
Old 02-27-2006, 12:12 AM   #11
Moebius
Member
 
Registered: Dec 2002
Location: Milwaukee, WI
Distribution: Ubuntu, Kubuntu, Debian, CentOS
Posts: 216

Original Poster
Rep: Reputation: 30
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.
 
Old 02-27-2006, 10:06 AM   #12
haertig
Senior Member
 
Registered: Nov 2004
Distribution: Debian, Ubuntu, LinuxMint, Slackware, SysrescueCD
Posts: 1,950

Rep: Reputation: 279Reputation: 279Reputation: 279
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
unknown monitor type clombard Red Hat 1 11-21-2005 01:36 PM
SSH unknown key type homestead1000 Linux - Software 1 01-13-2005 11:24 AM
Monitor type unknown richpri Fedora 4 12-30-2004 07:15 AM
root (hd 0,0)Filesystem type unknown, partition type 0x7chainloader +1 ece30675 Linux - Distributions 5 07-20-2004 09:04 AM
unknown terminal type BroX Linux - Networking 0 06-02-2004 04:04 AM


All times are GMT -5. The time now is 09:23 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration