[Cooker] mkinitrd apocalypse?
Hi, * Tue Apr 1 2003 Guillaume Cottenceau <[EMAIL PROTECTED]> 3.4.43-1mdk - merge RH version - add automatic modules deps handling (#3614 and so many more..) - this makes two good reasons to plank the children My tests show that it should work for most people. If you could test it and report any problem, it would help. Don't forget to not overwrite your existing initrd, in case the produced initrd is buggy :)! I'm particularly interested in lvm-on-root configs (the code changed because RH added support for it), raid, loopback; all of them I didn't test, thus possibly broke. http://people.mandrakesoft.com/~gc/pkgs/mkinitrd-3.4.43-1mdk.i586.rpm -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] mkinitrd fails with kernel 2.4.19-19mdk...
Gary Greene <[EMAIL PROTECTED]> writes: > > 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. Jeeze.. have you tried to investigate a bit further? Strace? Another loop device? Dmesg? Anything? I can't sit in front of your machine and type for you :(. -- 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 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/
[Cooker] mkinitrd fails with kernel 2.4.19-19mdk...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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 my current config: kernel: 2.4.19-16mdk mkinitrd: 3.1.6-33mdk [root@seele proc]# cat modules loop 11376 0 (autoclean) nfsd 66576 8 (autoclean) lockd 46480 1 (autoclean) [nfsd] sunrpc 60188 1 (autoclean) [nfsd lockd] ipx17124 11 (autoclean) isofs 25652 1 (autoclean) inflate_fs 17892 0 (autoclean) [isofs] floppy 49340 0 (autoclean) binfmt_misc 5696 1 appletalk 21668 12 (autoclean) lp 6720 1 parport_pc 21672 1 parport23936 1 [lp parport_pc] r128 75352 15 agpgart31840 3 (autoclean) af_packet 13000 1 (autoclean) sr_mod 15096 2 (autoclean) eepro100 19096 1 (autoclean) ntfs 72908 1 (autoclean) nls_iso8859-1 2844 3 (autoclean) nls_cp437 4348 1 (autoclean) vfat9588 1 (autoclean) fat31864 0 (autoclean) [vfat] ext3 73736 3 (autoclean) jbd38608 3 (autoclean) [ext3] ide-cd 28712 0 cdrom 26848 0 [sr_mod ide-cd] ide-scsi8212 1 scsi_mod 90372 2 [sr_mod ide-scsi] sb 7668 1 sb_lib 34958 0 [sb] uart401 6628 0 [sb_lib] sound 55732 1 [sb_lib uart401] soundcore 3780 0 [sb_lib sound] usb-uhci 21676 0 (unused) usbcore58304 1 [usb-uhci] rtc 6560 0 (autoclean) reiserfs 169776 3 - -- Gary Greene Sent from seele.gvsu.edu 14:42:09 up 1 day, 4:55, 3 users, load average: 0.42, 0.13, 0.12 = 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) iD8DBQE9zWcXVg8c0/GZcW8RAkeZAJ4/Iyql/QuBs1gl/OqtB9OD9DSN7gCfQNKY eFUQKihggmDVzMvxMt4wkbk= =kDX7 -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 ; exit -- Brad Felmey
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 <[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
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: > * 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
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 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 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]>
[Cooker] mkinitrd and mkbootdisk failed on install
hi, how u all doing. Well, on the installing of the mdk 9.0 beta 4, the install went ok until i'm asked about the boot, then a msg apeared that said "mkinitrd failed" , then the installing went fine until other msg apeared "mkbootdisk failed". I thougt that i could make the bootdisk from linux, but when boot the PC the system stopped on the line "LI", that's the begining of "LILO". Tried the bootdisk from mdk 8.1 but said something like the system were not compatible. Used the rescue disk (CD1) but when asked for re-installing the boot it failed again. So my only choice was reinstalling windows boot. Hope the problem is clear and i'll be waiting your answer. Thanks Gonzalo Avaria [EMAIL PROTECTED] _ Do You Yahoo!? Información de Estados Unidos y América Latina, en Yahoo! Noticias. Visítanos en http://noticias.espanol.yahoo.com
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/
[Cooker] mkinitrd + ext3 + recent kernels
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. The problem is that if someone compiles a recent kernel, has an ext3 rootfs, and said filesystem is compiled into the kernel; when the user employs"make install" to install it, your installkernel script calls mkinitrd (with the correct --ifneeded switch) and the above logic dictates that mkinitrd will create an initrd to load ext3, even though it's totally useless in this case. (Not harmful; just useless.) This was a source of concern to me in trying to compile a kernel for which no initrd was necessary. I kept getting one, no matter what. I finally mounted one to see what was in there, and puzzled this out. I'm not sure what the best all things to all people solution is. Maybe you'll feel some need to support older, patched kernels or whatever. My own fix was: if [ -z "$rootfsopts" -a -n "$ifneeded" -a -z "$MODULES" -a -z "$splash" ]; then if [ -n "$verbose" ]; then echo "There are no rootfs special options, and no modules are needed." echo "-- not building initrd image." fi exit 0 fi Just tested. Worked as designed. No initrd was created, no reference to such in /etc/lilo.conf, and all is well. For me anyway. Guess I should try with ext3 compiled as module, but it looks like it would catch that and deal with it appropriately. -- Michael McIntyre zone 6b in SW VA Silvan Pagan umount /mnt/windows;mke2fs /dev/hde1;tune2fs -j /dev/hde1 www.geocities.com/Paris/Rue/5407/index.html
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-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.)
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.)
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.)
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 (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.)
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?)
> > 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.)
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-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 (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...
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/
[Cooker] mkinitrd-3.1.6-18mdk (what ever happened to it?)
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? 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... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Oden Eriksson, Deserve-IT Networks/HFE Systems, Jokkmokk, Sweden. | Mandrake Linux release 8.2 (Cooker) for i586 | Current uptime with kernel 2.4.17-5mdksmp: 1 day 55 minutes | cpu0 @ 799.53 bm, fan 4560 rpm, temp +30°C | cpu1 @ 801.17 bm, fan 4530 rpm, temp +30.5°C
[Cooker] mkinitrd-3.1.6-18mdk.i586.rpm (still the same error.)
Hi,
This won't work:
fmPath=`(cd /lib/modules/$kernel; sh_find ./ $modName.o.gz | grep -v build)`
As the magic seems to happen in the "sh_find" function.
# sh_find
sh_find() {
if [ -n "$2" ]; then [ -r $1$2 ] && echo $1$2; else echo "$1"*; fi
for i in "$1"*; do
[ -d $i ] && sh_find $i/ $2
done
}
It has to be something like:
IGNOREDIRS="build"
And a more clever "sh_find" function, I don't know how, I'm too tired right
now... Why is there a "build" softlink in there anyway???
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| Oden Eriksson, Deserve-IT Networks/HFE Systems, Jokkmokk, Sweden.
| Mandrake Linux release 8.2 (Cooker) for i586
| Current uptime with kernel 2.4.17-5mdksmp: 1 day 47 minutes
| cpu0 @ 799.53 bm, fan 4591 rpm, temp +30°C
| cpu1 @ 801.17 bm, fan 4500 rpm, temp +29.5°C
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...
- 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...
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...
> > 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
[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.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Oden Eriksson, Deserve-IT Networks, Jokkmokk, Sweden. | Mandrake Linux release 8.2 (Cooker) for i586 | Current uptime with kernel 2.4.17-5mdksmp: 18 minutes | cpu0 @ 799.53 bm, fan 4500 rpm, temp +30°C | cpu1 @ 801.17 bm, fan 4530 rpm, temp +30.0°C mkinitrd.strace.gz Description: GNU Zip compressed data
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: > > 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 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-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 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
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 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: > 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 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: > 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/
[Cooker] mkinitrd-3.1.6-13mdk
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. [root@media /]# mount /dev/hda6 on / type ext3 (rw) none on /proc type proc (rw) none on /dev/pts type devpts (rw,mode=0620) none on /dev/shm type tmpfs (rw) /dev/hda3 on /mnt/mp3 type reiserfs (rw,notail) /dev/hda5 on /mnt/redhat type ext2 (rw) /dev/hda1 on /mnt/windows type vfat (rw,iocharset=iso8859-1,codepage=850) /dev/hda8 on /usr type ext3 (rw) /dev/hda7 on /var type ext3 (rw) /proc/bus/usb on /proc/bus/usb type usbdevfs (rw,devmode=0664,devgid=43) 192.168.100.2:/mnt/Cooker on /mnt/Cooker type nfs (ro,nosuid,rsize=8192,wsize=8192,addr=192.168.100.2) [root@media /]# mkinitrd -v -f /boot/initrd-2.4.16-10mdk.img 2.4.16-10mdk Using modules: ./kernel/fs/jbd/jbd.o ./kernel/fs/ext3/ext3.o /sbin/nash -> /tmp/initrd.yT3fnU/bin/nash /sbin/insmod-DIET -> /tmp/initrd.yT3fnU/bin/insmod Loading module jbd with options Loading module ext3 with options Contents of RCFILE: #!/bin/nash echo "Loading jbd module" insmod /lib/jbd.o echo "Loading ext3 module" insmod /lib/ext3.o echo Mounting /proc filesystem mount -t proc /proc /proc echo Creating root device mkrootdev /dev/root echo 0x0100 > /proc/sys/kernel/real-root-dev umount /proc echo Mounting root filesystem mount --ro -t ext3 /dev/root /sysroot pivot_root /sysroot /sysroot/initrd echo Remounting devfs at correct place if necessary handledevfs Creating filesystem with size 286KB and 45 inodes mke2fs 1.25 (20-Sep-2001) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Oden Eriksson, Deserve-IT Networks, Jokkmokk, Sweden. | Mandrake Linux release 8.2 (Cooker) for i586 | Current uptime with kernel 2.4.16-10mdksmp: 1 hour 36 minutes | cpu0 @ 799.53 bm, fan 4192 rpm, temp +27°C | cpu1 @ 801.17 bm, fan 4560 rpm, temp +28.5°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
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
> > 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 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
> > 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.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
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.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: > > 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 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: > 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/
[Cooker] mkinitrd
Hi all, Some positive things for a change :) I just love the new mkinitrd version, it's so damn fast compared to MDK7.2, and also the usage of dietlibc is making it awesome and also the best one I've ever seen! Great job guys! -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Oden Eriksson, Deserve-IT Networks, Jokkmokk, Sweden. | Mandrake Linux release 8.2 (Cooker) for i586 | Current uptime with kernel 2.4.13-4mdksmp: 23:35 | cpu0 @ 814.28 bm, fan 4166 rpm, temp +33.0°C | cpu1 @ 815.92 bm, fan 4066 rpm, temp +32°C
[Cooker] mkinitrd
I tried to install cooker today which wasn't a total succes. I couldn't get it to setup lilo-bootloader what seems to me somewhat important.:) I have the cooker on one reiserfs-partion and i get as error-messages in ddebug.log * starting step `setupBootloader' * to put in modules * no scsi devices are available * no scsi devices are available * default cancel_clicked * running: mkinitrd -f /boot/initrd-2.2.17-29mdk.img --ifneeded 2.2.17-29mdk wit h root /mnt bash: error while loading shared libraries: libtermcap.so.2: cannot open shared object file: No such file or directory * warning: mkinitrd failed at /usr/bin/perl-install/bootloader.pm line 73. * writing lilo config to /mnt/etc/lilo.conf * Installing boot loader... * running: lilo 2> /tmp/.error with root /mnt * warning: lilo failed at /usr/bin/perl-install/bootloader.pm line 470. * warning: lilo failed at /usr/bin/perl-install/bootloader.pm line 470. * warning: already displayed at /usr/bin/perl-install/install_steps_interactive. pm line 932. Can anybody say what went wrong and how i can install a working cooker.
[Cooker] mkinitrd fail with hackkernel-smp-2.4.0-0.31
** Forwarding message from Jim Bradley <[EMAIL PROTECTED]> on From: Jim Bradley <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: mkinitrd fail with hackkernel-smp-2.4.0-0.31 I just tried to install hackkernel-smp-2.4.0-0.31mdk.i586.rpm, and get an error message "No module aic7xxx found for kernel 2.4.0-0.31mdksmp" when I try to build an initrd module with mkinitrd. Jim Bradley -- Maryville, MO USA ([EMAIL PROTECTED])
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.
[Cooker] mkinitrd-2.5-1mdk
Okay, looks like this one got eaten.
mkinitrd is now broken, but it's an easy fix. Line 236 still has the old
style two arguments to findmodule:
--- mkinitrd.orig Mon Aug 21 07:04:35 2000
+++ mkinitrdWed Aug 23 12:57:56 2000
@@ -233,7 +233,7 @@
fi
fs=$(awk '$2 == "/" { print $3 }' /etc/fstab)
-[ -n "$fs" -a "$fs" != "ext2" ] && findmodule "" $fs
+[ -n "$fs" -a "$fs" != "ext2" ] && findmodule $fs
# check to see if we need to set up a loopback filesystem
--
Anton GrahamGPG ID: 0x18F78541
<[EMAIL PROTECTED]> RSA key available upon request
Don't try to outweird me, three-eyes. I get stranger things than you free
with my breakfast cereal."
-- Zaphod Beeblebrox [Douglas Adams, "Hithiker's Guide to the Galaxy"]
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
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
> > > 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
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
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
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
"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 :(
[Cooker] mkinitrd
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? Mike
[Cooker] mkinitrd broken! (was Re: Kernel panic w/ 2.2.16-10mdk)
Quel Qun wrote: > Since I am obviously not the only one having this problem, I now feel there > is definitely something broken (kernel or mkinitrd?). Also, grub often tells > me that the initrd.img is corrupted or contains bad data. Lilo tells me > there is a hole in the map. I had similar problems. mkinitrd seems to be broken. No matter what kernel I used my reiserfs root fs could never be mounted. A solution is to recompile the kernel with reiserfs not as module but inside the kernel. Then you don't need an initrd. Cheers, Andreas
