Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On 7/10/07, Rob Landley [EMAIL PROTECTED] wrote: On Tuesday 10 July 2007 14:30:38 Blue Swirl wrote: The sparc platform has a problem that if I boot with init as a hello world program everything behaves as expected (there are two in the image for testing purposes, /tools/bin/hello-dynamic and /tools/bin/hello-static). But if you boot with init=/tools/bin/bash it hangs. And so do the busybox shells. I think there is a problem with the dynamic loader, I get a bus error when running the programs on real Sparc. Huh. That's odd because hello-dynamic is using the dynamic loader. (That's why there's a hello-dynamic and a hello-static.) It's entirely possibly that qemu and real sparc hardware are behaving differently, but I'm not seeing this bus error under qemu. (I haven't got real sparc hardware, so I can only debug against qemu...) Right. Debugging the problem I found out that in Qemu, 64-bit loads and stores to unaligned addresses do not trigger any traps as they should. I'll commit a fix soon. The problem is in uClibc ldso, there is this kind of store. Running the program on qemu-sparc reveals another problem, probably because of these definitions in ldso/ldso/sparc/dl-sysdep.h: /* 4096 bytes alignment */ /* ...but 8192 is required for mmap() on sparc64 kernel */ #define PAGE_ALIGN 0xe000 #define ADDR_ALIGN 0x1fff #define OFFS_ALIGN 0x7fffe000 On Sparc32 the correct page alignment is still 4096. Because of these definitions, some code apparently tries to clear a 8k page, but only 4k of memory is mapped.
Re: [Detaolb-devel] [Qemu-devel] ANN: DetaolB v0.4 is released
On 7/11/07, Blue Swirl [EMAIL PROTECTED] wrote: It's entirely possibly that qemu and real sparc hardware are behaving differently, but I'm not seeing this bus error under qemu. (I haven't got real sparc hardware, so I can only debug against qemu...) Right. Debugging the problem I found out that in Qemu, 64-bit loads and stores to unaligned addresses do not trigger any traps as they should. I'll commit a fix soon. The problem is in uClibc ldso, there is this kind of store. Running the program on qemu-sparc reveals another problem, probably because of these definitions in ldso/ldso/sparc/dl-sysdep.h: /* 4096 bytes alignment */ /* ...but 8192 is required for mmap() on sparc64 kernel */ #define PAGE_ALIGN 0xe000 #define ADDR_ALIGN 0x1fff #define OFFS_ALIGN 0x7fffe000 On Sparc32 the correct page alignment is still 4096. Because of these definitions, some code apparently tries to clear a 8k page, but only 4k of memory is mapped. I just managed a compilation of bash-3.2 using ncurses-5.6 and uClibc-0.9.29 inside a qemu-system-sparc (native compilation, no cross compilation). ldd ./bash points naturally to libdl.so.0, libc.so.0, ld-uClibc.so.0 ./bash Segmentation fault I do not have gdb compiled yet... I'll check soon with busybox ash, since I recompiled uClibc with the sched_affinity patch. -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Detaolb-devel] [Qemu-devel] ANN: DetaolB v0.4 is released
On 7/11/07, Christian MICHON [EMAIL PROTECTED] wrote: I just managed a compilation of bash-3.2 using ncurses-5.6 and uClibc-0.9.29 inside a qemu-system-sparc (native compilation, no cross compilation). ldd ./bash points naturally to libdl.so.0, libc.so.0, ld-uClibc.so.0 ./bash Segmentation fault I do not have gdb compiled yet... I'll check soon with busybox ash, since I recompiled uClibc with the sched_affinity patch. busybox-1.6.0 does segfault here too. I had to remove taskset as apparently the sched_affinity patch did not fix the linking step. is there a repository of sparc/uclibc patches somewhere ? Blue mentionned he'll have a fix for uclibc ldso. I'll try it using this dev environment as soon as it'll be out. -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Detaolb-devel] [Qemu-devel] ANN: DetaolB v0.4 is released
On Wednesday 11 July 2007 9:34:17 am Christian MICHON wrote: I just managed a compilation of bash-3.2 using ncurses-5.6 and uClibc-0.9.29 inside a qemu-system-sparc (native compilation, no cross compilation). ldd ./bash points naturally to libdl.so.0, libc.so.0, ld-uClibc.so.0 ./bash Segmentation fault When you get that kind of segmentation fault, see if hello world segfaults too. (In general, when building with a new toolchain, new C library, new kernel, new root filesystem packaging method, or a new system in general, if anything goes wrong back up a few steps and make sure hello world works before trying to debug anything fancier.) I do not have gdb compiled yet... I'll check soon with busybox ash, since I recompiled uClibc with the sched_affinity patch. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson.
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On Wednesday 11 July 2007 7:17:28 am Blue Swirl wrote: On 7/10/07, Rob Landley [EMAIL PROTECTED] wrote: On Tuesday 10 July 2007 14:30:38 Blue Swirl wrote: The sparc platform has a problem that if I boot with init as a hello world program everything behaves as expected (there are two in the image for testing purposes, /tools/bin/hello-dynamic and /tools/bin/hello-static). But if you boot with init=/tools/bin/bash it hangs. And so do the busybox shells. I think there is a problem with the dynamic loader, I get a bus error when running the programs on real Sparc. Huh. That's odd because hello-dynamic is using the dynamic loader. (That's why there's a hello-dynamic and a hello-static.) It's entirely possibly that qemu and real sparc hardware are behaving differently, but I'm not seeing this bus error under qemu. (I haven't got real sparc hardware, so I can only debug against qemu...) Right. Debugging the problem I found out that in Qemu, 64-bit loads and stores to unaligned addresses do not trigger any traps as they should. I'll commit a fix soon. The problem is in uClibc ldso, there is this kind of store. I'll leave that to you. I can commit the patches to the uClibc repository if you can get them to me and confirm they work for you. (And get them added to the 0.9.29.1 patch list.) On Sparc32 the correct page alignment is still 4096. Because of these definitions, some code apparently tries to clear a 8k page, but only 4k of memory is mapped. Hmmm... It's possible that hello world is working but nothing larger is just because it uses such small amounts of memory nothing ever crosses a page boundary, or gets aligned properly by accident... I look forward to a fix. It would be nice to add sparc to the actually works list. :) Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson.
Re: [Detaolb-devel] [Qemu-devel] ANN: DetaolB v0.4 is released
On 7/11/07, Rob Landley [EMAIL PROTECTED] wrote: When you get that kind of segmentation fault, see if hello world segfaults too. (In general, when building with a new toolchain, new C library, new kernel, new root filesystem packaging method, or a new system in general, if anything goes wrong back up a few steps and make sure hello world works before trying to debug anything fancier.) I was not clear then. I've binutils already compiled versus uClibc for sparc, and it works. Some of those binaries from binutils are bigger than the expected size of final uclibc dynamic busybox. of course, as soon as I got uclibc compiled, hello world comes first to my mind, and it was working. -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Detaolb-devel] [Qemu-devel] ANN: DetaolB v0.4 is released
On 7/11/07, Rob Landley [EMAIL PROTECTED] wrote: I look forward to a fix. It would be nice to add sparc to the actually works list. :) that's 2 persons looking forward to it. ;-) today's results: - uclibc ok (minus the segfaults coming from it) - conf from busybox segfaults - bash segfaults - busybox segfaults - gcc does not build without bash (I'll replace with ash tomorrow) - binutils ok - ncurses ok (I need to look at uclibc' conf now) - make ok - bzip2 ok - coreutils ok - findutils ok Blue swirl, please note that the porting of DetaolB to sparc32 will take more time than scheduled, once the segfault issues are covered. I'd like to spend some time testing firmware and cross compilation :) -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On Saturday 30 June 2007 13:15:44 Blue Swirl wrote: On 6/30/07, Thiemo Seufer [EMAIL PROTECTED] wrote: Johannes Schindelin wrote: Hi, On Sat, 30 Jun 2007, Blue Swirl wrote: On 6/30/07, Christian MICHON [EMAIL PROTECTED] wrote: DetaolB aimed to be a much-less-than-a-floppy x86 linux live distro. Now, it's evolving more into a-la-slax type of distro. As the number of Sparc32 distributions keeps approaching zero, could you consider porting DetaolB to non-x86 CPUs? Yes, please! The reason why distributions drop sparc32 is the unmaintained kernel. Nobody stepped up for Linux kernel maintenance in the last years. Debian managed to keep up a sort-of working kernel for the last release, the people who put their time into it are disinclined to repeat this exercise. But there is a difference in maintaining a kernel suitable for high quality distribution with over 18733 packages working in different real hardware, versus a test/evaluation distribution with 30 packages running on Qemu. I'd see that as an enhanced qemu-tests.tar.gz. Just FYI, Firmware Linux builds for sparc and has for months now. http://landley.net/code/firmware Go ./build.sh sparc, and wait a bit. It even generates a run-sparc.sh in the build directory that'll invoke qemu against the kernel and ext2 image it generated. That creates a sparc cross compiler, uses it to build a root filesystem containing a native toolchain for sparc, and packages it into an ext2 image. Over on arm I've built binutils and gcc natively inside the emulator. The sparc platform has a problem that if I boot with init as a hello world program everything behaves as expected (there are two in the image for testing purposes, /tools/bin/hello-dynamic and /tools/bin/hello-static). But if you boot with init=/tools/bin/bash it hangs. And so do the busybox shells. I think it's a uClibc bug on sparc, but haven't made time to track it down. Either that or the kernel needs something _weird_ for console initialization. (The cross-compiler and kernel seem to be working fine...) You can try it out yourself by downloading all the *sparc* files from http://landley.net/code/firmware/downloads/images and then running: qemu-system-sparc -nographic -no-reboot -hda image-sparc.ext2 -kernel \ zImage-sparc -append 'rw init=/tools/bin/hello-dynamic panic=1 \ PATH=/tools/bin root=/dev/sda console=ttyS0' That prints Hello world!, panics, and exits. ./run-sparc.sh does the exact same command line with init=/tools/bin/sh (bash 2.05b), which hangs. Note that init=/tools/bin/ash (busybox ash) does the same thing. Haven't debugged beyond that yet... Rob P.S. I gave a tutorial about this system at OLS, and my lecture notes are at http://landley.net/ols/ols2007/tutorial.txt -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson.
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
The sparc platform has a problem that if I boot with init as a hello world program everything behaves as expected (there are two in the image for testing purposes, /tools/bin/hello-dynamic and /tools/bin/hello-static). But if you boot with init=/tools/bin/bash it hangs. And so do the busybox shells. I think there is a problem with the dynamic loader, I get a bus error when running the programs on real Sparc. If I try to run the dynamic loader, it reports on real HW as well as on Qemu: Standalone execution is not supported yet
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On Tuesday 10 July 2007 14:30:38 Blue Swirl wrote: The sparc platform has a problem that if I boot with init as a hello world program everything behaves as expected (there are two in the image for testing purposes, /tools/bin/hello-dynamic and /tools/bin/hello-static). But if you boot with init=/tools/bin/bash it hangs. And so do the busybox shells. I think there is a problem with the dynamic loader, I get a bus error when running the programs on real Sparc. Huh. That's odd because hello-dynamic is using the dynamic loader. (That's why there's a hello-dynamic and a hello-static.) It's entirely possibly that qemu and real sparc hardware are behaving differently, but I'm not seeing this bus error under qemu. (I haven't got real sparc hardware, so I can only debug against qemu...) If I try to run the dynamic loader, it reports on real HW as well as on Qemu: Standalone execution is not supported yet The ability to run the dynamic loader as an executable and the ability to use it as a dynamic loader are two completely unrelated things on a modern Linux system. The kernel doesn't _exec_ the library loader, it calls into it as a shared library. In fact, under 2.4 if you ever mount any partitions with noexec you also need to remove the executable bit from the shared library loader, because otherwise you can just run the library loader and feed it any program to run and it'll do it for you. (The library loader doesn't care about the noexec mount flag.) Of course between 2.4 and 2.6 they added an extra check to the kernel so it refused to exec a program if the shared library loader that program refers to didn't have the executable bit set, for security reasons. (And the glibc guys made ld-linux.so start checking the executable bit on libraries too.) This of course means that the old trick of removing the executable bit doesn't _work_ anymore, so mounting stuff noexec is essentially meaningless. Oh well, it already was if you had something like perl on the system. Or a command shell that could launch a shell script. :) Note also that this is why uClibc includes its own ldd, because the glibc one is just a wrapper that attempts to execute ld-linux.so with some debugging arguments to dump the library names. So the glibc ldd doesn't work on uClibc binaries, because they're not linked against ld-linux.so. The uClibc one works like readelf instead, and should work on anything. But anyway, the ability to run a library loader as a command, and its ability to function _as_ a library loader, are totally unrelated. Different entry points. This talks about the issue in passing: http://www.usenix.org/publications/library/proceedings/usenix98/freenix/record_html/lxrun-3.html Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson.
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On Wed, Jul 04, 2007 at 09:54:48PM +0200, Cedric Hombourger wrote:
The busybox link failure has an existing entry in mantis:
http://www.uclibc.org/bugs/bug_view_advanced_page.php?bug_id=1356
Just to expand on this one last time, here is the help-text of taskset:
config TASKSET
bool taskset
default n
help
Retrieve or set a processes's CPU affinity.
This requires sched_{g,s}etaffinity support in your libc.
This was slightly adjusted in uClibc trunk (to stub it out if the syscall is
unavailable),
a patch against 0.9.29 which updates this can be found here:
http://buildroot.uclibc.org/cgi-bin/viewcvs.cgi/trunk/buildroot/toolchain/uClibc/
HTH,
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On 7/10/07, Bernhard Fischer [EMAIL PROTECTED] wrote:
On Wed, Jul 04, 2007 at 09:54:48PM +0200, Cedric Hombourger wrote:
The busybox link failure has an existing entry in mantis:
http://www.uclibc.org/bugs/bug_view_advanced_page.php?bug_id=1356
Just to expand on this one last time, here is the help-text of taskset:
config TASKSET
bool taskset
default n
help
Retrieve or set a processes's CPU affinity.
This requires sched_{g,s}etaffinity support in your libc.
This was slightly adjusted in uClibc trunk (to stub it out if the syscall is
unavailable),
a patch against 0.9.29 which updates this can be found here:
http://buildroot.uclibc.org/cgi-bin/viewcvs.cgi/trunk/buildroot/toolchain/uClibc/
HTH,
I hit this today. I'll need this patch then, since I did not see the problem
on i686. Thanks!
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On Wednesday 04 July 2007 16:32:44 Christian MICHON wrote: On 7/4/07, Andreas Färber [EMAIL PROTECTED] wrote: Is there a special reason to use Aurora? I thought it was an abandoned port of Fedora Core 2... (with Fedora 7 available nowadays) Debian was the only maintained Sparc distribution I could recently find for qemu. that's the only port I found. maybe I did not look enough. thanks for the hint. Firmware Linux has a sparc target. http://landley.net/code/firmware Go ./build.sh sparc and then look at run-sparc.sh in the build directory. There's a bug I haven't bothered to track down (possibly in uClibc) that prevents the console from initializing properly, but if you boot with init=/tools/bin/hello-dynamic you get a hello world message. (I haven't tracked down why the shell hangs yet.) Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson.
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
ok, I found this file (google for it): stage3-sparc-2006.0.tar.bz2 I put it into a vmdk image file, preformatted in ext2 fs. I touched up a few files and used the sparc kernel and binaries from the qemu-windows page. I've now a native compiler for sparc32. I managed some stuff with it already. If the kernel patches I've works with this compiler, porting DetaolB to sparc32 should be fine. I'll just take some times (native compilation in qemu). Many of you will say: why not cross-compiling ? It's hard to setup. Actually, the paper from Rob at OLS should help me a lot when he'll release it. ;-) -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On Wednesday 04 July 2007 16:11:19 Christian MICHON wrote: On 7/4/07, Cedric Hombourger [EMAIL PROTECTED] wrote: You may want to look at crosskit.sourceforge.net thanks for this hint. I haven't looked at detaoib yet but it was surely created before crosskit and may therefore be a safer bet. DetaolB aims to be a native solution, not a cross compiling tool. I've to get to the point where a native sparc32 toolchain will be usable in detaolb-sparc32... What's the difference between deltaolb and Firmware Linux, anyway? I'm still curious about this. Firmware Linux currently builds both working cross-compilers and minimal native build environments you can boot into for qemu. It does this for x86, x86-64, armv4-soft and armv5-vfp (both OABI, I'll probably move the v5 to EABI when I get around to it), and both endiannesses of mips. It also does sparc32 (although there's a bug, probably in uClibc, which I have yet to track down that screws up console initialization, so init=/bin/hello prints hello world for both static and dynamic, but init=/bin/sh hangs.) And I've got a working powerpc cross compiler that builds a root filesystem but have yet to build a kernel qemu can boot. The theory I've been going on is that once you've got a minimal native build environment, you boot into it and build the rest of what you need in there for your target platform. The next release will come with a setup script to let you run Firmware Linux under itself. (And thus cross compile from arm to mips or equally silly things.) A friend of mine built 60 gentoo packages under the thing before he got bored, although he was using an x86 chroot rather than qemu. I'm trying to get _that_ script into the next release as well, and then tackle Ubuntu starting from http://www.quietearth.us/articles/2006/08/16/Building-deb-package-from-source Plus the distcc cross compile thing. I've now got networking working on arm (qemu's arm PCI controller can't do PIO yet, so I needed to switch from ne2k to rtl8139 setup for mmio, then networking worked fine) so setting up distcc is mostly a matter of making a cross compiler that does C++ as well. Not sure if it should be the bootstrap one or if I should build a second copy... Oh, by the way, the Fedora for Arm project is also building natively on arm, but they got some fast ARM hardware and stuck lots of DRAM and hard drive space onto it rather than using QEMU. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson.
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On 7/5/07, Rob Landley [EMAIL PROTECTED] wrote: What's the difference between deltaolb and Firmware Linux, anyway? I'm still curious about this. a few differences, quite minor actually (that's why I said in the past we shared many common goals :-) )... I actually started this in 2002, but then hit many bugs in uclibc. In the end, I actually used a trimmed LFS approach, using zisofs. My bootable env then was ~45Mb. At that time, buildroot was also starting... I lacked of time to work on it. The biggest difference today is that your firmware is based on automation or Makefiles, whereas I still use a LFS type of approach. I first build a static minimal toolchain with a static busybox: all native, no cross compilation. Then I chroot in it, compile uclibc, busybox, the toolchain. The rest is obvious, but quite manual. I really should do Makefiles... The other difference is that I base detaolb on aufs/squashfs (I do not think you passed that stage yet, if I recall not all the archs you're targetting can take this). That's today's improvement over the stuff I did in 2002 using zifofs. Oh, by the way, the Fedora for Arm project is also building natively on arm, but they got some fast ARM hardware and stuck lots of DRAM and hard drive space onto it rather than using QEMU. in 2003/2004, I also worked on porting linux to an Ipaq h2215. I actually then used buildroot arm precompiled, and managed to chroot in it using nfs over usb. quite cool, and the speed was better than qemu today. It was just a 400Mhz Xscale. I'm still interested in your cross compiling tutorial. I believe we all are :) If I start putting too many archs in the picture, I believe DetaolB will be redundant with Firmware. This is not intended. Originally I wanted to share the portable x86 env I carry on my usb key. Some of you asked for a sparc32 port. I'll complete this one at least (I'm progressing quite fast on it). -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On 6/30/07, Blue Swirl [EMAIL PROTECTED] wrote: As the number of Sparc32 distributions keeps approaching zero, could you consider porting DetaolB to non-x86 CPUs? ok, I documented myself, and I'll try on sparc32. any hint on patches, config files for the kernel ? will uclibc work well enough on sparc32 ? -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
Hi, You may want to look at crosskit.sourceforge.net (a crosstool/buildroot-like project that I have recently started and that you can find on sourceforge). Following your e-mails, I have added sparc support. The toolchain builds fine but busybox fails to link (sched_getaffinity and sched_setaffinity undefined). If I manage to pass this issue, I will then try to build a kernel for sparc for testing with qemu-sparc. I will also add glibc support (crosskit aims at providing scripts for building packages against either uclibc or glibc). I haven't looked at detaoib yet but it was surely created before crosskit and may therefore be a safer bet. Regards, Cedric Hombourger 2007/7/4, Christian MICHON [EMAIL PROTECTED]: On 6/30/07, Blue Swirl [EMAIL PROTECTED] wrote: As the number of Sparc32 distributions keeps approaching zero, could you consider porting DetaolB to non-x86 CPUs? ok, I documented myself, and I'll try on sparc32. any hint on patches, config files for the kernel ? will uclibc work well enough on sparc32 ? -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu ___ uClibc mailing list [EMAIL PROTECTED] http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
The busybox link failure has an existing entry in mantis: http://www.uclibc.org/bugs/bug_view_advanced_page.php?bug_id=1356 2007/7/4, Cedric Hombourger [EMAIL PROTECTED]: Hi, You may want to look at crosskit.sourceforge.net (a crosstool/buildroot-like project that I have recently started and that you can find on sourceforge). Following your e-mails, I have added sparc support. The toolchain builds fine but busybox fails to link (sched_getaffinity and sched_setaffinity undefined). If I manage to pass this issue, I will then try to build a kernel for sparc for testing with qemu-sparc. I will also add glibc support (crosskit aims at providing scripts for building packages against either uclibc or glibc). I haven't looked at detaoib yet but it was surely created before crosskit and may therefore be a safer bet. Regards, Cedric Hombourger 2007/7/4, Christian MICHON [EMAIL PROTECTED]: On 6/30/07, Blue Swirl [EMAIL PROTECTED] wrote: As the number of Sparc32 distributions keeps approaching zero, could you consider porting DetaolB to non-x86 CPUs? ok, I documented myself, and I'll try on sparc32. any hint on patches, config files for the kernel ? will uclibc work well enough on sparc32 ? -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu ___ uClibc mailing list [EMAIL PROTECTED] http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On 7/4/07, Cedric Hombourger [EMAIL PROTECTED] wrote: You may want to look at crosskit.sourceforge.net thanks for this hint. I haven't looked at detaoib yet but it was surely created before crosskit and may therefore be a safer bet. DetaolB aims to be a native solution, not a cross compiling tool. I've to get to the point where a native sparc32 toolchain will be usable in detaolb-sparc32... -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On 7/4/07, Christian MICHON [EMAIL PROTECTED] wrote: I noticed spurious fast keyboard repeats. Like I must be extra careful when typing commands when in the qemu-system-sparc guest. I thought that was fixed some time ago, but I'll check. I plan to build uclibc and the rest natively from aurora linux 2.99 any objection ? advice ? Aurora is fine, Debian should work on Sparc too.
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
Am 04.07.2007 um 21:45 schrieb Christian MICHON: I plan to build uclibc and the rest natively from aurora linux 2.99 Is there a special reason to use Aurora? I thought it was an abandoned port of Fedora Core 2... (with Fedora 7 available nowadays) Debian was the only maintained Sparc distribution I could recently find for qemu. Andreas
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On 7/4/07, Blue Swirl [EMAIL PROTECTED] wrote: Aurora is fine, Debian should work on Sparc too. when trying to boot aurora, it stops and complains about /dev/sda I already gave a hda disk. is it a problem of size or a problem of command line switch ? what command line did you use when you reported a successful installation of aurora earlier this year ? -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On 7/4/07, Andreas Färber [EMAIL PROTECTED] wrote: Is there a special reason to use Aurora? I thought it was an abandoned port of Fedora Core 2... (with Fedora 7 available nowadays) Debian was the only maintained Sparc distribution I could recently find for qemu. that's the only port I found. maybe I did not look enough. thanks for the hint. -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On 7/4/07, Christian MICHON [EMAIL PROTECTED] wrote: On 7/4/07, Blue Swirl [EMAIL PROTECTED] wrote: Aurora is fine, Debian should work on Sparc too. when trying to boot aurora, it stops and complains about /dev/sda I already gave a hda disk. is it a problem of size or a problem of command line switch ? what command line did you use when you reported a successful installation of aurora earlier this year ? qemu-system-sparc -boot d -hda aurora-1.0.img -cdrom aurora-1.0-sparc-disc1.iso I tested Aurora 1.0 and 2.0, 2.1 can't read from cdrom. I tried 2.98 only briefly and never 2.99.
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On 7/4/07, Blue Swirl [EMAIL PROTECTED] wrote: what command line did you use when you reported a successful installation of aurora earlier this year ? qemu-system-sparc -boot d -hda aurora-1.0.img -cdrom aurora-1.0-sparc-disc1.iso I tested Aurora 1.0 and 2.0, 2.1 can't read from cdrom. I tried 2.98 only briefly and never 2.99. I did this too. maybe aurora is not a good idea then. maybe simply a stage3 sparc from gentoo would do ? -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On 6/30/07, Christian MICHON [EMAIL PROTECTED] wrote: DetaolB aimed to be a much-less-than-a-floppy x86 linux live distro. Now, it's evolving more into a-la-slax type of distro. As the number of Sparc32 distributions keeps approaching zero, could you consider porting DetaolB to non-x86 CPUs?
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
Hi, On Sat, 30 Jun 2007, Blue Swirl wrote: On 6/30/07, Christian MICHON [EMAIL PROTECTED] wrote: DetaolB aimed to be a much-less-than-a-floppy x86 linux live distro. Now, it's evolving more into a-la-slax type of distro. As the number of Sparc32 distributions keeps approaching zero, could you consider porting DetaolB to non-x86 CPUs? Yes, please! Ciao, Dscho
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
Johannes Schindelin wrote: Hi, On Sat, 30 Jun 2007, Blue Swirl wrote: On 6/30/07, Christian MICHON [EMAIL PROTECTED] wrote: DetaolB aimed to be a much-less-than-a-floppy x86 linux live distro. Now, it's evolving more into a-la-slax type of distro. As the number of Sparc32 distributions keeps approaching zero, could you consider porting DetaolB to non-x86 CPUs? Yes, please! The reason why distributions drop sparc32 is the unmaintained kernel. Nobody stepped up for Linux kernel maintenance in the last years. Debian managed to keep up a sort-of working kernel for the last release, the people who put their time into it are disinclined to repeat this exercise. Thiemo
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On 6/30/07, Thiemo Seufer [EMAIL PROTECTED] wrote: The reason why distributions drop sparc32 is the unmaintained kernel. Nobody stepped up for Linux kernel maintenance in the last years. Debian managed to keep up a sort-of working kernel for the last release, the people who put their time into it are disinclined to repeat this exercise. good point. I'm not a kernel maintainer, I'm just a distro maker. -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On 6/30/07, Johannes Schindelin [EMAIL PROTECTED] wrote: Hi, On Sat, 30 Jun 2007, Blue Swirl wrote: On 6/30/07, Christian MICHON [EMAIL PROTECTED] wrote: DetaolB aimed to be a much-less-than-a-floppy x86 linux live distro. Now, it's evolving more into a-la-slax type of distro. As the number of Sparc32 distributions keeps approaching zero, could you consider porting DetaolB to non-x86 CPUs? Yes, please! Ciao, Dscho there might be a arm port (I'll need to figure out the framebuffer part though). the original target of detaolb is to have a quick x86 development environment that can boot/run quickly in qemu. -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On 6/30/07, Thiemo Seufer [EMAIL PROTECTED] wrote: Johannes Schindelin wrote: Hi, On Sat, 30 Jun 2007, Blue Swirl wrote: On 6/30/07, Christian MICHON [EMAIL PROTECTED] wrote: DetaolB aimed to be a much-less-than-a-floppy x86 linux live distro. Now, it's evolving more into a-la-slax type of distro. As the number of Sparc32 distributions keeps approaching zero, could you consider porting DetaolB to non-x86 CPUs? Yes, please! The reason why distributions drop sparc32 is the unmaintained kernel. Nobody stepped up for Linux kernel maintenance in the last years. Debian managed to keep up a sort-of working kernel for the last release, the people who put their time into it are disinclined to repeat this exercise. But there is a difference in maintaining a kernel suitable for high quality distribution with over 18733 packages working in different real hardware, versus a test/evaluation distribution with 30 packages running on Qemu. I'd see that as an enhanced qemu-tests.tar.gz.
[Qemu-devel] ANN: DetaolB v0.4 is released
DetaolB aimed to be a much-less-than-a-floppy x86 linux live distro. Now, it's evolving more into a-la-slax type of distro. DetaolB v0.4 has been released 29th,June 2007 on sf.net = http://sourceforge.net/project/showfiles.php?group_id=140321package_id=155481release_id=519786 Mailing list: [EMAIL PROTECTED] Changelog: == - updated aufs and squashfs - increased the list of modules - vesafb-tng included (default boot is 800x600x24bpp) - included some X11 functionality: log in as root, then xinit - included ext2fs utilities: you can now work in qemu/vmplayer - self sufficient to compile itself and linux-2.6.21 - killing features: git, vim Detailed list of modules: = barebone: busybox-1.6.0 e2fsprogs-1.39 uclibc-0.9.29 zlib-1.2.3 dev: bash-3.2 binutils-2.16.1 bison-2.1 bzip2-1.0.4 coreutils-6.9 (od tail) cpio-2.8 diffutils-2.8.1 findutils-4.2.31 flex-2.5.33 gawk-3.1.5 gcc-3.4.6 git-1.5.2 gzip-1.3.12 headers-2.6.21 less-382 m4-1.4 make-3.81 ncurses-5.6 patch-2.5.4 tar-1.17 vim: vim-7.1 x11: fvwm-2.4.11 xfree86-4.2.0 -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
