-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Andree,
Andree Leidenfrost wrote:
>>Since the mondo package complains in its documentation and the program
>>itself about the stock debian kernels
>
> Can you point out where exactly the mondo package and the program
> (mondoarchive I presume) complain about the kernel?
>
> In essence, README.Debian of the mindi package tries to convey that the
> fact that stock 2.4 i386 kernels are fine and that all stock 2.6 kernels
> are fine >= 2.6.6. I am sure there may be contradicting information
> elsewhere. It would be great if you could point out where it is and I
> shall amend.
I guess a lot of the complaining is done in places like
/usr/share/doc/mondo-doc/html/faqbooting.html
now (I think I came across more assassination in old locations while
googling). mondoarchive itself complains in mondo/common/libmondo-devices.c
#ifndef __FreeBSD__
if (!ask_me_yes_or_no
("Are you confident that your kernel is a sane,
sensible, standard
Linux kernel? Say 'no' if you are using a Gentoo <1.4 or Debian <3.0,
please."))
#endif
Now I'm running etch, on a kernel that has a config that was once
(probably years ago) derived from a stock kernel. So it probably still
applies to me.
>>I have been trying to build into
>>my (already custom) kernel the lines needed to provide other support.
>>Specifically from the docs (I think I have all the rest)
>>
>>* stable loopfs support, which means it really needs to be 2.2.19 or
>>2.4.7 (or later)
>>* initrd ramdisk support (built-in)
>
> You are referring to
> file:///usr/share/doc/mondo-doc/html/kernelsupport.html, is that
> correct?
Yes, thanks.
>>It would be useful to know which CONFIG lines to put in my .config file
>>so I could do this. I have tried to add
>>
>>-=- snip
>>
>>#
>># Block devices
>>#
>>CONFIG_BLK_DEV_FD=y
>># CONFIG_BLK_DEV_XD is not set
>># CONFIG_PARIDE is not set
>># CONFIG_BLK_CPQ_DA is not set
>># CONFIG_BLK_CPQ_CISS_DA is not set
>># CONFIG_BLK_DEV_DAC960 is not set
>># CONFIG_BLK_DEV_UMEM is not set
>># CONFIG_BLK_DEV_COW_COMMON is not set
>>CONFIG_BLK_DEV_LOOP=y
>># CONFIG_BLK_DEV_CRYPTOLOOP is not set
>># CONFIG_BLK_DEV_NBD is not set
>># CONFIG_BLK_DEV_SX8 is not set
>># CONFIG_BLK_DEV_UB is not set
>>CONFIG_BLK_DEV_RAM=y
>>CONFIG_BLK_DEV_RAM_COUNT=16
>>CONFIG_BLK_DEV_RAM_SIZE=4096
>>CONFIG_BLK_DEV_INITRD=y
>># CONFIG_LBD is not set
>>
>>-=-
>
>
> At first glance, this looks alright. What kernel version is this,
> 2.6.14?
Yes. But the plot has thickened since I submitted my report. I made the
following changes since I noted mondoarchive tries insmod:
> # Block devices
> #
> CONFIG_BLK_DEV_FD=y
> # CONFIG_BLK_DEV_XD is not set
> # CONFIG_PARIDE is not set
> # CONFIG_BLK_CPQ_DA is not set
> # CONFIG_BLK_CPQ_CISS_DA is not set
> # CONFIG_BLK_DEV_DAC960 is not set
> # CONFIG_BLK_DEV_UMEM is not set
> # CONFIG_BLK_DEV_COW_COMMON is not set
> CONFIG_BLK_DEV_LOOP=m
> # CONFIG_BLK_DEV_CRYPTOLOOP is not set
> # CONFIG_BLK_DEV_NBD is not set
> # CONFIG_BLK_DEV_SX8 is not set
> # CONFIG_BLK_DEV_UB is not set
> CONFIG_BLK_DEV_RAM=y
> CONFIG_BLK_DEV_RAM_COUNT=16
> CONFIG_BLK_DEV_RAM_SIZE=4096
> CONFIG_BLK_DEV_INITRD=y
> # CONFIG_LBD is not set
> # CONFIG_CDROM_PKTCDVD is not set
As you can see I changed BLK_DEV_LOOP to a module rather than built in
(the /dev/loop devices were clearly visible when it was built in BTW).
Although mondoarchive still initially complains bitterly about the lack
of initrd support it *was* then able to mount the images and I could get
a backup done, albeit a FAILSAFE once I guess.
To check initrd support the program does a
cat /proc/devices | grep ramdisk
which comes up blank on that server.
The plot thickens further, in my work machine I tried duplicating this,
and installed both loop and ramdisk support as modules, installed the
new modules, but there it didn't work. Although it made no complaints
about the kernel sanity (the ramdisk entry appeared) it still eventually
failed to loop mount the files later.
>>recompiled and reinstalled the kernel, but this still leaves the program
>>complaining:
>>
>>-=- From mindi
>>
>>Fatal error. Can't loopmount
>>/home/tmp.mondo.11814/tmp.mondo.7097/mindilinux/7235/mountpoint.7235;
>>does your kernel support loopfs? If not, please recompile your kernel.
>>Your Linux distro is broken.
>
> Maybe the loop devices don't exist? Are you using udev or devfs?
Ah good point. I've just discovered that my home server is not running
udev but my office machine is. That might explain the discrepancy with
/proc/devices. I can install it on my home server if you'd like me to
try that?
> You could try to just mount a iso image file by doing:
>
> mount -o loop <iso file> <mount point>
>
> and see what that gives?
Well, as noted that's working on the machine of the original report now,
but I got it working by removing built in support and compiling module
support. I don't know if it's just that mondo bails if insmod doesn't
work. I can recompile the kernel if you'd like me to test that again.
In any case, I'll try that on my work machine which is still failing at
that point... Hmm, seems to be working on that machine too...
> einstein:/home/colin# mount -o loop debian-31r1a-i386-netinst.iso /cdrom
> einstein:/home/colin# ls -al /cdrom
> total 190
> dr-xr-xr-x 10 root root 4096 2005-12-24 02:17 .
> drwxr-xr-x 23 root root 4096 2006-01-05 09:24 ..
> -r--r--r-- 1 root root 60 2005-12-24 02:17 autorun.bat
> -r--r--r-- 1 root root 29 2005-12-24 02:17 autorun.inf
> lr-xr-xr-x 1 root root 1 2005-12-24 02:17 debian -> .
> dr-xr-xr-x 2 root root 2048 2005-12-24 02:17 .disk
> dr-xr-xr-x 3 root root 2048 2005-12-24 02:17 dists
> dr-xr-xr-x 3 root root 2048 2005-12-24 02:17 doc
> dr-xr-xr-x 4 root root 2048 2005-12-24 02:17 install
> dr-xr-xr-x 2 root root 4096 2005-12-24 02:17 isolinux
> -r--r--r-- 1 root root 37753 2005-12-24 02:17 md5sum.txt
> dr-xr-xr-x 2 root root 2048 2005-12-24 02:17 pics
> dr-xr-xr-x 3 root root 2048 2005-12-24 02:17 pool
> -r--r--r-- 1 root root 10315 2005-12-24 02:17 README.html
> -r--r--r-- 1 root root 72495 2005-11-26 19:52 README.mirrors.html
> -r--r--r-- 1 root root 39790 2005-11-26 19:52 README.mirrors.txt
> -r--r--r-- 1 root root 5341 2005-12-24 02:17 README.txt
> dr-xr-xr-x 3 root root 2048 2005-12-24 02:17 tools
I'll try another mondoarchive on that machine when I get to the office
and see how it goes.
> What does
>
> lsmod | grep loop
>
> give?
>
> What does
>
> modprobe loop
>
> give?
See above, sorry I have changed the scenery since the original report, I
was trying to crack it myself.
>>-=-
>>
>>Checking sanity of your Linux distribution
>>---promptdialogYN---1--- Your kernel has no ramdisk support. That's
>>mind-numbingly stupid but I'll allow it if you're planning to use a
>>failsafe kernel. Are you?
>>
>>-=-
>
>
> Hm, your kernel config looks ok, maybe this is just a consequence of the
> loopfs problem.
No, I think this is a different (though possibly related problem)
- -=-
In mondo/common/libmondo-tools.c
#ifndef __FreeBSD__
if (run_program_and_log_output
("cat /proc/devices | grep ramdisk", FALSE)) {
if (!ask_me_yes_or_no
("Your kernel has no ramdisk support. That's
mind-numbingly stupid
but I'll allow it if you're planning to use a failsafe kernel. Are you?"))
{
// retval++;
log_to_screen
("It looks as if your kernel lacks ramdisk and
initrd support.");
log_to_screen
("I'll allow you to proceed but FYI, if I'm
right, your kernel is
broken.");
}
}
#endif
- -=-
So you can see this is failing because of the lack of the ramdisk entry
in /proc/devices.
>>Is it possible the appropriate CONFIG lines could be placed in
>>README.Debian please?
>
> Hm, I might be able to put .config for the FAILSAFE kernel from
> upstream, but that's still 2.4 I think.
Well, I may be slowly unentangling this anyway. Possibly udev is the
missing link. I won't install it right away in case you'd rather I tried
something else first.
I still have to work out why the office machine is failing the loopback
mount when I did exactly the same thing, but I'll try a manual loopmount
and get back to you on that one.
> All in all, you'd be better advised to use a stock Debian kernel.
> 2.6.15-i486 works certainly fine for me.
I needed RAID support from a fairly recent kernel, and Debian has only
packaged the source up to 2.6.11 and that recently I think. As I
mentioned, the .config I am using came from a Debian stock kernel *once*
but it was probably 2.2.? and certainly much has changed since then. I
might be able to download a more recent image, copy the .config and
customize it I guess.
I'll try an experiment or two in my office box and get back to you. In
the meantime I do have a successful backup to DVD of my home server,
albeit probably without the all singing / all dancing kernel
installation (FAILSAFE was requested).
Thanks for your help, and your hard work packaging this,
CT.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFEAsMU0SwfPjLnaZYRAh44AKD0oqgYCLUjg1qDZE+ZQfJ5rQOroACgtV/U
Em/rqW61UMjquE56umpJp5o=
=1l6M
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
