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
