FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 12-06-2007, 11:04 AM
Andrew Morton
 
Default 2.6.24-rc4-mm1

On Thu, 06 Dec 2007 06:49:24 -0500 Valdis.Kletnieks@vt.edu wrote:

> On Tue, 04 Dec 2007 21:17:01 PST, Andrew Morton said:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/
>
> Something in here broke LVM support - an initrd that has worked fine for
> quite some time suddenly couldn't mount /dev/VolGroup00/root so we get the
> infamous "Kernel panic - not syncing: Attempted to kill init!" when we
> fall off the end of the initrd and haven't pivoted to the real disk.
>
> It finds the disk OK:
>
> [ 81.202310] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
> [ 81.214466] sd 0:0:0:0: [sda] Write Protect is off
> [ 81.226467] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> [ 81.238436] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> [ 81.250780] sda: sda1 sda2
> [ 75.396119] sd 0:0:0:0: [sda] Attached SCSI disk
>
> but then the lvm command says it can't find the volume group VolGroup00 (which
> is actually sda2 - sda1 is a small /boot partition, rest of disk is LVM).
>
> A quick look at the rc4-mm1 announcement doesn't have any obviously tempting
> patch names to start at, so it looks like it's time to play mm-bisect. It may
> take me a day or two, as I have some time management issues this week...
>

OK, thanks.

First step would be to eliminate rewrite-rd.patch: maybe the ramdisk driver
in which that initrd resides is bust.

After that, agk-dm-dm-*.patch are of course the ones to look at.

Please keep dm-devel@redhat.com cc'ed.

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 12-06-2007, 06:18 PM
 
Default 2.6.24-rc4-mm1

On Thu, 06 Dec 2007 04:04:20 PST, Andrew Morton said:

> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/
> >
> > Something in here broke LVM support - an initrd that has worked fine for
> > quite some time suddenly couldn't mount /dev/VolGroup00/root so we get the
> > infamous "Kernel panic - not syncing: Attempted to kill init!" when we
> > fall off the end of the initrd and haven't pivoted to the real disk.
> >
> > It finds the disk OK:
> >
> > [ 81.202310] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
> > [ 81.214466] sd 0:0:0:0: [sda] Write Protect is off
> > [ 81.226467] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> > [ 81.238436] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> > [ 81.250780] sda: sda1 sda2
> > [ 75.396119] sd 0:0:0:0: [sda] Attached SCSI disk
> >
> > but then the lvm command says it can't find the volume group VolGroup00 (which
> > is actually sda2 - sda1 is a small /boot partition, rest of disk is LVM).
> >
> > A quick look at the rc4-mm1 announcement doesn't have any obviously tempting
> > patch names to start at, so it looks like it's time to play mm-bisect. It may
> > take me a day or two, as I have some time management issues this week...
> >
>
> OK, thanks.
>
> First step would be to eliminate rewrite-rd.patch: maybe the ramdisk driver
> in which that initrd resides is bust.
>
> After that, agk-dm-dm-*.patch are of course the ones to look at.

How did I not notice them? Yeah, those guys would be on the suspicious list...

> Please keep dm-devel@redhat.com cc'ed.

I've gotten it down to about 128 patches, but it's interesting what ended
up bracketed by GOOD/BAD:

powerpc-invalid-size-for-swapper_pg_dir-with-config_pte_64bit=y.patch GOOD
#GREGKH-DRIVER-START
gregkh-driver-nozomi.patch
gregkh-moby-patch-tree....
unbork-gregkh-driver-kset-convert-sys-devices-to-use-kset_create-vioc.patch BAD

Would I be remiss in hypothesising that something in gregkh-driver-kobject-*
changed something, and now we need a agk-dm-dm-kobject-fixupage.patch?

The actual bug is probably elsewhere, but it *manifests* due to gregkh-driver
tree. Will probably be tomorrow before I get it down further...

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 12-06-2007, 06:38 PM
Greg KH
 
Default 2.6.24-rc4-mm1

On Thu, Dec 06, 2007 at 02:18:08PM -0500, Valdis.Kletnieks@vt.edu wrote:
> On Thu, 06 Dec 2007 04:04:20 PST, Andrew Morton said:
>
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/
> > >
> > > Something in here broke LVM support - an initrd that has worked fine for
> > > quite some time suddenly couldn't mount /dev/VolGroup00/root so we get the
> > > infamous "Kernel panic - not syncing: Attempted to kill init!" when we
> > > fall off the end of the initrd and haven't pivoted to the real disk.
> > >
> > > It finds the disk OK:
> > >
> > > [ 81.202310] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
> > > [ 81.214466] sd 0:0:0:0: [sda] Write Protect is off
> > > [ 81.226467] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> > > [ 81.238436] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> > > [ 81.250780] sda: sda1 sda2
> > > [ 75.396119] sd 0:0:0:0: [sda] Attached SCSI disk
> > >
> > > but then the lvm command says it can't find the volume group VolGroup00 (which
> > > is actually sda2 - sda1 is a small /boot partition, rest of disk is LVM).
> > >
> > > A quick look at the rc4-mm1 announcement doesn't have any obviously tempting
> > > patch names to start at, so it looks like it's time to play mm-bisect. It may
> > > take me a day or two, as I have some time management issues this week...
> > >
> >
> > OK, thanks.
> >
> > First step would be to eliminate rewrite-rd.patch: maybe the ramdisk driver
> > in which that initrd resides is bust.
> >
> > After that, agk-dm-dm-*.patch are of course the ones to look at.
>
> How did I not notice them? Yeah, those guys would be on the suspicious list...
>
> > Please keep dm-devel@redhat.com cc'ed.
>
> I've gotten it down to about 128 patches, but it's interesting what ended
> up bracketed by GOOD/BAD:
>
> powerpc-invalid-size-for-swapper_pg_dir-with-config_pte_64bit=y.patch GOOD
> #GREGKH-DRIVER-START
> gregkh-driver-nozomi.patch
> gregkh-moby-patch-tree....
> unbork-gregkh-driver-kset-convert-sys-devices-to-use-kset_create-vioc.patch BAD
>
> Would I be remiss in hypothesising that something in gregkh-driver-kobject-*
> changed something, and now we need a agk-dm-dm-kobject-fixupage.patch?

I don't know, it all depends on what is in the dm patches. Hopefully
everything that I have changed will manifest with a build breakage to
obviously detect that something needs to be fixed up.

But I've been known to mess things up that I didn't intend to

If there's anything that I can do to test this, please let me know.

thanks,

greg k-h

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 12-06-2007, 07:04 PM
 
Default 2.6.24-rc4-mm1

On Thu, 06 Dec 2007 11:38:43 PST, Greg KH said:
> > Would I be remiss in hypothesising that something in gregkh-driver-kobject-*
> > changed something, and now we need a agk-dm-dm-kobject-fixupage.patch?
>
> I don't know, it all depends on what is in the dm patches. Hopefully
> everything that I have changed will manifest with a build breakage to
> obviously detect that something needs to be fixed up.
>
> But I've been known to mess things up that I didn't intend to

Given that it *didn't* totally break the build, it's likely a fencepost error
or some similar issue...

> If there's anything that I can do to test this, please let me know.

I wanted to give a heads-up, in case there was a D'Oh! patch hiding. At worst,
I just need another 6 or 7 bisects to figure out which of those 120-ish patches
is the culprit. With luck I'll end up stopped on a patch that in retrospect
was obviously busticated. If not, we'll have to apply the usual more drastic
measures. If you don't have a box that's already demonstrating it, and you
don't have any obvious candidates, it's likely that the most productive
use of everybody's time is for you to chase down any other kobject issues
while I bisect the problem down further...
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 12-06-2007, 09:04 PM
"Kay Sievers"
 
Default 2.6.24-rc4-mm1

On Dec 6, 2007 8:38 PM, Greg KH <greg@kroah.com> wrote:
> On Thu, Dec 06, 2007 at 02:18:08PM -0500, Valdis.Kletnieks@vt.edu wrote:
> > On Thu, 06 Dec 2007 04:04:20 PST, Andrew Morton said:
> >
> > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/
> > > >
> > > > Something in here broke LVM support - an initrd that has worked fine for
> > > > quite some time suddenly couldn't mount /dev/VolGroup00/root so we get the
> > > > infamous "Kernel panic - not syncing: Attempted to kill init!" when we
> > > > fall off the end of the initrd and haven't pivoted to the real disk.
> > > >
> > > > It finds the disk OK:
> > > >
> > > > [ 81.202310] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
> > > > [ 81.214466] sd 0:0:0:0: [sda] Write Protect is off
> > > > [ 81.226467] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> > > > [ 81.238436] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> > > > [ 81.250780] sda: sda1 sda2
> > > > [ 75.396119] sd 0:0:0:0: [sda] Attached SCSI disk
> > > >
> > > > but then the lvm command says it can't find the volume group VolGroup00 (which
> > > > is actually sda2 - sda1 is a small /boot partition, rest of disk is LVM).
> > > >
> > > > A quick look at the rc4-mm1 announcement doesn't have any obviously tempting
> > > > patch names to start at, so it looks like it's time to play mm-bisect. It may
> > > > take me a day or two, as I have some time management issues this week...
> > > >
> > >
> > > OK, thanks.
> > >
> > > First step would be to eliminate rewrite-rd.patch: maybe the ramdisk driver
> > > in which that initrd resides is bust.
> > >
> > > After that, agk-dm-dm-*.patch are of course the ones to look at.
> >
> > How did I not notice them? Yeah, those guys would be on the suspicious list...
> >
> > > Please keep dm-devel@redhat.com cc'ed.
> >
> > I've gotten it down to about 128 patches, but it's interesting what ended
> > up bracketed by GOOD/BAD:
> >
> > powerpc-invalid-size-for-swapper_pg_dir-with-config_pte_64bit=y.patch GOOD
> > #GREGKH-DRIVER-START
> > gregkh-driver-nozomi.patch
> > gregkh-moby-patch-tree....
> > unbork-gregkh-driver-kset-convert-sys-devices-to-use-kset_create-vioc.patch BAD
> >
> > Would I be remiss in hypothesising that something in gregkh-driver-kobject-*
> > changed something, and now we need a agk-dm-dm-kobject-fixupage.patch?
>
> I don't know, it all depends on what is in the dm patches. Hopefully
> everything that I have changed will manifest with a build breakage to
> obviously detect that something needs to be fixed up.
>
> But I've been known to mess things up that I didn't intend to
>
> If there's anything that I can do to test this, please let me know.

What's the value of SYSFS_DEPRECATED? Care to set it to yes, if it isn't,
and try again?

A fix for LVM to handle symlinks instead of directories is in the LVM
CVS tree, but there wasn't a release since August.

Kay

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 12-06-2007, 09:12 PM
Alasdair G Kergon
 
Default 2.6.24-rc4-mm1

On Thu, Dec 06, 2007 at 11:04:12PM +0100, Kay Sievers wrote:
> A fix for LVM to handle symlinks instead of directories is in the LVM
> CVS tree, but there wasn't a release since August.

I released it yesterday:-)

Alasdair
--
agk@redhat.com

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 12-06-2007, 10:12 PM
 
Default 2.6.24-rc4-mm1

On Thu, 06 Dec 2007 23:04:12 +0100, Kay Sievers said:

> What's the value of SYSFS_DEPRECATED? Care to set it to yes, if it isn't,
> and try again?

I *knew* there was a D'Oh! error in here.

Bisection is fast closing in on gregkh-driver-block-device.patch, which broke
my LVM almost the exact same way the *last* time it showed up in -mm

> A fix for LVM to handle symlinks instead of directories is in the LVM
> CVS tree, but there wasn't a release since August.

I seem to recall it was 'nash' rather than LVM that had the indigestion the
last time around.







--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 12-06-2007, 10:24 PM
Kay Sievers
 
Default 2.6.24-rc4-mm1

On Thu, 2007-12-06 at 18:12 -0500, Valdis.Kletnieks@vt.edu wrote:
> On Thu, 06 Dec 2007 23:04:12 +0100, Kay Sievers said:
>
> > What's the value of SYSFS_DEPRECATED? Care to set it to yes, if it isn't,
> > and try again?
>
> I *knew* there was a D'Oh! error in here.
>
> Bisection is fast closing in on gregkh-driver-block-device.patch, which broke
> my LVM almost the exact same way the *last* time it showed up in -mm

Oh, it must not, if SYSFS_DEPRECATED=y is set. I hope we fixed all
issues. Please let us know if it does not work, then we will need to
look into it.

> > A fix for LVM to handle symlinks instead of directories is in the LVM
> > CVS tree, but there wasn't a release since August.
>
> I seem to recall it was 'nash' rather than LVM that had the indigestion the
> last time around.

I think that a recent nash should work, even with SYSFS_DEPRECATED=n.
Anyway, nothing should change when SYSFS_DEPRECATED set, nash works fine
here, with that.

Kay

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 12-07-2007, 05:20 PM
 
Default 2.6.24-rc4-mm1

On Fri, 07 Dec 2007 00:24:04 +0100, Kay Sievers said:
> On Thu, 2007-12-06 at 18:12 -0500, Valdis.Kletnieks@vt.edu wrote:
> > On Thu, 06 Dec 2007 23:04:12 +0100, Kay Sievers said:
> >
> > > What's the value of SYSFS_DEPRECATED? Care to set it to yes, if it isn't,
> > > and try again?
> >
> > I *knew* there was a D'Oh! error in here.
> >
> > Bisection is fast closing in on gregkh-driver-block-device.patch, which broke
> > my LVM almost the exact same way the *last* time it showed up in -mm
>
> Oh, it must not, if SYSFS_DEPRECATED=y is set. I hope we fixed all
> issues. Please let us know if it does not work, then we will need to
> look into it.

I changed SYSFS_DEPRECATED to y, and it was able to boot with the same old
initrd I've been using for a while.

Note that I had it set to 'n' for at least the last 4-5 -mm kernels, so it
*was* working fine without it..

> > > A fix for LVM to handle symlinks instead of directories is in the LVM
> > > CVS tree, but there wasn't a release since August.
> >
> > I seem to recall it was 'nash' rather than LVM that had the indigestion the
> > last time around.
>
> I think that a recent nash should work, even with SYSFS_DEPRECATED=n.
> Anyway, nothing should change when SYSFS_DEPRECATED set, nash works fine
> here, with that.

It was working fine with =n here until -rc4-mm1 as well, that's why it's a bit
of a surprise. What got added to the 'deprecated' list in this iteration?

Now for the truly odd part - I just tried with a rebuilt initrd that included
the lvm.static from last night's Rawhide (lvm2-2.02.29-1.fc9). And that didn't
work any better.

So to summarize: (old lvm == 2.02.24)

release SYSFS_DEPRECATED lvm2 works
-rc3-mm2 N old yes
-rc4-mm1 N old no
-rc4-mm1 Y old yes
-rc4-mm1 N new no

(I'm sure looking at that, everybody is now going 'WTF??!?'

gregkh-driver-driver-core-fix-class-glue-dir-cleanup-logic.patch and
gregkh-driver-block-device.patch are the only patches left in the (very small)
bisect window that reference SYSFS_DEPRECATED at all (according to grep)

Anybody got any brilliant ideas?




--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 12-07-2007, 05:44 PM
Kay Sievers
 
Default 2.6.24-rc4-mm1

On Fri, 2007-12-07 at 13:20 -0500, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 07 Dec 2007 00:24:04 +0100, Kay Sievers said:
> > On Thu, 2007-12-06 at 18:12 -0500, Valdis.Kletnieks@vt.edu wrote:
> > > On Thu, 06 Dec 2007 23:04:12 +0100, Kay Sievers said:
> > >
> > > > What's the value of SYSFS_DEPRECATED? Care to set it to yes, if it isn't,
> > > > and try again?
> > >
> > > I *knew* there was a D'Oh! error in here.
> > >
> > > Bisection is fast closing in on gregkh-driver-block-device.patch, which broke
> > > my LVM almost the exact same way the *last* time it showed up in -mm
> >
> > Oh, it must not, if SYSFS_DEPRECATED=y is set. I hope we fixed all
> > issues. Please let us know if it does not work, then we will need to
> > look into it.
>
> I changed SYSFS_DEPRECATED to y, and it was able to boot with the same old
> initrd I've been using for a while.

Great!

> Note that I had it set to 'n' for at least the last 4-5 -mm kernels, so it
> *was* working fine without it..

Yeah, but the raw block kobjects got converted to devices, which are
symlinks with SYSFS_DEPRECATED=n.

> > > > A fix for LVM to handle symlinks instead of directories is in the LVM
> > > > CVS tree, but there wasn't a release since August.
> > >
> > > I seem to recall it was 'nash' rather than LVM that had the indigestion the
> > > last time around.
> >
> > I think that a recent nash should work, even with SYSFS_DEPRECATED=n.
> > Anyway, nothing should change when SYSFS_DEPRECATED set, nash works fine
> > here, with that.
>
> It was working fine with =n here until -rc4-mm1 as well, that's why it's a bit
> of a surprise. What got added to the 'deprecated' list in this iteration?

Block devices got integrated in the driver model.

> Now for the truly odd part - I just tried with a rebuilt initrd that included
> the lvm.static from last night's Rawhide (lvm2-2.02.29-1.fc9). And that didn't
> work any better.
>
> So to summarize: (old lvm == 2.02.24)
>
> release SYSFS_DEPRECATED lvm2 works
> -rc3-mm2 N old yes
> -rc4-mm1 N old no
> -rc4-mm1 Y old yes
> -rc4-mm1 N new no
>
> (I'm sure looking at that, everybody is now going 'WTF??!?'
>
> gregkh-driver-driver-core-fix-class-glue-dir-cleanup-logic.patch and
> gregkh-driver-block-device.patch are the only patches left in the (very small)
> bisect window that reference SYSFS_DEPRECATED at all (according to grep)
>
> Anybody got any brilliant ideas?

I guess it's nash again, which version is it?

You probably need to wait for Red Hat to catch up, and don't disable
SYSFS_DEPRECATED for now, they don't support that.

Kay

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 

Thread Tools




All times are GMT. The time now is 09:33 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org