On Sat, Jun 05, 2010 at 08:58:39PM +0200, Nils Radtke wrote:
# Your patches are not enough for me, however, and I wonder if you # perhaps have applied other patches too, that might be relevant to # include as well. Yep, that's what I noticed here as well. But only since I changed my config. I'm hitting considerable problems regarding luks+lvm2.
Ah, no. My problem was different: http://bugs.debian.org/519866 - which lead to wrongly closed) http://bugs.debian.org/523828 explaining that "depmod -m" needs to be run explicitly now.
First off, yaird encountered more kernel specific modifications which made it scream. Haven't been able to fix it finally. I got it working for lvm2 but it now doesn't take into account that the lvm2 volumes are _inside_ the luks container. I just started wondering whether yaird was designed to handle this situation at all. Maybe you are able to shed some light on this aspect?
I do not use LUKS myself, so unfortunately have no experience with that. Is it perhaps similar to http://bugs.debian.org/516465 ?
# You call it a Debian-specific modification. Are you aware of yaird # being used naywhere else than in Debian? Oh, that's just because I noticed that comment in the source telling that the mktemp stuff is debian-specific and that's what made yaird bail on calling it w/ -f -o parameters. And I believe remembering that I read somewhere on the net something about other dists (like RH) using it.. But didn't verify neither source nor statement.
Ah, I see.Yaird was originally written to work both with Debian and Redhat based systems. As far as I am aware, it never was used much except in Debian. Only one other use I have stumbled upon is with early releases of OLPC (One Laptop Per Child - better known as the "$100 laptop").
So, I'd be interested in knowing whether yaird does handle lvm inside luks. Because that's what I'm failing to fix.. Right now it's about a dm-? device being handled as lvm lv instead of lvm pv which it really is. The question that just arose is: why isn't dm-? not yet catched by the tryDMcrypt target right before the tryLvm target in Plan.pm?I'm still quite new to the yaird source and just hacking what I see and see fit. As requirements change I adjust my knowledge of the working of yaird internals but I'm still far from having a complete picture. I hope I didn't anything too stupid in the previous patches.
It works for me too (now that I've generated that PCI module list. But I am a bit suspicious about the devices that you ignore - could you perhaps elaborate more on that, to help ensure that they are universally sane to ignore?
last year I had a closer look at the problems with newer kernels, and tried to change how symlinks was resolved more generically (which I suspect is what you try to cover up with your ignore pieces). I did not succeed, however, and got distracted with other things since then...
The actual fix I'm working on is a bit more intrusive as I had to handle a 253:4 device no call in Plan.pm: tryLvm, which bailed out. I got beyond this checking within LvmTab.pm whether the called device is actually a lvm pv and if so just went on. That's working right now but I end up w/ a ramfs w/o luks support. And therefore I'm into the luks target and why it isn't called/matched..Ah, another note: The patches I provided worked for me (and are otherwise untested) because I had a fairly simple setup. A couple of luks containers, no boot-relevant modules, no pm modules nothing. Plain luks. Worked like a charm, and I love those small ramfs images.Right now, I'm a bit out of time and start thinking about hacking one of my previously used ramfs images w/ the new lvm stuff. Probably the faster solution, but then.. it's a hack.. :|
If you can be persuaded, then I would be happy to have you help work directly on yaird.
If "fumbling around" then you could do that on a separate branch, and when certain that you've narrowed down some flaw and found a sensible fix then you can apply that with a clear commit message to the main branch.
Insterested? Are you familiar with Git? With Alioth? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: Digital signature
