The Slackintosh project currently has their hands full with work on their upcoming 12.1 release. Performance is quite good under the current version, which implements almost all Slackware 12.0 features.
I'm working on booting Slackintosh from a USB drive on a G4 Mac Mini, which involves learning details of yaboot, the PowerPC equivalent of lilo / grub.
Would there be much demand for Slax or Linux-Live on legacy Macs?
And about the linux-live tools and especially mksquashfs, can your ppc version of unsquashfs work with a squashfs file (lzm for example) that has been made on an x86 ?
I recently ported the squashfs tools (patched with lzma support) on Mac Os X PPC, I can use it (create/open lzm), but can't work with x86-made lzm. I got an endianness problem....
How about your version ?
Actually, I'd like to be able to crosscompile for Slax, from ppc to x86, and from x86 to ppc :)
Thanks for the quick feedback, ben_coh -- I'll check what would be involved in porting Linux-Live and Slax, while tackling the yaboot issues. The Slackintosh guys may have most Slackware 12.1 packages ported soon after Pat's release.
I'm just a Slackintosh user, but was able to hack their install scripts to support booting from a USB drive. They'll integrate those ugly hacks if I can recreate them as clean, reliable patches.
As to squashfs, there are three versions of Linux-Live in the directory I mentioned above, with the latest dated 2006-Jul-24. Was Tomas even using squashfs back then?:
(There's also a larger image there named GUS_wesnothlive_powerpc.iso which the README describes as having KDE and Fluxbox to run games under X11.)
Since all packages need to be recompiled for PPC, and the Live CD would boot only on the appropriate CPU, would you actually need to read an .lzm built for the other architecture?
If so (maybe for data files), then I've read that there's a way to automatically resolve the endian-ness issue when compiling under OS X as a Universal binary. Google would be your best bet for specifics -- while I began software development in the mid '70s, I'm a n00b with PPC.
Actually I have an endian-ness issue with lzm, not binaries (at least I've never had such a problem when cross-compiling between to endian-different cpu).
Little question to make things easier : the qemu ppc bios seems to be broken (well maybe it's not, but I have no documentation) as I can't make it work with the slackintosh-live ....
I believe it has some trouble with the 'cd' device ID, and thus can't find the kernel/initrd to boot with.
So, do you know another way to boot slackintosh in a virtual machine ?
How are you using Qemu, ben_coh: are you emulating a PowerPC on an x86 CPU; or an x86 PC on a PowerPC CPU; or some other arrangement? What OS are you using as the host?
Ideally I'd like to run a PowerPC version of Linux in a VM, under Mac OS X on a G4 Mac. The most promising open-source VM project I've found so far is kju, a Qemu port for the Mac:
However, kju seems focused on relatively slow cross-CPU emulation, rather than the more efficient hypervisor approach used by VMWare and Parallels. But those require recent x86 CPUs with hardware support for virtualization. So it may be a while before Linux performance is acceptable in a VM under Mac OS X on a G4.
That's why, for now, I'm more interested in booting PowerPC versions of Slackintosh and Slax, using either the Boot Camp approach (Startup Disk or Option-key Startup Manager), or a grub / lilo-like boot menu on the Linux startup disk (external hard disk or flash drive).
But if you have a working, open-source VM solution for PowerPC, I'd love to hear the details. I've learned a lot about Open Firmware device IDs, which might be useful if your VM is emulating a PPC-based Mac.
I'm working on a PowerBook G4, so I'm trying to emulate a PPC on a PPC :)
I've tried qemu both using Q (kju) and my own port. None of them boots the slackintosh-live iso :(
But I directly booted on your slackintosh-live cd and started playing with it.
I first had to add some devtools (gcc/g++, binutils, make, libtool, autoconf/automake) to do some interesting things :-) (I got them from the slackintosh tgz repository).
My idea is to upgrade your live slackintosh to the latest Thomas's live-linux kernel/initrd with support for squashfs+lzma, and other cool thingies :)
Little question : When booting from your slackintosh livecd, I finally managed to mount an ext2 formatted usbpen (had to find out that the usb-storage kernmodule had to be loaded first).
But I can't mount my hfs internal disk (running my main system, so I don't want to mess it up :P ).
Well I'm not sure whether my disk is hfs or hfs+, or any other Apple HFS flavour ^^
hi all,
just a quick note: there's no SLAX for powerpc :)
Those isos are just livecds built upon slackintosh + linux-live, but they've nothing to do with this project (apart for using my powerpc ported version of linux-live).
Said that it would be nice if someone is going to breathe some more life in the linux-live/powerpc project and, maybe, a SLAX/ppc (ok, I'm daydreaming :-P )
Considering Slax is roughly linux-live + slackware , then even if this live version of slackintosh isn't Slax, it's kinda close to it.
That's why my idea is first to port the latest linux-live :)
Slackintosh 12.0 will mount your Mac OS X hfs+ partitions, and 12.0 may be a better development environment than the old ISO images. USB support is compiled into the Slackintosh 12.0 kernel, though you do need to specify 'rootdelay=10' when booting from a USB drive.
I installed 12.0 to an external USB hard drive, to preserve my internal drive for just OS X. Slackintosh's installer will currently fail to make the USB drive bootable, but you can boot it by entering yaboot commands at the 'boot:' prompt from Install Disk #1. I can provide details if you go that route.
Again, I'm just a Slackintosh user, rather than a member of their team, or a creator of the old ISOs. Thanks, sid77, for the corrections about those images.
Yes, the first goal for 'Slax 6 PPC' should be to port the latest Linux-Live. Endian issues could likely be handled by swapping bytes on-the-fly. Or as an initial work-around, we might bypass squashfs to facilitate porting.
I've yet to find source code for most Linux-Live binaries -- have you found all those, ben_coh?
Well, I finally made it mount my hfs+ disk, but I can't write ...
Anyway, I wanted to build the latest kernel from your livecd, but most of the libraries are out-of-date, so I can't build it.
To correct an apparent misunderstanding: I'm not a member of the Slackintosh team, and I had nothing to do with creating the Slackintosh Minimal Live CD, nor with porting Linux-Live to PPC.
Examining those old projects may be useful in porting Linux Live 6 (and Slax 6) to PowerPC. However, Slackintosh 12.0 will serve far better as a development environment.
I have downloaded, un-compressed, and searched through the latest Linux Live package:
There are links to squashfs, lzma, aufs on Thomas's site (linux-live.org)
About hfs+ : then how to mount it read/write ? (working with the slackintosh-live)
Actually, mount says that it's mounted read/write, but when trying with echo > for example, I got a read-only error.
Is there any mount option ?
OK, thanks, I found mksquashfs.c in the squashfs-tools directory, inside squashfs3.3.tar.gz there.
The endian-ness issue is related to a 'filesystem flag' called swap. That flag determines whether or not bytes are swapped, by calling (or skipping) a routine called SQUASHFS_SWAP_DATA.
So we should be able to solve this with a little more digging, probably for a 'config' or 'make' variable to change the default state for 'swap'.
If you're adventurous, to get write access to hfsplus volumes under Linux, I've read that you first need to disable journalling under Mac OS X. In Terminal, 'diskutil disableJournal' will do that, if you boot from a different OS X volume.
After booting back from Linux to OS X, you can run 'diskutil enableJournal'. There's supposed to be a GUI for these commands in Disk Utility, though I've yet to find it under Leopard.
But, do you really want to risk damaging your Mac OS volume, especially under an old 'test-drive' live CD? Under Slackintosh 12.0, KDE automatically mounted my Mac OS X volumes rw by default. For safety, I chose to remount ro, to avoid any possible damage.
From the command line I also tested 'mount -t hfsplus ...' but again, I chose read-only. I believe Slackintosh 12.0 has a 'man' entry for 'hfsplus'.
A little more digging in the squashfs-tools directory turned up this macro in several files:
#if __BYTE_ORDER == __BIG_ENDIAN
...
However, there are no instances of a '#define' statement for either of those values in this directory. So these must be defined higher up, perhaps near the top level of the kernel source tree.
So if endian-ness failed to get configured automatically in your previous build, perhaps it needs to be set manually as a kernel build option?
So far I only tried to port the squashfs-tools to Mac Os X, not to a ppc linux kernel.
I managed to build it (with some tweaks).
And I think the BYTE_ORDER should be defined in one of the system headers (dunno which one ...)
From the ftp directory which you supplied, squashfs-tools appears to be part of Tomas' kernel source tree.
So, as with Linux kernel modules, squashfs-tools may "expect" to be built in the context of the kernel under which they will run. Specifically, squashfs-tools may depend on macro definitions or environment variables which are normally set up during kernel configuration. And these values must match the settings in the kernel.
The way I understand it, filesystem support is normally either integrated with the kernel, or else implemented in 'user-space' with a fuse-type filesystem. Either of these methods would allow mounting a foreign filesystem (such as squashfs) on a mount point under the OS's root filesystem.
Another option might be to keep the squashfs separate from the root filesystem, to be accessed only via special tools, as with the old 'mtools' for accessing MS-DOS disks under Linux. But if squashfs-tools were meant to be used like mtools, then they likely would not have been integrated into the kernel source tree.
So, do you know whether squashfs is already supported under Mac OS X, or are you just hoping to add support by kludging the build process for squashfs-tools, perhaps to use them like mtools?
If the latter is the case, then your tweaks for Mac OS X would at least need to set up all the same macros / variables which would otherwise be set by the Linux kernel configuration process.
So far, squashfs isn't supported under Mac Os X as a filesystem.
But I could at least build the tools, that you can use the way you would use tar, ie:
- mksquashfs to create a squashfs filesystem (like tar -cf)
- unsquashfs to extract a squashfs filesystem content (like tar -xf)
This isn't what squashfs was built for, but it would allow me to open/modify/create squashfs modules from Mac Os X.
And with some cross-compiling tools, I would be able to build packages (from source) for Slax x86 from Mac Os X.
NB : You don't need the kernel-tree to build the tools.
First it would help if you'd post the 'tweaks' you used to build the squashfs-tools binaries, along with all warnings from the build process.
Then at the very least, we'll need to discover and pass the appropriate __BYTE_ORDER macro value to the makefile. That requires finding the definition of __BIG_ENDIAN (and perhaps __LITTLE_ENDIAN), since I failed to find that #define anywhere in the squashfs-tools source directory.
The man pages show that mksquashfs takes an argument -be or -le to create a big or little endian file system, respectively; but unsquashfs does not appear to accept those options. So we need the __*_ENDIAN macro definitions to get a build which will be compatible with files created under x86 Linux.
I have found that squashfs-tools is very specific to Linux, with no record of it ever having been ported to OS X or any other *nix. If you can find the definition of __BIG_ENDIAN anywhere in the Linux headers, that would expedite the process, as I mostly run Leopard these days. If it's not in the normal system headers, then it would be somewhere in the kernel source tree.
Yes and yes: G4 does support switching endianness, but that has consequences for all running software; and there's also a hardware issue on the motherboard / chipset:
When compiling the tools, or the kernel ?
I can't build the kernel on Mac Os X.
Oh, and checking the tools source, I found this in mksquashfs.c :
#ifndef linux
#define __BYTE_ORDER BYTE_ORDER
#define __BIG_ENDIAN BIG_ENDIAN
#define __LITTLE_ENDIAN LITTLE_ENDIAN
#include
#else
#include
#include
#endif
And at top of code, there is a sys/types.h include, which includes machine/endian.h itself , which includes ppc/endian.h , which defines BIG_ENDIAN.
So, in mksquashfs, __BIG_ENDIAN is defined :)
(__BYTE_ORDER and BYTE_ORDER are defined the same way, so no worries about that)
I was referring to compiling the tools, since you want to use them stand-alone like 'tar', without kernel support.
I'd previously searched the entire squashfs-tools directory using Spotlight, but failed to find the #defines you quoted from mksquashfs.c so, I will abandon Spotlight and use 'grep' from now on ;-<
From what you just reported, it looks like the #defines should work as-is, without the changes I mentioned above. I'll double check those values against /usr/include/ppc/endian.h
Meanwhile it would *really* help if you'd detail the 'tweaks' you made to build squashfs-tools, along with any warnings you might have received!
Hmmm .... good idea .
First, which version are you working on ? 3.3 ?
To build the 3.3 without lzma patch :
- Remove the FNM_EXTMATCH flag as argument to the fnmatch function, in unsquashfs and mksquashfs (there is only one call to this function in each file)
- make
To build the 3.3 with the lzma patch, that's a bit more .... difficult.
You need to download the sqlzma tarball from http://www.squashfs-lzma.org/ , follow the readme (patching files, ...), edit the Makfile to disable the modules building (there is a make variable to change from 1 to 0, don't worry the Makefile is annoted).
Then you have to modify the mksquashfs.c and unsquashfs.c the way you would do when building without lzma support (FNM_EXTMATCH).
Then make. You'll get some errors about some linx files missing, or something like that. Just use make -ik to ignore them, and wait.
At the end, you'll see that unsquashfs was built, but that mksquashfs failed.
Check the error : missing symbols. You'll have to manually link the different files (get the commandline from your make feedback), adding the lzmaXXX/CPP/7zip/Compress/LZMA_Alone/7zCrc.o object file. (maybe it's lzmaXXX/CPP/7zip/Compress/LZMA_Alone/7zCrc_r.o , both of them exist)
The byte-order of a squashfs filesystem depends on the endianness of the CPU on which it's created, unless you override this using the mksquashfs options -le or -be.
This design optimizes performance at the expense of portability.
Currently unsquashfs has a -stat option which can sense and report the byte-order of a squashfs filesystem. This is implemented in subroutine squashfs_stat() which also prints other filesystem statistics.
One solution would be to enhance unsquashfs.c by adapting the byte-swapping logic from mksquashfs.c and add a command-line option to select the conversion.
We might want to check upstream to see if they already have plans to implement this. In any case, the change looks fairly simple to code.
But something is bothering me in unsquashfs.c : there are several variables, like 'swap', that should tell us whether to swap or not. But when meeting a little-endian, the program decides to stop. (around line 1795).
I just found something. Seems that with just a little tweak, we can make it work.
- Look for that string in unsquashfs.c : case SQUASHFS_MAGIC_LZMA_SWAP:
- Comment the line : ERROR("Reading a different endian SQUASHFS filesystem on %s\n", source);
- And after : swap = 1;
Add : break;
I tested it with something very simple (a little-endian module with a text file, that the untweaked lzma-patched unsquashfs couldn't expand). It worked !
Gonna test it with a module I made on Slax x86.
Great work! The original, un-patched unsquashfs.c looks like it might work without the added break; so I wonder if your tweak might be correcting a problem introduced by the lzma patch?
I've already been looking into MacFUSE for two reasons: first, sshfs is very useful under Ubuntu, so I'd also like to run sshfs under OS X.
Second, it would be great to access my Slackintosh drive under OS X, and this thread indicates that ext2 support might be available soon via MacFUSE:
Slackintosh may be a useful development bridge to get from OS X to Slax PPC, so bidirectional filesystem access via FUSE would be very convenient.
Since unionfs already works under MacFUSE, it should also be straightforward to port aufs. Add a squashfs FUSE port, and OS X becomes a nice development environment for Slax.
But I didn't know unionfs has been ported to OsX/MacFuse.
Actually, I think that Mac Os X natively supports a sort of union filesystem (check the hdiutil manpage and look for union, then check the mount manpage and look for union ;) )
Yes, MacFUSE supports sshfs but I need to check which version, fink or MacPorts, would be best for both Leopard and Tiger. I've been tied up with clients and with Leopard support issues here.
The Mac OS X Ext2 Filesystem project has been Inactive for a couple of years, and has yet to be updated for Leopard. So it seems safer to wait for ext2 support to be released for MacFUSE, as I use the same Mac for both production and testing.
Support for unionfs is listed on the main MacFuse page:
but I mentioned that, in my previous post, only to point out that it should also be straightforward to port aufs. Tomas has found that to be far superior, so we'd likely want aufs for Slax PPC, rather than unionfs even if that is supported under OS X.
Thanks for adding a link to this thread from the other one, "dir2lzm for OS X?". Slackware 12.1 may be released soon, so I hope to finish up my USB Installer patches for Slackintosh to be ready in time for their 12.1 release.
Have you done any further testing on the idea of cross-compiling Slax modules?
it will be great to port SLAX for POWERPC cause it's a amazing opportunity to use LIVE distr with COPY2RAM on MACINTOSH notebook
at first- without HDD notebook run longer without recharging
2-notebook becomes more portatable and no vibration can hurt hard disk(if it unmounted and linux run from cd or from RAM)
3-it makes ibooks more universal
I will have to jump in and join you in building Slax 6.0 for PowerPC. It is something I need to do for a project at work, so hopefully, I will be able to pull your knowledge into this project as needed. Thank you for getting this started.
mektigmuse wrote:
I will have to jump in and join you in building Slax 6.0 for PowerPC. It is something I need to do for a project at work, so hopefully, I will be able to pull your knowledge into this project as needed. Thank you for getting this started.
it will be great +) every mac must have it's slax ))) i wish i can help, ,but i can't =(
--------------------------------------
you might ask for help and PPC guidence in the power developers message board if you want to take this PPC slax anywere...
if your looking to use easy ways to increase linux PPC and perhaps even x86 slax code speeds
its always wise to have a word with Markos and look at his Freevec libray routines and speed increase charts, serious speed increases there, take a look if you understand these things...
and can include this freevex in the ppc or x86 compiles.
they have a BSD both free and open sections ,but they dont get used much as people just dont seem interested in contributing in these sections currently!
incase i wasnt clear , it appears that until Markos looked at it, PPC linux did and does NOT have ANY Altivec or other SIMD optimaisations in its kernel or related libs.
his freevec library is a current and ongoing project to finally make a reasonably easy way to make use of far better and tested lib funcitions for your apps and OS to take advantage of with very little effort apparently, if you understand these thing OC ;) and are willing to take the time and effort to include it in your compiles... http://www.freevec.org/functions
doh, and i cant see any reason it cant also be used for *BSD, do they also lack any ALtivec or other SIMD optimisations also? both PPC and x86, perhaps you might like to ask him and even help each other become far better and produce faster code for everyone app benefit.
i've downloaded some "slackintosh" - and its REALY WORK!
but the only KDE version, network doesnt work(ethernet and wifi-airport)
i've got powerbook g4 1,5 ghz, lately i've got ibook g4 and this dist dont work on it
lately i will try on imac g5
is it possible to put network drivers to work into this distro? and may be gnome or fluxbox interface? and is it possible to turn of Hdd and copy to ram it (very useful thing on notebook)?
and i've get some geexbox - multimedia dist with copy2ram enebled by default, 17mb iso but it didn't boot up into GUI - just black screen (on powerbook) - may be useful for other PowerPC notebook users
