Extra copies boot direcotry in /boot?

[leonardevens]

I am running Fedora 14, which I installed from scratch in a new computer.
ls -l /boot
shows a subdirectory also called boot and
ls -l /boot/boot
shows what appears to be a another copy of
grub
which is already in /boot.
It is not a symbolic link. It shows 14 of the 17 files in the /boot/grub.
All of these are identical to the same files in /boot/grub
with two exceptions
device.map in /boot/grub shows

# this device map was generated by anaconda
(hd0) /dev/sda
(hd1) /dev/sdb

while
device.map in /boot/boot/grub shows

(fd0) /dev/fd0
(hd0) /dev/sdaAlso the stage2 files differ.
(hd1) /dev/sdb

My machine doesn't have a /dev/fd0.

Also the stage2 files differ, Finally the /boot/boot/grub directory is missing three files
../boot/grub/grub.conf: No such file or directory
../boot/grub/menu.lst: No such file or directory
: ../boot/grub/splash.xpm.gz:
present in /boot/grub

Can anyone explain any of this?

When I did the install, I had a problem. The machine is dual boot with
Windows 7 on the first disk and Fedora 14 on the second disk. I intended to have the Windows boot loader do the booting, but I made a mistake during installation and set it up to use grub to boot. So I had to fix the MBR on the first disk and reinstall grub to reside entirely on the second disk. In that process I could conceivably have created /boot/boot/grub, but I don't remember anything like that happening at the time.
While doing this, I created a bootable grub CD to be sure I could get into Fedora.

Can I be reasonably confident that /boot/boot/grub is not doing anything? ( I have plenty of room in /boot so I can leave it there.)

[jpollard]

Not sure.

You would have a problem if the current boot block in the filesystem is pointing to the boot/boot/grub files rather than the files /boot/grub.

The worst thing to happen if you deleted these, is that you might need to use grub_install to make sure you have the files in /boot/grub.

Sometimes, nothing will happen, as the data that is needed (xx_stage_1.5) may be copied to boot area of the partition, but this is not mandatory, as sometimes only the block map is put in the boot and the data loaded from the map. This is why you might need to reinstall grub on the partition.

[leonardevens]

Originally Posted by jpollard

Not sure.

You would have a problem if the current boot block in the filesystem is pointing to the boot/boot/grub files rather than the files /boot/grub.

The worst thing to happen if you deleted these, is that you might need to use grub_install to make sure you have the files in /boot/grub.

Sometimes, nothing will happen, as the data that is needed (xx_stage_1.5) may be copied to boot area of the partition, but this is not mandatory, as sometimes only the block map is put in the boot and the data loaded from the map. This is why you might need to reinstall grub on the partition.

I don't think the boot block is pointing to the boot/boot/grub files, but how can I tell?

There is no grub.conf in that directory, which suggests that /boot/grub, which does have grub.conf, is what is being used.

[stoat]

I think you can try moving that extra /boot/boot subfolder somewhere (say, your home folder) leaving your normal /boot folder with kernel related files, and the normal /boot/grub subfolder with GRUB related files. Then reboot and see what happens. If Fedora boots, then delete the extra /boot/boot thing and everything in it. If it doesn't boot, then re-install GRUB using the grub-install command in rescue mode and try booting again. Here's why I think (but can't promise, of course) that will be okay...

First, you already said that /boot/boot/grub does not have grub.conf or the symlink menu.lst. Fedora cannot boot without grub.conf, so it's using the one in the normal location of /boot/grub.

Next, the device.map file has absolutely no role in booting. At all. In fact, Fedora can boot without a device.map file. Furthermore, it is recreated by certain GRUB shell and grub-install commands when one does not exist. So deleting the device.map file means even less than nothing and carries zero risk.

The stage2 that you said is different from the one in /boot/grub is potentially important because it is the only "stage" file in the /boot/grub folder that is actually involved in booting. However, even if this extra one is the one being used, and deleting it breaks the boot loader, the stage2 file is always recreated by the grub-install command. So this risk should be manageable.

Then all that remains are those various stage1_5 files. Those also have nothing to do with booting. Those are image files used by the GRUB shell when the GRUB boot loader is installed or re-installed and stage1.5 is installed as part of that. These stage1_5 image files also are completely regenerated every time GRUB is re-installed with the grub-install command. So these duplicates are useless and can be deleted with no risk.

So if your kernels and initial ram filesystem files and other kernel related files remain in /boot, and all of the usual GRUB related things remain in /boot/grub, then deleting that extra /boot/boot directory should cause no harm. And if it does (the stage2 thing), then stage2 will be recreated when you re-install GRUB with grub-install.

I believe what I just wrote based on countless experiments with the GRUB shell and its front-end script grub-install. And I wouldn't hesitate to clean up such mess, but I also am confident that I could fix any unexpected damage to my boot loader. However, only you can decide if deleting that extra /boot/boot directory of yours is best for you. And don't delete it until you accept the responsibility for any bad thing that happens.

[leonardevens]

Thanks for the response.

I think I know how this convoluted setup got created in the first place.

I remember now that I had a lot of trouble installing grub on the second disk and accessing it via EasyBCD iin windows 7 when I was setting up the machine.
See the thread entitled
"Trouble with grub-install"
for the details.

I did finally get it to work, and I think I can do it again if necessary, but I would rather avoid doing so unless I absolutely must. I think the extra /boot/boot/grub was created when I was trying to do it.

So I will leave things as they are since everything does work now.