Help needed with understanding PCLinuxOS boot process

[sling-shot]

I have seen posts by some members here of seeing a message "Cannot open file delete" during boot immediately after GRUB menu. For a few it seems to cause a long delay, while others have reported shorter delay. The only working solution for this is to verify the UUID of all partitions to see that they match properly in both menu.lst and fstab. But this does not work for all. And even if it works, it is a workaround and does not explain why.

Every message that appears on the screen during the boot sequence has to originate from some program. If we can completely detail the chain of command during boot, it might lead to some understanding.

An internet search for linux boot sequence throws up a lot of pages explaining the general working but it may not be relevant to PCLinuxOS completely. And they do not mention the exact package names involved.

The general idea of boot as per my current knowledge is BIOS > MBR > GRUB > Kernel > Init > Runlevel programs.

How to correlate these to the text that appears online in verbose mode?

I believe we see some text indicating that GRUB is active. Then we see GRUB menu. After that this cannot open file delete appears. Then other PCLinuxOS messages start appearing.

[kjpetrie]

This message is not the cause of the delay. It is a comment by some process that looks for a file somewhere called delete and is probably a programming error of some sort, but by the time the message appears the process has already stopped looking for it.

The delay is caused when a partition cannot be found, and is associated with the message "waiting for /dev/sdxn to appear" where x and n are the letter and number of the partition. This might occur before the / partition is mounted and therefore while the kernel is still operating with /boot/initrd.img as the file system.

The remedy, as you say, is to ensure the UUIDs specified in /etc/fstab match the actual UUIDs of the partitions (or specify the partitions in some other way such as a label). However, this applies to both /etc/stab in the / partition and /etc/fstab in initrd.img, which can only be changed by remaking the file to which initrd.img points after making all the other changes. Read the man page on mkinitrd for more details of that.

Hope this helps.

[sling-shot]

I had thought that it could be something like that. I have heard a statement that Everything is a file in Linux. From that I guessed that it could be Cannot open file delete.

In my case, I am not getting any "waiting for ..." message. Here I just get a blank screen for sometime following which cannot open file delete appears. There has not been a change in the UUIDs after the initial installation and I have verified that all entries are indeed correct.

Is it true that installing a new kernel does a similar thing like mkinitrd? I have installed the .pae.bfs  kernel recently and the message still appears.

What if we know the exact package which throws this error and then it may be possible to communicate with the author of the package and see if anything else could be found?

------------------------------

Could the actual boot sequence be enumerated as packages?
MBR > grub > grub-0.97-27pclos2011.src.rpm > ..... etc.

[kjpetrie]

Sounds as if you have something happening or waiting between grub and the loading of the kernel, or between the loading of the kernel and whatever produces that message, but I don't know what.

Making a new initrd is part of installing a kernel, as it has to fit the particular system in use so it can't be a pre-compiled binary.

I don't think the boot sequence relates to package. Grub is partly installed in the MBR and partly in /boot/grub. It reads menu.lst from /boot/grub/ and displays the menu. Then it waits for a selection and loads the kernel with the appropriate arguments passed. The kernel then searches for initrd.img and sets up what it needs to set up. Then it mounts the / partition and starts to execute "init", which configures the system further and then starts to call the boot scripts, which come from all sorts of packages.

[sling-shot]

Regarding the "cannot open file delete" I have found a new clue.

It is the first line which appears in boot.log. So we need to know which process starts writing boot.log.

The relation to package will be needed to try and see if this particular error message may be searched from source. (I believe this being a string, it should be there somewhere in the source.) and the source is there in the source packages.

I will remove the "quiet" option from menu.lst and see if it provides any further clues.

[TerryN]

The relation to package will be needed to try and see if this particular error message may be searched from source. (I believe this being a string, it should be there somewhere in the source.) and the source is there in the source packages.

We already know that the message is due to a problem in plymouth-theme-pclinuxos-1.1.10-2pclos2011 (and possibly other plymouth themes).  We also know that it is completely harmless which is why we are not devoting much time to tracking it down more precisely.

Doing such a string search on the source is unlikely to reveal anything useful as the message string is most likely something like "cannot open file: %s" (where the %s gets substituted with the file name) which will appear in thousands of packages.
 
Terry.

[sling-shot]

We already know that the message is due to a problem in plymouth-theme-pclinuxos-1.1.10-2pclos2011 (and possibly other plymouth themes).  We also know that it is completely harmless which is why we are not devoting much time to tracking it down more precisely.
...

Terry.

Terry,
Thanks for that information. There has been some discussion going on about this in the forum but this is the first time there has been any indication that it is known. So good

-------------------

After removing "quiet", I now see that my installation pauses at a line switching to clocksource tsc. A search for this indicates that it may also be due to some hardware / driver thing. They say that some more clues may be found in dmesg. I will look into that too and get back.

-------------------

May be we should have a "Known issues" page on the wiki to prevent the same things being discussed again and again.