Re: [leaf-devel] bering-uclibc4 initrd migration
Am Samstag, 22. Januar 2011, um 17:53:02 schrieb Andrew: > 22.01.2011 01:50, KP Kirchdoerfer пишет: > > Am Freitag, 21. Januar 2011, um 00:25:13 schrieb Andrew: > >> 10.01.2011 20:04, KP Kirchdoerfer пишет: > >>> Andrew; > >>> > >>> can/will you make the changes necessary? I guess you're the one who > >>> knows best what has changed moving to initramfs (only) and what needs > >>> to be done to have initramfs with rootfs. > >>> > >>> I consider the issue described above as serious and like to get it > >>> solved for beta2. > >>> > >>> Anything else that anyone considers as showstopper for a new beta > >>> version? > >>> > >>> kp > >> > >> I've commited new init script into CVS. I use initramfs till actually > >> init call, and before init call I added new rootfs creation and then > >> switching into new rootfs with small wrapper (that mounts /proc and /sys > >> and then transfers control to main init) as init.script. This makes > >> easier work with variables (I don't need to export all kernel > >> variables), but makes a headache when rootfs is smaller than it should > >> be - so for that case I added error processing and booting with > >> initramfs on failure. > >> Cons of this solution: higher memory requirements (it needs 2x >> rootfs size> RAM at booting), but IMHO it isn't big trouble because > >> executables are tiny. And for resource-limited PCs I added option to > >> disable rootfs moving by setting syst_size to 0. > >> > >> It'll be good if someone re-checks code. > > > > Andrew; > > > > while booting the image I see: > > > > LINUXRC: Removing /mnt2 > > LINUXRC: Loaded Packages > > sh: 40M: bad number > > ^^ > > LINUXRC: Creating new rootf.. > > > > > > kp > > Fixed. Nice. Given that the rebuild and testing the image (at least) in qemu runs fine, I think we are ready to tag beta2 (and start release work). Anyone disagree? kp -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] bering-uclibc4 initrd migration
22.01.2011 01:50, KP Kirchdoerfer пишет: > Am Freitag, 21. Januar 2011, um 00:25:13 schrieb Andrew: >> 10.01.2011 20:04, KP Kirchdoerfer пишет: >>> Andrew; >>> >>> can/will you make the changes necessary? I guess you're the one who knows >>> best what has changed moving to initramfs (only) and what needs to be >>> done to have initramfs with rootfs. >>> >>> I consider the issue described above as serious and like to get it >>> solved for beta2. >>> >>> Anything else that anyone considers as showstopper for a new beta >>> version? >>> >>> kp >> I've commited new init script into CVS. I use initramfs till actually >> init call, and before init call I added new rootfs creation and then >> switching into new rootfs with small wrapper (that mounts /proc and /sys >> and then transfers control to main init) as init.script. This makes >> easier work with variables (I don't need to export all kernel >> variables), but makes a headache when rootfs is smaller than it should >> be - so for that case I added error processing and booting with >> initramfs on failure. >> Cons of this solution: higher memory requirements (it needs 2x> rootfs size> RAM at booting), but IMHO it isn't big trouble because >> executables are tiny. And for resource-limited PCs I added option to >> disable rootfs moving by setting syst_size to 0. >> >> It'll be good if someone re-checks code. > Andrew; > > while booting the image I see: > > LINUXRC: Removing /mnt2 > LINUXRC: Loaded Packages > sh: 40M: bad number > ^^ > LINUXRC: Creating new rootf.. > > > kp > Fixed. -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] bering-uclibc4 initrd migration
Am Samstag, 22. Januar 2011, um 12:49:07 schrieb Andrew: > 22.01.2011 01:35, KP Kirchdoerfer пишет: > >> It'll be good if someone re-checks code. > >> > >> P.S. About beta2 - IMHO it'll be good to update kernel before beta2 > >> tagging to latest 2.6.35 minor (currently 2.6.35.10), and possible to > >> update busybox (or we have something that depends on bb version?) > > > > If you ask me, the kernel seems less intrusive and I vote to update. > > How much work will be to update and test busybox yet? > > > > kp > > IMHO busybox update isn't too hard. I expect that it'll be enough just > to replace old version by new one and review config, and port patches.. You've been right; the patches applied, the config changed (I had to set CONFIG_PLATFORM_LINUX=y, otherwise a few applets has been lost, anyway the binary is a little bit smaller than before) - and I was able to boot into a kernel 2.6.35.10 and busybox 1.18.2 iso image with qemu. Will commit later and rebuild everything from scratch. kp -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] bering-uclibc4 initrd migration
22.01.2011 01:35, KP Kirchdoerfer пишет: > >> It'll be good if someone re-checks code. >> >> P.S. About beta2 - IMHO it'll be good to update kernel before beta2 >> tagging to latest 2.6.35 minor (currently 2.6.35.10), and possible to >> update busybox (or we have something that depends on bb version?) > If you ask me, the kernel seems less intrusive and I vote to update. > How much work will be to update and test busybox yet? > > kp IMHO busybox update isn't too hard. I expect that it'll be enough just to replace old version by new one and review config, and port patches.. -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] bering-uclibc4 initrd migration
Am Freitag, 21. Januar 2011, um 00:25:13 schrieb Andrew: > 10.01.2011 20:04, KP Kirchdoerfer пишет: > > Andrew; > > > > can/will you make the changes necessary? I guess you're the one who knows > > best what has changed moving to initramfs (only) and what needs to be > > done to have initramfs with rootfs. > > > > I consider the issue described above as serious and like to get it > > solved for beta2. > > > > Anything else that anyone considers as showstopper for a new beta > > version? > > > > kp > > I've commited new init script into CVS. I use initramfs till actually > init call, and before init call I added new rootfs creation and then > switching into new rootfs with small wrapper (that mounts /proc and /sys > and then transfers control to main init) as init.script. This makes > easier work with variables (I don't need to export all kernel > variables), but makes a headache when rootfs is smaller than it should > be - so for that case I added error processing and booting with > initramfs on failure. > Cons of this solution: higher memory requirements (it needs 2x rootfs size> RAM at booting), but IMHO it isn't big trouble because > executables are tiny. And for resource-limited PCs I added option to > disable rootfs moving by setting syst_size to 0. > > It'll be good if someone re-checks code. Andrew; while booting the image I see: LINUXRC: Removing /mnt2 LINUXRC: Loaded Packages sh: 40M: bad number ^^ LINUXRC: Creating new rootf.. kp -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] bering-uclibc4 initrd migration
Am Freitag, 21. Januar 2011, um 00:25:13 schrieb Andrew: > 10.01.2011 20:04, KP Kirchdoerfer пишет: > > Andrew; > > > > can/will you make the changes necessary? I guess you're the one who knows > > best what has changed moving to initramfs (only) and what needs to be > > done to have initramfs with rootfs. > > > > I consider the issue described above as serious and like to get it > > solved for beta2. > > > > Anything else that anyone considers as showstopper for a new beta > > version? > > > > kp > > I've commited new init script into CVS. I use initramfs till actually > init call, and before init call I added new rootfs creation and then > switching into new rootfs with small wrapper (that mounts /proc and /sys > and then transfers control to main init) as init.script. This makes > easier work with variables (I don't need to export all kernel > variables), but makes a headache when rootfs is smaller than it should > be - so for that case I added error processing and booting with > initramfs on failure. > Cons of this solution: higher memory requirements (it needs 2x rootfs size> RAM at booting), but IMHO it isn't big trouble because > executables are tiny. And for resource-limited PCs I added option to > disable rootfs moving by setting syst_size to 0. I sucessfully built a new buildenv and was able to boot into an image, will have a closer look tomorrow. > It'll be good if someone re-checks code. > > P.S. About beta2 - IMHO it'll be good to update kernel before beta2 > tagging to latest 2.6.35 minor (currently 2.6.35.10), and possible to > update busybox (or we have something that depends on bb version?) If you ask me, the kernel seems less intrusive and I vote to update. How much work will be to update and test busybox yet? kp -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] bering-uclibc4 initrd migration
10.01.2011 20:04, KP Kirchdoerfer пишет: > > Andrew; > > can/will you make the changes necessary? I guess you're the one who knows best > what has changed moving to initramfs (only) and what needs to be done to have > initramfs with rootfs. > > I consider the issue described above as serious and like to get it solved for > beta2. > > Anything else that anyone considers as showstopper for a new beta version? > > kp > I've commited new init script into CVS. I use initramfs till actually init call, and before init call I added new rootfs creation and then switching into new rootfs with small wrapper (that mounts /proc and /sys and then transfers control to main init) as init.script. This makes easier work with variables (I don't need to export all kernel variables), but makes a headache when rootfs is smaller than it should be - so for that case I added error processing and booting with initramfs on failure. Cons of this solution: higher memory requirements (it needs 2x RAM at booting), but IMHO it isn't big trouble because executables are tiny. And for resource-limited PCs I added option to disable rootfs moving by setting syst_size to 0. It'll be good if someone re-checks code. P.S. About beta2 - IMHO it'll be good to update kernel before beta2 tagging to latest 2.6.35 minor (currently 2.6.35.10), and possible to update busybox (or we have something that depends on bb version?) -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] bering-uclibc4 initrd migration
Am Montag, 10. Januar 2011, 19:16:00 schrieb Andrew: > 10.01.2011 20:04, KP Kirchdoerfer пишет: > > Am Donnerstag, 6. Januar 2011, 15:44:37 schrieb KP Kirchdoerfer: > >> Am Donnerstag, 6. Januar 2011, 15:06:42 schrieb Andrew: > >>> 06.01.2011 15:56, KP Kirchdoerfer пишет: > Hi; > > this is from an old mail, but I tested today what happens if > Bering-uClibc3 runs out of memory and what happens on Bering-uClibc4 > box. > > Am Samstag, 12. Juni 2010, 20:17:49 schrieb Andrew: > > Hi. > > I just finished migration from compressed minix initrd to initramfs > > that uses compressed as cpio.gz archive with files. > > I'm done this due to several reasons: > > 1) Support for multiple initrd files (so, it'll be possible to split > > initrd module packages); > > 2) It's much easier to repack .cpio archive, and minix driver can be > > excluded from kernels (both LEAF and host) > > > > Due to migration I omitted diverting of rootfs into separate ramdisk > > - IMHO it's really unuseful in that case; rootfs with it's default > > size will take up to half of available RAM during filling - so it'll > > be enough big, and it'll .never consume all available memory. (I > > check this, it's working) > > > > One of it's cons that I found - there is no initramfs usage > > statistics in output of 'df'. > > I simulated running out of space with dd > dd if=/dev/zero of=output.file bs=1024 count=1024 > filling up the memory to the max. > > If a Bering-uClibc3 box runs out of memory the dd command fails with > the message "no disk on space" and refused to generate the last MB. On > a Bering-uClibc4 it starts to kill processes: > [36521.153494] Out of memory: kill process 2809 (mini_httpd) score 87 > or a child > [36521.160859] Killed process 2809 (mini_httpd) vsz:696kB, > anon-rss:88kB, file- rss:180kB > [36521.190261] Out of memory: kill process 2228 (dnsmasq) score 85 or > a child [36521.197453] Killed process 2228 (dnsmasq) vsz:680kB, > anon-rss:80kB, file- rss:256kB > [36521.219629] Out of memory: kill process 2897 (aiccu) score 37 or a > child [36521.226586] Killed process 2897 (aiccu) vsz:4796kB, > anon-rss:120kB, file- rss:264kB > > This is a serious pb and it may happen that a remote box is > unavailable even for login via ssh, so you can't just reboot it. > > Something I've overlooked? > kp > >>> > >>> Hmm, it looks like initramfs behavior was changed from 2.6.32 kernel, > >>> and now it hasn't limit in half of available memory. > >>> We can switch back to rootfs on tmpfs, this will require some init > >>> scripts modification. > >> > >> I found a text which describes the pb's I found (don't know how old it > >> is) > >> > >> http://opensource.dyc.edu/ramdisk-vs-ramfs > >> > >> Switching back seems to provide a more stable environement > >> kp > > > > Andrew; > > > > can/will you make the changes necessary? I guess you're the one who knows > > best what has changed moving to initramfs (only) and what needs to be > > done to have initramfs with rootfs. > > > > I consider the issue described above as serious and like to get it > > solved for beta2. > > > > Anything else that anyone considers as showstopper for a new beta > > version? > > > > kp > > Yes, I'll make it in near future. It'll require splitting initrc script > to 2 parts - 1st part for preparing tmpfs and switch_root in it, and 2nd > part - to finish init. Great! kp -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] bering-uclibc4 initrd migration
10.01.2011 20:04, KP Kirchdoerfer пишет: > Am Donnerstag, 6. Januar 2011, 15:44:37 schrieb KP Kirchdoerfer: >> Am Donnerstag, 6. Januar 2011, 15:06:42 schrieb Andrew: >>> 06.01.2011 15:56, KP Kirchdoerfer пишет: Hi; this is from an old mail, but I tested today what happens if Bering-uClibc3 runs out of memory and what happens on Bering-uClibc4 box. Am Samstag, 12. Juni 2010, 20:17:49 schrieb Andrew: > Hi. > I just finished migration from compressed minix initrd to initramfs > that uses compressed as cpio.gz archive with files. > I'm done this due to several reasons: > 1) Support for multiple initrd files (so, it'll be possible to split > initrd module packages); > 2) It's much easier to repack .cpio archive, and minix driver can be > excluded from kernels (both LEAF and host) > > Due to migration I omitted diverting of rootfs into separate ramdisk - > IMHO it's really unuseful in that case; rootfs with it's default size > will take up to half of available RAM during filling - so it'll be > enough big, and it'll .never consume all available memory. (I check > this, it's working) > > One of it's cons that I found - there is no initramfs usage statistics > in output of 'df'. I simulated running out of space with dd dd if=/dev/zero of=output.file bs=1024 count=1024 filling up the memory to the max. If a Bering-uClibc3 box runs out of memory the dd command fails with the message "no disk on space" and refused to generate the last MB. On a Bering-uClibc4 it starts to kill processes: [36521.153494] Out of memory: kill process 2809 (mini_httpd) score 87 or a child [36521.160859] Killed process 2809 (mini_httpd) vsz:696kB, anon-rss:88kB, file- rss:180kB [36521.190261] Out of memory: kill process 2228 (dnsmasq) score 85 or a child [36521.197453] Killed process 2228 (dnsmasq) vsz:680kB, anon-rss:80kB, file- rss:256kB [36521.219629] Out of memory: kill process 2897 (aiccu) score 37 or a child [36521.226586] Killed process 2897 (aiccu) vsz:4796kB, anon-rss:120kB, file- rss:264kB This is a serious pb and it may happen that a remote box is unavailable even for login via ssh, so you can't just reboot it. Something I've overlooked? kp >>> Hmm, it looks like initramfs behavior was changed from 2.6.32 kernel, >>> and now it hasn't limit in half of available memory. >>> We can switch back to rootfs on tmpfs, this will require some init >>> scripts modification. >> I found a text which describes the pb's I found (don't know how old it is) >> >> http://opensource.dyc.edu/ramdisk-vs-ramfs >> >> Switching back seems to provide a more stable environement >> kp > Andrew; > > can/will you make the changes necessary? I guess you're the one who knows best > what has changed moving to initramfs (only) and what needs to be done to have > initramfs with rootfs. > > I consider the issue described above as serious and like to get it solved for > beta2. > > Anything else that anyone considers as showstopper for a new beta version? > > kp Yes, I'll make it in near future. It'll require splitting initrc script to 2 parts - 1st part for preparing tmpfs and switch_root in it, and 2nd part - to finish init. -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] bering-uclibc4 initrd migration
Am Donnerstag, 6. Januar 2011, 15:44:37 schrieb KP Kirchdoerfer: > Am Donnerstag, 6. Januar 2011, 15:06:42 schrieb Andrew: > > 06.01.2011 15:56, KP Kirchdoerfer пишет: > > > Hi; > > > > > > this is from an old mail, but I tested today what happens if > > > Bering-uClibc3 runs out of memory and what happens on Bering-uClibc4 > > > box. > > > > > > Am Samstag, 12. Juni 2010, 20:17:49 schrieb Andrew: > > >> Hi. > > >> I just finished migration from compressed minix initrd to initramfs > > >> that uses compressed as cpio.gz archive with files. > > >> I'm done this due to several reasons: > > >> 1) Support for multiple initrd files (so, it'll be possible to split > > >> initrd module packages); > > >> 2) It's much easier to repack .cpio archive, and minix driver can be > > >> excluded from kernels (both LEAF and host) > > >> > > >> Due to migration I omitted diverting of rootfs into separate ramdisk - > > >> IMHO it's really unuseful in that case; rootfs with it's default size > > >> will take up to half of available RAM during filling - so it'll be > > >> enough big, and it'll .never consume all available memory. (I check > > >> this, it's working) > > >> > > >> One of it's cons that I found - there is no initramfs usage statistics > > >> in output of 'df'. > > > > > > I simulated running out of space with dd > > > dd if=/dev/zero of=output.file bs=1024 count=1024 > > > filling up the memory to the max. > > > > > > If a Bering-uClibc3 box runs out of memory the dd command fails with > > > the message "no disk on space" and refused to generate the last MB. On > > > a Bering-uClibc4 it starts to kill processes: > > > [36521.153494] Out of memory: kill process 2809 (mini_httpd) score 87 > > > or a child > > > [36521.160859] Killed process 2809 (mini_httpd) vsz:696kB, > > > anon-rss:88kB, file- rss:180kB > > > [36521.190261] Out of memory: kill process 2228 (dnsmasq) score 85 or a > > > child [36521.197453] Killed process 2228 (dnsmasq) vsz:680kB, > > > anon-rss:80kB, file- rss:256kB > > > [36521.219629] Out of memory: kill process 2897 (aiccu) score 37 or a > > > child [36521.226586] Killed process 2897 (aiccu) vsz:4796kB, > > > anon-rss:120kB, file- rss:264kB > > > > > > This is a serious pb and it may happen that a remote box is unavailable > > > even for login via ssh, so you can't just reboot it. > > > > > > Something I've overlooked? > > > kp > > > > Hmm, it looks like initramfs behavior was changed from 2.6.32 kernel, > > and now it hasn't limit in half of available memory. > > We can switch back to rootfs on tmpfs, this will require some init > > scripts modification. > > I found a text which describes the pb's I found (don't know how old it is) > > http://opensource.dyc.edu/ramdisk-vs-ramfs > > Switching back seems to provide a more stable environement > kp Andrew; can/will you make the changes necessary? I guess you're the one who knows best what has changed moving to initramfs (only) and what needs to be done to have initramfs with rootfs. I consider the issue described above as serious and like to get it solved for beta2. Anything else that anyone considers as showstopper for a new beta version? kp -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] bering-uclibc4 initrd migration
Am Donnerstag, 6. Januar 2011, 15:06:42 schrieb Andrew: > 06.01.2011 15:56, KP Kirchdoerfer пишет: > > Hi; > > > > this is from an old mail, but I tested today what happens if > > Bering-uClibc3 runs out of memory and what happens on Bering-uClibc4 > > box. > > > > Am Samstag, 12. Juni 2010, 20:17:49 schrieb Andrew: > >> Hi. > >> I just finished migration from compressed minix initrd to initramfs that > >> uses compressed as cpio.gz archive with files. > >> I'm done this due to several reasons: > >> 1) Support for multiple initrd files (so, it'll be possible to split > >> initrd module packages); > >> 2) It's much easier to repack .cpio archive, and minix driver can be > >> excluded from kernels (both LEAF and host) > >> > >> Due to migration I omitted diverting of rootfs into separate ramdisk - > >> IMHO it's really unuseful in that case; rootfs with it's default size > >> will take up to half of available RAM during filling - so it'll be > >> enough big, and it'll .never consume all available memory. (I check > >> this, it's working) > >> > >> One of it's cons that I found - there is no initramfs usage statistics > >> in output of 'df'. > > > > I simulated running out of space with dd > > dd if=/dev/zero of=output.file bs=1024 count=1024 > > filling up the memory to the max. > > > > If a Bering-uClibc3 box runs out of memory the dd command fails with the > > message "no disk on space" and refused to generate the last MB. > > On a Bering-uClibc4 it starts to kill processes: > > [36521.153494] Out of memory: kill process 2809 (mini_httpd) score 87 or > > a child > > [36521.160859] Killed process 2809 (mini_httpd) vsz:696kB, anon-rss:88kB, > > file- rss:180kB > > [36521.190261] Out of memory: kill process 2228 (dnsmasq) score 85 or a > > child [36521.197453] Killed process 2228 (dnsmasq) vsz:680kB, > > anon-rss:80kB, file- rss:256kB > > [36521.219629] Out of memory: kill process 2897 (aiccu) score 37 or a > > child [36521.226586] Killed process 2897 (aiccu) vsz:4796kB, > > anon-rss:120kB, file- rss:264kB > > > > This is a serious pb and it may happen that a remote box is unavailable > > even for login via ssh, so you can't just reboot it. > > > > Something I've overlooked? > > kp > > Hmm, it looks like initramfs behavior was changed from 2.6.32 kernel, > and now it hasn't limit in half of available memory. > We can switch back to rootfs on tmpfs, this will require some init > scripts modification. I found a text which describes the pb's I found (don't know how old it is) http://opensource.dyc.edu/ramdisk-vs-ramfs Switching back seems to provide a more stable environement kp -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] bering-uclibc4 initrd migration
06.01.2011 15:56, KP Kirchdoerfer пишет: > Hi; > > this is from an old mail, but I tested today what happens if Bering-uClibc3 > runs out of memory and what happens on Bering-uClibc4 box. > > Am Samstag, 12. Juni 2010, 20:17:49 schrieb Andrew: >> Hi. >> I just finished migration from compressed minix initrd to initramfs that >> uses compressed as cpio.gz archive with files. >> I'm done this due to several reasons: >> 1) Support for multiple initrd files (so, it'll be possible to split >> initrd module packages); >> 2) It's much easier to repack .cpio archive, and minix driver can be >> excluded from kernels (both LEAF and host) >> >> Due to migration I omitted diverting of rootfs into separate ramdisk - >> IMHO it's really unuseful in that case; rootfs with it's default size >> will take up to half of available RAM during filling - so it'll be >> enough big, and it'll .never consume all available memory. (I check >> this, it's working) >> >> One of it's cons that I found - there is no initramfs usage statistics >> in output of 'df'. > I simulated running out of space with dd > dd if=/dev/zero of=output.file bs=1024 count=1024 > filling up the memory to the max. > > If a Bering-uClibc3 box runs out of memory the dd command fails with the > message "no disk on space" and refused to generate the last MB. > On a Bering-uClibc4 it starts to kill processes: > [36521.153494] Out of memory: kill process 2809 (mini_httpd) score 87 or a > child > [36521.160859] Killed process 2809 (mini_httpd) vsz:696kB, anon-rss:88kB, > file- > rss:180kB > [36521.190261] Out of memory: kill process 2228 (dnsmasq) score 85 or a child > [36521.197453] Killed process 2228 (dnsmasq) vsz:680kB, anon-rss:80kB, file- > rss:256kB > [36521.219629] Out of memory: kill process 2897 (aiccu) score 37 or a child > [36521.226586] Killed process 2897 (aiccu) vsz:4796kB, anon-rss:120kB, file- > rss:264kB > > This is a serious pb and it may happen that a remote box is unavailable even > for login via ssh, so you can't just reboot it. > > Something I've overlooked? > kp Hmm, it looks like initramfs behavior was changed from 2.6.32 kernel, and now it hasn't limit in half of available memory. We can switch back to rootfs on tmpfs, this will require some init scripts modification. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] bering-uclibc4 initrd migration
Hi; this is from an old mail, but I tested today what happens if Bering-uClibc3 runs out of memory and what happens on Bering-uClibc4 box. Am Samstag, 12. Juni 2010, 20:17:49 schrieb Andrew: > Hi. > I just finished migration from compressed minix initrd to initramfs that > uses compressed as cpio.gz archive with files. > I'm done this due to several reasons: > 1) Support for multiple initrd files (so, it'll be possible to split > initrd module packages); > 2) It's much easier to repack .cpio archive, and minix driver can be > excluded from kernels (both LEAF and host) > > Due to migration I omitted diverting of rootfs into separate ramdisk - > IMHO it's really unuseful in that case; rootfs with it's default size > will take up to half of available RAM during filling - so it'll be > enough big, and it'll .never consume all available memory. (I check > this, it's working) > > One of it's cons that I found - there is no initramfs usage statistics > in output of 'df'. I simulated running out of space with dd dd if=/dev/zero of=output.file bs=1024 count=1024 filling up the memory to the max. If a Bering-uClibc3 box runs out of memory the dd command fails with the message "no disk on space" and refused to generate the last MB. On a Bering-uClibc4 it starts to kill processes: [36521.153494] Out of memory: kill process 2809 (mini_httpd) score 87 or a child [36521.160859] Killed process 2809 (mini_httpd) vsz:696kB, anon-rss:88kB, file- rss:180kB [36521.190261] Out of memory: kill process 2228 (dnsmasq) score 85 or a child [36521.197453] Killed process 2228 (dnsmasq) vsz:680kB, anon-rss:80kB, file- rss:256kB [36521.219629] Out of memory: kill process 2897 (aiccu) score 37 or a child [36521.226586] Killed process 2897 (aiccu) vsz:4796kB, anon-rss:120kB, file- rss:264kB This is a serious pb and it may happen that a remote box is unavailable even for login via ssh, so you can't just reboot it. Something I've overlooked? kp -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] bering-uclibc4 initrd migration
> /sys/devices/pci:00/:00:0f.2/modalias - > pci:v1022d209Asv1022sd209Abc01sc01i80 > Hm, strange. pci:v1022d209Asv1022sd209Abc01sc01i80 is in modaliases of pata_amd. Possible it's appears after some bridge driver initialization... Ok, I'll try to make iteration driver autoloading. It may slowdown loading of box by some seconds, but will be helpful for devices that connected via busses that require additional drivers. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] bering-uclibc4 initrd migration
Am Freitag, 25. Juni 2010 12:07:49 schrieb Andrew:
> 25.06.2010 12:24, KP Kirchdoerfer пишет:
> > Am Freitag, 25. Juni 2010 10:53:56 schrieb Andrew:
> >>> Hi;
> >>>
> >>> automatic detection still does not work, but adding the KMODULES to
> >>> the init string helps alittle - at least I can boot.
> >>> I consider this more or less as a workaround, it's not easy to find the
> >>> right driver, if one cannot even start the box...
> >>
> >> Ok.
> >> Can you execute `find /sys/devices -name modalias -exec echo -n "{} - "
> >> \; -exec cat {} \;` on your live 2.6 system?
> >
> > # `find /sys/devices -name modalias -exec echo -n "{} - " \; -exec cat
> > {} \;`
> > -sh: /sys/devices/platform/rtc_cmos/modalias: Permission denied
> >
> >
> > kp
>
> Do it without `` bracers - I put it for dividing command from other text
sorry;
/sys/devices/platform/rtc_cmos/modalias - platform:rtc_cmos
/sys/devices/platform/pcspkr/modalias - platform:pcspkr
/sys/devices/platform/serial8250/modalias - platform:serial8250
/sys/devices/pci:00/:00:01.0/modalias -
pci:v1022d2080sv1022sd2080bc06sc00i00
/sys/devices/pci:00/:00:01.2/modalias -
pci:v1022d2082sv1022sd2082bc10sc10i00
/sys/devices/pci:00/:00:09.0/modalias -
pci:v1106d3053sv1106sd0106bc02sc00i00
/sys/devices/pci:00/:00:0a.0/modalias -
pci:v1106d3053sv1106sd0106bc02sc00i00
/sys/devices/pci:00/:00:0b.0/modalias -
pci:v1106d3053sv1106sd0106bc02sc00i00
/sys/devices/pci:00/:00:0c.0/modalias -
pci:v168Cd001Asv168Csd2052bc02sc00i00
/sys/devices/pci:00/:00:0f.0/modalias -
pci:v1022d2090sv1022sd2090bc06sc01i00
/sys/devices/pci:00/:00:0f.2/modalias -
pci:v1022d209Asv1022sd209Abc01sc01i80
/sys/devices/pci:00/:00:0f.2/host0/target0:0:0/0:0:0:0/modalias -
scsi:t-0x00
/sys/devices/pci:00/:00:0f.4/modalias -
pci:v1022d2094sv1022sd2094bc0Csc03i10
/sys/devices/pci:00/:00:0f.4/usb1/1-0:1.0/modalias -
usb:v1D6Bp0001d0206dc09dsc00dp00ic09isc00ip00
/sys/devices/pci:00/:00:0f.5/modalias -
pci:v1022d2095sv1022sd2095bc0Csc03i20
/sys/devices/pci:00/:00:0f.5/usb2/2-0:1.0/modalias -
usb:v1D6Bp0002d0206dc09dsc00dp00ic09isc00ip00
kp
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] bering-uclibc4 initrd migration
25.06.2010 12:24, KP Kirchdoerfer пишет:
> Am Freitag, 25. Juni 2010 10:53:56 schrieb Andrew:
>
>>> Hi;
>>>
>>> automatic detection still does not work, but adding the KMODULES to the
>>> init string helps alittle - at least I can boot.
>>> I consider this more or less as a workaround, it's not easy to find the
>>> right driver, if one cannot even start the box...
>>>
>> Ok.
>> Can you execute `find /sys/devices -name modalias -exec echo -n "{} - "
>> \; -exec cat {} \;` on your live 2.6 system?
>>
> # `find /sys/devices -name modalias -exec echo -n "{} - " \; -exec cat
> {} \;`
> -sh: /sys/devices/platform/rtc_cmos/modalias: Permission denied
>
>
> kp
>
>
Do it without `` bracers - I put it for dividing command from other text
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] bering-uclibc4 initrd migration
Am Freitag, 25. Juni 2010 10:53:56 schrieb Andrew:
> > Hi;
> >
> > automatic detection still does not work, but adding the KMODULES to the
> > init string helps alittle - at least I can boot.
> > I consider this more or less as a workaround, it's not easy to find the
> > right driver, if one cannot even start the box...
>
> Ok.
> Can you execute `find /sys/devices -name modalias -exec echo -n "{} - "
> \; -exec cat {} \;` on your live 2.6 system?
# `find /sys/devices -name modalias -exec echo -n "{} - " \; -exec cat
{} \;`
-sh: /sys/devices/platform/rtc_cmos/modalias: Permission denied
kp
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] bering-uclibc4 initrd migration
> Hi;
>
> automatic detection still does not work, but adding the KMODULES to the init
> string helps alittle - at least I can boot.
> I consider this more or less as a workaround, it's not easy to find the right
> driver, if one cannot even start the box...
>
>
Ok.
Can you execute `find /sys/devices -name modalias -exec echo -n "{} - "
\; -exec cat {} \;` on your live 2.6 system?
> Why have you removed the generic driver again?
>
> kp
>
>
IMHO it's better to add it as optional to KMODULES - so everybody can
disable it. And I'm not sure that generic driver will work as planned.
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] bering-uclibc4 initrd migration
Am Freitag, 25. Juni 2010 00:29:10 schrieb Andrew: > > I use the pata_amd to boot successfully- added that (and others) in the > > meantime. > > Will have a look if it works with just a generic driver later this week. > > > > The cpio initrd is indeed better to work with! > > kp > > Hi. > > I added KMODULES variable to kernel init string to specify what modules > will be forced to load; also I changed modalias searching mechanism. Try > now, possible it'll work; even if it won't work - you can specify needed > module manually by setting KMODULES=pata_amd. Hi; automatic detection still does not work, but adding the KMODULES to the init string helps alittle - at least I can boot. I consider this more or less as a workaround, it's not easy to find the right driver, if one cannot even start the box... Why have you removed the generic driver again? kp -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] bering-uclibc4 initrd migration
> I use the pata_amd to boot successfully- added that (and others) in the > meantime. > Will have a look if it works with just a generic driver later this week. > > The cpio initrd is indeed better to work with! > kp > > Hi. I added KMODULES variable to kernel init string to specify what modules will be forced to load; also I changed modalias searching mechanism. Try now, possible it'll work; even if it won't work - you can specify needed module manually by setting KMODULES=pata_amd. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] bering-uclibc4 initrd migration
Am Donnerstag, 24. Juni 2010 15:27:08 schrieb Andrew: > > It solved the build pb's; unfortunatley I'm not able to boot from an IDE > > CF disk. > > > > The error I see is: > > > > LINUXRC: Bering - Initrd - 4.0.0 Rev 8 uClibc 0.9.30.3 > > [1.679028] SCSI subsystem initialized > > [2.027591] usbcore: registered new interface driver usbfs > > [2.037774] usbcore: registered new interface driver hub > > [2.044838] usbcore: registered new device driver usb > > [2.065189] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver > > [2.075893] ohci_hcd :00:0f.4: OHCI Host Controller > > [2.076635] ohci_hcd :00:0f.4: new USB bus registered, assigned > > bus number 1 > > [2.088773] ohci_hcd :00:0f.4: irq 15, io mem 0xefffe000 > > [2.174051] usb usb1: configuration #1 chosen from 1 choice > > [2.185534] hub 1-0:1.0: USB hub found > > [2.185534] hub 1-0:1.0: 4 ports detected > > [2.222875] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver > > [2.232084] Warning! ehci_hcd should always be loaded before uhci_hcd > > and ohci_hcd, not after > > [2.241631] ehci_hcd :00:0f.5: EHCI Host Controller > > [2.247743] ehci_hcd :00:0f.5: new USB bus registered, assigned > > bus number 2 > > [2.282635] ehci_hcd :00:0f.5: irq 15, io mem 0xefffd000 > > [2.288451] ehci_hcd :00:0f.5: USB 2.0 started, EHCI 1.00 > > [2.295402] usb usb2: configuration #1 chosen from 1 choice > > [2.302235] hub 2-0:1.0: USB hub found > > [2.302945] hub 2-0:1.0: 4 ports detected > > LINUXRC: Installing - root: root(nf!) config: config(nf!) etc: > > etc(nf!) modules: modules(nf!) dropbear: dropbear(nf!) . > > /init: source: line 309: can't open '/var/lib/lrpkg/root.dev.own' > > [3.433366] Kernel panic - not syncing: Attempted to kill init! > > > > > > This is usually a pb, when initrd can't find the media with the packages. > > > > The syslinux.cfg I use (this is a dual boot setup for CF) looks like > > this: > > > > kernel linux26 > > append initrd=initrd26.lrp root=/dev/ram0 rw console=ttyS0,115200n8 > > LEAFCFG=/dev/sda2:msdos PKGPATH=/dev/sda2:msdos > > LRP=root,config,etc,modules,dropbear > > > > I also tried the shorter one > > kernel linux26 > > append initrd=initrd26.lrp root=/dev/ram0 rw console=ttyS0,115200n8 > > LEAFCFG=/dev/sda2:msdos > > > > kp > > Can you look what device driver is actually use your IDE controller? If > earlier build with unconditional loading of all initrd modules works for > you, can you run `cat /sys/class/scsi_host/*/proc_name` and tell me result? > Also I've added ata_generic to initrd, try to reassemble it and run - > possible it'll work if there is no ATA drivers will be loaded by autoload. I use the pata_amd to boot successfully- added that (and others) in the meantime. Will have a look if it works with just a generic driver later this week. The cpio initrd is indeed better to work with! kp -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] bering-uclibc4 initrd migration
> It solved the build pb's; unfortunatley I'm not able to boot from an IDE CF > disk. > > The error I see is: > > LINUXRC: Bering - Initrd - 4.0.0 Rev 8 uClibc 0.9.30.3 > [1.679028] SCSI subsystem initialized > [2.027591] usbcore: registered new interface driver usbfs > [2.037774] usbcore: registered new interface driver hub > [2.044838] usbcore: registered new device driver usb > [2.065189] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver > [2.075893] ohci_hcd :00:0f.4: OHCI Host Controller > [2.076635] ohci_hcd :00:0f.4: new USB bus registered, assigned bus > number 1 > [2.088773] ohci_hcd :00:0f.4: irq 15, io mem 0xefffe000 > [2.174051] usb usb1: configuration #1 chosen from 1 choice > [2.185534] hub 1-0:1.0: USB hub found > [2.185534] hub 1-0:1.0: 4 ports detected > [2.222875] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver > [2.232084] Warning! ehci_hcd should always be loaded before uhci_hcd and > ohci_hcd, not after > [2.241631] ehci_hcd :00:0f.5: EHCI Host Controller > [2.247743] ehci_hcd :00:0f.5: new USB bus registered, assigned bus > number 2 > [2.282635] ehci_hcd :00:0f.5: irq 15, io mem 0xefffd000 > [2.288451] ehci_hcd :00:0f.5: USB 2.0 started, EHCI 1.00 > [2.295402] usb usb2: configuration #1 chosen from 1 choice > [2.302235] hub 2-0:1.0: USB hub found > [2.302945] hub 2-0:1.0: 4 ports detected > LINUXRC: Installing - root: root(nf!) config: config(nf!) etc: etc(nf!) > modules: modules(nf!) dropbear: dropbear(nf!) . > /init: source: line 309: can't open '/var/lib/lrpkg/root.dev.own' > [3.433366] Kernel panic - not syncing: Attempted to kill init! > > > This is usually a pb, when initrd can't find the media with the packages. > > The syslinux.cfg I use (this is a dual boot setup for CF) looks like this: > > kernel linux26 > append initrd=initrd26.lrp root=/dev/ram0 rw console=ttyS0,115200n8 > LEAFCFG=/dev/sda2:msdos PKGPATH=/dev/sda2:msdos > LRP=root,config,etc,modules,dropbear > > I also tried the shorter one > kernel linux26 > append initrd=initrd26.lrp root=/dev/ram0 rw console=ttyS0,115200n8 > LEAFCFG=/dev/sda2:msdos > > kp > Can you look what device driver is actually use your IDE controller? If earlier build with unconditional loading of all initrd modules works for you, can you run `cat /sys/class/scsi_host/*/proc_name` and tell me result? Also I've added ata_generic to initrd, try to reassemble it and run - possible it'll work if there is no ATA drivers will be loaded by autoload. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] bering-uclibc4 initrd migration
Am Mittwoch, 23. Juni 2010 21:25:05 schrieb Andrew: > 23.06.2010 22:18, KP Kirchdoerfer пишет: > > Am Mittwoch, 23. Juni 2010 20:59:37 schrieb Andrew: > >> 23.06.2010 21:41, KP Kirchdoerfer пишет: > >>> Am Sonntag, 13. Juni 2010 00:19:42 schrieb Andrew: > After rebuild all looks OK. Image is working. > > It'll be enough good to leave initramfs 'as is', that can consume up > to half of physical memory, or we'll use switch_root (which is > currently buggy - it doesn't umount /proc& /sys from old root fs; so > even I don't shure that it actually cleans filesystem after switching) > or pivot_root + some clean-up for creating root tmpfs with limited > size? Is it actually needed? > > In few days, when I'll get free time, I'll try to enable devtmpfs > instead of manual creation of device files, and look what it actually > does, and how successfully it'll replace device creation scripts. It > isn't critical milestone for beta release, but IMHO will be gladly > seen in stable release, enhanced by busybox's mdev and some other very > useful features. > >>> > >>> Andrew; > >>> > >>> I've made a fresh rebuild from cvs and installed on my router. > >>> > >>> To package initd.lrp I had to remove the line > >>> #include > >>> from buildtool.cfg cause thatis missing. > >>> Following that I've been avble to build an initrd.lrp > >>> > >>> Starting the new version results in the error: > >>> > >>> LINUXRC: Bering - Initrd - 4.0.0 Rev 8 uClibc 0.9.30.3 > >>> modprobe: module 'isofs' not found > >>> modprobe: module 'vfat' not found > >>> > >>> What am I missing? > >>> kp > >> > >> Strange. 'files' is generated by buildtool.mk from 'mod', which is also > >> generated by script from input filelist and kernel's modules.dep > >> Can you give me log of initrd building (actually - part of execution > >> buildtool.mk 'build' part)? > > > > There are a some errors which may explain the pb: > > > > make: Gehe in Verzeichnis '/opt/buildtool26/source/initrd' > > touch ./.configured > > sort: invalid option -- V > > „sort --help“ gibt weitere Informationen. > > sort: invalid option -- V > > „sort --help“ gibt weitere Informationen. > > mkdir -p /opt/buildtool26/build/config > > mkdir -p /opt/buildtool26/build/config/var/lib/lrpkg > > mkdir -p /opt/buildtool26/build/config/boot/etc > > BT_STAGING_DIR=/opt/buildtool26/staging BT_KERNEL_RELEASE= \ > > sh /opt/buildtool26/tools/getdep.sh "ata_.*" ahci ehci-hcd > > uhci-hcd > > \ ohci-hcd usb-storage sd_mod sr_mod isofs vfat floppy>mod > > cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or > > directory > > cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or > > directory > > cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or > > directory > > cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or > > directory > > cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or > > directory > > cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or > > directory > > cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or > > directory > > cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or > > directory > > cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or > > directory > > cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or > > directory > > cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or > > directory > > #cat mod|sed 's/[a-z]*\/[a-z_/-]*\///g; s/\.ko//g; > > s/ /\n/g'>/opt/buildtool26/build/config/boot/etc/modules > > echo -e "isofs\nvfat">/opt/buildtool26/build/config/boot/etc/modules > > rm -f files > > (BT_KERNEL_RELEASE=; for i in `cat mod`; do echo -e "\n\tSource\t= > > lib/modules/$BT_KERNEL_RELEASE/$i\n\t\ > > Filename\t= lib/modules/$(echo $i|sed 's/[a-z]*\/[a-z_/-]*\///g')\n\t\ > > Type\t= binary\n\tType\t= module\n\tPermissions\t= 644\n">>files; > > done) > > cp -a README /opt/buildtool26/build/config/boot/etc > > cp -a root.blk.mk /opt/buildtool26/build/config/var/lib/lrpkg > > cp -a root.dev.mk /opt/buildtool26/build/config/var/lib/lrpkg > > cp -a root.linuxrc /opt/buildtool26/build/config/var/lib/lrpkg > > cp -a /opt/buildtool26/build/config/* /opt/buildtool26/staging > > touch ./.build > > make: Verlasse Verzeichnis '/opt/buildtool26/source/initrd' > > > > > > kp > > Try now to rebuild initrd. I fixed makefile. It solved the build pb's; unfortunatley I'm not able to boot from an IDE CF disk. The error I see is: LINUXRC: Bering - Initrd - 4.0.0 Rev 8 uClibc 0.9.30.3 [1.679028] SCSI subsystem initialized [2.027591] usbcore: registered new interface driver usbfs [2.037774] usbcore: registered new interface driver hub [2.044838] usbcore: registered new device driver usb [2.065189] ohci_hcd: USB 1.1 'Open' Host Controller (OH
Re: [leaf-devel] bering-uclibc4 initrd migration
23.06.2010 22:18, KP Kirchdoerfer пишет: > Am Mittwoch, 23. Juni 2010 20:59:37 schrieb Andrew: > >> 23.06.2010 21:41, KP Kirchdoerfer пишет: >> >>> Am Sonntag, 13. Juni 2010 00:19:42 schrieb Andrew: >>> After rebuild all looks OK. Image is working. It'll be enough good to leave initramfs 'as is', that can consume up to half of physical memory, or we'll use switch_root (which is currently buggy - it doesn't umount /proc& /sys from old root fs; so even I don't shure that it actually cleans filesystem after switching) or pivot_root + some clean-up for creating root tmpfs with limited size? Is it actually needed? In few days, when I'll get free time, I'll try to enable devtmpfs instead of manual creation of device files, and look what it actually does, and how successfully it'll replace device creation scripts. It isn't critical milestone for beta release, but IMHO will be gladly seen in stable release, enhanced by busybox's mdev and some other very useful features. >>> Andrew; >>> >>> I've made a fresh rebuild from cvs and installed on my router. >>> >>> To package initd.lrp I had to remove the line >>> #include >>> from buildtool.cfg cause thatis missing. >>> Following that I've been avble to build an initrd.lrp >>> >>> Starting the new version results in the error: >>> >>> LINUXRC: Bering - Initrd - 4.0.0 Rev 8 uClibc 0.9.30.3 >>> modprobe: module 'isofs' not found >>> modprobe: module 'vfat' not found >>> >>> What am I missing? >>> kp >>> >> Strange. 'files' is generated by buildtool.mk from 'mod', which is also >> generated by script from input filelist and kernel's modules.dep >> Can you give me log of initrd building (actually - part of execution >> buildtool.mk 'build' part)? >> > There are a some errors which may explain the pb: > > make: Gehe in Verzeichnis '/opt/buildtool26/source/initrd' > touch ./.configured > sort: invalid option -- V > „sort --help“ gibt weitere Informationen. > sort: invalid option -- V > „sort --help“ gibt weitere Informationen. > mkdir -p /opt/buildtool26/build/config > mkdir -p /opt/buildtool26/build/config/var/lib/lrpkg > mkdir -p /opt/buildtool26/build/config/boot/etc > BT_STAGING_DIR=/opt/buildtool26/staging BT_KERNEL_RELEASE= \ > sh /opt/buildtool26/tools/getdep.sh "ata_.*" ahci ehci-hcd > uhci-hcd \ > ohci-hcd usb-storage sd_mod sr_mod isofs vfat floppy>mod > cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or > directory > cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or > directory > cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or > directory > cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or > directory > cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or > directory > cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or > directory > cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or > directory > cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or > directory > cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or > directory > cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or > directory > cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or > directory > #cat mod|sed 's/[a-z]*\/[a-z_/-]*\///g; s/\.ko//g; > s/ /\n/g'>/opt/buildtool26/build/config/boot/etc/modules > echo -e "isofs\nvfat">/opt/buildtool26/build/config/boot/etc/modules > rm -f files > (BT_KERNEL_RELEASE=; for i in `cat mod`; do echo -e "\n\tSource\t= > lib/modules/$BT_KERNEL_RELEASE/$i\n\t\ > Filename\t= lib/modules/$(echo $i|sed 's/[a-z]*\/[a-z_/-]*\///g')\n\t\ > Type\t= binary\n\tType\t= module\n\tPermissions\t= 644\n">>files; > done) > cp -a README /opt/buildtool26/build/config/boot/etc > cp -a root.blk.mk /opt/buildtool26/build/config/var/lib/lrpkg > cp -a root.dev.mk /opt/buildtool26/build/config/var/lib/lrpkg > cp -a root.linuxrc /opt/buildtool26/build/config/var/lib/lrpkg > cp -a /opt/buildtool26/build/config/* /opt/buildtool26/staging > touch ./.build > make: Verlasse Verzeichnis '/opt/buildtool26/source/initrd' > > > kp > > Try now to rebuild initrd. I fixed makefile. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] bering-uclibc4 initrd migration
Am Mittwoch, 23. Juni 2010 20:59:37 schrieb Andrew: > 23.06.2010 21:41, KP Kirchdoerfer пишет: > > Am Sonntag, 13. Juni 2010 00:19:42 schrieb Andrew: > >> After rebuild all looks OK. Image is working. > >> > >> It'll be enough good to leave initramfs 'as is', that can consume up to > >> half of physical memory, or we'll use switch_root (which is currently > >> buggy - it doesn't umount /proc& /sys from old root fs; so even I don't > >> shure that it actually cleans filesystem after switching) or pivot_root > >> + some clean-up for creating root tmpfs with limited size? Is it > >> actually needed? > >> > >> In few days, when I'll get free time, I'll try to enable devtmpfs > >> instead of manual creation of device files, and look what it actually > >> does, and how successfully it'll replace device creation scripts. It > >> isn't critical milestone for beta release, but IMHO will be gladly seen > >> in stable release, enhanced by busybox's mdev and some other very useful > >> features. > > > > Andrew; > > > > I've made a fresh rebuild from cvs and installed on my router. > > > > To package initd.lrp I had to remove the line > > #include > > from buildtool.cfg cause thatis missing. > > Following that I've been avble to build an initrd.lrp > > > > Starting the new version results in the error: > > > > LINUXRC: Bering - Initrd - 4.0.0 Rev 8 uClibc 0.9.30.3 > > modprobe: module 'isofs' not found > > modprobe: module 'vfat' not found > > > > What am I missing? > > kp > > Strange. 'files' is generated by buildtool.mk from 'mod', which is also > generated by script from input filelist and kernel's modules.dep > Can you give me log of initrd building (actually - part of execution > buildtool.mk 'build' part)? There are a some errors which may explain the pb: make: Gehe in Verzeichnis '/opt/buildtool26/source/initrd' touch ./.configured sort: invalid option -- V „sort --help“ gibt weitere Informationen. sort: invalid option -- V „sort --help“ gibt weitere Informationen. mkdir -p /opt/buildtool26/build/config mkdir -p /opt/buildtool26/build/config/var/lib/lrpkg mkdir -p /opt/buildtool26/build/config/boot/etc BT_STAGING_DIR=/opt/buildtool26/staging BT_KERNEL_RELEASE= \ sh /opt/buildtool26/tools/getdep.sh "ata_.*" ahci ehci-hcd uhci-hcd \ ohci-hcd usb-storage sd_mod sr_mod isofs vfat floppy >mod cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or directory cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or directory cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or directory cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or directory cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or directory cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or directory cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or directory cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or directory cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or directory cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or directory cat: /opt/buildtool26/staging/lib/modules//modules.dep: No such file or directory #cat mod|sed 's/[a-z]*\/[a-z_/-]*\///g; s/\.ko//g; s/ /\n/g'>/opt/buildtool26/build/config/boot/etc/modules echo -e "isofs\nvfat">/opt/buildtool26/build/config/boot/etc/modules rm -f files (BT_KERNEL_RELEASE=; for i in `cat mod`; do echo -e "\n\tSource\t= lib/modules/$BT_KERNEL_RELEASE/$i\n\t\ Filename\t= lib/modules/$(echo $i|sed 's/[a-z]*\/[a-z_/-]*\///g')\n\t\ Type\t= binary\n\tType\t= module\n\tPermissions\t= 644\n">>files; done) cp -a README /opt/buildtool26/build/config/boot/etc cp -a root.blk.mk /opt/buildtool26/build/config/var/lib/lrpkg cp -a root.dev.mk /opt/buildtool26/build/config/var/lib/lrpkg cp -a root.linuxrc /opt/buildtool26/build/config/var/lib/lrpkg cp -a /opt/buildtool26/build/config/* /opt/buildtool26/staging touch ./.build make: Verlasse Verzeichnis '/opt/buildtool26/source/initrd' kp -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] bering-uclibc4 initrd migration
23.06.2010 21:41, KP Kirchdoerfer пишет: > Am Sonntag, 13. Juni 2010 00:19:42 schrieb Andrew: > >> After rebuild all looks OK. Image is working. >> >> It'll be enough good to leave initramfs 'as is', that can consume up to >> half of physical memory, or we'll use switch_root (which is currently >> buggy - it doesn't umount /proc& /sys from old root fs; so even I don't >> shure that it actually cleans filesystem after switching) or pivot_root >> + some clean-up for creating root tmpfs with limited size? Is it >> actually needed? >> >> In few days, when I'll get free time, I'll try to enable devtmpfs >> instead of manual creation of device files, and look what it actually >> does, and how successfully it'll replace device creation scripts. It >> isn't critical milestone for beta release, but IMHO will be gladly seen >> in stable release, enhanced by busybox's mdev and some other very useful >> features. >> > Andrew; > > I've made a fresh rebuild from cvs and installed on my router. > > To package initd.lrp I had to remove the line > #include > from buildtool.cfg cause thatis missing. > Following that I've been avble to build an initrd.lrp > > Starting the new version results in the error: > > LINUXRC: Bering - Initrd - 4.0.0 Rev 8 uClibc 0.9.30.3 > modprobe: module 'isofs' not found > modprobe: module 'vfat' not found > > What am I missing? > kp > > Strange. 'files' is generated by buildtool.mk from 'mod', which is also generated by script from input filelist and kernel's modules.dep Can you give me log of initrd building (actually - part of execution buildtool.mk 'build' part)? -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] bering-uclibc4 initrd migration
Am Sonntag, 13. Juni 2010 00:19:42 schrieb Andrew: > After rebuild all looks OK. Image is working. > > It'll be enough good to leave initramfs 'as is', that can consume up to > half of physical memory, or we'll use switch_root (which is currently > buggy - it doesn't umount /proc & /sys from old root fs; so even I don't > shure that it actually cleans filesystem after switching) or pivot_root > + some clean-up for creating root tmpfs with limited size? Is it > actually needed? > > In few days, when I'll get free time, I'll try to enable devtmpfs > instead of manual creation of device files, and look what it actually > does, and how successfully it'll replace device creation scripts. It > isn't critical milestone for beta release, but IMHO will be gladly seen > in stable release, enhanced by busybox's mdev and some other very useful > features. Andrew; I've made a fresh rebuild from cvs and installed on my router. To package initd.lrp I had to remove the line #include from buildtool.cfg cause thatis missing. Following that I've been avble to build an initrd.lrp Starting the new version results in the error: LINUXRC: Bering - Initrd - 4.0.0 Rev 8 uClibc 0.9.30.3 modprobe: module 'isofs' not found modprobe: module 'vfat' not found What am I missing? kp -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] bering-uclibc4 initrd migration
After rebuild all looks OK. Image is working. It'll be enough good to leave initramfs 'as is', that can consume up to half of physical memory, or we'll use switch_root (which is currently buggy - it doesn't umount /proc & /sys from old root fs; so even I don't shure that it actually cleans filesystem after switching) or pivot_root + some clean-up for creating root tmpfs with limited size? Is it actually needed? In few days, when I'll get free time, I'll try to enable devtmpfs instead of manual creation of device files, and look what it actually does, and how successfully it'll replace device creation scripts. It isn't critical milestone for beta release, but IMHO will be gladly seen in stable release, enhanced by busybox's mdev and some other very useful features. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] bering-uclibc4 initrd migration
Hi. I just finished migration from compressed minix initrd to initramfs that uses compressed as cpio.gz archive with files. I'm done this due to several reasons: 1) Support for multiple initrd files (so, it'll be possible to split initrd module packages); 2) It's much easier to repack .cpio archive, and minix driver can be excluded from kernels (both LEAF and host) Due to migration I omitted diverting of rootfs into separate ramdisk - IMHO it's really unuseful in that case; rootfs with it's default size will take up to half of available RAM during filling - so it'll be enough big, and it'll .never consume all available memory. (I check this, it's working) One of it's cons that I found - there is no initramfs usage statistics in output of 'df'. Now it looks like migration is completed, and I'll try to reassemble all form scratch to ensure that I don't break something today.. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
