This is the feedback thread for metalhedd's UN1: Partition Mounts Wrong. There's a lot of good dense information in there, metalhedd. I think it might benefit from some more descriptive and newbie-friendly phrasing. I'm still afraid that people who most often encounter this problem wouldn't necessarily be able to recognize themselves in here. Hopefully, you can edit your post in the FAQ forum. I tried to set it up so that anybody who has a post in there can edit it. If that doesn't work yet, please send me a PM.

More suggestions for improvement here wanted. I think this one has become the most common FAQ over the last couple of months, after klieber's aggressive campaign to stomp out the late-summer infestation of "Why can't I su to root?" reduced those significantly._________________For every higher wall, there is a taller ladder

Last edited by rac on Thu Dec 05, 2002 11:05 pm; edited 2 times in total

The difference between Windows and Linux/UNIX when it comes to initializing a new disk is the format step. Windows uses a program called format to actually write to every block on the disk or if you use the /Q switch, it will only re-write the directory aka the index of the disk.

Linux/UNIX uses a program ala mke2fs to initialize the disk. This program only writes to a few blocks on the disk. The information written is to the superblock (and several copies of the superblock are stored in different physical locations around the disk for redundancy) and an intial i-node structure. The superblock contains basic information about the disk and where the first i-node structure is located. The i-node structure is, in a simplified way, similar to the directory structure on a Windows disk.

The problem where you actually may see files that existed on the Windows formatted disk after re-partitioning and using mke2fs is most likely due to trying to mount the partition without specifying the type of the partition, i.e:

mount /dev/hda4 /home

This will cause the mount program to read the first few blocks of the partition in order to determine the type of the partition. In this case, mount finds information indicating it is a Windows disk, and mounts the disk as type vfat. Now when you do an ls of the mount-point (/home) you may or may not see files that existed when the disk was still a Windows disk. The only file that should exits on a newly created Linux/Unix disk is the lost+found directory.

Now to avoid seeing the old Windows directory, try to mount the partition as follows:
mount -t ext3 /dev/hda4 /home
This will tell the mount program to treat the partition as an ext3 type partition and the only file on this disk is the lost+found directory. The ext3 must reflect the type of file-system that you created on this disk, i.e it can be ext2, ext3, reiserfs, xfs or several other types.

Bottom line is:
Alway use the type specifier, -t, when mounting a partition. This will ensure you that the partition gets mounted with the correct format.

ebrostig, here's something I've never gotten a handle on about this problem: when the fstype is specified in /etc/fstab, and the partition is mounted automatically at startup, does it get mounted correctly? Can the ghost superblock data continue to cause problems? If so, then we really need to get people to zero it out before they put important data on it.

Say we have an infected hda1 that is destined for /boot. During the install the FAQ says "always use -t when mounting /mnt/gentoo/boot". So they do that, and everything looks OK. Then comes new kernel compilation time sometime down the road. User does "mount /boot". What happens?_________________For every higher wall, there is a taller ladder

Well, if you type "mount /boot", the /boot partition will be looked up in /etc/fstab, which presumably has the correct partition type. The problems would start if you did not have an entry for /boot in fstab.

If you didn't have an entry for /boot in fstab, then "mount /boot" wouldn't work because it wouldn't know which partition to mount there. Apologies if I'm reading too much into one word, but "presumably" worries me. If we're going to put this into a FAQ answer, I would prefer to have some concrete evidence from somebody who actually has experienced this problem and knows for sure whether having an entry in /etc/fstab is enough to overcome it._________________For every higher wall, there is a taller ladder

Can I just make a small request that however this gets published, we don't call it "sticky windows"? It sounds more like something that deals with pinning X-windows to a desktop or workspace than anything about boot sectors..._________________Linux user off and on since circa 1995

ebrostig, here's something I've never gotten a handle on about this problem: when the fstype is specified in /etc/fstab, and the partition is mounted automatically at startup, does it get mounted correctly?

Yes, the boot process reads the superblock from the disk before actually booting anything.

rac wrote:

Can the ghost superblock data continue to cause problems? If so, then we really need to get people to zero it out before they put important data on it.

Well, it is not a ghost superblock per se. The problem is that, and I really don't know why - I would have to look at the source for mount to find out, the disk is recognized as a vfat rather than ext2/ext3 partition.

It is not really necessary to zero out the disk prior to making a filesystem on it. It doesn''t hurt to do it, but it may take a long time to do.

rac wrote:

Say we have an infected hda1 that is destined for /boot. During the install the FAQ says "always use -t when mounting /mnt/gentoo/boot". So they do that, and everything looks OK. Then comes new kernel compilation time sometime down the road. User does "mount /boot". What happens?

He may actually see the incorrect directory entries, but then again he may not. It all depends on what is written where.

If your /etc/fstab is set correctly, all you need to do is:
mount /boot

This will read your /etc/fstab to see what needs to be mounted on /boot and find the correct partition type there.
Try it and you will see.

Can the ghost superblock data continue to cause problems? If so, then we really need to get people to zero it out before they put important data on it.

Well, it is not a ghost superblock per se. The problem is that, and I really don't know why - I would have to look at the source for mount to find out, the disk is recognized as a vfat rather than ext2/ext3 partition.

Since dd fixes it, but mkfs doesn't, that's why I thought it was ghost data in the superblock.

Quote:

It is not really necessary to zero out the disk prior to making a filesystem on it. It doesn''t hurt to do it, but it may take a long time to do.

As I understand the "ghost superblock" threads, once people's partitions get "infected", dd is the only thing that fixes it permanently. I could be misunderstanding, but that's the way I read it. Again, since I've never seen this firsthand, it's hard for me to say much of anything definitively.

Quote:

If your /etc/fstab is set correctly, all you need to do is:
mount /boot

This will read your /etc/fstab to see what needs to be mounted on /boot and find the correct partition type there.
Try it and you will see.

I understand that that's how it normally works. But I'm curious as to whether it really works that way for these people with infected partitions or not._________________For every higher wall, there is a taller ladder