Hi all
When i tried kernel 2.6.15.4, i noticed i cant boot it, i get
"warning: cannot open initial console" then it reboots. I've searched
for it and found the breakage occurs from 2.6.15.1 to 2.6.15.2
Before i start to bisect to find the culpirit, and as there were few
changes, anyone has a good guess about what broke it?
Thanks all in advance.
On 2/22/06, Matheus Izvekov <[email protected]> wrote:
> Hi all
>
> When i tried kernel 2.6.15.4, i noticed i cant boot it, i get
> "warning: cannot open initial console" then it reboots. I've searched
> for it and found the breakage occurs from 2.6.15.1 to 2.6.15.2
>
> Before i start to bisect to find the culpirit, and as there were few
> changes, anyone has a good guess about what broke it?
>
> Thanks all in advance.
>
Actually, i dont even know what git tree i should be using for this...
How can i get the individual patches for the 2.6.15.1 -> 2.6.15.2 transition?
On Thu, Feb 23, 2006 at 02:27:30AM -0300, Matheus Izvekov wrote:
> On 2/22/06, Matheus Izvekov <[email protected]> wrote:
> > Hi all
> >
> > When i tried kernel 2.6.15.4, i noticed i cant boot it, i get
> > "warning: cannot open initial console" then it reboots. I've searched
> > for it and found the breakage occurs from 2.6.15.1 to 2.6.15.2
> >
> > Before i start to bisect to find the culpirit, and as there were few
> > changes, anyone has a good guess about what broke it?
> >
> > Thanks all in advance.
> >
>
> Actually, i dont even know what git tree i should be using for this...
> How can i get the individual patches for the 2.6.15.1 -> 2.6.15.2 transition?
http://www.<country>.kernel.org/pub/linux/kernel/v2.6/incr/
Willy
Hi.
On Thursday 23 February 2006 12:18, Matheus Izvekov wrote:
> Hi all
>
> When i tried kernel 2.6.15.4, i noticed i cant boot it, i get
> "warning: cannot open initial console" then it reboots. I've searched
> for it and found the breakage occurs from 2.6.15.1 to 2.6.15.2
>
> Before i start to bisect to find the culpirit, and as there were few
> changes, anyone has a good guess about what broke it?
My guess would be that /dev/console doesn't exist on an initrd/initramfs
you're using. If you're not using one, my second guess would be that
something did a nasty and deleted the node on you. Only a guess, mind you.
Regards,
Nigel
> Thanks all in advance.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On 2/22/06, Matheus Izvekov <[email protected]> wrote:
> Hi all
>
> When i tried kernel 2.6.15.4, i noticed i cant boot it, i get
> "warning: cannot open initial console" then it reboots. I've searched
> for it and found the breakage occurs from 2.6.15.1 to 2.6.15.2
>
> Before i start to bisect to find the culpirit, and as there were few
> changes, anyone has a good guess about what broke it?
>
> Thanks all in advance.
>
Found the bad patch by reversing by hand.
diff --git a/fs/reiserfs/super.c b/fs/reiserfs/super.c
index 42afb5b..9c38f10 100644
--- a/fs/reiserfs/super.c
+++ b/fs/reiserfs/super.c
@@ -1131,7 +1131,7 @@ static void handle_attrs(struct super_bl
REISERFS_SB(s)->s_mount_opt &= ~(1 << REISERFS_ATTRS);
}
} else if (le32_to_cpu(rs->s_flags) & reiserfs_attrs_cleared) {
- REISERFS_SB(s)->s_mount_opt |= REISERFS_ATTRS;
+ REISERFS_SB(s)->s_mount_opt |= (1 << REISERFS_ATTRS);
}
}
Reversing this fixes the problem, double checked it. What was that
patch supposed to do anyway?
On 2/23/06, Matheus Izvekov <[email protected]> wrote:
> On 2/22/06, Matheus Izvekov <[email protected]> wrote:
> > Hi all
> >
> > When i tried kernel 2.6.15.4, i noticed i cant boot it, i get
> > "warning: cannot open initial console" then it reboots. I've searched
> > for it and found the breakage occurs from 2.6.15.1 to 2.6.15.2
> >
> > Before i start to bisect to find the culpirit, and as there were few
> > changes, anyone has a good guess about what broke it?
> >
> > Thanks all in advance.
> >
>
> Found the bad patch by reversing by hand.
>
> diff --git a/fs/reiserfs/super.c b/fs/reiserfs/super.c
> index 42afb5b..9c38f10 100644
> --- a/fs/reiserfs/super.c
> +++ b/fs/reiserfs/super.c
> @@ -1131,7 +1131,7 @@ static void handle_attrs(struct super_bl
> REISERFS_SB(s)->s_mount_opt &= ~(1 << REISERFS_ATTRS);
> }
> } else if (le32_to_cpu(rs->s_flags) & reiserfs_attrs_cleared) {
> - REISERFS_SB(s)->s_mount_opt |= REISERFS_ATTRS;
> + REISERFS_SB(s)->s_mount_opt |= (1 << REISERFS_ATTRS);
> }
> }
>
> Reversing this fixes the problem, double checked it. What was that
> patch supposed to do anyway?
>
Adding Vitaly Fertman to this thread, as he is the one who seems to
have submitted that patch.
* Matheus Izvekov ([email protected]) wrote:
> On 2/23/06, Matheus Izvekov <[email protected]> wrote:
> > On 2/22/06, Matheus Izvekov <[email protected]> wrote:
> > } else if (le32_to_cpu(rs->s_flags) & reiserfs_attrs_cleared) {
> > - REISERFS_SB(s)->s_mount_opt |= REISERFS_ATTRS;
> > + REISERFS_SB(s)->s_mount_opt |= (1 << REISERFS_ATTRS);
> > }
> > }
> >
> > Reversing this fixes the problem, double checked it. What was that
> > patch supposed to do anyway?
>
> Adding Vitaly Fertman to this thread, as he is the one who seems to
> have submitted that patch.
It's attempting to properly automatically enable a reiserfs feature
supporting attributes (via chattr/lsattr interface). When mounting
(w/out attrs mount option) a reiserfs that should support attrs, the
above patch fixes the value OR'd with s_mount_opt (which was incorrectly
the shift value rather than the shifted value). This has been backed
out in current -stable queue, and was fixed in Linus' tree as well.
thanks,
-chris
On Thursday 23 February 2006 09:46, Matheus Izvekov wrote:
> On 2/23/06, Matheus Izvekov <[email protected]> wrote:
> > On 2/22/06, Matheus Izvekov <[email protected]> wrote:
> > > Hi all
> > >
> > > When i tried kernel 2.6.15.4, i noticed i cant boot it, i get
> > > "warning: cannot open initial console" then it reboots. I've searched
> > > for it and found the breakage occurs from 2.6.15.1 to 2.6.15.2
> > >
> > > Before i start to bisect to find the culpirit, and as there were few
> > > changes, anyone has a good guess about what broke it?
> > >
> > > Thanks all in advance.
> > >
> >
> > Found the bad patch by reversing by hand.
> >
> > diff --git a/fs/reiserfs/super.c b/fs/reiserfs/super.c
> > index 42afb5b..9c38f10 100644
> > --- a/fs/reiserfs/super.c
> > +++ b/fs/reiserfs/super.c
> > @@ -1131,7 +1131,7 @@ static void handle_attrs(struct super_bl
> > REISERFS_SB(s)->s_mount_opt &= ~(1 << REISERFS_ATTRS);
> > }
> > } else if (le32_to_cpu(rs->s_flags) & reiserfs_attrs_cleared) {
> > - REISERFS_SB(s)->s_mount_opt |= REISERFS_ATTRS;
> > + REISERFS_SB(s)->s_mount_opt |= (1 << REISERFS_ATTRS);
> > }
> > }
> >
> > Reversing this fixes the problem, double checked it. What was that
> > patch supposed to do anyway?
> >
>
> Adding Vitaly Fertman to this thread, as he is the one who seems to
> have submitted that patch.
this line enables attribues by default -- sets the mount option flag.
the problem was that the value itself, instead of the flag, was set.
reiserfs_attrs_cleared on-disk super block flag indicates if attributes
of all files were cleared initially or not -- fs is ready to use attributes.
if they were not cleared, files may contain garbage instead of attribute flags.
reiserfs_attrs_cleared flag may lie, garbage in file attributes may appear
due to using old kernels/reiserfsprogs, before attributes were supported by
reiserfs; or due to a corruption.
so it seems better to disable the enable-by-default behaviour -- look into
the attachment please -- and clear the file attributes before using them:
reiserfsck --clean-attributes <device>
--
Vitaly