[SOLVED] Recovering from possibly corrupted (by pvcreate) boot partition
Red HatThis forum is for the discussion of Red Hat Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Re-run those e2fsck commands, but this time include the "-f" option to force a check even though the super block appears clean. You didn't need that option the first time because the filesystem was obviously broken (missing super block).
You might just need to log out and back in again to get the list to refresh.
I logged out and the screen went black and stayed that way (which was pretty scary). So I went ahead and turned off the computer and started it up again. It appears to have booted up successfully. No problems so far. So it appears my greatest concern has been resolved. Thank you very much for your help with that.
But the Ubuntu system still does not show up under Places although it still appears to be seen by CentOS.
Code:
$ sudo fdisk -l
Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x8b8e8b8e
Device Boot Start End Blocks Id System
/dev/sda1 * 1 64 512000 83 Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2 5953 9730 30336001 5 Extended
/dev/sda3 64 5953 47300608 83 Linux
/dev/sda5 5953 9600 29296640 83 Linux
/dev/sda6 9601 9730 1038336 82 Linux swap / Solaris
Partition table entries are not in disk order
Quote:
Originally Posted by rknichols
If you want to make a separate partition for /tmp, you will need to use a tool like gparted to shrink one of your existing partitions to make space for a new one. You will need to boot from a rescue disk to do that since some of the operations cannot be done on a mounted filesystem. I recommend SystemRescueCD for that. Note that rearranging partitions is always a dangerous operation and should only be done with a full backup available.
Would that not make me end up another partition like I currently have for Ubuntu? Could I sacrifice Ubuntu and use its partition?
Thanks,
OH
Last edited by OtagoHarbour; 06-05-2014 at 09:39 PM.
OK, I did some experimenting, and I see what happened. The ext2/3/4 super block is at offset 1024 in the partition, and that was restored by e2fsck. But, that didn't touch the LVM physical volume label that is at offset 512. blkid is reporting the first signature it finds, which is LVM. Your GUI file manager is apparently seeing the same thing. The solution is to zero out that LVM label:
Please don't leave out that "count=1" parameter or you will wipe out the whole partition.
As for the manual mount command, you need to specify both the device and a mount point:
Code:
mount /dev/sda5 /mnt/tmp
That mount point must be an existing directory. If directory /mnt/tmp does not already exist, create it with mkdir.
As for the additional partition for /tmp, you did say that was your intent. You aren't using LVM, so an LV is out of the question and a partition is the only choice. Using the whole ~29GB sda5 partition for /tmp seems a bit excessive. Current practice seems to be moving toward putting /tmp on a tmpfs in RAM, limiting its expansion to perhaps 2GB. Your 80GB disk suggests that you have an older machine, perhaps without a lot of RAM to spare. What I would do is boot up SystemRescueCD, shrink sda3 by 2 or 3 GB, and use that space for a primary partition for /tmp. If you do want to sacrifice the Ubuntu partition, just delete it, create a 2 or 3 GB logical partition for /tmp, and have the remainder of the 29GB available for other use. Heck, if you want to play with LVM you could do what you did before running "pvcreate /dev/sda5" and recognize that you are wiping out the Ubuntu installation in the process. My concern about that is that it's not clear just which OS owns the sda1 boot partition. If that happens to be the Ubuntu installation, you would be left in the strange position of having your booting depend on some orphan files in sda1.
OK, I did some experimenting, and I see what happened. The ext2/3/4 super block is at offset 1024 in the partition, and that was restored by e2fsck. But, that didn't touch the LVM physical volume label that is at offset 512. blkid is reporting the first signature it finds, which is LVM. Your GUI file manager is apparently seeing the same thing. The solution is to zero out that LVM label:
Please don't leave out that "count=1" parameter or you will wipe out the whole partition.
That worked!!! Thanks very much. The Ubuntu partition came back and I did not have to do anything such as manually mount the disk or log out and log back in again. I rebooted the computer to make sure the boot partition is working rather than run the risk of its failing a couple of months from now. It rebooted fine! Thanks again for your help!
Quote:
Originally Posted by rknichols
As for the additional partition for /tmp, you did say that was your intent. You aren't using LVM, so an LV is out of the question and a partition is the only choice. Using the whole ~29GB sda5 partition for /tmp seems a bit excessive. Current practice seems to be moving toward putting /tmp on a tmpfs in RAM, limiting its expansion to perhaps 2GB. Your 80GB disk suggests that you have an older machine, perhaps without a lot of RAM to spare. What I would do is boot up SystemRescueCD, shrink sda3 by 2 or 3 GB, and use that space for a primary partition for /tmp. If you do want to sacrifice the Ubuntu partition, just delete it, create a 2 or 3 GB logical partition for /tmp, and have the remainder of the 29GB available for other use. Heck, if you want to play with LVM you could do what you did before running "pvcreate /dev/sda5" and recognize that you are wiping out the Ubuntu installation in the process. My concern about that is that it's not clear just which OS owns the sda1 boot partition. If that happens to be the Ubuntu installation, you would be left in the strange position of having your booting depend on some orphan files in sda1.
I bought the PC in 2001. One could buy PCs that lasted back then but they do admittedly lack some of the modern features. It does appear that most of the RAM is committed.
I understand that the units are kB so would that be 29 MB free? I'm not sure which process owns the boot partition. The PC initially ran Win XP. Then I installed Ubuntu on its current partition. This hardware cannot run newer versions of Ubuntu and it has become pretty well impossible to install anything except very old versions of SW on Ubuntu 11.4 (which is no longer supported) which is why I moved to CentOS. I installed CentOS on the partition that was housing Win XP. So it's difficult to tell which distribution owns the boot partition.
It seems the best thing to do is what you suggested with SystemRescueCD. One caveat is that I have never used it before. I did make a GParted CD and ran it although I forget whether I actually used it to modify partitions. I suspect I just used the CentOS installation CD to zap Win XP and install CentOS in its place.
You have just 1GB of RAM on that machine -- not enough to be putting /tmp there. FYI, the Linux kernel will always try to make use of all the RAM. See Linux Ate My Ram for more info.
Running gparted from SystemRescueCD will be just like running it from a GParted CD. I like SystemRescueCd because it includes a lot of other tools, such as testdisk and photorec, supports networking and a lot of common wireless cards, supports LUKS encrypted partitions, etc. I'm not familiar with what other tools might be on the GParted CD, but since you already have that, you can just go ahead an use it.
You have just 1GB of RAM on that machine -- not enough to be putting /tmp there. FYI, the Linux kernel will always try to make use of all the RAM. See Linux Ate My Ram for more info.
Running gparted from SystemRescueCD will be just like running it from a GParted CD. I like SystemRescueCd because it includes a lot of other tools, such as testdisk and photorec, supports networking and a lot of common wireless cards, supports LUKS encrypted partitions, etc. I'm not familiar with what other tools might be on the GParted CD, but since you already have that, you can just go ahead an use it.
I backed my partitions up with CloneZilla. When I went to format partition /dev/sda5 with GParted but it said that there was only 8 MB of disk space free. This was confirmed with df
Code:
$df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda3 46558184 4476040 39717116 11% /
tmpfs 511168 80 511088 1% /dev/shm
/dev/sda5 28836860 18324488 9047540 67% /media/bb3d8b8a-cdca-4398-8835-f26d928ed5de
and this was after I had deleted some files. But boabab only lists 4.6 GB of disk space that I am using on /media/bb3d8b8a-cdca-4398-8835-f26d928ed5de. It does not show where else I can delete files to make more room.
I don't know what "boabab" is (and, other than being the common name of a genus of trees, neither does Google), but that "4.6 GB" used looks suspiciously like the amount of used space in your root filesystem (4476040*1024 = 4583464960).
EDIT: OK, I found "Baobab" (not "boabab") is Ubuntu's disk usage analyzer.
What I would do is take 2 to 4 GB from your root filesystem, sda3, and use that space to make a new primary partition, sda4. That will put /tmp physically adjacent to your root filesystem rather than at the end of the disk on the most distant and lowest-performing cylinders.
Last edited by rknichols; 06-11-2014 at 08:52 AM.
Reason: Found "Baobab"
I don't know what "boabab" is (and, other than being the common name of a genus of trees, neither does Google), but that "4.6 GB" used looks suspiciously like the amount of used space in your root filesystem (4476040*1024 = 4583464960).
EDIT: OK, I found "Baobab" (not "boabab") is Ubuntu's disk usage analyzer.
What I would do is take 2 to 4 GB from your root filesystem, sda3, and use that space to make a new primary partition, sda4. That will put /tmp physically adjacent to your root filesystem rather than at the end of the disk on the most distant and lowest-performing cylinders.
Sorry about that. Should I make a separate partition for /home or just for /tmp?
That kind of depends on whether you plan on keeping your Ubuntu partition. Having a separate partition for /home can be nice when it comes time to do a major OS upgrade/reinstall since you can easily preserve /home. But if you want to keep that Ubuntu partition, that leaves you with just 47GB (less ~2GB for /tmp) for the OS on sda3, and that's just not enough space to further subdivide. You would have to make a decision on how big to make each filesystem, and however you decide it will almost certainly turn out to be wrong for something you try to do in the future.
If you are getting rid of the Ubuntu installation, by all means just use that 29GB sda5 partition for /home.
That kind of depends on whether you plan on keeping your Ubuntu partition. Having a separate partition for /home can be nice when it comes time to do a major OS upgrade/reinstall since you can easily preserve /home. But if you want to keep that Ubuntu partition, that leaves you with just 47GB (less ~2GB for /tmp) for the OS on sda3, and that's just not enough space to further subdivide. You would have to make a decision on how big to make each filesystem, and however you decide it will almost certainly turn out to be wrong for something you try to do in the future.
If you are getting rid of the Ubuntu installation, by all means just use that 29GB sda5 partition for /home.
Thank you very much for all your help. It seems that I have a fair amount of latitude. I am not that concerned about keeping the Ubuntu partition. At the same time, I have the latest version of CentOS and a c. 2001 PC so the computer will be about 20 years old when the CentOS support period ends. So I don't think I need to do a major system upgrade. I keep backing up the disk so I would probably just reinstall on the same partition or new disk. I was mainly concerned about a hacker filling up my disk. I will just partition part of sda3 for the /tmp directory, as you suggest, and maybe put /home on the Ubuntu partition. I will not be booting up into Ubuntu again on this PC.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
