You are not logged in.
Pages: 1
Topic closed
I just set up my /var on reiser4 again but i have a weird issue.
When i boot my 2.6.11-cko2 kernel it hangs at the "Removing Leftover Files" stage but it boots fine with 2.6.11-cko4 and boots fine with an old 2.6.9-nitro4.
So it can't be permissions can it? I used the same config for the -cko4 kernel as I used for -cko2 so they are configured the same.
And I can't just switch to -cko4 because that annoying cdrecord crash is back AGAIN!
Offline
i went for the middle ground and tried -cko3 - it boots and cdrecord works again - thank god
no idea what is wrong with -cko2?
anyone?
Offline
maybe it is a kernel oops, in which its probly just a bug that has since been squiished. if you think about it, removing files from /var are probably the first time its actually going to read and write from the /var partition.
If its only occuring with that kernel, then it has to be a kernel bug of some sort.
Either way, cdrecord is likely to be fixed in the next cko, they're pretty good with that stuff.
Offline
well, here's hoping iph - i like cko - it's my fav
Offline
The same thing happened to me and I have two diffrent kernels:
2.6.17.13 from www.kernel.org
and the one that comes whith arch-0.7.2-base.iso, i'm not shure what the version is...
I have solved the problem by repairing the filesystem whith:
fsck.reiserfs --rebuild-tree
good luck
Offline
It also hangs there for me sometimes. My /var directory is using reiserfs but if I restart the computer it usually gets past it the next time. A real fix would be great.
6EA3 F3F3 B908 2632 A9CB E931 D53A 0445 B47A 0DAB
Great things come in tar.xz packages.
Offline
I've got a new install (first time I've installed Arch, BTW -- and I'm fairly impressed) that is doing the same thing. My filesystems are ext3, for what that's worth. Usually when it hangs I can hard reboot the system and it will go past it on the restart, but I've had a couple of times where it has hung on consecutive boots. Would it be worth hacking that part of rc.sysinit to see if it is a specific step in the process that is causing the hang?
EDIT: I've gone ahead and added stat_busy/stat_done calls around each of the steps in that part of the boot process in rc.sysinit, as of late yesterday to see if there is any consistency on where the hang occurs. Interestingly -- or not, perhaps, I haven't had it hang yet... I'll keep an eye on it, and post more if I see a pattern.
Last edited by rps63ifid (2008-08-03 13:34:04)
Offline
As a follow-up to this thread: I did add stat_busy/stat_done calls around each of the steps in rc.sysinit. After watching this for a week, every instance where the boot process hangs has been on the 6th step, which reads:
(cd /var/run && /usr/bin/find . ! -type d -exec /bin/rm -f -- {} \; )
: > /var/run/utmp
Any thoughts on why that would hang things up? Any chance this has been resolved in the new kernel that appears to have hit the repos over the weekend?
Offline
It's back... hadn't seen it since upgrading to the 2.6.26 kernels, but with the 2.6.26.3-1 kernel that showed up in the updates this morning, I've my first hang on this same step of the boot process.
Anyone have any ideas what's causing this?
Offline
Also happened to me on ext2 filesystem with the newest kernel (2.6.26).
Linux user #403491
"Men have called me mad; but the question is not yet settled, whether madness is or is not the loftiest intelligence– whether much that is glorious– whether all that is profound– does not spring from disease of thought– from moods of mind exalted at the expense of the general intellect." - E. A. Poe from Eleonora
Offline
this happened to me too, on my notebook, kernel 2.6.27.8-1
in fact / get corrupted baddly... Ill be reinstalling arch soon
edit: btw, I was using ext3
Last edited by luuuciano (2008-12-21 21:00:35)
I arch, you arch, he arch, she arch, we arch, they arch...
Offline
5 years later and it's still a bug. 2.6.32 kernel with ext2 boot, and xfs root
Offline
Offline
Pages: 1
Topic closed