With kernel 3.5-rc1, LVM volumes are not detected. A bisection leads to the following commit: commit 794c10fa0fa4d1781c5651c31e3d4d0b71629128 Author: Jörn Engel <joern@logfs.org> Date: Thu Apr 12 17:32:48 2012 -0400 [SCSI] sg: remove while (1) non-loop The while (1) construct isn't actually a loop at all. So let's not pretent and obfuscate the code. Signed-off-by: Joern Engel <joern@logfs.org> Acked-by: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Unfortunately, I cannot revert it on top of 3.5-rc1 or 3.5-rc2 to confirm this. My harddisk is using the AHCI drivers. Can somebody explains what's happening ?
This problem seems impossible to bisect. The first run (794c10fa0fa4d) was the result of the bisection limited to drivers and fs directories. A second run where I also added the block directory lead to a commit related to watchdog, which is impossible since I don't use watchdog on my computer. A 3rd run on the whole kernel tree leads to this commit: From 4523e1458566a0e8ecfaff90f380dd23acc44d27 Mon Sep 17 00:00:00 2001 From: Dave Hansen <dave@linux.vnet.ibm.com> Date: Wed, 30 May 2012 07:51:07 -0700 Subject: [PATCH] mm: fix vma_resv_map() NULL pointer hugetlb_reserve_pages() can be used for either normal file-backed hugetlbfs mappings, or MAP_HUGETLB. In the MAP_HUGETLB, semi-anonymous mode, there is not a VMA around. The new call to resv_map_put() assumed that there was, and resulted in a NULL pointer dereference: This is also strange because I don't use hugetlb. I can revert this commit but it doesn't change anything. Does anybody have an idea on what I could do to further investigate this problem.
Might be worth attaching a dmesg of both a working and failing boot
I don't understand at all what has happened but the problem is gone. I recompiled my kernel without using ccache and it works correctly. I use ccache since a very long time and it's the first time I encounter such a problem.
Thanks for trying.
Reply-To: muthu.lkml@gmail.com I am using CentOS 6.x and I hit this bug with 3.5-rc2. I tried to look in to the boot process and found that the initramfs generated from 3.5.-rc2 is not good for lvm root. It was missing /lib/modules/<uname -r>/kernel/drivers/md/*". Also /sbin/ doesn't have lvm_scan and was missing a bunch of other files too. CCing initramfs folks. Any help? On Sat, Jun 9, 2012 at 11:12 PM, <bugzilla-daemon@bugzilla.kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=43359 > > > > > > --- Comment #1 from François Valenduc <francois.valenduc@tvcablenet.be> > 2012-06-10 06:12:06 --- > This problem seems impossible to bisect. The first run (794c10fa0fa4d) was > the > result of the bisection limited to drivers and fs directories. A second run > where I also added the block directory lead to a commit related to watchdog, > which is impossible since I don't use watchdog on my computer. > A 3rd run on the whole kernel tree leads to this commit: > > From 4523e1458566a0e8ecfaff90f380dd23acc44d27 Mon Sep 17 00:00:00 2001 > From: Dave Hansen <dave@linux.vnet.ibm.com> > Date: Wed, 30 May 2012 07:51:07 -0700 > Subject: [PATCH] mm: fix vma_resv_map() NULL pointer > > hugetlb_reserve_pages() can be used for either normal file-backed > hugetlbfs mappings, or MAP_HUGETLB. In the MAP_HUGETLB, semi-anonymous > mode, there is not a VMA around. The new call to resv_map_put() assumed > that there was, and resulted in a NULL pointer dereference: > > This is also strange because I don't use hugetlb. I can revert this commit > but > it doesn't change anything. Does anybody have an idea on what I could do to > further investigate this problem. > > -- > Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the assignee for the bug.-- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Ok so that's a centos initrd bug. Probably best to open a centos bug for it.
CentOS 6 dracut doesn't support 3.x kernels (probably easy to persuade it to but not sure that they'd want a bug on that). I talked to Muthu off-list and his problem turned out to be with a local blkid build that was breaking dracut's LVM module check script.