tomsrtbt linux on usb floppy disk
johnlumby
linux working on a usb floppy disk.
It is probably just history now, but for anyone who may still want to
be able to do this, I have a working system which boots and runs
from a usb floppy and includes all facilities including building
itself on a usb floppy. Based on linux 2.2.21 and libc5 and with
several newer versions of tools such as e2fsprogs 1.41.13
John Lumby
Sidney Lambe
I've got TRB here. Nice little tool. I have a regular floppy
drive, but if you were to post your document, I'd copy it
to disk. You never know...
Your article gives the impression that there is something called
a "USB floppy disk" that is different from a regular floppy
disk. I don't believe that is true.
Sid
johnlumby
wrote:
> On comp.os.linux.setup, johnlumby <johnlu...@hotmail.com> wrote:
> ...
> John Lumby
>
> Nice little tool.
Indeed it is.
> if you were to post your document, I'd copy it to disk. You never know...
I am happy to post my floppy image somewhere but don't see any "files"
or "attachments" section for this group.
Is there one? Or feel free to request by email.
>
> Your article gives the impression that there is something called
> a "USB floppy disk" that is different from a regular floppy
> disk. I don't believe that is true.
>
Both true and not true. True if you are referring to the 3.5i
diskette itself - yes, that's the same in each case.
But if and when you try booting your "built-on-a-PC-floppy-drive"
diskette from a USB-attached drive,
you'll find its a very different device at all levels of the system
under filesystem level.
Different capacity, different device drivers, different device
name. And those differences require several changes
in both the linux OS and to tomsrtbt files, in order to be able to
load the root filesystem from it
into the ramdisk. So in the tomsrtbt context they are really
different devices.
>
> Sid
JEDIDIAH
....I would imagine it all comes down to the BIOS of the particular machine.
--
The difference between a monopoly and a "market leader" is |||
that you can simply ignore a "market leader" and be no worse / | \
for it.
Mike Easter
> Sidney Lambe
>> Your article gives the impression that there is something called
>> a "USB floppy disk" that is different from a regular floppy
>> disk. I don't believe that is true.
>
> ....I would imagine it all comes down to the BIOS of the particular machine.
I have a BIOS which offers options to boot from USB zip, USB floppy, or
USB CDROM along with the other 5 non-USB choices.
It won't boot from a USB thumbdrive without workaround - ie create
bootable USB thumbdrive, boot from PLOP CD bootmanager which can manage
to boot from the USB.
Puppy Linux has a lot of tricks to try to help boot from 'difficult' USB
situations, but none of them worked on that machine.
--
Mike Easter
johnlumby
>
> ....I would imagine it all comes down to the BIOS of the particular machine.
>
similar is basically a 3-part process :
1. BIOS loads the boot program, LILO, from the disk and runs it
2. LILO loads the kernel from the disk and runs it
3. The kernel loads the root filesystem image from the disk and
stores it in a ramdisk (/dev/ram0)
Parts 1 and 2 all come down to the BIOS as you say (LILO uses BIOS to
read the floppy).
If there was no part 3 to worry about, you could boot a "built-on-a-
PC-floppy-drive" tomrtbt from a floopy, BIOS permitting.
But part 3 requires that the kernel knows how to read a file off a
specified sector range from the boot disk,
and a standard tomsrtbt 2.2.x kernel can't do that if the disk is
attached by USB. Basically, there is no
ramdisk support for reading from removable SCSI .
I think some other people got it to work by splitting part 3 from
parts 1&2 onto two different floppy disks and
switching them in the drive at a prompt, see e.g.
http://www.mail-archive.com/toms...@toms.net/msg01448.html
but I don't know if that setup was ever distributed. Certainly now
that I look I see other appends asking for help
dated much later than that one so where it went I don't know.
My approach was to add the missing support into linux 2.2.21
so it uses the same single-disk concept.
John
Sidney Lambe
> On Jan 10, 3:34=A0pm, Sidney Lambe
> <sidneyla...@somewhere.invalid> wrote:
>
>> On comp.os.linux.setup, johnlumby <johnlu...@hotmail.com>
>> wrote: ... John Lumby
>>
>> Nice little tool.
>
> Indeed it is.
>
>> if you were to post your document, I'd copy it to disk. You
>> never know...
>
> I am happy to post my floppy image somewhere but don't see any
> "files" or "attachments" section for this group. Is there one?
> Or feel free to request by email.
Nothing but plain text allowed on groups like this.
>> Your article gives the impression that there is something
>> called a "USB floppy disk" that is different from a regular
>> floppy disk. I don't believe that is true.
>
>
> Both true and not true. True if you are referring to the 3.5i
> diskette itself - yes, that's the same in each case. But if and
> when you try booting your "built-on-a-PC-floppy-drive" diskette
> from a USB-attached drive, you'll find its a very different
> device at all levels of the system under filesystem level.
> Different capacity, different device drivers, different device
> name. And those differences require several changes in both the
> linux OS and to tomsrtbt files, in order to be able to load the
> root filesystem from it into the ramdisk. So in the tomsrtbt
> context they are really different devices.
Interesting.
Thanks, but there's no way I could accept the image under these
circumstances. I was thinking the directions for creating it. The
recipe. That's what we need here. And you certainly could post
those.
Thanks
Sid
Sidney Lambe
> On 2011-01-10, Sidney Lambe <sidne...@somewhere.invalid>
> wrote:
>
>> On comp.os.linux.setup, johnlumby <john...@hotmail.com>
>> wrote:
>>
>>> Some years ago there were a number of posts about how to get
>>> tomsrtbt linux working on a usb floppy disk. It is probably
>>> just history now, but for anyone who may still want to be
>>> able to do this, I have a working system which boots and
>>> runs from a usb floppy and includes all facilities including
>>> building itself on a usb floppy. Based on linux 2.2.21 and
>>> libc5 and with several newer versions of tools such as
>>> e2fsprogs 1.41.13
>>>
>>> John Lumby
>>
>> I've got TRB here. Nice little tool. I have a regular floppy
>> drive, but if you were to post your document, I'd copy it to
>> disk. You never know...
>>
>> Your article gives the impression that there is something
>> called a "USB floppy disk" that is different from a regular
>> floppy disk. I don't believe that is true.
>
> ....I would imagine it all comes down to the BIOS of the
> particular machine.
>
>
Thanks. I'll check mine the next time I reboot.
Sid
Sidney Lambe
>>
>> ....I would imagine it all comes down to the BIOS of the particular machi=
And how did you add this support from a later kernel? That
sounds tricky. Did you edit the kernel module's source code?
Sid
johnlumby
> > was to add the missing support into linux 2.2.21 so it uses the
> > same single-disk concept.
>
> > John
>
> And how did you add this support from a later kernel? That
> sounds tricky. Did you edit the kernel module's source code?
Yes, I did. The 2.2-series kernel in the distributed tomsrtbt
2.0.103 is already substantially modified
for the bzip2 compression and the ext3 support, so a bit more
modifying is not really much trouble,
and avoids awkward work-arounds.
>
> Sid
johnlumby
wrote:
>
> I was thinking the directions for creating it. The recipe.
> That's what we need here. And you certainly could post those.
I certainly could, but as you guessed and I replied in the later
posting, the recipe includes a
kernel source patch, and so in order for you to make use of it, you
would need to set up a
linux 2.2.21 kernel build environment, with kernel source tree,
suitable egcs compiler
and compatible binutils, and so on. If tomsrtbt was being actively
maintained,
I could feed my patch back into that, but unfortunately I don't think
it is.
In addition, I've added another kernel patch from someone else for 48-
bit LBA support of IDE disks
(i.e. >128GB disk support) and several other applications that I
wanted, such as gpm
(the console mouse driver), diff, newer e2fsprogs. Those are
quite independent of the
usb-floppy support.
>
> Thanks
>
> Sid
Sidney Lambe
> wrote:
Your other reply to me:
> And how did you add this support from a later kernel? That
> sounds tricky. Did you edit the kernel module's source code?
Yes, I did. The 2.2-series kernel in the distributed tomsrtbt
2.0.103 is already substantially modified
for the bzip2 compression and the ext3 support, so a bit more
modifying is not really much trouble,
and avoids awkward work-arounds.
/endquote
Good work.
>>
>> I was thinking the directions for creating it. The recipe.
>> That's what we need here. And you certainly could post those.
>
> I certainly could, but as you guessed and I replied in the later
> posting, the recipe includes a
> kernel source patch, and so in order for you to make use of it, you
> would need to set up a
> linux 2.2.21 kernel build environment, with kernel source tree,
> suitable egcs compiler
> and compatible binutils, and so on. If tomsrtbt was being actively
> maintained,
> I could feed my patch back into that, but unfortunately I don't think
> it is.
I could do that, but it would be a lot of work and I can't
see it happenning. Especially when I am basically satisfied
with TRB as it is.
Too bad about it not being maintained. Maybe you could do that (?).
>
> In addition, I've added another kernel patch from someone else for 48-
> bit LBA support of IDE disks
> (i.e. >128GB disk support) and several other applications that I
> wanted, such as gpm
> (the console mouse driver), diff, newer e2fsprogs. Those are
> quite independent of the
> usb-floppy support.
>
Neat. I don't know how their sizes and dependencies compare, but
I'd rather have gnu screen than GPM. As I am sure you know, its
cut&paste capabilities are far superior to those of GPM, just
for starters.
And I don't see any problem with TRB requiring two floppies.
They aren't exactly bulky or expensive.
Sid
Doug Laidlaw
There can be a floppy drive that plugs into a USB port, but the OP probably
means a flash drive or pen drive.
I used tomsrtbt a lot, but outdated libraries made it unusable with time.
No doubt they could be updated.
Doug.
Sidney Lambe
wrote:
> Sidney Lambe wrote:
>
>> On comp.os.linux.setup, johnlumby <john...@hotmail.com>
>> wrote:
>>
>>> Some years ago there were a number of posts about how to get
>>> tomsrtbt linux working on a usb floppy disk. It is probably
>>> just history now, but for anyone who may still want to be
>>> able to do this, I have a working system which boots and
>>> runs from a usb floppy and includes all facilities including
>>> building itself on a usb floppy. Based on linux 2.2.21 and
>>> libc5 and with several newer versions of tools such as
>>> e2fsprogs 1.41.13
>>>
>>> John Lumby
>>
>> I've got TRB here. Nice little tool. I have a regular floppy
>> drive, but if you were to post your document, I'd copy it to
>> disk. You never know...
>>
>> Your article gives the impression that there is something
>> called a "USB floppy disk" that is different from a regular
>> floppy disk. I don't believe that is true.
>>
>> Sid
>
> There can be a floppy drive that plugs into a USB port, but the
> OP probably means a flash drive or pen drive.
? Didn't seem like it. Are you saying that he's loading
the floppy image into one of these media? As a loopback device?
That really does make more sense.
> I used tomsrtbt a lot, but outdated libraries made it unusable
> with time. No doubt they could be updated.
The problem there is that more recent kernels and especially
recent glibc's, are massive compared to the ones TRB uses.
I wonder how many floppies it would take...
Hell, might as well add a tinyX server.
Oh yeh. I recall reading about stripped down versions
of glibc for embedded systems. That might work.
>
> Doug.
Cheers,
Sid
johnlumby
wrote:
>
> I'd rather have gnu screen than GPM. As I am sure you know, its
> cut&paste capabilities are far superior to those of GPM, just
> for starters.
screen is a useful tool and its cut&paste capabilities are very
powerful - so long as you don't mind using the keyboard.
gpm is a simple and rather limited tool for enabling use of
the mouse for "standard" cut&paste. So I'd say they are
complementary rather than alternatives. However I don't
know if anyone ever built a version of screen for the tomsrtbt
environment. I rarely use more than one console at a time
while in tomsrtbt so wouldn't have a lot of use for it although it
would
be nice if it was there.
>
> And I don't see any problem with TRB requiring two floppies.
> They aren't exactly bulky or expensive.
True. If you can find their setup and it works then that's great.
>
> Sid
johnlumby
>
> There can be a floppy drive that plugs into a USB port, but the OP probably
> means a flash drive or pen drive.
>
No I really do mean a 3.5i diskette in a usb-attached diskette drive.
The same considerations re loading the compressed root filesystem
image
into the ramdisk would apply to any mass-storage device attached via
USB on a linux 2.2.x -
they all end up appearing to be a removable SCSI. Since capacity
would not be
(such) an issue, you could try running the root filesystem directly
on it,
uncompressed of course, but such a setup would probably be quite
slow in operation with the USB uhci latency. There are numerous
ways of
setting up a rescue system and tomsrtbt might not be the best choice
on
a large-capacity device.
Douglas Mayne
Good work with tom's root/boot. The requirement to backport elements to
the 2.2 kernel sounds difficult. Like a lot of people, tom's root/boot
environment was one of my first exposures to GNU/Linux in general. It was
a good companion to the TLDP docs.
OT: Moore's Law keeps giving big dividends! Manufacturers keep doubling
capacity and increasing reliability. IIRC, the first flash drive I had
was 32M, or approx equal to 25 floppy discs. Now, a simple 8G flash drive
is equivalent to 5500 floppies. That's a dramatic improvement, wow! It
looks like flash memory is going to deliver on the promise of being able
to have a "system in your pocket." Flash offers high durability and now
coupled with a very usable capacity and reasonable price- say 8G capacity
for $20. With that you can run a full Linux distribution, including
networking, X, etc. The previous generation of rescue environments/live
cds/floppy-based distros/ etc. were much more limited. Now, you can just
snap in one drive and you're good to go with the tools you are used to
using.
8G capacity makes creating "rescue" environments much easier, now. You
can basically install a full distribution without even thinking about
ways to conserve space. There are lots of early flash based distributions
(puppy, slax, etc), and it's also fairly easy to do-it-for-yourself. I've
been experimenting with running Slackware from a USB flash drive. I wrote
some notes here to setup the distro on an 8G flash drive:
http://ddmayne.blogspot.com/2010/12/diy-slackware-on-usb-flash-8g.html
I also tested running from a flash drive on some older hardware- a
computer that only had USB v1.1 ports. My limited tests showed that USB
v2.0 makes the user experience much nicer and doesn't get bogged down. I
wrote about that here:
http://preview.tinyurl.com/6bwgdvj
--
Douglas Mayne
Bill Marcum
format or read the 1.7 MB format that tomsrtbt normally uses.
--
Heavier than air flying machines are impossible.
-- Lord Kelvin, President, Royal Society, c. 1895
johnlumby
>
> Now, you can just snap in one drive and you're good to go
> with the tools you are used to using.
>
> 8G capacity makes creating "rescue" environments much easier, now.
Yes, I agree, special-purpose systems on large flash drives
and LiveCD's on CDRoms are much more functional and up-to-date
than an ancient tomsrtbt. For me, the advantages of tomsrtbt are
that
I already had the equipment, and I have a variety of machines,
some old and some new, and the one tomsrtbt (with two flavours,
boot from PC floppy and boot from USB floppy) works on all of them.
I use only a very limited set of functions - mostly dd, e2fsck/
dumpe2fs,
netcat, diff - which all work fine. So it's always been enough for
what I do.
If I was starting out from square zero I would not use it.
> I've been experimenting with running Slackware from a USB flash drive.
> I wrote some notes here to setup the distro on an 8G flash drive:
> http://ddmayne.blogspot.com/2010/12/diy-slackware-on-usb-flash-8g.html
>
> I also tested running from a flash drive on some older hardware- a
> computer that only had USB v1.1 ports. My limited tests showed that USB
> v2.0 makes the user experience much nicer and doesn't get bogged down. I
> wrote about that here:http://preview.tinyurl.com/6bwgdvj
Useful information thanks
Sidney Lambe
Aha! Mystery solved. Gracias.
Sid