PDA

View Full Version : Very slow fedora 15 loading ... Recreate volatile files and directory...



SSMark
7th June 2011, 04:09 PM
Good afternoon,
my fedora 15 is very slow during the loading, at Recreate volatile files and directory... takes about 1 minute....

have anyone the same problem?

---------- Post added at 03:09 PM ---------- Previous post was at 02:57 PM ----------

Started Recreate Volatile Files and Directories.
Starting /dev/disk/by-uuid/e43d9130-4ffe-4ef6-9b95-edfbd9270bb8 ^[[1;31maborted^[[0m because a dependency failed.

John5342
7th June 2011, 05:43 PM
Systemd (the new init system in f15) starts multiple services at the same time rather than one after another so the last service listed is not necessarily the reason for the problems. The output of:
systemctl list-units --failed should give you a better idea of what unit actually failed and therefore where to investigate further.

snoze
7th June 2011, 05:55 PM
not only that type df in terminal you will get what you se

AceRoom
19th June 2011, 07:36 PM
I seem to be having the same problem. After installing, the first few times, this didn't happen. It started later. Did you manage to solve the problem and find out which process was slowing down the boot? Mine stalls at the same point but according to John about the new init, it might be any of the previous processes... Makes it tough to narrow it down :(

ramblinman
19th June 2011, 07:53 PM
Slow boots are also a symptom of a hard drive failing. I'm not saying yours is, but I have experienced it recently. Just food for thought...

jvillain
19th June 2011, 10:08 PM
I have hellacious boot times as well. One thing I found is that the is a /.relabel file put in on install. If you have selinux installed you can delete it as there is no need to relabel the file system every time you boot.

I don't know if you have seen this but you should give it a look.

http://0pointer.de/blog/projects/blame-game.html

John5342
19th June 2011, 10:26 PM
I seem to be having the same problem. After installing, the first few times, this didn't happen. It started later. Did you manage to solve the problem and find out which process was slowing down the boot? Mine stalls at the same point but according to John about the new init, it might be any of the previous processes... Makes it tough to narrow it down :(

My instructions should show you any units that have failed which actually makes it very easy to narrow down. My point about previous processes is referring to the information displayed during bootup. My command shows exactly what has actually failed. Of course if a unit has failed it may of course be as the result of another unit that may have failed before it but that should also be listed.

If no units have failed then it is probably just taking a long time. In the case of systemd-tmpfiles-setup.service it could for instance be due to disks taking a while to come online or filesystem checking. /tmp is if i remember right by default a tmpfs mount so if you have mounted an actual partition there that could slow it down or since tmpfs is backed by the swap partition so perhaps that is slow.

Another thing to note is that systemd starts a lot of services in parallel so if it is starting a lot of disk related services at once systemd-tmpfiles-setup.service may only appear to be running slowly because a lot of things are waiting for the harddisk.

AceRoom
20th June 2011, 06:58 AM
Thanks. That article is quite good. Will need to do some experimenting though. The two hints provided directly don't work as most of my partitions are logical and I don't have an extra home partition. I don't think it would be a hard disk failure as this is a brand new SATA harddisk.

@John, the command you suggested doesn't list any jobs. So if I understand correctly, that means none of the jobs have failed?

Actually, I noticed this really long delay after doing this:
I had both Fedora_i686 and x86_64. The 32 bit was on sda8, swap on sda9 and 64 bit on sda10 as I installed the 64 bit afterwards. Then I deleted the 32bit partition and changed the 64bit partition to be labeled sda8 and the swap to sda9. I modified menu.lst to boot into the 64 bit parition.

Oh wait, I just realized something while I was typing this out. Since I recreated the swap parition, the UUID has changed and I think during the boot, the older swap partition was trying to be mounted which of course doesn't exist. I just opened gparted and the new swap isn't mounted. I'll try changing that and checking it out.

---------- Post added at 11:28 AM ---------- Previous post was at 11:22 AM ----------

Yeah, that was the problem. Thanks a lot guys :)

Lesson well learnt ;)

The graph from systemd-analyze plot went from 99s to 25s! Which is what it was like before I messed around with the partitioning ;)

arunsfriend
27th July 2011, 06:49 PM
https://bugzilla.redhat.com/show_bug.cgi?id=694647

This is the work around

lcnsqr
14th September 2011, 07:07 PM
I went through this same problem and found that the cause was an invalid entry in /etc/fstab file. Removing it solved the problem completely.

fred108
12th November 2011, 10:43 AM
Thanks all, fixing up the fstab (swap) files worked for me too
Cheers

smr54
15th January 2012, 03:10 PM
I've found this to happen because, if adding a new install--say, with a multi boot, when the new install recreates swap it does something, I guess, to the UUID. I don't know enough about UUID to be sure of anything, save for the fact that

1. It will happen if I install another O/S on the machine that recreates the swap partition.
2. I can fix it by editing fstab in the way that one is no longer supposed to do , using /dev/sdxX for the swap partition.