Re: [Cooker] mkinitrd fails with kernel 2.4.19-19mdk...
Gary Greene [EMAIL PROTECTED] writes: Subject says it all. The error I got was: [root@seele root]# mkinitrd /boot/initrd-2.4.19-19mdk.img 2.4.19-19mdk mke2fs 1.30 (31-Oct-2002) ioctl: LOOP_SET_FD: Invalid argument Can't get a loopback device I've got the loop.o.gz module loaded, so I don't know what else to do. Here's What does it give to you when trying to manipulate any loop device with losetup? -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] mkinitrd fails with kernel 2.4.19-19mdk...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 11 November 2002 12:34 pm, Guillaume Cottenceau wrote: Gary Greene [EMAIL PROTECTED] writes: Subject says it all. The error I got was: [root@seele root]# mkinitrd /boot/initrd-2.4.19-19mdk.img 2.4.19-19mdk mke2fs 1.30 (31-Oct-2002) ioctl: LOOP_SET_FD: Invalid argument Can't get a loopback device I've got the loop.o.gz module loaded, so I don't know what else to do. Here's What does it give to you when trying to manipulate any loop device with losetup? It doesn't report anything at all. I ran the following command: [root@seele /root]# losetup /dev/loop/0 autosetup.img no message at all. - -- Gary Greene Sent from seele.gvsu.edu 00:55:23 up 3 days, 15:09, 4 users, load average: 3.91, 3.44, 2.88 = Founder and president of GVLUG. Chairman and Project Lead of the E-media Committee of AltReal. PHONE : 331-0562 EMAIL : [EMAIL PROTECTED] [EMAIL PROTECTED] = -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE90JiYVg8c0/GZcW8RAjQ2AJoCNP8rUggIEos1T1A33/Sm+25mvgCfTyEy g+xuiJnkgCLRaCLTcmwCTgs= =1kXQ -END PGP SIGNATURE-
Re: [Cooker] mkinitrd fails after RC2 installation, can't mount XFS
On Sat, 2002-09-07 at 12:10, David Walluck wrote: 2.) How can I run mkinitrd with a different root (i.e. /mnt) if I do happen to get the system to boot some other way? # chroot /mnt ; mkinitrd ARGS ; exit -- Brad Felmey
Re: [Cooker] mkinitrd fails after RC2 installation, can't mount XFS
David Walluck [EMAIL PROTECTED] writes: * running: mkinitrd -v -f /boot/initrd-2.4.19-xfs.img --ifneeded 2.4.19-xfs with root /mnt No module xfs_support found for kernel 2.4.19-xfs * warning: mkinitrd failed at /usr/bin/perl-install/bootloader.pm line 64. here is the why. I'll try to fix this. * starting step `setupBootloader' * to put in modules * warning: Perl v18.884.15 required--this is only v5.8.0, stopped at /usr/bin/perl-install/interactive.pm line 307. hum. Perl going crazy is no good for sure :-(
Re: [Cooker] mkinitrd fails after RC2 installation, can't mount XFS
On Sat, 2002-09-07 at 10:30, Pixel wrote: David Walluck [EMAIL PROTECTED] writes: I use XFS for my root filesystem. After the installation, mkinitrd fails, so that obviously the kernel fails to mount the XFS root filesystem. Unfortunately I can't find any errors being reported by mkinitrd. Right now when I try to use a rescue RAM disk and run the system that way, it tells me that the RAM disk image is too large. My major questions are: 1.) Does mkinitrd ever report any descriptive errors? the interesting information is in /tmp/ddebug.log during install, and in /root/drakx/ddebug.log after install I faced a similar problem with RC1. My disk has reiserfs partitions. Everything is recognized during the install, but the machine fails to reboot for lack of reiserfs module in the initrd. I fortunately had an old kernel (and associated initrd) still on the machine so I could boot with it, uninstall the new kernel and install it again. report.bug.gz attached. Thanks, -- kk1 report.bug.gz Description: GNU Zip compressed data
Re: [Cooker] mkinitrd fails after RC2 installation, can't mount XFS
David Walluck [EMAIL PROTECTED] writes: [...] Right, so it turned out mkinitrd worked, but was never added to lilo (since both mkinitrd and lilo portions of the install fail). One problem the install has is that I have two disks, '/dev/hda' and '/dev/hde'. '/dev/hda' is the first normal IDE disk, and '/dev/hde' is the first disk on the ATA100 controller, which is my boot drive. The install likes to try to use '/dev/hda' simply because it's the first drive, but the installation I was upgrading isn't even located on that drive. The installation resides on 'dev/hde'. nope. The report.bug tells me that DrakX did try to install to hde with hde being drive 0x80 (the first one) alas, the bad thing is that due to the error warning: Perl v18.884.15 required--this is only... bootloader installation went wrong and lilo never got installed. hopefully fixing the pb with the xfs kernel lying around will fix perl going crazy. [...] 'renaming /boot//boot/initrd.img entry by /boot/initrd-2.4.19-8mdk.img' only the message is wrong, not what is done. anyway fixing this. thanks!
Re: [Cooker] mkinitrd fails after RC2 installation, can't mount XFS
Pixel wrote: David Walluck [EMAIL PROTECTED] writes: ddebug.log says nothing about why it fails, but then the bootloader fails too and the install is stuck in a loop. That is interesting because '/mnt/sbin/lilo -r /mnt' from the shell worked fine. The major bug is the install is not adding the 'initrd=' lines to '/etc/lilo.conf' (for any kernel!). Each kernel needs to use its own particular initrd in order for things to work correctly. no kidding! ;p Right, so it turned out mkinitrd worked, but was never added to lilo (since both mkinitrd and lilo portions of the install fail). One problem the install has is that I have two disks, '/dev/hda' and '/dev/hde'. '/dev/hda' is the first normal IDE disk, and '/dev/hde' is the first disk on the ATA100 controller, which is my boot drive. The install likes to try to use '/dev/hda' simply because it's the first drive, but the installation I was upgrading isn't even located on that drive. The installation resides on 'dev/hde'. It should also take care not to use the '/boot/initrd.img' symlink, since this is only good for a particular kernel. i don't understand what's happening. Can you please send me the ddebug.log? or better /root/drakx/report.bug.gz The ddebug is 'tail'-ed during the install, right? I can't seem to find the messages in it that I saw on the console, but I will send you both. You will notice there are '/boot/initrd.img' everywhere in 'lilo.conf', but after the install the lines are gone. Both ways are incorrect. Then it says things like: 'renaming /boot//boot/initrd.img entry by /boot/initrd-2.4.19-8mdk.img' It looks like there's an extra '/boot/' there, but in any case these renamed entries never make it back to 'lilo.conf' . -- Sincerely, David Walluck [EMAIL PROTECTED]
Re: [Cooker] mkinitrd fails after RC2 installation, can't mount XFS
David Walluck wrote: I use XFS for my root filesystem. After the installation, mkinitrd fails, so that obviously the kernel fails to mount the XFS root filesystem. Unfortunately I can't find any errors being reported by mkinitrd. Right now when I try to use a rescue RAM disk and run the system that way, it tells me that the RAM disk image is too large. My major questions are: 1.) Does mkinitrd ever report any descriptive errors? 2.) How can I run mkinitrd with a different root (i.e. /mnt) if I do happen to get the system to boot some other way? 3.) Is the RAM disk a completely different problem? I did some investigating. ddebug.log says nothing about why it fails, but then the bootloader fails too and the install is stuck in a loop. That is interesting because '/mnt/sbin/lilo -r /mnt' from the shell worked fine. *** The major bug is the install is not adding the 'initrd=' lines to '/etc/lilo.conf' (for any kernel!). Each kernel needs to use its own particular initrd in order for things to work correctly. It should also take care not to use the '/boot/initrd.img' symlink, since this is only good for a particular kernel. *** There are some other unrelated bugs. 1.) The installer completely ignores the hostname I enter and uses the one from the DHCP server instead. I need to change it manually after the install finishes. In addition, the auto-generated hostname seems to be incorrect, it's certainly not what the nameserver returns, but it's possible that the DHCP server is returning the wrong hostname. 2.) I have an emu10k1, and the install incorrectly uses the ALSA drivers. I don't think they work well, and they should not be preferred over the OSS drivers because, for example, you cannot use the mixer with ALSA. The install gives no option to choose the sound driver, however if I run 'draksound' after the install, it will choose the OSS driver (or at least does not provide an ALSA option). 3.) drakxservices (newt version) displays nothing but 'OK' and 'Cancel' buttons. ntsysv from console works fine, however. -- Sincerely, David Walluck [EMAIL PROTECTED]
Re: [Cooker] mkinitrd fails after RC2 installation, can't mount XFS
On Sun, 2002-09-08 at 06:18, David Walluck wrote: It's cooker, but the install says RC2. I can't get the real RC2 (RC1, whatever) because as far as I can tell they are only offered as .iso files, and I don't have a CD burner in my computer. I only do the HTTP or FTP based installs. Hi David, You don't need a CD burner; you can mount the ISO itself while it's sitting on your hard drive, copy the files, and do a hard drive install. Obviously a space muncher though :-) Damon
Re: [Cooker] mkinitrd fails after RC2 installation, can't mount XFS
David Walluck [EMAIL PROTECTED] writes: ddebug.log says nothing about why it fails, but then the bootloader fails too and the install is stuck in a loop. That is interesting because '/mnt/sbin/lilo -r /mnt' from the shell worked fine. The major bug is the install is not adding the 'initrd=' lines to '/etc/lilo.conf' (for any kernel!). Each kernel needs to use its own particular initrd in order for things to work correctly. no kidding! ;p It should also take care not to use the '/boot/initrd.img' symlink, since this is only good for a particular kernel. i don't understand what's happening. Can you please send me the ddebug.log? or better /root/drakx/report.bug.gz
Re: [Cooker] mkinitrd fails
Patrick Kennedy [EMAIL PROTECTED] writes: Looking on vc3, I see that mkinitrd failed in the module: /usr/bin/perl-install/bootloader.pm i'd love to have the ddebug.log containing the precise error of mkinitrd. for this, you can for example mail me the report.bug to get it: during install, switch to console 2, put a fat floppy in floppy drive, and type bug - it will put report.bug on floppy and this file interests me :) thanks, cu Pixel.
Re: [Cooker] mkinitrd + ext3 + recent kernels
Silvan [EMAIL PROTECTED] writes: I'm _not_ keeping up with Cooker and the latest betas, due to a small pipe. However, I've had someone send me the mkinitrd from a recent beta (pre RC1) and it seems this still hasn't been addressed. if [ $rootfs != ext3 -a -z $rootfsopts -a -n $ifneeded -a -z $MODULES -a -z $splash ]; then if [ -n $verbose ]; then echo Rootfs is not ext3, there is no rootfs special options, and echo no modules are needed -- not building initrd image. fi exit 0 fi This assumes that if the rootfs is ext3 then an initrd is needed. Presumably because Mandrake patched ext3 into kernels long before it got incorporated at or around 2.4.15, and you assume that if ext3 exists it's because the user is using one of your kernels, and that it was compiled with ext3 as a module. Looks to me like this hard coding for ext3 was a quick kludge which has outlived its usefulness. No it's because ext3 FS is compatible with ext2 FS so as there is no standard way to tell the kernel which FS to use for rootFS, we need to manually mount ext3 in the initrd and pivot_root. But anyway of course we assume you're using our kernel. We don't support your kernel if you use XFS for rootfs with XFS as built-in, for example, just as for ext3. -- Guillaume Cottenceau - http://www.frozen-bubble.org/
Re: [Cooker] mkinitrd-3.1.6-17mdk is comatized...
Oden Eriksson [EMAIL PROTECTED] writes: mkinitrd -v /boot/initrd-2.4.17-5mdksmp-TEST.img 2.4.17-5mdksmp And nothing happens for a _very_ long time, it seems mkinitrd is comatized... Anyone else experiencing this problem ? Can you also check if stating of filesystems is reasonably quick (do df and check if speed is normal). -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] mkinitrd-3.1.6-18mdk (what ever happened to it?)
Oden Eriksson [EMAIL PROTECTED] writes: Hi again. A while back I was very pleased with the mkinitrd script because it was so much faster than in Mandrake 7.2, now something has happened to it and there's suddenly not much difference in execution time. The use of diet libc speeded up this process a great deal. Somewhere in the evolution of mkinitrd it only took a couple of seconds to make a ramdisk, now it takes at least ten seconds (up to a minute if there's a softlink to the source...). Why is that? Because the find is now made by shell globbing which is rather slow. I'll have to find a better way to do the find. I still have the same hardware. Is it all in the sh_find function? It seems to scan through the directories over and over and yet over again. It makes no sence to me... -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] mkinitrd-3.1.6-17mdk is comatized...
Hi ! On Thu, Jan 17, 2002 at 12:19:00PM +0100, Guillaume Cottenceau wrote: Oden Eriksson [EMAIL PROTECTED] writes: mkinitrd -v /boot/initrd-2.4.17-5mdksmp-TEST.img 2.4.17-5mdksmp And nothing happens for a _very_ long time, it seems mkinitrd is comatized... Anyone else experiencing this problem ? Yes, already told that this is happening to me, but failed to notice that with the latest version it seems to be getting worse and that the load also is much higher than with 16mdk (I skipped/missed 17mdk). Can you also check if stating of filesystems is reasonably quick (do df and check if speed is normal). df is as fast as usual on both my desktop and laptop system. Regards, Reinhard -- Software-Engineer, Developer for Embedded Devices Project: HyperPen Tablet USB Driver for Linux GnuPG Public Key available on request msg51401/pgp0.pgp Description: PGP signature
Re: [Cooker] mkinitrd-3.1.6-18mdk.i586.rpm (still the same error.)
Hi Oden! On Thu, Jan 17, 2002 at 02:10:38AM +0100, Oden Eriksson wrote: Hi, This won't work: It works fine on my system, all the modules previously taken from the build path are now ignored. But it's still damn slow, on my AMD-K62 500 Mhz system it took I think about a minute to build the initrd image... It was already slow since 16mdk, but I did not notice it that much before on my AMD Duron Laptop. Another bug (I did install the newest devfsd from 1.3.18, but not yet reboot, maybe this cures the problem): loop.o module is not loaded (modprobe) with the current version. And a final problem: Temporary files of initrd are not removed when a problem appears (like a missing loop device). Please remove them either on startup (better solution for debugging :) or after the error occured With best regards, Reinhard Katzmann -- Software-Engineer, Developer for Embedded Devices Project: HyperPen Tablet USB Driver for Linux GnuPG Public Key available on request msg51402/pgp0.pgp Description: PGP signature
RE: [Cooker] mkinitrd-3.1.6-18mdk (what ever happened to it?)
Because the find is now made by shell globbing which is rather slow. I'll have to find a better way to do the find. Move find into /bin? It is basic (and useful) enough to be available early. -andrej
Re: [Cooker] mkinitrd-3.1.6-18mdk.i586.rpm (still the same error.)
Reinhard Katzmann [EMAIL PROTECTED] writes: But it's still damn slow, on my AMD-K62 500 Mhz system it took I think about a minute to build the initrd image... It was already slow since 16mdk, but I did not notice it that much before on my AMD Duron Laptop. I'll take care of that. Another bug (I did install the newest devfsd from 1.3.18, but not yet reboot, maybe this cures the problem): loop.o module is not loaded (modprobe) with the current version. Why should it take the loop.o module anyway? And a final problem: Temporary files of initrd are not removed when a problem appears (like a missing loop device). Please remove them either on startup (better solution for debugging :) or after the error occured I'll throw an eye but I don't promise anything. -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] mkinitrd-3.1.6-18mdk (what ever happened to it?)
Borsenkow Andrej [EMAIL PROTECTED] writes: Move find into /bin? It is basic (and useful) enough to be available early. That's an easy way, right :-). It's 50 kbytes. We probably can afford this. -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] mkinitrd-3.1.6-18mdk.i586.rpm (still the same error.)
Hi Guillaume, On Thu, Jan 17, 2002 at 01:09:37PM +0100, Guillaume Cottenceau wrote: Reinhard Katzmann [EMAIL PROTECTED] writes: Another bug (I did install the newest devfsd from 1.3.18, but not yet reboot, maybe this cures the problem): loop.o module is not loaded (modprobe) with the current version. Why should it take the loop.o module anyway? Because otherwise there is no /dev/loop# device accessable, so the initrd image can not be created. (Maybe the mdk kernel do include the loop support in the kernel, I'm one of those who like to have as much stuff as possible outside the kernel, I don't usually need the loopback device). Regards, Reinhard -- Software-Engineer, Developer for Embedded Devices Project: HyperPen Tablet USB Driver for Linux GnuPG Public Key available on request msg51417/pgp0.pgp Description: PGP signature
Re: [Cooker] mkinitrd-3.1.6-18mdk.i586.rpm (still the same error.)
Reinhard Katzmann [EMAIL PROTECTED] writes: Hi Guillaume, On Thu, Jan 17, 2002 at 01:09:37PM +0100, Guillaume Cottenceau wrote: Reinhard Katzmann [EMAIL PROTECTED] writes: Another bug (I did install the newest devfsd from 1.3.18, but not yet reboot, maybe this cures the problem): loop.o module is not loaded (modprobe) with the current version. Why should it take the loop.o module anyway? Because otherwise there is no /dev/loop# device accessable, so the initrd image can not be created. (Maybe the mdk kernel do include the loop support in the kernel, I'm one of those who like to have as much stuff as possible outside the kernel, I don't usually need the loopback device). It's loaded before uninstalling the kernel : chmou@giants|~| rpm -q --scripts kernel-2.4.17.2mdk-1-1mdk|grep -i loop /sbin/modprobe loop 2 /dev/null /dev/null To be sure the user can regenerate an initrd... -- http://www.linux-mandrake.com/en/club/
Re: [Cooker] mkinitrd-3.1.6-18mdk.i586.rpm (still the same error.)
Guillaume Cottenceau [EMAIL PROTECTED] writes: Chmouel Boudjnah [EMAIL PROTECTED] writes: It's loaded before uninstalling the kernel : chmou@giants|~| rpm -q --scripts kernel-2.4.17.2mdk-1-1mdk|grep -i loop /sbin/modprobe loop 2 /dev/null /dev/null To be sure the user can regenerate an initrd... ?? But kmod will load loop.o when mkinitrd mount -o loop the initrd... normally ?? Remember if rpm -e, the module is not here anymore. -- http://www.linux-mandrake.com/en/club/
Re: [Cooker] mkinitrd-3.1.6-18mdk.i586.rpm (still the same error.)
Chmouel Boudjnah [EMAIL PROTECTED] writes: It's loaded before uninstalling the kernel : chmou@giants|~| rpm -q --scripts kernel-2.4.17.2mdk-1-1mdk|grep -i loop /sbin/modprobe loop 2 /dev/null /dev/null To be sure the user can regenerate an initrd... ?? But kmod will load loop.o when mkinitrd mount -o loop the initrd... normally ?? -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] mkinitrd-3.1.6-18mdk.i586.rpm (still the same error.)
Chmouel Boudjnah [EMAIL PROTECTED] writes: ?? But kmod will load loop.o when mkinitrd mount -o loop the initrd... normally ?? Remember if rpm -e, the module is not here anymore. Of course, /me stupid, sorry. But I have an excuse :-), I don't experience any trouble like that for ages on my machines since: [gc@obiwan ~] cat /etc/modules vfat loop floppy nls_cp437 nfsd -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] mkinitrd-3.1.6-17mdk is comatized...
Oden Eriksson [EMAIL PROTECTED] writes: Hi list, I'm running: mkinitrd -v /boot/initrd-2.4.17-5mdksmp-TEST.img 2.4.17-5mdksmp And nothing happens for a _very_ long time, it seems mkinitrd is comatized... this: time -p mkinitrd -v -f /boot/initrd-2.4.17-5mdksmp-TEST.img 2.4.17-5mdksmp sh -x mkinitrd -v -f /boot/initrd-2.4.17-5mdksmp-TEST.img 2.4.17-5mdksmp give ? -- http://www.linux-mandrake.com/en/club/
Re: [Cooker] mkinitrd-3.1.6-17mdk is comatized...
- Original Message - From: Chmouel Boudjnah [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 16, 2002 10:38 AM Subject: Re: [Cooker] mkinitrd-3.1.6-17mdk is comatized... Oden Eriksson [EMAIL PROTECTED] writes: Hi list, I'm running: mkinitrd -v /boot/initrd-2.4.17-5mdksmp-TEST.img 2.4.17-5mdksmp And nothing happens for a _very_ long time, it seems mkinitrd is comatized... this: time -p mkinitrd -v -f /boot/initrd-2.4.17-5mdksmp-TEST.img 2.4.17-5mdksmp sh -x mkinitrd -v -f /boot/initrd-2.4.17-5mdksmp-TEST.img 2.4.17-5mdksmp give ? Output of this is to huge for this list, I sent it directly to Chmouel.
Re: [Cooker] mkinitrd-3.1.6-17mdk is comatized...
On Wednesdayen den 16 January 2002 08.57, Borsenkow Andrej wrote: Hi list, I'm running: mkinitrd -v /boot/initrd-2.4.17-5mdksmp-TEST.img 2.4.17-5mdksmp And nothing happens for a _very_ long time, it seems mkinitrd is comatized... this: time -p mkinitrd -v -f /boot/initrd-2.4.17-5mdksmp-TEST.img 2.4.17-5mdksmp gives: real 39.36 user 31.78 sys 7.26 (strace log attached.) I recall similar problem when program statted fixed built-in device names that resulted in devfsd attempting to load various modules. What top says during mkinitrd run? BTW if you debug timing problem it is helpful to do strace -r to get relative timestamps (to know how much which call takes). -andrej I think it's fixed with mkinitrd-3.1.6-18mdk (haven't tried it yet...) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Oden Eriksson, Deserve-IT Networks, Jokkmokk, Sweden. | Mandrake Linux release 8.2 (Cooker) for i586 | Current uptime with kernel 2.4.17-5mdksmp: 22 hours 51 minutes | cpu0 @ 799.53 bm, fan 4560 rpm, temp +29°C | cpu1 @ 801.17 bm, fan 4560 rpm, temp +29.5°C
RE: [Cooker] mkinitrd-3.1.6-17mdk is comatized...
Hi list, I'm running: mkinitrd -v /boot/initrd-2.4.17-5mdksmp-TEST.img 2.4.17-5mdksmp And nothing happens for a _very_ long time, it seems mkinitrd is comatized... this: time -p mkinitrd -v -f /boot/initrd-2.4.17-5mdksmp-TEST.img 2.4.17-5mdksmp gives: real 39.36 user 31.78 sys 7.26 (strace log attached.) I recall similar problem when program statted fixed built-in device names that resulted in devfsd attempting to load various modules. What top says during mkinitrd run? BTW if you debug timing problem it is helpful to do strace -r to get relative timestamps (to know how much which call takes). -andrej
Re: [Cooker] mkinitrd-3.1.6-13mdk
Oden Eriksson [EMAIL PROTECTED] writes: What's in ramdisk is only for mounting the / partition, no more is needed, so if you're using ext3, reiserfs module is not needed in ramdisk. A number of times when I have upgraded the kernel, I forgot to fix the depmod and the ramdisk stuff manually. In these rare cases it leaved me with a kernel without modules, other than those in the ramdisk (no nic, etc.). I This is usually solved by Rescue.. must add that the automization doing rpm -U or -i of the kernel works much better now. As I use my md for backups and other important stuff I have to have it accessible at all times. Since my recent change to ext3 on /, the fact that my md is at /mnt/md0 and rfs, I now need to make the ramdisk manually anyway. What I'm trying to say is... if one uses things like md, it would be nice to have mkinitrd check what fs the md is using, and include (or propose to include) that module in the ramdisk, regardless of its mountpoint. I still don't understand why since the modules in the ramdisk will be somewhere on disk anyway so when / is mounted, disk is available thus modules also. Do I make any sense at all? Nope :-). -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] mkinitrd-3.1.6-13mdk
On Wednesdayen den 19 December 2001 13.57, Guillaume Cottenceau wrote: Oden Eriksson [EMAIL PROTECTED] writes: What I'm trying to say is... if one uses things like md, it would be nice to have mkinitrd check what fs the md is using, and include (or propose to include) that module in the ramdisk, regardless of its mountpoint. I still don't understand why since the modules in the ramdisk will be somewhere on disk anyway so when / is mounted, disk is available thus modules also. Do I make any sense at all? Nope :-). Well..., never mind..., I won't try explain this yet another way. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Oden Eriksson, Deserve-IT Networks, Jokkmokk, Sweden. | Mandrake Linux release 8.2 (Cooker) for i586 | Current uptime with kernel 2.4.16-10mdksmp: 1 day 13 hours 10 minutes | cpu0 @ 799.53 bm, fan 4192 rpm, temp +26°C | cpu1 @ 801.17 bm, fan 4500 rpm, temp +27.5°C
Re: [Cooker] mkinitrd-3.1.6-13mdk
Oden Eriksson [EMAIL PROTECTED] writes: Hi, It appears like there is a bug in mkinitrd-3.1.6-13mdk. Because I use ext3 on / (?), no RFS module makes it into the ramdisk. there is no need to have a non / partition type in ramdisk. -- http://www.linux-mandrake.com/en/club/
Re: [Cooker] mkinitrd-3.1.6-13mdk
On Tuesdayen den 18 December 2001 13.42, Chmouel Boudjnah wrote: Oden Eriksson [EMAIL PROTECTED] writes: Hi, It appears like there is a bug in mkinitrd-3.1.6-13mdk. Because I use ext3 on / (?), no RFS module makes it into the ramdisk. there is no need to have a non / partition type in ramdisk. True, but this means that even when a raid is detected, only the raid modules not the fs will be in the ramdisk? What if I had /usr/local as... ntfs (silly I know), that fs module won't be in the ramdisk. I'm trying to understand here. The only reason for bringing it up is that sometimes when I make a mistake, I can get a backup from the md. And, my md is rfs, and the rest is not. It may have been like this for a long time now, but I haven't noticed since I resently went over to ext3 for the / stuff. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Oden Eriksson, Deserve-IT Networks, Jokkmokk, Sweden. | Mandrake Linux release 8.2 (Cooker) for i586 | Current uptime with kernel 2.4.16-10mdksmp: 8 hours 7 minutes | cpu0 @ 799.53 bm, fan 4166 rpm, temp +26°C | cpu1 @ 801.17 bm, fan 4560 rpm, temp +27.5°C
Re: [Cooker] mkinitrd-3.1.6-13mdk
Oden Eriksson [EMAIL PROTECTED] writes: What if I had /usr/local as... ntfs (silly I know), that fs module won't be in the ramdisk. so what, after loading the / partitions it will load the others modules for others partitions. -- http://www.linux-mandrake.com/en/club/
Re: [Cooker] mkinitrd-3.1.6-13mdk
On Tuesdayen den 18 December 2001 15.21, Chmouel Boudjnah wrote: Oden Eriksson [EMAIL PROTECTED] writes: What if I had /usr/local as... ntfs (silly I know), that fs module won't be in the ramdisk. so what, after loading the / partitions it will load the others modules for others partitions. Yes, I understand that. The problems I have had occurs when I forget to fix lilo... Thanks. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Oden Eriksson, Deserve-IT Networks, Jokkmokk, Sweden. | Mandrake Linux release 8.2 (Cooker) for i586 | Current uptime with kernel 2.4.16-10mdksmp: 13 hours 38 minutes | cpu0 @ 799.53 bm, fan 4166 rpm, temp +25°C | cpu1 @ 801.17 bm, fan 4530 rpm, temp +26.5°C
Re: [Cooker] mkinitrd-3.1.6-13mdk
Oden Eriksson [EMAIL PROTECTED] writes: On Tuesdayen den 18 December 2001 15.21, Chmouel Boudjnah wrote: Oden Eriksson [EMAIL PROTECTED] writes: What if I had /usr/local as... ntfs (silly I know), that fs module won't be in the ramdisk. so what, after loading the / partitions it will load the others modules for others partitions. Yes, I understand that. The problems I have had occurs when I forget to fix lilo... Oden -- but what is the problem exactly ? What's in ramdisk is only for mounting the / partition, no more is needed, so if you're using ext3, reiserfs module is not needed in ramdisk. -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] mkinitrd-3.1.6-13mdk
On Wednesdayen den 19 December 2001 00.26, Guillaume Cottenceau wrote: Oden Eriksson [EMAIL PROTECTED] writes: On Tuesdayen den 18 December 2001 15.21, Chmouel Boudjnah wrote: Oden Eriksson [EMAIL PROTECTED] writes: What if I had /usr/local as... ntfs (silly I know), that fs module won't be in the ramdisk. so what, after loading the / partitions it will load the others modules for others partitions. Yes, I understand that. The problems I have had occurs when I forget to fix lilo... Oden -- but what is the problem exactly ? What's in ramdisk is only for mounting the / partition, no more is needed, so if you're using ext3, reiserfs module is not needed in ramdisk. A number of times when I have upgraded the kernel, I forgot to fix the depmod and the ramdisk stuff manually. In these rare cases it leaved me with a kernel without modules, other than those in the ramdisk (no nic, etc.). I must add that the automization doing rpm -U or -i of the kernel works much better now. As I use my md for backups and other important stuff I have to have it accessible at all times. Since my recent change to ext3 on /, the fact that my md is at /mnt/md0 and rfs, I now need to make the ramdisk manually anyway. What I'm trying to say is... if one uses things like md, it would be nice to have mkinitrd check what fs the md is using, and include (or propose to include) that module in the ramdisk, regardless of its mountpoint. Do I make any sense at all? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Oden Eriksson, Deserve-IT Networks, Jokkmokk, Sweden. | Mandrake Linux release 8.2 (Cooker) for i586 | Current uptime with kernel 2.4.16-10mdksmp: 19 hours 1 minute | cpu0 @ 799.53 bm, fan 4245 rpm, temp +27°C | cpu1 @ 801.17 bm, fan 4591 rpm, temp +28.0°C
Re: [Cooker] mkinitrd-3.1.6-13mdk
On Wednesday 19 Dec 2001 00:05, Oden Eriksson wrote: On Wednesdayen den 19 December 2001 00.26, Guillaume Cottenceau wrote: Oden Eriksson [EMAIL PROTECTED] writes: On Tuesdayen den 18 December 2001 15.21, Chmouel Boudjnah wrote: Oden Eriksson [EMAIL PROTECTED] writes: What if I had /usr/local as... ntfs (silly I know), that fs module won't be in the ramdisk. so what, after loading the / partitions it will load the others modules for others partitions. Yes, I understand that. The problems I have had occurs when I forget to fix lilo... Oden -- but what is the problem exactly ? What's in ramdisk is only for mounting the / partition, no more is needed, so if you're using ext3, reiserfs module is not needed in ramdisk. A number of times when I have upgraded the kernel, I forgot to fix the depmod and the ramdisk stuff manually. In these rare cases it leaved me with a kernel without modules, other than those in the ramdisk (no nic, etc.). I must add that the automization doing rpm -U or -i of the kernel works much better now. As I use my md for backups and other important stuff I have to have it accessible at all times. Since my recent change to ext3 on /, the fact that my md is at /mnt/md0 and rfs, I now need to make the ramdisk manually anyway. What I'm trying to say is... if one uses things like md, it would be nice to have mkinitrd check what fs the md is using, and include (or propose to include) that module in the ramdisk, regardless of its mountpoint. Do I make any sense at all? It might make more sense to me if I knew what md was. -- Peter Ruskin, Wrexham, Wales. Registered Linux User No. 219434 ( see http://counter.li.org/ ). Mandrake Linux release 8.1 (Vitamin) for i586 Kernel 2.4.8-34.1mdk-win4lin, XFree86 4.1.0, patch level 21mdk. KDE: 2.2.2. Qt: 2.3.2. Uptime 0 hours 46 minutes. --
Re: [Cooker] mkinitrd-3.1.6-13mdk
On Wednesdayen den 19 December 2001 02.54, Peter Ruskin wrote: On Wednesday 19 Dec 2001 00:05, Oden Eriksson wrote: What I'm trying to say is... if one uses things like md, it would be nice to have mkinitrd check what fs the md is using, and include (or propose to include) that module in the ramdisk, regardless of its mountpoint. Do I make any sense at all? It might make more sense to me if I knew what md was. md = multi device (raid and lvm) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Oden Eriksson, Deserve-IT Networks, Jokkmokk, Sweden. | Mandrake Linux release 8.2 (Cooker) for i586 | Current uptime with kernel 2.4.16-10mdksmp: 21 hours 33 minutes | cpu0 @ 799.53 bm, fan 4272 rpm, temp +26°C | cpu1 @ 801.17 bm, fan 4591 rpm, temp +27.5°C
Re: [Cooker] mkinitrd
Oden Eriksson [EMAIL PROTECTED] writes: Hi all, Some positive things for a change :) I just love the new mkinitrd version, it's so damn fast compared to MDK7.2, Fast? When executing at bootup, you mean? I didn't notice that. Maybe because of dietlibc?... and also the usage of dietlibc is making it awesome and also the best one I've ever seen! Thanks :-). Great job guys! Thanks! Nice to hear that :-). -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] mkinitrd
On Fridayen den 9 November 2001 15.31, Guillaume Cottenceau wrote: Oden Eriksson [EMAIL PROTECTED] writes: Hi all, Some positive things for a change :) I just love the new mkinitrd version, it's so damn fast compared to MDK7.2, Fast? When executing at bootup, you mean? I didn't notice that. Maybe because of dietlibc?... At boot? Does it run at boot I dare to ask... No, I mean when creating the old plain initrd, like mkinird -v -f /boot/initrd.img kernel_ver. I keep all sorts of init ramdisk just in case, my lilo.conf is filled with stuff:) and also the usage of dietlibc is making it awesome and also the best one I've ever seen! Thanks :-). Great job guys! Thanks! Nice to hear that :-). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Oden Eriksson, Deserve-IT Networks, Jokkmokk, Sweden. | Mandrake Linux release 8.2 (Cooker) for i586 | Current uptime with kernel 2.4.13-4mdksmp: 1:50 | cpu0 @ 814.28 bm, fan 4090 rpm, temp +32.0°C | cpu1 @ 815.92 bm, fan 4090 rpm, temp +31°C
Re: [Cooker] mkinitrd
Oden Eriksson [EMAIL PROTECTED] writes: Fast? When executing at bootup, you mean? I didn't notice that. Maybe because of dietlibc?... At boot? Does it run at boot I dare to ask... Well it's executed at boot when it loads modules, mounts the rootfs, etc. No, I mean when creating the old plain initrd, like mkinird -v -f /boot/initrd.img kernel_ver. I keep all sorts of init ramdisk just in case, my lilo.conf is filled with stuff:) Ok I see. I don't know why it's faster. Probably because it creates a FS which is 3 times smaller. -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] mkinitrd
On Fridayen den 9 November 2001 16.05, Guillaume Cottenceau wrote: Oden Eriksson [EMAIL PROTECTED] writes: Fast? When executing at bootup, you mean? I didn't notice that. Maybe because of dietlibc?... At boot? Does it run at boot I dare to ask... Well it's executed at boot when it loads modules, mounts the rootfs, etc. Executed?, it's not that it's extracted into ram by another software, but really _executed_ by its own? This is a part I would really like to learn more about, but I don't know where to look... No, I mean when creating the old plain initrd, like mkinird -v -f /boot/initrd.img kernel_ver. I keep all sorts of init ramdisk just in case, my lilo.conf is filled with stuff:) Ok I see. I don't know why it's faster. Probably because it creates a FS which is 3 times smaller. I don't know either, but it's very nice compared to how it were before. Thanks. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Oden Eriksson, Deserve-IT Networks, Jokkmokk, Sweden. | Mandrake Linux release 8.2 (Cooker) for i586 | Current uptime with kernel 2.4.13-4mdksmp: 2:55 | cpu0 @ 814.28 bm, fan 4166 rpm, temp +30.0°C | cpu1 @ 815.92 bm, fan 4066 rpm, temp +29°C
Re: [Cooker] mkinitrd
Oden Eriksson [EMAIL PROTECTED] writes: [...] Executed?, it's not that it's extracted into ram by another software, but really _executed_ by its own? Linux INITRD scheme: - kernel checks if there is an initrd - kernel uncompresses it into memory - kernel mounts initrd on / - kernel executes /linuxrc and waits for this process to terminate - kernel unmounts / This is a part I would really like to learn more about, but I don't know where to look... Very easy, read `linux/Documentation/initrd.txt'. -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] mkinitrd
On Fridayen den 9 November 2001 16.55, Guillaume Cottenceau wrote: Oden Eriksson [EMAIL PROTECTED] writes: [...] Executed?, it's not that it's extracted into ram by another software, but really _executed_ by its own? Linux INITRD scheme: - kernel checks if there is an initrd - kernel uncompresses it into memory - kernel mounts initrd on / - kernel executes /linuxrc and waits for this process to terminate - kernel unmounts / AHA!!! Crystal clear! I like this way of summaryzation, great thanks! This is a part I would really like to learn more about, but I don't know where to look... Very easy, read `linux/Documentation/initrd.txt'. I will do. Thanks a bunch! -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Oden Eriksson, Deserve-IT Networks, Jokkmokk, Sweden. | Mandrake Linux release 8.2 (Cooker) for i586 | Current uptime with kernel 2.4.13-4mdksmp: 3:21 | cpu0 @ 814.28 bm, fan 4192 rpm, temp +32.0°C | cpu1 @ 815.92 bm, fan 4066 rpm, temp +30°C
RE: [Cooker] mkinitrd
On Fridayen den 9 November 2001 16.05, Guillaume Cottenceau wrote: Oden Eriksson [EMAIL PROTECTED] writes: Fast? When executing at bootup, you mean? I didn't notice that. Maybe because of dietlibc?... At boot? Does it run at boot I dare to ask... Well it's executed at boot when it loads modules, mounts the rootfs, etc. Executed?, it's not that it's extracted into ram by another software, but really _executed_ by its own? Of course not. RAM disk image created by mkinitrd is uncompressed and then mounted. It is never executed directly (and of course no mkinitrd ever runs at boot time). This is a part I would really like to learn more about, but I don't know where to look... Have you already tried /usr/src/linux? Sorry, could not resist :-) -andrej
Re: [Cooker] mkinitrd
On Fridayen den 9 November 2001 16.57, Borsenkow Andrej wrote: On Fridayen den 9 November 2001 16.05, Guillaume Cottenceau wrote: Oden Eriksson [EMAIL PROTECTED] writes: Fast? When executing at bootup, you mean? I didn't notice that. Maybe because of dietlibc?... At boot? Does it run at boot I dare to ask... Well it's executed at boot when it loads modules, mounts the rootfs, etc. Executed?, it's not that it's extracted into ram by another software, but really _executed_ by its own? Of course not. RAM disk image created by mkinitrd is uncompressed and then mounted. It is never executed directly (and of course no mkinitrd ever runs at boot time). Thanks, gc explained this too. It's very interesting to learn this kind of in-deep stuff, but I can't learn everything at once, only small fragments each day. This is a part I would really like to learn more about, but I don't know where to look... Have you already tried /usr/src/linux? Sorry, could not resist :-) No problem, sometimes I speak before I think..., sometimes it's too often..., I wonder if it has to do with age? :) Thanks guys. BTW. Andrej, your mail client breaks the lines in mysterious ways... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Oden Eriksson, Deserve-IT Networks, Jokkmokk, Sweden. | Mandrake Linux release 8.2 (Cooker) for i586 | Current uptime with kernel 2.4.13-4mdksmp: 3:27 | cpu0 @ 814.28 bm, fan 4166 rpm, temp +32.0°C | cpu1 @ 815.92 bm, fan 4090 rpm, temp +30°C
RE: [Cooker] mkinitrd
BTW. Andrej, your mail client breaks the lines in mysterious ways... That's probably remove extra line breaks feature in Outlook XP. I am really fond of wordmail as mail composer but most other features could be spared ...
Re: [Cooker] mkinitrd
On Fridayen den 9 November 2001 17.34, Borsenkow Andrej wrote: BTW. Andrej, your mail client breaks the lines in mysterious ways... That's probably remove extra line breaks feature in Outlook XP. I am really fond of wordmail as mail composer but most other features could be spared ... Aha, I haven't used that one. What's wordmail ? (please don't say it's winword.exe...) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Oden Eriksson, Deserve-IT Networks, Jokkmokk, Sweden. | Mandrake Linux release 8.2 (Cooker) for i586 | Current uptime with kernel 2.4.13-4mdksmp: 4:03 | cpu0 @ 814.28 bm, fan 4166 rpm, temp +32.0°C | cpu1 @ 815.92 bm, fan 4090 rpm, temp +31°C
Re: [Cooker] mkinitrd
Oden Eriksson wrote: On Fridayen den 9 November 2001 17.34, Borsenkow Andrej wrote: BTW. Andrej, your mail client breaks the lines in mysterious ways... That's probably remove extra line breaks feature in Outlook XP. I am really fond of wordmail as mail composer but most other features could be spared ... Aha, I haven't used that one. What's wordmail ? (please don't say it's winword.exe...) It is :-) It is a special mode? of word that is called out of outlook. In Office XP as opposed to Office 2000 it - is really fast even on my system - finally supports correct charset tagging (in Outlook 2000 it sent everything in your main default encoding; now it correctly sends German with umlauts as iso-8859-1 and russian as koi8-r) - of course, fully supports proofing tools. The second (automatic charset) is really great feature. -andrej
Re: [Cooker] mkinitrd-2.5-1mdk
Anton Graham [EMAIL PROTECTED] writes: mkinitrd is now broken, but it's an easy fix. Line 236 still has the old style two arguments to findmodule: ok, thanks. Will fix it.
Re: [Cooker] mkinitrd
the loop.o module *must* be installed before removing the old and running kernel. Otherwise, mkinitrd will fail, and ... well hell :( Is that something that will be changed, or could you point to the preferred way of installing this module? (another rpm perhaps?) it is fixed now is in recent cooker kernels. Thank you Sir =)
Re: [Cooker] mkinitrd
on 7/10/00 1:30 AM, Pixel at [EMAIL PROTECTED] wrote: the loop.o module *must* be installed before removing the old and running kernel. Otherwise, mkinitrd will fail, and ... well hell :( Is that something that will be changed, or could you point to the preferred way of installing this module? (another rpm perhaps?) it is fixed now is in recent cooker kernels. So, is there a chance of getting that also fixed in current release kernels - you know, the ones MandrakeUpdate installs, and then renders the system unusable? Seriously, if one has a ReiserFS system, and then applies the MandrakeUpdate for kernel 2.2.16, the system ends up unusable. This should not be. Harry
Re: [Cooker] mkinitrd
Mandrake Bugs [EMAIL PROTECTED] writes: on 7/10/00 1:30 AM, Pixel at [EMAIL PROTECTED] wrote: the loop.o module *must* be installed before removing the old and running kernel. Otherwise, mkinitrd will fail, and ... well hell :( Is that something that will be changed, or could you point to the preferred way of installing this module? (another rpm perhaps?) it is fixed now is in recent cooker kernels. So, is there a chance of getting that also fixed in current release kernels - you know, the ones MandrakeUpdate installs, and then renders the system unusable? pb is the old kernel preuninstall script, not the new kernels...
Re: [Cooker] mkinitrd
Mike Tracy Holt [EMAIL PROTECTED] writes: [...] the loop.o module *must* be installed before removing the old and running kernel. Otherwise, mkinitrd will fail, and ... well hell :( Is that something that will be changed, or could you point to the preferred way of installing this module? (another rpm perhaps?) it is fixed now is in recent cooker kernels.
Re: [Cooker] mkinitrd
"Mike Tracy Holt" [EMAIL PROTECTED] writes: Hello cooker, I've had this problem in the past with kernel upgrades, then it went away, now it's back. I'm trying to get kernel 2.2.17-0.7mdk installed and I get the following error message when trying to mkinitrd: "mount: Could not find any loop device, and, according to /proc/devices, this kernel does not know about the loop device. (If so, then recompile or 'insmod loop.o'.) Can't get a loopback device" Could you please tell me if I'm hitting a bug or just loosing my mind? pb was in the old %preun. the loop.o module *must* be installed before removing the old and running kernel. Otherwise, mkinitrd will fail, and ... well hell :(
Re: [Cooker] mkinitrd
Pixel [EMAIL PROTECTED] writes: the loop.o module *must* be installed before removing the old and running kernel. Otherwise, mkinitrd will fail, and ... well hell :( (chmou@kenobi)[~]-% rpm -q --scripts kernel-smp preinstall script (through /bin/sh): /sbin/modprobe loop 2 /dev/null /dev/null rm -f /lib/modules/2.2.15-4mdksmp/modules.dep exit 0 postinstall script (through /bin/sh): /sbin/installkernel -a -c 2.2.15-4mdksmp postinstall script (through /bin/sh): /sbin/installkernel -a -c 2.2.17-0.5mdksmp preuninstall script (through /bin/sh): /sbin/modprobe loop 2 /dev/null /dev/null rm -f /lib/modules/2.2.17-0.5mdksmp/modules.dep exit 0 or i did something wrong ? -- MandrakeSoft Inchttp://www.mandrakesoft.com San-Francisco, CA USA --Chmouel
Re: [Cooker] mkinitrd
Pixel wrote: "Mike Tracy Holt" [EMAIL PROTECTED] writes: Hello cooker, I've had this problem in the past with kernel upgrades, then it went away, now it's back. I'm trying to get kernel 2.2.17-0.7mdk installed and I get the following error message when trying to mkinitrd: "mount: Could not find any loop device, and, according to /proc/devices, this kernel does not know about the loop device. (If so, then recompile or 'insmod loop.o'.) Can't get a loopback device" Could you please tell me if I'm hitting a bug or just loosing my mind? pb was in the old %preun. the loop.o module *must* be installed before removing the old and running kernel. Otherwise, mkinitrd will fail, and ... well hell :( Is that something that will be changed, or could you point to the preferred way of installing this module? (another rpm perhaps?) Thanks, Mike
