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

[Nils Radtke]

  Hi Jonas,

# On Fri, Jun 04, 2010 at 06:14:58PM +0200, Nils Radtke wrote:
# > Thanks for yaird. I take it as a great program that required hard
# >work for tying everything up and knotting it against bare kernel
# >/sys  files. It's about aiming at a moving target.
# >
# > That's also the reason why I have to file this report as yaird
# >breaks  regularly w/ kernel internals changing. But this is
# >well-known, as  previous reports witness.
# >
# > yaird failed to create an initramfs image on kernel 2.6.33.4. I
# >believe it used to work w/ kernel 2.6.27.4, 2.6.29, 2.6.30 as I
# >use  yaird initramfs images with those kernels. For kernel
# >2.6.33.4 though  I had to patch some files.
# >
# > I like yaird for the small images and I avoid any kernel-specific
# >modules as it's more portable across kernel versions.
# 
# I am happy to hear that others find yaird usefull too.
# 
# And I am especially excited that you provide patches to make it work
# with recent kernels!
# 
# 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.

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?
 
# >Though the patch for /usr/sbin/yaird doesn't quite fit into this
# >report I filed it inline. Maybe it's better suited for the man
# >page.
# >
# >It tried to fix the copy function using
# >File::Copy::Recursive::rmove but that fails due to inadequate
# >special file handling. Didn't find a better solution, so just
# >giving an annotation for users wondering. BTW, it seems this fs
# >boundary copy problem is caused by a debian-specific modification
# >of yaird using secure temporary files/dirs. As my /tmp is a tmpfs,
# >this is due to fail when not using something like:
# > yaird -f directory -o /tmp/initramfs_2.6.33.4
# >Where the target is on the same fs.
# 
# Yes, I think the comment is better suited in the man page - and
# should probably be added to the README as well.
Yep, good idea.

# 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.

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. 

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.. :|
 
  Cheers,

              Nils