You are not logged in.

#126 2013-03-25 01:47:07

mdias
Member
Registered: 2010-01-18
Posts: 11

Re: Changes to LVM2 and udev break LVM2 on LUKS?

Well, I'm just another user suffering from random boot failures, using LVM on top of RAID-1 array...

I suspect a race condition somewhere is making LVM scan for volumes before mdadm is actually done assembling the array, but then again this is my first time using LVM on linux (just installed) so I don't know much of what I'm talking about...

Oh well, at least now I know how to manually scan and resume booting...

Offline

#127 2013-03-25 02:10:31

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,412

Re: Changes to LVM2 and udev break LVM2 on LUKS?

mdias wrote:

Well, I'm just another user suffering from random boot failures, using LVM on top of RAID-1 array...

I suspect a race condition somewhere is making LVM scan for volumes before mdadm is actually done assembling the array, but then again this is my first time using LVM on linux (just installed) so I don't know much of what I'm talking about...

Oh well, at least now I know how to manually scan and resume booting...

If you take a look at what the hooks in mkinitcpio actually do, you will see that they are simple scripts.  This is why order matters.  So if you have a RAID array with LVM on top of that, you will have to have mdadm_udev before lvm, and if you have a RAID array that is encrypted with Luks, which then has lvm on top of that you would have to have mdadm_udev encrypt lvm, in that order.

So I don't think it is necessarily a race condition, as these things are being called in order.  I think what appears to be happening in my case is that lvmetad (which is now what is used to scan for and activate the volume groups) fails to start for some reason.

As a side note, this ordering is only relevant for hooks that include a script to be run in the initramfs.  There are some hooks which simply determine the necessary filesystem modules that need to be included or which fsck binaries to include.  For those, order is not as strict.

Offline

#128 2013-03-25 16:10:37

mdias
Member
Registered: 2010-01-18
Posts: 11

Re: Changes to LVM2 and udev break LVM2 on LUKS?

WonderWoofy wrote:

If you take a look at what the hooks in mkinitcpio actually do, you will see that they are simple scripts.  This is why order matters.  So if you have a RAID array with LVM on top of that, you will have to have mdadm_udev before lvm, and if you have a RAID array that is encrypted with Luks, which then has lvm on top of that you would have to have mdadm_udev encrypt lvm, in that order.

I understand that, however if the mdadm_udev hook run returns before the arrays are actually assembled, lvm won't find the volumes when it runs. Think of it as a disk write operation, and not calling "sync" before hard reseting the PC, the write operation would return success before the data actually gets on disk.
Maybe this isn't the problem, I don't know, but as a programmer I usually find this kind random behaviour to be a race condition of some sort.

WonderWoofy wrote:

So I don't think it is necessarily a race condition, as these things are being called in order.  I think what appears to be happening in my case is that lvmetad (which is now what is used to scan for and activate the volume groups) fails to start for some reason.

lvmetad doesn't fail to start (at least in my case), and actually sometimes only finds some volumes (random, not always the same ones), and rarely finds all.
Running "lvm pvscan --cache --activate ay" on the shell will find the previously missing volumes, and I am able to continue booting.

Offline

#129 2013-03-26 12:24:48

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,097
Website

Re: Changes to LVM2 and udev break LVM2 on LUKS?

mdias wrote:

I understand that, however if the mdadm_udev hook run returns before the arrays are actually assembled, lvm won't find the volumes when it runs.

Please look again -- not every hook has a runtime component. The mdadm_udev hook includes udev rules which run asynchronously (likely at some point after 'udevadm trigger' is called via the udev hook) with 'udevadm settle' as a synchronization point. There's no such thing as mdadm_udev "running" out of order unless the udev hook is wrongly ordered.

Offline

#130 2013-03-26 15:20:51

mdias
Member
Registered: 2010-01-18
Posts: 11

Re: Changes to LVM2 and udev break LVM2 on LUKS?

falconindy wrote:

Please look again -- not every hook has a runtime component. The mdadm_udev hook includes udev rules which run asynchronously (likely at some point after 'udevadm trigger' is called via the udev hook) with 'udevadm settle' as a synchronization point. There's no such thing as mdadm_udev "running" out of order unless the udev hook is wrongly ordered.

Yes, I meant the lvm hook running before udev was actually finished doing it's job. However I just tried to add "sleep 2" after "udevadm settle" to make sure, and the issue remains...

Offline

#131 2013-03-26 15:34:31

mdias
Member
Registered: 2010-01-18
Posts: 11

Re: Changes to LVM2 and udev break LVM2 on LUKS?

ok, I found a temporary workaround that seems to work for me,

I edited the file /usr/lib/initcpio/hooks/lvm2 to add this:

run_hook() {
    lvm pvscan --cache --activate ay
}

Now, this will activate all lvm volumes regardless of lvm.conf, but it suits my needs for now.

Offline

#132 2013-03-31 05:10:34

BeepDog
Member
Registered: 2013-03-31
Posts: 5

Re: Changes to LVM2 and udev break LVM2 on LUKS?

brain0 wrote:

Everyone who is still having trouble, try changing the global filter line in /etc/lvm/lvm.conf from

# global_filter = []

to

global_filter = [ "r|^/dev/fd[0-9]$|", "r|^/dev/sr[0-9]$|" ]

Then run mkinitcpio -p linux again.

This solved the problem for me on two different boxes. One in VirtualBox that was using mdadm as well (the root partition was a lvm on a raid1 mdadm), and one box that just has a single drive, and the root partition is on LVM.

Thanks!

Offline

#133 2013-05-23 22:05:08

resi
Member
Registered: 2009-12-15
Posts: 43

Re: Changes to LVM2 and udev break LVM2 on LUKS?

Hi all, is someone still reading this thread?

I'm still stuck with this issue, although it seems to work with the kernel "debug" parameter (which makes me think its a timing issue).

1.)
I have problems when running the stock kernel 3.9.3-1 and lvm 2.02.98-3, but not using the lts kernel (3.0.79-1). I'm running 2 plain volume groups and another one on top of raid1 (mdadm).
I guess my mkinitcpio.conf is ok since it works at least sometimes.

2.)
The global_filter thing fixed the early boot issue right after the pre-hooks and the udev hook. This reliably detects the volume group where my / is located.

3.)
Now it is not-so-random that the local-fs target fails due to non-detectable devices during fsck. This happens about 9 out of 10 times, failing to detect any/all of the non-root volume groups. I am dropped into the emergency console then.
lvmetad is running in all these cases (use_lvmetad=1).
vgmknodes says something about udev not doing its job:

vgmknodes
The link /dev/mapper/... should had been created by udev but it was not found.

Doing a "vgchange -a y" finds all 3 volume groups and I can continue booting.

4.)

udevadm info --query=all <dev>

reports ID_FS_TYPEs for all physical devices and the recognized /dev/dm-X devices, but not for the missing /dev/dm-Y ones, although all 3 dm device nodes are present and have the same mtime. Also the /dev/mapper/... symlinks are missing.

journalctl | grep dm

doesn't give more hints than showing which dm devices were successfully mounted.

5.)
This looks like a timing issue/race condition to me since it never failed when adding "debug" to the kernel.

6.)
Using the run_hook patch from mdias is slightly more reliable, only 1 out of the first 5 boots failed (2 out of 6 while writing this wink).

Currently I'm stuck using the debug kernel parameter, which gives best results for me ...

I would be glad to help (since it seems reproducible on my machine) but do not know where to start. I've never bisected the kernel, is there some guide for dummies doing this on arch?

Offline

#134 2013-05-23 22:22:59

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,412

Re: Changes to LVM2 and udev break LVM2 on LUKS?

If you think it is a race condition (which it very very well may be), have you thought about trying to use the mkinitcpio "sleep" hook?  There is the parameter "sleepdevice=<device>" which might just work, as it simply pauses the initramfs process until the device is found.  I think if you stick it in between the lvm2 hook and the fsck hook somewhere, maybe it will actually have it wait until the initramfs finds the device. 

I have never tried to use this hook before though, so I am not sure how precisely to use it.  There is also a more general "sleep=<time>" kernel paramter you can use with that hook.

Having said all that, I will tell you that because of all this craziness, I have moved away from using LVM2.  This is unfortunate because I really liked LVM2 and until this paritcular update, it was incredibly reliable.  So now I am using btrfs... and TBH, I love it.  It may not be quite as performance oriented as the ext4 filesystem, but it gives me all the features of LVM2 and a lot more.  I still kind of miss LVM2 though.

I also see you tried using mdias' "patch" that was listed earlier in the thread.  I put it in quotes because it really is just a copy/paste of the old run_hook that was used in the previous build method.  So because of this, on my fileserver (which is still on LVM2 as I don't have enough spare disk space to move the data anywhere) I actually just went and found the old PKGBUILDs and other files from the previous version in the git repo.  This method works 100% of the time, no probem.  I just bumped the pkgrel to what it is now, so that pacman doesn't complain, and since it is equal to what the official repos have now, I will still also get notified of an update in that event.

Offline

#135 2013-05-24 07:42:18

resi
Member
Registered: 2009-12-15
Posts: 43

Re: Changes to LVM2 and udev break LVM2 on LUKS?

WonderWoofy wrote:

If you think it is a race condition (which it very very well may be), have you thought about trying to use the mkinitcpio "sleep" hook?  There is the parameter "sleepdevice=<device>" which might just work, as it simply pauses the initramfs process until the device is found.  I think if you stick it in between the lvm2 hook and the fsck hook somewhere, maybe it will actually have it wait until the initramfs finds the device.

I didn't know that hook, but will give it a try when I'm back home. I think I have to patch it though, 'cause I'm waiting for more than 1 device.

WonderWoofy wrote:

Having said all that, I will tell you that because of all this craziness, I have moved away from using LVM2.  This is unfortunate because I really liked LVM2 and until this paritcular update, it was incredibly reliable.  So now I am using btrfs... and TBH, I love it.  It may not be quite as performance oriented as the ext4 filesystem, but it gives me all the features of LVM2 and a lot more.  I still kind of miss LVM2 though.

Offtopic:
Funny thing, I'm going the other direction. Not on the machine with the LVM2/udev issues, but on my notebook (btrfs waking up the disc way too often, resulting in poor battery lifetime) and my machine at work, where I moved to ext4+LVM2 just yesterday. btrfs is very nice when looking at the features, but unbearable on a desktop running firefox, thunderbird and db related stuff (leafnode and recoll comes to my mind). I've been running btrfs on this machine for more than a year now and got tired of waiting for firefox/thunderbird taking several minutes to be usable (after booting) and the generally high I/O waiting time (where iotop always identified btrfs processes as cause). Now my desktop with firefox, thunderbird and some other tools starts in only few seconds smile.

Offline

#136 2013-05-24 13:26:50

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,412

Re: Changes to LVM2 and udev break LVM2 on LUKS?

resi wrote:

I didn't know that hook, but will give it a try when I'm back home. I think I have to patch it though, 'cause I'm waiting for more than 1 device.

I don't think so, as the device you are waiting for it a virtual device, but still a device. Therefore having it wait for /dev/mapper/volume-name should work just fine, as it is simply waiting for the thing to appear in /dev.

Offtopic:
Funny thing, I'm going the other direction. Not on the machine with the LVM2/udev issues, but on my notebook (btrfs waking up the disc way too often, resulting in poor battery lifetime) and my machine at work, where I moved to ext4+LVM2 just yesterday. btrfs is very nice when looking at the features, but unbearable on a desktop running firefox, thunderbird and db related stuff (leafnode and recoll comes to my mind). I've been running btrfs on this machine for more than a year now and got tired of waiting for firefox/thunderbird taking several minutes to be usable (after booting) and the generally high I/O waiting time (where iotop always identified btrfs processes as cause). Now my desktop with firefox, thunderbird and some other tools starts in only few seconds smile.

Yeah, see I have a SSD... or rather three.  So not only does it work incredibly fast, but by using the ssd mount option it tries to aggressively group write commands (amongst some other thigns I think).

Offline

#137 2013-05-24 14:08:45

resi
Member
Registered: 2009-12-15
Posts: 43

Re: Changes to LVM2 and udev break LVM2 on LUKS?

WonderWoofy wrote:
resi wrote:

I didn't know that hook, but will give it a try when I'm back home. I think I have to patch it though, 'cause I'm waiting for more than 1 device.

I don't think so, as the device you are waiting for it a virtual device, but still a device. Therefore having it wait for /dev/mapper/volume-name should work just fine, as it is simply waiting for the thing to appear in /dev.

I understand that, but I'm waiting for 2 logical volumes (dm-1 and dm-2). I don't remember exactly why I chose that setup, but I think I used it to have a logical volume with just 1 physical partition and then let LVM2 mirror this partition on a new disc.

Offtopic:
Funny thing, I'm going the other direction. Not on the machine with the LVM2/udev issues, but on my notebook (btrfs waking up the disc way too often, resulting in poor battery lifetime) and my machine at work, where I moved to ext4+LVM2 just yesterday. btrfs is very nice when looking at the features, but unbearable on a desktop running firefox, thunderbird and db related stuff (leafnode and recoll comes to my mind). I've been running btrfs on this machine for more than a year now and got tired of waiting for firefox/thunderbird taking several minutes to be usable (after booting) and the generally high I/O waiting time (where iotop always identified btrfs processes as cause). Now my desktop with firefox, thunderbird and some other tools starts in only few seconds smile.

Yeah, see I have a SSD... or rather three.  So not only does it work incredibly fast, but by using the ssd mount option it tries to aggressively group write commands (amongst some other thigns I think).

Ok, btrfs on SSDs is probably another thing smile.

Offline

#138 2013-05-24 16:59:50

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,412

Re: Changes to LVM2 and udev break LVM2 on LUKS?

I see, so what you are saying is that sometimes it fails waiting for the rootfs, but sometimes it fails waiting for the second lvm in order to fsck the volumes?

So why not combine the two lvm volumes, and then just make sure that the right volumes are dedicated to the right devices. This is actually totally possible with lvm and actually should be pretty easy. Maybe in this way you can ensure that the entire single lvm appears before proceeding.

Just a thought. I am unsure if there are other reasons for keeping the layout separate, but it sounds like this is just something you did on setup and have since then never had the motivation to change. So maybe thus might be the motivation you need.

BTW, have you tried building the lvm2/device-mapper packages with the old setup. Lvmetad is cool, but not so cool that it is worth a shoddy boot process IMO.

Offline

#139 2013-05-24 17:38:40

resi
Member
Registered: 2009-12-15
Posts: 43

Re: Changes to LVM2 and udev break LVM2 on LUKS?

First things first, I just tried the sleep hook. It works with a plain 5s sleep and also if I hardcode poll_device for all my logical volumes. This is great, but will probably be lost on the mkinitcpio update (where the hook will just sleep 5s again). I can very well live with this solution.
Thanks a lot for this hint.

WonderWoofy wrote:

I see, so what you are saying is that sometimes it fails waiting for the rootfs, but sometimes it fails waiting for the second lvm in order to fsck the volumes?

Almost right smile. The no-rootfs-error was resolved with the global_filter expression. But I have another 2 data volume groups, see below.

WonderWoofy wrote:

So why not combine the two lvm volumes, and then just make sure that the right volumes are dedicated to the right devices. This is actually totally possible with lvm and actually should be pretty easy. Maybe in this way you can ensure that the entire single lvm appears before proceeding.

Just a thought. I am unsure if there are other reasons for keeping the layout separate, but it sounds like this is just something you did on setup and have since then never had the motivation to change. So maybe thus might be the motivation you need.

Right, why not? My layout consists of 3 vgs with 1 lv each, vg-root (mounted at /), vg-home (/home) with random data and vg-data (/home/data) with "important" data. I split root and home out of no particular reason, I thought it might be handy to have them separated and, through LVM, always extendable. /home/data is the raid1 device with data not to be lost. I am by no means an expert in partitioning or LVM, is it possible to combine those into a single mapped device while making sure /home/data refers to the raid device?

WonderWoofy wrote:

BTW, have you tried building the lvm2/device-mapper packages with the old setup. Lvmetad is cool, but not so cool that it is worth a shoddy boot process IMO.

I'm sorry, I have no idea what you mean. Is "old setup" the one before the update (old lvm package, old kernel, old ...)?

Offline

#140 2013-05-24 21:30:23

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,412

Re: Changes to LVM2 and udev break LVM2 on LUKS?

You certainly can combine lvm volumes into a big single one with vgmerge.  Then you can use the lvm tools to also ensure that the logical volumes stay on a the device of your choice.  This seems like a better option than having three volume groups for three logical volumes.  The thing is that with three volume groups, there is no practical advantage to having that over regular partitions.  Sure the userspace tools might be a bit more straight forward to use with LVM, but the advantage with LVM is that you can extend volume groups (partitions/filesystems) even if they are not contiguous.  So by having three separate volume groups, you are already laying out space for where each partition would have gone anyway.

What I mean by old setup is the package versions of lvm and device-mapper that did not use lvmetad, but instead simply used a series of simple commands in a script to activate the volume groups.  If you view the package from the web site, you can click the option in the upper right hand corner to view the changes to the package.  Then you can track back to around november or december when the package was built in that way.  You can easily tell by the commits when that took place.  Then just use those version of the files to build the package yourself.  Oh BTW, the lvm2 package is actually a split package that will build both the lvm2 and device-mapper packages.

Offline

#141 2013-05-25 11:49:45

resi
Member
Registered: 2009-12-15
Posts: 43

Re: Changes to LVM2 and udev break LVM2 on LUKS?

WonderWoofy wrote:

You certainly can combine lvm volumes into a big single one with vgmerge.  Then you can use the lvm tools to also ensure that the logical volumes stay on a the device of your choice.  This seems like a better option than having three volume groups for three logical volumes.  The thing is that with three volume groups, there is no practical advantage to having that over regular partitions.

Yes, I can easily merge the root and home vgs and keep the lvs separated, but I see no way to also merge the volume group on my raid device. I want to make sure that /home/data is located on the raid discs. And if I merge the raid volume group I don't think there is a way to map a logical volume to specific physical volumes, after all, this is what lvm hides.

Anyway, thanks a lot for your help. I have a booting system again and know that I have to take care about the lvm setup. I really wouldn't mind just using the 5s sleep hook, I'm rarely in such a hurry smile

Offline

#142 2013-05-25 15:51:54

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,412

Re: Changes to LVM2 and udev break LVM2 on LUKS?

I'm glad things are working for you.  But about making a single lvm, you can use the /dev/md* as the special block device to add the to lvm.  It will treat this the same as it treats a /dev/sdXY.  So again, you can use vgmerge to put them all together.  The you can use pvmove to make sure that things stay where you want them to be.  Though this should not be necessary, because it is not going to go allotting extents without you telling it to.  With that tool, you could, for example, tell it to move all extents from logical volume "stuffs" from /dev/sda1 to /dev/md127.  But again, just vgmerge'ing the volume groups should not make the logical volumes move between disks.  So then when you want to extend a logicial volume or create a logical volume or whatever, you always have the option of specifying what disk it goes on to.  All this in the fantastic wealth of information documented in the lvm2 man pages.  So when there is a command that gives you the option to put something on a specific disk, it will tell you that amongst the options there is "[PhysicalVolumePath[:PE[-PE]]...]".

So if you are a visual kind of person, here is an example.  Say you have a volume group "computer" and you have a logical volume called "stuffs".  But your setup spans two normal drives /dev/sda2 and /dev/sdb1 and a RAID 0 array /dev/md127.  You want to expand by 23.7GB the "stuffs" volume, but you want to ensure that it uses only space available on /dev/md127 (does this example sound familiar?).  You would do:

# lvresize -L +23.7G computer/stuffs /dev/md127

This assumes that you created a logical volume on /dev/md127 without creating partitions.  In case you are not aware, LVM2 can handle whole disks w/o partitions quite well.

Also, I'm not sure how willing you would be to change your setup (or rather if you have the available disk space to move stuff around), but LVM2 offers integrated RAID levels in its functionality. So you can actually create a large lvm storage pool (a volume group) that is across several special block devices. Then you can create linear (normal) logical volumes as you wish.  But you can also throw in striped logical volumes as you wish.  Or you can create mirrored logical volumes as well.  These can all coexist within the same volume group, and is handled with the specification of the physical volume location option as examplified above.

You should know though that in your case it using LVM2 striping (RAID 0) will work the same way as what you have going now.  It will be faster, yet have half the fault tollerance.  But RAID1 on mdadm will use both copies to read the data.  So the resulting read speeds will be similar to RAID0.  With LVM2, the mirroring (RAID1) functionality apparently does not bring this benefit.  So the read speeds with mirroring in LVM will be the same as having a single copy of the disk.

LVM2 has a crazy amount of cool features and options.  From waht you have told me, it just seems like you don't fully grasp the amazing benefits that using LVM2 can bring.  So I am not saying that you cannot use the LVM2 in the way you are. But I think that there are better ways to utilize its power.  You can do what you want.  I just want to make you aware.

Offline

#143 2013-05-25 16:28:10

resi
Member
Registered: 2009-12-15
Posts: 43

Re: Changes to LVM2 and udev break LVM2 on LUKS?

WonderWoofy wrote:

LVM2 has a crazy amount of cool features and options.  From waht you have told me, it just seems like you don't fully grasp the amazing benefits that using LVM2 can bring.  So I am not saying that you cannot use the LVM2 in the way you are. But I think that there are better ways to utilize its power.  You can do what you want.  I just want to make you aware.

You're absolutely right, I feel like I've totally missed the best parts of LVM. I just used it as magic out-of-place-add-another-disc tool. Although I've read a lot about LVM, I never understood the idea about physical extents and the way LVM allocates them, also I didn't care too much 'cause nobody pointed me that way and I just assumed my scenario is more or less the whole LVM thing. Except the LVM-level RAIDing, I knew about that, just didn't need it.

Anyway, thanks for your insights and example, now I also understand what lvdisplay -m is for ... I will start merging right now smile.

Offline

#144 2013-05-25 17:27:34

resi
Member
Registered: 2009-12-15
Posts: 43

Re: Changes to LVM2 and udev break LVM2 on LUKS?

Hmm, not that easy. Merging my raid-vg worked, merging the other fails:

[root@nomad ~]# umount /home/data/; umount /home/; lvchange -a n /dev/mapper/vg-home ; vgchange -a n vg ; vgmerge -v vgsys vg
umount: /home/data/: not mounted
  0 logical volume(s) in volume group "vg" now active
    Checking for volume group "vg"
    Checking for volume group "vgsys"
    Archiving volume group "vg" metadata (seqno 24).
    Archiving volume group "vgsys" metadata (seqno 12).
    Writing out updated volume group
  /dev/sda1: lseek 18446744071600930816 failed: Invalid argument

google suggests a missing #include <unistd.h>, but the current lvm code (lib/device/dev-io.c) has that include. But now I'm getting really offtopic, so thanks WonderWoofy for all your help. I guess this is something for the lvm guys.

Offline

#145 2013-06-07 19:31:36

jmu
Member
From: Finland
Registered: 2012-03-18
Posts: 34

Re: Changes to LVM2 and udev break LVM2 on LUKS?

Here's my closure for the issue:

End up re-installing my server while moving most of the precious data into new NAS-device. When I was copying the data into new location, I noticed how second disc in RAID-1 had out of sync for some time - partially causing the issues I had with this upgrade. However, the sync issue had started *long before* the upgrade, but somehow it brought the issue up.

All in all, everything's fine now: I've been happy with NAS, no data was lost and re-installed Arch setup is working just fine for me.

Offline

#146 2013-07-06 22:40:04

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,412

Re: Changes to LVM2 and udev break LVM2 on LUKS?

My home file server is still on lvm2.  For the time being I had just downgraded the lvm2 and device-mapper packages to the pre-lvmetad versions.  But today I decided to see if I could fix the issue.

So I took the lvm2 ABS sources and then modified them to use the git source instead (renaming them to lvm2-git and device-mapper-git).  It was super trivial to do.  I have tested three boots in a row, all of which seem to work flawlessly. 

Here is the diff for what is in the ABS right now (2.02.98-4): http://pastebin.com/B2nCsFYn 

Hopefully this might help someone else who might still be struggling with this.  Maybe there will be a new stable release soon, which would likely include whatever it is that fixed this for me...

Last edited by WonderWoofy (2013-07-06 22:40:59)

Offline

#147 2013-11-08 01:17:33

dafrizz
Member
Registered: 2011-05-27
Posts: 21

Re: Changes to LVM2 and udev break LVM2 on LUKS?

resi wrote:

First things first, I just tried the sleep hook. It works with a plain 5s sleep and also if I hardcode poll_device for all my logical volumes. This is great, but will probably be lost on the mkinitcpio update (where the hook will just sleep 5s again). I can very well live with this solution.

Can you give me a bit more detail on this, i.e. what exactly you put in your mkinitcpio.conf etc. ?

I am suffering from this annoying problem (see here) and have not found a solution yet. Thanks a lot.

Offline

#148 2014-05-06 20:03:22

nanawel
Member
Registered: 2012-05-07
Posts: 66
Website

Re: Changes to LVM2 and udev break LVM2 on LUKS?

brain0 wrote:

Everyone who is still having trouble, try changing the global filter line in /etc/lvm/lvm.conf from

# global_filter = []

to

global_filter = [ "r|^/dev/fd[0-9]$|", "r|^/dev/sr[0-9]$|" ]

Then run mkinitcpio -p linux again.

And it solved the problem for me too!
I have an old Athlon XP with 2 hard disks using LVM2 and a floppy drive. This trick fixed the "end_request: I/O error, dev fd0, sector 0" that prevented the root partition to be detected at boot before timeout.

Thanks!

Offline

#149 2015-04-08 17:29:24

dbourgeo
Member
Registered: 2012-11-26
Posts: 29

Re: Changes to LVM2 and udev break LVM2 on LUKS?

brain0's global_filter solution seems to be working now for me.

The issue on my new computer used to only come up when I had snapshots (usually after updating arch, in case I need to rollback).
Nothing I could do with lvm or lvmetad on the rescue command line would get things to proceed. However, if I booted enough times, things would randomly work. So it does seem like a timing thing to me. So far, no issues with snapshots using the global_filter solution.

Offline

Board footer

Powered by FluxBB