UNIX for Advanced & Expert Users

Hi,

I have experienced a situation whereby after rebooting the server, we were not able to bring it up.
After further troubleshooting it was found that it was an issue with the "boot" image/file permission.
Have you experienced such an issue?

I was not the one who did the troubleshooting and the team that resolved the issue did not properly provide a report on
which were the boot files/images with the permission issue. Thus I do not know the name of the file.
Will you be able to provide the possibilities of the boot files that was affected?

The Operating System is Red Hat Enterprise Linux 5 (RHEL 5) and Red Hat Enterprise Linux 6 (RHEL 6)

Hi,

On most Linux systems, the /boot directory holds the files that the system needs in order to boot. Note that this is meant quite literally - it holds purely the files needed for booting, i.e. getting from the BIOS/EFI stage to the "the kernel is loaded and I'm starting process number one to do the rest" stage. So there's not much in here ordinarily, and seldom is there any need on a Red Hat-style system for you to ever change or modify the contents of this directory manually, or to even look at it at all to be honest.

The main files you'll find in here of interest are as follows:

/boot/config*
These files contain the configuration with which the kernel version specified in their filename was built. This is handy if ever you need to re-compile or re-build the same or a similar version of kernel, as you can get the configuration options used to build that kernel from here. Unless you're compiling kernels regularly, this is a file you'll never have to touch at all.

/boot/initrd*
These files are the initial RAM disks. Once the kernel loads, it generally is configured or passed by the boot loader the name of a RAM disk to load and mount. The main purpose of the initrd image is to hold modules and drivers that the kernel needs to initialise the rest of the system - most importantly, drivers for storage controllers and networking in particular, so that the system will be able to mount its root file system and carry on booting once the kernel startup is completed. Again, unless you are routinely building kernels or need to insert custom drivers into your kernel to get a working system, you won't need to (and shouldn't) touch these.

/boot/symvers-*
These files contain debugging symbols for the modules included with the version of the kernel specified in their filename. You might find this useful if you ever need to attach a debugger to your kernel or if a particular kernel module is having serious problems, but again for the day-to-day use of most servers for routine purposes, you'll never need to look at or touch this.

/boot/System.map*
These files contain the kernel symbol tables for the version of the kernel they're associated with. A symbol table is a list of symbols and the memory addresses that they're associated with. Again, unless you have to debug kernel panics or other similar failures, this has no day-to-day impact on your usage of the system, and can and should be left well alone.

/boot/vmlinuz-*
This is the big one (in more ways than one) - the kernel. The vmlinuz file is the Linux kernel, the heart of the operating system. This, plus the initrd, are the two files that your system needs more than any other to be readable and working in order to boot. Without a kernel and the RAM disk associated with that exact version of the kernel, you're probably not going to have a bootable system.

It's the boot loader configuration (usually GRUB) that tells the system which kernel and RAM disk to load, and which passes parameters to the kernel telling it key pieces of info about the system (i.e. where to find the root file system, and which process to execute to begin the system startup process).

As to how permissions problems could stop the system booting here - hard to say exactly without more info. But as a general rule of thumb: ensure that the /boot directory or filesystem always has plenty of free space, and on a RHEL-style system never manually mess with the contents of this directory unless you know exactly what you're doing and exactly why you have to do it.

Hope this helps ! If you have any further questions let me know and I'll see what I can do.