# LVM Segmentation fault with kernel 2.6.4 / 2.6.5

## Simba

Hi,

I use lvm with kernel 2.6.2 , everything is working fine. But when I upgrade

the kernel to 2.6.4 (gentoo-dev-sources), the vgscan crashed during booting

so I can't mount any lvm filesystem. here is the error message:

* Setting up the Logical Volume Manager

/sbin/rc: line 313 : 2512 Segmentation fault /sbin/vgscan >/dev/null

vgscan crashed although the kernel configuration is the same (I just 

copied .config from kernel 2.6.2 to 2.6.4 , and make oldconfig and 

than make .

can someone help me or give me a hint what I still miss here.

thanks,

cahya

----------

## neysx

I assume you have checked both your CFLAGS in your make.conf and your target in your kernel config.

Could you try with the vanilla sources? I use the vanilla-2.6.5 without any problem (# emerge development-sources).

If it turns out there is a bug in the gentoo-dev-sources, please file a bug on bugs.gentoo.org

Hth

----------

## Simba

Thanks for the hint, I tried the vanilla 2.6.5 , but it has the same problem,

vgscan creates segmentation fault  :Sad: 

my server is a compaq proliant with raid 5 , with root partition as normal 

xfs partition and everything else use lvm. 

And it uses sys-libs/device-mapper-1.00.08  and sys-fs/lvm2-2.00.08 .

I don't really know why there is lvm difference between 2.6.2 and 2.64/2.6.5.

normally there should not be any problem in such minor changes , or maybe 

I forget something what I did for 2.6.2 so it works but not in 2.6.4/2.6.5 .

----------

## Simba

I just  tried also gentoo-dev-sources-2.6.3-r2.ebuild with the same kernel config from 2.6.2 , and it works fine , it means I don't forget something with kernel 2.6.4/2.6.5 because 2.6.3 is working fine and what I did with 2.6.3 is just copying the 2.6.2 config file into 2.6.3 sources and make oldconfig and make.

so the difference is between 2.6.3 and 2.6.4 .

----------

## Simba

Anyway, is there any linux livecd with kernel >= 2.6.4 that I can try to test

in my server?

----------

## akhen

Similar problem here.

I've used a lvm2 root on 2.6.3-r1 (gentoo-dev-sources).

Since 2.6.5 , no way to boot :

devfs_mk_dir: invalid argument.Segmentation fault 

See https://forums.gentoo.org/viewtopic.php?p=1043169#1043169

A bug reports has been opened on that by someone else:

https://bugs.gentoo.org/show_bug.cgi?id=47797

Using udev changed the problem as the error disapear but gentoo stop booting later

----------

## BradN

I'm having a similar problem - LVM is locking up the boot process even with no LVM partitions present.  I waited a couple minutes and no error showed up - it just hangs.  I can make it boot to a login prompt with sysrq+e though (but it skips the rest of the startup scripts then).

----------

## redbully

Same problem here!

LVM2 worked from 2.6.test11 till 2.6.3.

With 2.6.4 the trouble starts (vgscan segfaults at boot), a little bit critical to my system since everything besides /boot and / lay on lvm  :Confused: 

The most anoing thing about it was the boot back to 2.6.3 after the first boot of 2.6.4, the system get stucked at lvm-init, i thought everything was f***ed up, i was near to throw a user-panic-exception... but a knoppix saved my live.

Finally:

I have solved the prob

but it is just a quick hack.

For everyone interested, what happened:

vgscan scans the complete /dev directory for devices whith a lvm.

kind of handy "PnP", since it will find it in every config (IDE, SCSI, eg. USB-Stick with lvm, who knows). With the kernelupdate, something get borked (kernel-devfs | devfsd ?). vgscan gets lost in an endless loop of

devices (eg. "/dev/disk0/disk0/disk0.....").

You can see this in a file called "/etc/lvm/.cache". This file is not some data-cache or so, it is the search-cache for lvm, where to search for lvms. After the boot to 2.6.4 it was 16MB, thats why 2.6.3 seemed to hang (it just needed ages). I deleted the .cache and everything was normal again (under 2.6.3), since *normaly* (default config) lvm writes a new one on 

*every* scan/boot.

My solution was to write a "lvm.conf" in "/etc/lvm". Before this, you don't need one. Mine looks like this:

```
devices

{

   scan = "/dev/ide"

   write_cache_status = 0

}

```

Yes, thats it. What does it do?

First entry says lvm to seach just in "/dev/ide". This is OK for /me/, since i just have IDE-drives.

The second entry disables the rewrite of the .cache-file, this line should only be added *after* a successful reboot/rescan so that a good (and short) .cache gets written one time.

Just look at the man-page (man 8 lvm.conf) for additional info.

The downside of this Qucik-hack is: you lose lvm-"PnP", meening not every possible devices with a lvm on it will be scanned, or other trouble. So as a good system-maintainer you should remember where to change things if your newly attached device does not get recognized by lvm...

Regard

   Jan

PS: Sorry for my bad english, not my native tounge.[/i]

----------

## neysx

/etc/lvm/lvm.conf

```
devices {

  filter=["r:cdrom:"]

  filter=["r:dvd:"]

  filter=["a:/dev/hd[aefgh]:"]

  filter=["r:.*:"]

}

```

is what I use to filter out any cdrom/dvd, accept IDE disks hda/hde/hdf/hdh and reject anything else.

The first two reject lines are not required but I like to keep them  :Wink: 

----------

## redbully

Hmmm...

Filtering is also an idea, but i don't remember the exact path (name, what to filter for), which makes trouble in /dev and at the moment it runs, so no need to play around with it (never touch a running...) for me.

At least i can say, limiting the searchpath speeds up the search, now it boots 0.01 sek faster *lol*   :Wink: 

Back to the topic:

The main thing is to recognize that vgscan segfaults due to some endless paths, so one has to disable the access of this path for lvm in /dev, either by limiting the searchpath or by filtering the right path, till this is fixed elsewhere. Which path has to be filtered can be found in an borked .cache-file from lvm.

Regards

   Jan

----------

## Peacefaker

Wooo, it works! Finaly someone else experianced the problem and solved it, I have to say that the problem itself might be older than you suspect. I experianced it first around the end of February when trying some new Love kernel (2.6.3 i belive), but back then people just tought I was crazy or something (hey, tinfoil hats aren't just for conspiracy crazed people). 

Since then I have been stuck with 2.6.2-love1. No other kernel would let me access my LVM2-partitions which is a drag since I have 315GB of LVM space, everything execpt the core system itself.

Now I can finaly be rid of my "jittery-mouse" problem.

----------

## redbully

 *Quote:*   

> I experianced it first around the end of February when trying some new Love kernel (2.6.3 i belive)

 

Seems they have included some 'patch' a little bit earlier.

Someone with mm-sources (or aa or what ever) with a similar problem earlier than vanilla-2.6.4?

At least it is a sign that this does not come from nothing, there must be a reason within. I reed all the (vanilla) Changelogs, but can not remember what could trigger this....

Regards

   Jan

----------

## atom2103

For me it works fine in kernel 2.6.7 now 

i only do `lvchange -ay /dev/vg0/lv0` now

prior I did also `pvscan`, `vgscan` & `lvscan`.

Now I have `cp -Rp /etc/lvm*` to my initrd, and pvscan is no longer needed, ergo no Segfault.   :Very Happy: 

----------

## cdebaes

Hi, 

If only I had seen this thread earlier.... interesting.

Well anyway, I found out that this problem is also solved when using the masked lvm2-2.00.15 package instead of the normal lvm2-2.00.08. (Of course the new lvm2 comes with an updated device-mapper v. 1.00.17).

Cheers

----------

## sams2100

Fixed it on my end by emerging the masked version of the lvm2 package.  Seems like they fixed it in the latest version and it scans the entire /dev tree still.

----------

## JeroenV

Still no luck here, using sys-fs/lvm2-2.00.25

It (vgscan) segfaults, but I don't notice any delay. It used to work on 2.6.3 (gentoo-dev), but I need a newer one for ACLs   :Sad: 

Any other ideas?

Or is there a trick to bypass vgscan?

----------

