I'm using Version 1.1 i486 (32 bit) from ISO installed onto a hard disk. I'm sure I'll find this once you move this conversation... Slackware linux doesn't have Forums and I'm still getting use to the layout of these Forums. There are a lot of topics... Very easy to get lost here. So once again my apologies for posting in the wrong topic and thanks for moving all this.
As far as the script goes, I'm sure it works well under normal conditions.. Everyone here is likely using ext3, ext4 or fat32 which is syslinux friendly. I just have my own habits and when I downloaded this distro, I treated it like I would slackware... Trip to cfdisk, create partition and mark active, save... mkreiserfs /dev/sda1, blar blar. When I rebooted it mounted it as /mnt/sda1 and I used the GUI tool to install the OS to the disk. I checked off Install Loader but it still didn't boot. BIOS error about no bootable media, etc, etc. Then I got to thinking syslinux likely doesn't like reiserfs, so I ran the script from /mnt/sda1 and told it to install LILO. I'm just use to lilo and I really didn't want to debug the problem with syslinux... Thats when the problem crept up and it wrote a lilo.conf with /dev/sda1/boot/vmlinuz as the filename instead of /mnt/..... That confused lilo and it failed to install. Once I saw the problem from the errors it gave, I simply edited lilo.conf and fixed the paths, then ran that script again and told it to install lilo. Problem solved. So I'm still on reiserfs, just with lilo and all its simplicity vs that very well drawn boot menu the ISO had with isolinux. Whoever put together the bitmaps, etc for the isolinux loader, great job! It makes me want to reformat it as ext3 just so I can install syslinux.
You guys got a FTP or HTTP Directory full of these modules... personally rather download them directly and just drop them in the modules directory and activate them. Overall, I have to catch up again, because I know all the ins and outs with slackware and I've already discovered the /etc/rc.d/ is remarkably simular to slackwares.. Right now I have a Slackware live that I built using build-slackware-live.sh. Same type of concept, I have a changes folder that shows new files added after the union was created and in that sense, I could copy out the files needed as I compiled and installed software 1 package at a time to make additional modules by simply snapshoting the changes folder, create module, then reboot (to clear changes (which is a ramdisk) and activate the new module I build from changes which in theory should bring me back to that current state) so I can make the next module (of course stripping /var/log, and other stupid things that are written by the OS).
My only real different with this OS is I don't want the memory disk mounted read-write at all. Rather it be like the ISO, create changes to a ramdisk and discard on reboot. It does this when booting Porteus from CD but not from the disk drive. Although, I'm sure you have some kernel parm that enables such support, for all I know "Always Fresh" does this for you, I just haven't played with that option yet.
On a good note, I could really be an asset to Porteus... I've always liked slackware and its simplicity, in a way this implements an "undo" option if things should really go wrong. This distro of linux is very neat, clean and compact. This is the IDEAL environment for making small appliance stuff like MythTV Frontends, Internet Cafe environments, Arcade Machines, etc. Not to say that its limited to that. Because in no way is that true. EVERY slackware package could be converted to LZMA Modules. In a few days I could rebuild this entire system to run a full fledged Slackware System and the entire system could have those packages (modules), activated, deactivated, deleted, on the fly. And it would do every bit as good as running slackware itself. The only real reason that would be silly is because this distro is much more up to date... They are still pondering the 2.6 kernel on Slackware 13.37 and I finally got bored waiting for the next release... This is running a kernel that's just about BLEEDING edge these days. Although, I did manually build a 3.x kernel in Slackware 13.37 and it worked GREAT!
I've had some interest in btrfs since I watched the conference video about it and a bleeding edge kernel is needed to use the latest features, fixes. Same sorta concept you can pull off using Porteus. Except instead of modules you have filesystem snapshots built into the filesystem itself with compression, etc. Restoring to a previous point was as easy as a kernel parm from the boot loader that points at the specific filesystem snapshot id number. It also supports filesystem level raid (each file can be mirrored or not depending on flags, etc).
Anyhow, it looks like you guys run a really cool community here and I wouldn't mind being apart of it...