Re: reiser4: mount -o remount,ro / causes error on reboot
On Mon, 11 Sep 2006 13:10:54 +0200, Sander Sweers wrote: snip... There was a bug in baselayout which caused partition (except /) not to remount ro properly. The bug number is 131001 [1], is this your problem? Greets Sander 1: http://bugs.gentoo.org/show_bug.cgi?id=131001 Thank you, I read that. My version of baselayout has that fix, but that does not appear to be the problem. I think it has more specifically to do with the way the remount option is affecting the reiser4 fs. And, only / is left when the remount,ro part comes anyway. Everything else is unmounted by that time. -- Peter + Do not reply to this email, it is a spam trap and not monitored. I can be reached via this list, or via jabber: pete4abw at jabber.org ICQ: 73676357
Re: reiser4: mount -o remount,ro / causes error on reboot
On Mon, 11 Sep 2006 11:30:39 +0400, Vladimir V. Saveliev wrote: snip... Sorry, I am confused. In the first mail you said: On reboot or after a poweroff, root does not mount properly, and after some modules are loaded, there are segfaults when running init scripts. This looks like you have problems on startup. Would you, please, describe the sequence of operations which leads to the problem with more details. I should have written that it occurs always after a normal shutdown or reboot. On initial startup, the error occurs. Then, after CTRL-D, the system reboots and all is fine. Then, after the day, normal shutdown, then abnormal startup. Some more information, I looked at the output from the final mount -v -n -o remont,ro / command, it appears perfectly normal. However, I am not sure it is working normally! -- Peter + Do not reply to this email, it is a spam trap and not monitored. I can be reached via this list, or via jabber: pete4abw at jabber.org ICQ: 73676357
Re: reiser4: mount -o remount,ro / causes error on reboot
On Sun, 10 Sep 2006 17:01:18 +, Peter wrote: Using: gentoo kernel 2.6.17.11 with beyond patchset reiser patch 2.6.17-3 reiser4progs 1.0.5 update... Transferring / to a reiser3 partition removes this problem. Shutdown and startup proceed normally. I am using util-linux-2.12r with gentoo patches -r4. This was updated on 9/4/06. I am thinking I will downgrade to -r3 and see if that removes the problem. -- Peter + Do not reply to this email, it is a spam trap and not monitored. I can be reached via this list, or via jabber: pete4abw at jabber.org ICQ: 73676357
Re: Reiser FS will not boot after crash
Hi, Sorry to take so long giving you a response. I did connect to the box as it crashed [via ssh]. There were no terminal messages [tail -f /var/log/messages]. This latest time an initial window for camorama was starting to open. You ask, Am I willing to help? debug the problem. Absolutely. [Linux has given so much to me!!] I reloaded camorama, so I should be able to reproduce the problem. The problem (not being able to boot) occurs frequently though not every time I run camorama. So my simple solution has been just to not run that program. This box has LILO on the master boot block. This chains to the Knoppix partition which has GRUB as the partition boot loader. As mentioned GRUB starts but then claims it finds an inconsistent filesystem. This repeats over and over until fsck.reiser is run on this partition from a different OS on a different partition. fsck.reiser replays the journal at first and then examines the filesystem and finds nothing wrong. I assume I am using the stock GRUB which Knoppix 5.0.1 installed since I haven't knowingly changed it? Perhaps the problem is simply that Knoppix installed an older version of GRUB ? john On Tue, 5 Sep 2006, Vladimir V. Saveliev wrote: Hello On Tuesday 05 September 2006 04:10, John M Harrison wrote: Hi, You make some good points. I wonder what the right fix is? I certainly think the user should not be stopped from booting and then get the inconsistent filesystem message over and over again as I do. Perhaps GRUB should offer to 'replay' the filesystem after discovering that the filesystem is inconsistent. I am not sure what other choices there are since the kernel and the initial boot filesystem are presumably not loadable? I looked at grub sources. It looks like it takes journal into account. It may have a bug, though. What version of grub do you have? Would you like to help to debug the problem? john On Tue, 5 Sep 2006, Vladimir V. Saveliev wrote: Hello On Tuesday 05 September 2006 00:30, [EMAIL PROTECTED] wrote: On Mon, 04 Sep 2006 23:33:27 +0400, Vladimir V. Saveliev said: after unclean shutdown journal reply is necessary to return reiserfs to consistent state. Maybe GRUB did not do that? A case can be made that GRUB should be keeping its grubby little paws off the filesystem journal. It's a *bootloader*. It's only purpose in life is to load other code that can make intelligent decisions about things like how (or even whether) to replay a filesystem journal. Yes, I did not say that grub has to replay a journal, I just tried to guess why grub failed to boot and why things went ok after fsck.
