Re: prepare 2.6.13
On Tue, Aug 30, 2005 at 11:38:31PM +0200, Erik van Konijnenburg wrote: On Tue, Aug 30, 2005 at 03:26:29PM +0200, Sven Luther wrote: On Tue, Aug 30, 2005 at 10:40:12AM +0200, Marco Amadori wrote: Now, initramfs is nothing more than a file organisation which is a bit different for the initial ramdisk, or is there more to it, and the above code path, for which i have seen no major change recently, will still work ? From memory: You can feed the kernel a file system in eg cramfs format from grub or another boot loader, and it will be treated like initrd. If the boot loader feeds a cpio file to the kernel, AND it contains a file named /init, it will be treated as initramfs. You can also append a cpio file to the kernel, and it will be treated as initramfs. Nice thanks. So, this stuff is feed to the kernel in much the same way the older initrds are, it is just the later handling that is different, right ? The kernel treats initrd and initramfs differently: for initrd, the kernel does a complicated two-stage shuffle with mount, chdir, chroot and ramdisks, while initramfs just gets unpacked into rootfs and the kernel hand over control to /init. Oh, and for initrd the kernel will try to mount devfs. To summarise, to the boot loader the difference between initramfs and initrd is not important, but for initrd-tools or yaird the difference is more than just packaging with cpio or mkcramfs; you'll also need to consider what goes on the image. Ok, it is just a different packaging format. and some special treatment if the initrd is detected as initramfs. What about the appending an cpio file to the kernel kind of thingy. The question is : we want to support nice things like EVMS at boot time? A tool for generating bootable initrd for evms is needed, it is targeted for etch evms support I hope. It seems that none our 3 tools supports it right now. I'll see what can be done about yaird support of EVMS. But right now is the time to investigate those issues, and fix the tools if possible, and not 6-12 month down the road, when we will be in late-freeze situation or something. Agreed. Let's maybe list all the things we want for sucha tool. My personal requisite are : - allow as well for the creation of generic images, as well as minimal ones. - allow for hand selected inclusion list as well as exclusion of modules. - allow to include script as well as mklibs-manipulated binaries and libraries. Hmm, I was not previously aware of mklibs. Just tested it on an unpacked yaird image and found zero size reduction on a sid/i386 box, presumably because none of the included libraries have a _pic.a file. For now I have higher hopes for klibc or uclibc to reduce size, but if you can show how mklibs will pay off, I'm listening. Well, it is extensively used in the debian-installer, so known to work and be worthwhile on each arch. Sure you need the _pic.a stuff installer probably, but it is a worthy goal of using it to make the initramfs as small as possible. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: prepare 2.6.13
Horms wrote: On Mon, Aug 29, 2005 at 07:05:59PM +0200, Maik Zumstrull wrote: Please evaluate just how broken ATAPI-over-SATA really is right now and consider enabling it. AFAIK other distributions have been running with it since 2.6.9 or something, so it can't be all bad from an end-user POV. And I could finally use my DVD drive without compiling my own kernel (which I'm too lazy to do, anyway, so I just don't use the drive). According to correspondence that I had with Jeff Garzik the other day, distributions enabling that option is regarded as folly by upstream as they believe it is still too green. Oh well. I guess I'll just have to hope that it will go stable for .14, as I have been doing for .12 and .13. Thanks for your efforts. signature.asc Description: OpenPGP digital signature
Re: prepare 2.6.13
On Tuesday 30 August 2005 07:47, you wrote: - initrd-tools needs to loose devfs usage. BTW, isn't it time to switch to initramfs ? I saw that ubuntu use initramfs-tools and in debian we have yaird that I personally use since it hit sid to boot from lvm on a md array. My personal believe is that something like yaird will produce smaller intram filesystems, and thus better suited to arches and subarches who have actually trouble with bigger bloated initrds. This is sure but I think will be a really nice feature to have in etch, with initramfs-tools concept we could change hardware quite a few and expect our beloved debian to boot without problem, recognizing at startup that e.g. we changed the mainboard and cpu so the old sata disc is mounted on a sas controller and change the module to load without leaving a un-bootable sistem like out actual mkinitrd and it seems also yaird. I am also a bit curious how initramfs behaves on the kernel wise, i mean i understand and all that it is just a bunch of cpio archives which are copied at the end of the kernel, but, taking the powerpc case for an example, there is either a bootwrapper, like the arch/ppc/boot/openfirmware stuff, or boot loaders, like yaboot, who know how to put the kernel and initrd in ram, and then pass the right info to the kernel to find the ramdisk back (passed as argument in r3/r4 if i remember well. I remebered booting linux from the destkop gui on in my Amiga times... Now, initramfs is nothing more than a file organisation which is a bit different for the initial ramdisk, or is there more to it, and the above code path, for which i have seen no major change recently, will still work ? The question is : we want to support nice things like EVMS at boot time? A tool for generating bootable initrd for evms is needed, it is targeted for etch evms support I hope. It seems that none our 3 tools supports it right now. -- ESC:wq -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: prepare 2.6.13
On Tue, Aug 30, 2005 at 10:40:12AM +0200, Marco Amadori wrote: On Tuesday 30 August 2005 07:47, you wrote: - initrd-tools needs to loose devfs usage. BTW, isn't it time to switch to initramfs ? I saw that ubuntu use initramfs-tools and in debian we have yaird that I personally use since it hit sid to boot from lvm on a md array. My personal believe is that something like yaird will produce smaller intram filesystems, and thus better suited to arches and subarches who have actually trouble with bigger bloated initrds. This is sure but I think will be a really nice feature to have in etch, with initramfs-tools concept we could change hardware quite a few and expect our beloved debian to boot without problem, recognizing at startup that e.g. we changed the mainboard and cpu so the old sata disc is mounted on a sas controller and change the module to load without leaving a un-bootable sistem like out actual mkinitrd and it seems also yaird. Well, agreed, both have their place. I think some of our supported arches will like a yaird-like situation or at least a more user-controlled initrd situation better over a huge bloated all-encompassing initramfs. I am also a bit curious how initramfs behaves on the kernel wise, i mean i understand and all that it is just a bunch of cpio archives which are copied at the end of the kernel, but, taking the powerpc case for an example, there is either a bootwrapper, like the arch/ppc/boot/openfirmware stuff, or boot loaders, like yaboot, who know how to put the kernel and initrd in ram, and then pass the right info to the kernel to find the ramdisk back (passed as argument in r3/r4 if i remember well. I remebered booting linux from the destkop gui on in my Amiga times... Well, yes, but this is not the question, the question is how the kernel knows about initramfs, beyond the way yaboot, lilo, amiboot or whatever gets this info from the user. Now, initramfs is nothing more than a file organisation which is a bit different for the initial ramdisk, or is there more to it, and the above code path, for which i have seen no major change recently, will still work ? The question is : we want to support nice things like EVMS at boot time? A tool for generating bootable initrd for evms is needed, it is targeted for etch evms support I hope. It seems that none our 3 tools supports it right now. But right now is the time to investigate those issues, and fix the tools if possible, and not 6-12 month down the road, when we will be in late-freeze situation or something. Let's maybe list all the things we want for sucha tool. My personal requisite are : - allow as well for the creation of generic images, as well as minimal ones. - allow for hand selected inclusion list as well as exclusion of modules. - allow to include script as well as mklibs-manipulated binaries and libraries. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: prepare 2.6.13
Sven Luther [EMAIL PROTECTED] writes: On Mon, Aug 29, 2005 at 11:40:47AM +0200, Bastian Blank wrote: Hi folks BTW, was 2.6.13 already released ? Or any idea when it will be ? Yes. Yestarday IIRC. Maybe a good plan would be to get 2.6.12 in testing, and then switch to 2.6.13 and initramfs ? Why not to use experimental to 2.6.13 while the team continue to work on 2.6.12 for testing? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: prepare 2.6.13
On Tue, Aug 30, 2005 at 12:12:59PM -0300, Otavio Salvador wrote: Sven Luther [EMAIL PROTECTED] writes: On Mon, Aug 29, 2005 at 11:40:47AM +0200, Bastian Blank wrote: Hi folks BTW, was 2.6.13 already released ? Or any idea when it will be ? Yes. Yestarday IIRC. Maybe a good plan would be to get 2.6.12 in testing, and then switch to 2.6.13 and initramfs ? Why not to use experimental to 2.6.13 while the team continue to work on 2.6.12 for testing? This is the plan. Bastian messed up all the subversion layout though, so we first need to sort this out and reorganize the team before we do some releasing. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: prepare 2.6.13
On Tue, Aug 30, 2005 at 03:26:29PM +0200, Sven Luther wrote: On Tue, Aug 30, 2005 at 10:40:12AM +0200, Marco Amadori wrote: Now, initramfs is nothing more than a file organisation which is a bit different for the initial ramdisk, or is there more to it, and the above code path, for which i have seen no major change recently, will still work ? From memory: You can feed the kernel a file system in eg cramfs format from grub or another boot loader, and it will be treated like initrd. If the boot loader feeds a cpio file to the kernel, AND it contains a file named /init, it will be treated as initramfs. You can also append a cpio file to the kernel, and it will be treated as initramfs. The kernel treats initrd and initramfs differently: for initrd, the kernel does a complicated two-stage shuffle with mount, chdir, chroot and ramdisks, while initramfs just gets unpacked into rootfs and the kernel hand over control to /init. Oh, and for initrd the kernel will try to mount devfs. To summarise, to the boot loader the difference between initramfs and initrd is not important, but for initrd-tools or yaird the difference is more than just packaging with cpio or mkcramfs; you'll also need to consider what goes on the image. The question is : we want to support nice things like EVMS at boot time? A tool for generating bootable initrd for evms is needed, it is targeted for etch evms support I hope. It seems that none our 3 tools supports it right now. I'll see what can be done about yaird support of EVMS. But right now is the time to investigate those issues, and fix the tools if possible, and not 6-12 month down the road, when we will be in late-freeze situation or something. Agreed. Let's maybe list all the things we want for sucha tool. My personal requisite are : - allow as well for the creation of generic images, as well as minimal ones. - allow for hand selected inclusion list as well as exclusion of modules. - allow to include script as well as mklibs-manipulated binaries and libraries. Hmm, I was not previously aware of mklibs. Just tested it on an unpacked yaird image and found zero size reduction on a sid/i386 box, presumably because none of the included libraries have a _pic.a file. For now I have higher hopes for klibc or uclibc to reduce size, but if you can show how mklibs will pay off, I'm listening. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: prepare 2.6.13
On Mon, Aug 29, 2005 at 11:40:47AM +0200, Bastian Blank wrote: Hi folks BTW, was 2.6.13 already released ? Or any idea when it will be ? Also, i believe we need a 2.6.12-6 upload which fix the remaining problems and can go into sarge. Do we have any plans regarding that ? The following tasks needs to be done for 2.6.13: - Merge of the current trees. - Config updates. - initrd-tools needs to loose devfs usage. BTW, isn't it time to switch to initramfs ? Maybe a good plan would be to get 2.6.12 in testing, and then switch to 2.6.13 and initramfs ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: prepare 2.6.13
Bastian Blank wrote: Hi folks The following tasks needs to be done for 2.6.13: - Merge of the current trees. - Config updates. - initrd-tools needs to loose devfs usage. Bastian I'm not shure whether my information is correct, but AFAIK is pcmcia-cs obsoleted with 2.6.13 and one should use PCMCIAutils[1] instead. There is an option in the new kernel to behave like the old ones so one can still use pcmcia-cs. Kind regards Bastian [1] ftp://ftp.kernel.org/pub/linux/utils/kernel/pcmcia/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: prepare 2.6.13
On Mon, Aug 29, 2005 at 11:50:33AM +0200, Sven Luther wrote: BTW, was 2.6.13 already released ? Or any idea when it will be ? The mail arrived 2:17 MEST. Also, i believe we need a 2.6.12-6 upload which fix the remaining problems and can go into sarge. Do we have any plans regarding that ? In preperation. The following tasks needs to be done for 2.6.13: - Merge of the current trees. - Config updates. - initrd-tools needs to loose devfs usage. BTW, isn't it time to switch to initramfs ? Does it work? Bastian -- Beam me up, Scotty! signature.asc Description: Digital signature
Re: prepare 2.6.13
On Mon, Aug 29, 2005 at 12:22:08PM +0200, Bastian Blank wrote: On Mon, Aug 29, 2005 at 11:50:33AM +0200, Sven Luther wrote: BTW, was 2.6.13 already released ? Or any idea when it will be ? The mail arrived 2:17 MEST. Also, i believe we need a 2.6.12-6 upload which fix the remaining problems and can go into sarge. Do we have any plans regarding that ? In preperation. The following tasks needs to be done for 2.6.13: - Merge of the current trees. - Config updates. - initrd-tools needs to loose devfs usage. BTW, isn't it time to switch to initramfs ? Does it work? Supposedly, best time now to find out, don't you think ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: prepare 2.6.13
Bastian Blank wrote: The following tasks needs to be done for 2.6.13: - Merge of the current trees. - Config updates. - initrd-tools needs to loose devfs usage. One thing I'd like to add for the wishlist: Please evaluate just how broken ATAPI-over-SATA really is right now and consider enabling it. AFAIK other distributions have been running with it since 2.6.9 or something, so it can't be all bad from an end-user POV. And I could finally use my DVD drive without compiling my own kernel (which I'm too lazy to do, anyway, so I just don't use the drive). Suspend/Resume support for SATA devices would also be greatly appreciated, but I think that patch actually is badly broken. signature.asc Description: OpenPGP digital signature
Re: prepare 2.6.13
On Mon, Aug 29, 2005 at 12:22:08PM +0200, Bastian Blank wrote: On Mon, Aug 29, 2005 at 11:50:33AM +0200, Sven Luther wrote: BTW, was 2.6.13 already released ? Or any idea when it will be ? The mail arrived 2:17 MEST. Also, i believe we need a 2.6.12-6 upload which fix the remaining problems and can go into sarge. Do we have any plans regarding that ? In preperation. Good, I would rather see at least one more 2.6.12 release before we switch to 2.6.13. I assume you're working on this? Let me know if you need any help w/ this, I'll be playing around w/ initramfs and 2.6.13 config stuff in the meantime. (BTW, I've gone over to [EMAIL PROTECTED], if you need me for anything; I've had enough of freenode.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: prepare 2.6.13
From: Sven Luther [EMAIL PROTECTED] On Mon, Aug 29, 2005 at 12:22:08PM +0200, Bastian Blank wrote: - initrd-tools needs to loose devfs usage. BTW, isn't it time to switch to initramfs ? Does it work? Supposedly, best time now to find out, don't you think ? I saw that ubuntu use initramfs-tools and in debian we have yaird that I personally use since it hit sid to boot from lvm on a md array. The superficial differences between the two tools are that initramfs checks for hardware at boot time and yaird at run time, so initramfs-tools promits to change the underlying hardware and boot equally well. Look at the bts if you want to try yaird, if you have to boot using mdadm, it needs a little patch to work with sid tools. -- ESC:wq -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: prepare 2.6.13
On Mon, Aug 29, 2005 at 07:05:59PM +0200, Maik Zumstrull wrote: Bastian Blank wrote: The following tasks needs to be done for 2.6.13: - Merge of the current trees. - Config updates. - initrd-tools needs to loose devfs usage. One thing I'd like to add for the wishlist: Please evaluate just how broken ATAPI-over-SATA really is right now and consider enabling it. AFAIK other distributions have been running with it since 2.6.9 or something, so it can't be all bad from an end-user POV. And I could finally use my DVD drive without compiling my own kernel (which I'm too lazy to do, anyway, so I just don't use the drive). Suspend/Resume support for SATA devices would also be greatly appreciated, but I think that patch actually is badly broken. Hi Maik, According to correspondence that I had with Jeff Garzik the other day, distributions enabling that option is regarded as folly by upstream as they believe it is still too green. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=319659;msg=57 -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: prepare 2.6.13
On Tue, Aug 30, 2005 at 02:40:01AM +0200, Marco Amadori wrote: From: Sven Luther [EMAIL PROTECTED] On Mon, Aug 29, 2005 at 12:22:08PM +0200, Bastian Blank wrote: - initrd-tools needs to loose devfs usage. BTW, isn't it time to switch to initramfs ? Does it work? Supposedly, best time now to find out, don't you think ? I saw that ubuntu use initramfs-tools and in debian we have yaird that I personally use since it hit sid to boot from lvm on a md array. The superficial differences between the two tools are that initramfs checks for hardware at boot time and yaird at run time, so initramfs-tools promits to change the underlying hardware and boot equally well. Look at the bts if you want to try yaird, if you have to boot using mdadm, it needs a little patch to work with sid tools. My personal believe is that something like yaird will produce smaller intram filesystems, and thus better suited to arches and subarches who have actually trouble with bigger bloated initrds. I am also a bit curious how initramfs behaves on the kernel wise, i mean i understand and all that it is just a bunch of cpio archives which are copied at the end of the kernel, but, taking the powerpc case for an example, there is either a bootwrapper, like the arch/ppc/boot/openfirmware stuff, or boot loaders, like yaboot, who know how to put the kernel and initrd in ram, and then pass the right info to the kernel to find the ramdisk back (passed as argument in r3/r4 if i remember well. Now, initramfs is nothing more than a file organisation which is a bit different for the initial ramdisk, or is there more to it, and the above code path, for which i have seen no major change recently, will still work ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
