Installed slackware on a usb-stick - no problems whatsoever.
I want to carry that li'l sucker around as my personal linux-on-a-stick - no matter which machine I put it into and boot from it.

My problem is booting - and I'm using 'grub legacy' (and please, grub2 is an OS looking for a bootloader - I don't want it!)

What happens is that I get the (in)famous:
My layout of the stick is as follows:
part #1: ext2, 64M (my 'grub'-partition)
part #2: swap, 2 gigs
part #3: jfs, 30 gigs, slackware in all its glory

I probably should explain my 'grub-partition', it is something I always use (as I generally have at least 3 different distros on each harddrive/computer).
Then, whenever I install a new distro, I let its bootloader reside on the partition of its root fs - be it grub or grub2. Then my menu.lst just contains 'root (hd0,X)' and 'chainloader +1' ... ez ...

I always use ext2 for my first partition - it is never mounted unless I change anything in there. In this example, the stick comes out as sdc - all depends how many hard-disks in the computer; on my laptop it would be sdb.
Then I make my menu.lst-file
- and it looks like this:
The way I understand it - when you boot from any disk, that disk will be device (hd0) - then the kernel gets loaded and your bootdisk might be demoted to eg. the 3rd disk - all depends on the bios.

After installing slackware, I also change the /etc/fstab to use UUID for the swap and rootfs so I should not be dependent upon which sdX my stick will end up as.

So yes, the kernel boots and everything looks good until it attempts to mount the root filesystem ...

And yes, I _have_ googled and got some few thousand hits ...

Anyone here that can solve my li'l problem?
Thank yall in advance!

Does grub-legacy have the jfs filesystem support build in? Do you need to load a module for jfs?

Are you booting your stick on bare hardware or inside a VM?

My guess would be, too, that you might need to load a module for jfs. One option here would be to set up an "initial RAM disk", an initrd that loads the required modules for your combination of kernel and file system.

gargamel

"The way I understand it - when you boot from any disk, that disk will be device (hd0)" This not correct. The order of the disks depends on how the BIOS sees them. In your case, the computer does not see sdc3 -it is trying to boot unknown-block(0,0), which is hd0,0 or sda1.
Note that once the kernel is booted *it* may see the disks in a different order than the BIOS sees them.

This doesn't help perbh, but I have a merchandise request...Pat is there any way that you could add pre-loaded Slackware USB sticks (with the Slackware logo on them of course) to the store? I know I'd definitely save up my pennies and buy one (or two)!

You still have to have everything you want in the kernel, but I'd also consider that, although it's easy enough to create one of your own and who knows if there is enough interest to buy usb thumb drives in bulk.

I'm _not_ using a 'vm' - it is mainly as a 'demo' (whereever I can boast of linux) or as a tool to sort out family pc's (sadly, most of'em are still using 'that other' OS).
And yes, jfs support _is_ in the hugesmp kernel - funny thing is - when it boots from the stick, if I use /dev/sdX3 in the kernel line - it all works beautifully.
It is almost like legacy grub does not support 'root=UUID=....' or 'root=LABEL=...' in the kernel invocation line (I'm checking out the manual now)
I get around it all by using a sufficiently long timeout so i can push 'e' and edit the kernel line to be /dev/sdX3 (where the stick might be sdb, sdc or sdf or whatever). However, that is not very satisfactory - it almost feels like cheating because I first have to boot and I know it will fail - just to see what device name it has - and then change it on the next boot ...

Really it doesn't even have to be preloaded with anything...like you say it's easy enough to do it myself. You're right though, there probably isn't enough interest in ordering them in bulk. Plus there's the whole obsolescence issue, where thumb drives seem to double in capacity every year for the same price.

Plueeze - is there nobody that knows how to have a persistent linux on a usb-stick???
Maybe the subject-line is not sufficiently 'catching'?

Have you looked at how the usb installer works? It's documented in the Slackware tree.

I've never had to use Grub yet.

I use lilo.

Here is an example of triple booting Slackware, Mythbuntu and NetBSD from different partitions on the same drive:

http://www.linuxquestions.org/questi...f-grub-937568/

You have already created a jfs partition with linux Slackware and lilo on it.

Edit the etc/lilo.conf on the usb and treat the usb like a hard disk.

On my system there is one hard drive, /dev/sda
so my usb sticks show up as /dev/sdb

The third regular partition of a usb stick would be /dev/sdb3.

Or for a newer way, use "UUID=..."

- sorry - double-posted

@damgar:
Oooops - never thought of that - will do ...

@comet.berkely:
I have no problems multibooting - I do it all the time (see my initial posting).
Funny thing is - my usb-stick will boot perfectly if I use the device name, ie:
Obviously, this will _not_ work if I try it in a machine with more than one disk - eg. both my desktops have two sata-disks, so the stick comes up as /dev/sdc - and therein is my big problem. I want a stick that will boot into slackware on _any_ machine. For some strange reason, my grub will _not_ honor 'root=UUID=...' or even 'root=LABEL=...'

As I initially said - my first (small) partition is (what I call) a 'grub'-partition - it only contains the grub-files and grub itself is installed on the MBR. In this case I have used archlinux's grub (because it is patched to support ext4) - and I have no success using root=UUID=...
Maybe I should try slackware's grub?

I'm not 100% positive here so keep that in mind. I don't believe root=UUID= is actually a valid kernel parameter (root= is, obviously, but not UUID=); instead, the init script in a mkinitrd-generated initrd determines the actual device (using findfs) when root=UUID= is passed. If you don't use an initrd, then it uses the system init binary and root=UUID= is not valid. I'm not sure how devices are populated before the root system is mounted, so I don't know if (udev-generated?) /dev/disk/by-uuid/* is available during early boot...if so then you could specify root=/dev/disk/by-uuid/UUID_HERE but if not then I don't know how you would get this to work without an initrd. Of course, you could just use an initrd with the generic kernel and the root=UUID= syntax would work without further effort.

Again, I'm not 100% positive, but I believe that is the situation as it stands.

1 members found this post helpful.

@T3slider:
Thank you!! That makes perfect sense (at least to me).
And yes - obviously there will not be any problems using a 'token' initrd. It really ought to be a 'token' one since I don't know the innards of any machine I might want to boot it on.

I will try out all of your suggestions and let yall know if/how it works.