[Yaird-devel] Bug#584565: Bug#584565: Bug#584565: [PATCH] enable yaird for kernel.org 2.6.33.4

Sat Jun 5 23:42:46 UTC 2010

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/yaird-devel/attachments/20100606/449bf718/attachment.pgp>