[solved-sort of]can not open file delete

[houndhen]

I am running PCLOS KDE 32 bit 2012 updated to KDE 4.8.?

Booting takes  longer than it did before. Not sure when the problem started. Booting seems to hang with the gui bar at about 40% of the way across. When I hit the escape key I see the message "can not open file delete". It seems to take nearly 30 seconds before something else appears about not finding resume device and then the boot continues fine. I have read the thread at http://www.pclinuxos.com/forum/index.php?topic=102836.0;wap2 while looking for a possible solution.

Not sure how to capture the text completely during the boot process.

Here is my fstab file,

Code: [Select]

# Entry for /dev/sda9 :
LABEL=pclos / ext3 defaults 1 1
# Entry for /dev/sda7 :
UUID=2f8d3813-8770-4808-ba3a-53bcf99b7fc1 /home ext3 defaults,user_xattr 1 2
none /proc proc defaults 0 0
# Entry for /dev/sda5 :
UUID=5bbd1ab5-a494-4241-8794-7e208b477e98 swap swap defaults 0 0
none /dev/pts devpts defaults 0 0sda9 is the \ partition and sda7 is the \home partition.

Here is blkid command output concerning the three above partitions,

Code: [Select]

/sda9: LABEL="pclos" UUID="d0fa4cbd-1809-45f7-91dc-9a99230f4a0a" TYPE="ext3"
/dev/sda5: UUID="5bbd1ab5-a494-4241-8794-7e208b477e98" TYPE="swap"
/dev/sda7: LABEL="homeext3" UUID="2f8d3813-8770-4808-ba3a-53bcf99b7fc1" TYPE="ext3" SEC_TYPE="ext2"
How do I stop this 'can not open file delete' message that interrupts the boot process? Could it have something to do with the entry in my 'menu.lst'?
Here is the menu.lst entry to start PCLOS

Code: [Select]

title PCLOS KDE 4.8
root (hd0,8)
kernel /boot/vmlinuz BOOT_IMAGE=PCLOS_2011 root=LABEL=pclos quiet vmalloc=256M acpi=on resume=UUID=d00fbeb3-c183-4d0a-b3f5-7293f8008bf2 splash=silent vga=788
initrd (hd0,8)/boot/initrd.imgDoes the resume need to point to the swap partition? If so, why?

Lot of questions....

Thanks,
Harold

[sling-shot]

I do see the same message but it does not seem to affect booting much other than a momentary stoppage.
A basic Google search does not yield any concrete solution yet.

Suggested remedies include:
1. Verifying the UUIDs are indeed correct particularly related to swap.
2. Changing from UUID to LABEL reference in menu.lst
3. Changing to /dev/sdx style in menu.lst

No one actually seems to know the cause of that message yet.
Archie somewhere else in this forum hinted towards Plymouth but he was not sure about it.

[Just17]

It seems to take nearly 30 seconds before something else appears about not finding resume device and then the boot continues fine.

The 'resume device' is the Swap partition/s as specified in your /etc/fstab file.

It is likely that the UUID used is incorrect, either in  the /boot/grub/menu.lst file or /etc/fstab.

You can check the UUIDs of your partitions using the following command


blkid   -c   /dev/null


You might need to su to root to issue this command.

[Vorteggs]

Here's how some guy resolved a similar problem:

# /dev/sda3
#UUID=a2bc95ec-5fe4-4651-9ca5-7027344141e3 none   swap    sw 0      0

#Swap reference changed by me
/dev/sda3             none           swap           sw       0 0

He commented out in fstab the original line that is pointing to swap by UUID, and used new one with pointing by device.
https://lists.another distro.com/archives/kubuntu-users/2009-March/040836.html

Code: [Select]

https://lists.another distro.com/archives/kubuntu-users/2009-March/040836.html
 

Aha
Here you have it:
http://tinyurl.com/from-another-distro

[Just17]

Here's how some guy resolved a similar problem:

# /dev/sda3
#UUID=a2bc95ec-5fe4-4651-9ca5-7027344141e3 none   swap    sw 0      0

#Swap reference changed by me
/dev/sda3             none           swap           sw       0 0

He commented out in fstab the original line that is pointing to swap by UUID, and used new one with pointing by device.
https://lists.another distro.com/archives/kubuntu-users/2009-March/040836.html

Code: [Select]

https://lists.another distro.com/archives/kubuntu-users/2009-March/040836.html

IMO, he should have corrected the erroneous UUID 

[kjpetrie]

If I recall correctly, once menu.lst and fstab have been corrected, you might need to run mkinitrd so the system has the information immediately on boot before the file system drivers are loaded and the partitions mounted.

[houndhen]

thanks for all the replies. I will try some of the proposed solutions and post back. I realized upon looking at the uuids that they didn't match in the menu.lst and fstab. I will start there and also change the fstab line to use /dev/sda?

[Vorteggs]

I will start there and also change the fstab line to use /dev/sda

May be it's good you have one uniform way of addressing which is less confusing

If in the future you create a new or delete existing partition(s) before the partition in question, its number (e.g. /dev/sdan) will change for the system but leaving the old value in fstab, hence there would be mismatch again.
So you better try to correct the UUIDs as all other guys proposed.

By the way the partitions can have labels and system can find them by labels only AFAIK.
It doesn't matter if their UUID or device name (e.g. /dev/sd(x,n)) changes - the label remains the same and will change only by your action.
IIRC this is the old-polack's favourite way of partition addressing.

[houndhen]

Anything old-polack does is bound to be the best way.

I edited the menu.lst entry and fstab file and used /dev/sda5 instead of UUID for the swap partition. Upon boot after doing these I still get the (at least) 30 second delay with the message 'can not open file delete', but I no longer get the message about not finding the resume partition.

From what I gather from the posts that I have read, I will just wait and watch for a solution to 'can not open file delete' message. I can live with it. It just takes longer to boot.

[Vorteggs]

I suppose we are waiting for Old-Polack to say something.
At least I am waiting because he is the one to say

[Just17]

Anything old-polack does is bound to be the best way.

I edited the menu.lst entry and fstab file and used /dev/sda5 instead of UUID for the swap partition. Upon boot after doing these I still get the (at least) 30 second delay with the message 'can not open file delete', but I no longer get the message about not finding the resume partition.

From what I gather from the posts that I have read, I will just wait and watch for a solution to 'can not open file delete' message. I can live with it. It just takes longer to boot.

Your problem has nothing at all to do with that message.
It is the last message displayed before the delay.

IMO, you would be best advised to use UUIDs in fstab and menu.lst.
They are unique to the partitions regardless what device designation the OS gives the partition.
Also UUID is the default means of identifying the partitions.

kjpetrie already posted the last step to get rid of the delay ......  mkinitrd.

[bosko]

As someone that likes to keep many distros installed and try new ones frequently, I've run into this issue several times. When you install a distro that formats your swap file (not all do), the uuid changes, leading to the issue at hand. I make it a point to always use /dev/sd?? in fstab swap entries for this reason. Even with distros on 3 different drives, this has never caused an issue for me.

Also, if it wasn't made clear enough already, you need to rebuild your initrd after making the fstab change for the boot delay to disappear. I find that doing plymouth-set-default-theme -R your-theme-name-here (-R rebuilds the initrd image - use -l for a list of theme choices) is as easy as anything else and works across many distros with different mkinitrd type commands.

[Vorteggs]

I am running PCLOS KDE 32 bit 2012 updated to KDE 4.8.?

Booting takes  longer than it did before.

I am wondering is it booting or restoring the session from the previous hibernating?

[houndhen]

Also, if it wasn't made clear enough already, you need to rebuild your initrd after making the fstab change for the boot delay to disappear. I find that doing plymouth-set-default-theme -R your-theme-name-here (-R rebuilds the initrd image - use -l for a list of theme choices) is as easy as anything else and works across many distros with different mkinitrd type commands.

I understand that I should rebuild initrd but I don't understand how to do it from what you said. I would need simpler instructions before attempting to do so.

Edit
I just timed PCLOS boot from start to music after desktop appears and it takes 2 minutes. The only message that appears that seems to delay boot is 'cannot open file delete'.

[Just17]

Probably the easiest thing for you to do would be to install a new kernel through Synaptic.

Installing the new kernel will build an initrd file for the new kernel and you should have no delay in booting.

If the new kernel works properly with your hardware then you are OK.

You also then have the option to uninstall the existing kernel (while running from the new one), rebooting, and reinstall the older kernel again.


Else if you search for threads on the forum using  mkinitrd  you will find instructions how to create a new initrd for the existing kernel.

Essentially you rename the existing initrd, and then use the mkinitrd command from a terminal to create a new one. Then boot using the kernel with its new initrd ...  and the delay should be gone.