Hi Thierry, all

First of all, thanks a lot for the further information you provide.

Now, I've looked into the issue with  calling mindi directly specifying
the FAILSAFE kernel, and can vonfirm there is an issue. I attach patch
TryToBeCleverAboutInitrd_BTS324302.diff that fixes the problem for me.
Note that you need to have a 2.4 kernel _running_ when using the
FAILSAFE kernel (see README.Debian in the mindi package). Does this
patch fix the problem with running mindi directly for you?

Further to that, you ask which kernel to use. Upstream says, as you
rightfully point out, to use the FAILSAFE kernel. This is problaby true
for the origianl upstream version but not the packages in Debian. If you
use the Debian packages, it is recommended to use the latest stock
Debian 2.6 kernel available for the Debian version used. Only if a 2.4
kernel is used should the FAILSAFE kernel be specified. Again, this is
covered in README.Debian in the mindi package. Maybe I should just patch
the upstream documentation in the Debian package or something to make
things more clearer. Supposedly putting it in README.Debian is not good
enough. Where did you look first?

On Wed, 2005-10-05 at 21:46 +0200, thierry lathuille wrote: 
> Hello Andree and everyone,
> 
> (Sorry Andree, I've  just noticed that you had sent the previous message to 
> the BTS as well as to me... I make the answer short here !)
> 
> > The failure you report is interesting, indeed. I've tried with a minimum
> > recovery CD myself (excluded all files, booted in expert), and didn't
> > see a problem, neither on a Sarge nor on a Sid system, e.g. grep started
> > fine using the libc6 from the /lib/tls directory. How did things fail
> > for you?
> 
> So, I've made some more experiments...
> 
> Both systems I tested the patches on yesterday use 2.6 kernels, one is my 
> laptop with a real old Sarge, the other one a fresh Ubuntu Breezy, with the 
> same mindi package as unstable and a libc2.3.5. Both behave the same way with 
> both patches : break with the first one (only the libraries in TLS) and 
> succeed with mine.
> 
> I had a closer look at the differences in ldd's output
> 
> - about ld-linux.so :
> 
> old libc6 : ld-linux.so.2 => ld-linux.so.2
> new libc6 : ld-linux.so.2
> So, ok, with the original mindi behaviour, ld-linux.so doesn't get included 
> on 
> the cd. So, ok, nothing can work.
> - for all "normal" libraries, it depends on the kernel...
> 
> kernel 2.4.27 : libc.so.6 => /lib/libc.so.6 
> 
> kernel 2.6.7 : libc6.so.6 => /lib/tls/libc.so.6
> and different again with the 2.6.12 
> 
> And here is the trick, I think : if I call mindi on a system with a 2.6 
> kernel 
> with the first patch, only the libs in tls get included. But if my CD boots 
> with the 2.4 FAILSAFE kernel, I'll need the libs in /lib, that are missing, 
> and not the ones in /lib/tls.
> 
> So, I verified: 
> - system with 2.4 kernel, FAILSAFE kernel on the CD, first patch : ok
> - system with 2.6 kernel, system's 2.6 kernel on the CD, first patch : ok
> - system with 2.6 kernel, FAILSAFE kernel on the CD, first patch : can't find 
> libc6. The second patch is necessary, in order to let mindi include the 
> libraries in /lib.

Hm, as pointed out above using the FAILSAFE kernel on a system actually
running a 2.6 kernel is not recommended a will break (for numerous
reasons). 

> By the way, do you always use your own kernel with mondo ? I haven't looked 
> at 
> the doc for a long time, but I think Hugo insisted that Debian users should 
> use the failsafe kernel - and so do many comments in the code !
> Is it still good advice, or should we rather use our own kernels ? I just 
> tried it, and it seems to work - and my laptop hangs with 2.4.*, anyway...

As I wrote above, use a stock 2.6 Debian kernel for best results.

> > As far as your patch is concerned, I'd generally be happy to just use it
> > if it works (which I believe it does). However, I'd rather see one
> > single command and not a sequence of four. Do you think you could do
> > that? (You may call me anal but you may also check bug #222052 for the
> > same line of argumentation. ;-);-) )
> Well... I've just read #222052 and understand the point. But : 
> - the example shows what happens with piped greps on very big files (many 
> MBs). Here, we don't treat more than a small number of short lines at once.
> - sed programs can be incredibly efficient and short. And I really like it ! 
> I 
> use mondo to clone old PCs in the school where I work, and I use sed to 
> manipulate the Windows registry after restauration - and I would never have 
> thought it could be so easy before learning sed... Though, sed programs (like 
> regexps) get quickly difficult to read and debug, as it's difficult to see 
> the effects step by step, the way you can do it with simple piped commands.
> 
> Well, if I find something really elegant, I'll tell you ! But what I sent 
> yesterday is easy to understand and debug - just what #222052 requested, 
> would I say :-)). 

Comments about your final patch in direct reply to follow.

> Thierry

Cheers
Andree
-- 
Andree Leidenfrost
Sydney - Australia

--- TryToBeCleverAboutInitrd.orig	2005-10-10 20:58:54.000000000 +1000
+++ TryToBeCleverAboutInitrd	2005-10-10 21:17:12.000000000 +1000
@@ -92,7 +92,7 @@
 # If we are using the FAILSAFE kernel, only ensure the correct config files for
 # isolinux and syslinux are used and continue in mindi. Otherwise try to be
 # clever first (and then continue in mindi).
-if [ "${kernelname}" == "FAILSAFE" ] ; then
+if [ "${kernelname}" == "FAILSAFE" -o "${kernelpath}" = "$MINDI_HOME/vmlinuz" ] ; then
   UseExt2
 else
   # What filesystem we are after.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to