Tutorials and references on booting from tape, please.

I have a computer with an LTO drive. I'm curious about the possibility of booting FreeBSD 12.1 from tape. Most of the instructions I've found have been centered around the concept of storing BSD on a hard drive. Do any of you have any reference recommendations for working with FreeBSD 12.1 from tape?

Just curious, and I know we have a handbook. Who's actually booted from tape here? What's it take?
 
Nobody boots from tape any more. This was done in the '70s and '80s, early computing history. Until things like hard and floppy drives became more prevalent. Nowadays tapes are only used for backups, nothing more. And even that is dwindling, although there are still some companies that use tape for long-term backups.
 
What's it take?
The problem here is that the CPU needs to execute code that know how to read from tape. And that code has to get into the CPU somehow. So we need to ask: where does the first code the CPU executes come from? The answer is on standard hardware (PC) today: From flash memory on the motherboard, namely the BIOS. Today's BIOS has code to boot by reading from various direct access storage, typically disk, floppy, and USB mass storage. Not from tape. So someone would have to modify a BIOS to read tape. Given that tape is sadly falling by the wayside for most users, that's unlikely to happen.

I used to boot from tape ... in the late 70s and early 80s. The machine was a Philips P7000 (which was an OEM version of the Four Phase Systems CPU). That was done by toggling in the necessary instructions from the front panel; it took about a half dozen instructions.
 
Writing / modifying UEFI firmware to boot from tape would be an epic hack. I hope someone does it.
It doesn't stop at UEFI. Booting from tape would require either a predictable load order or populating a root fs in a ramdisk before init takes over. The latter being the saner option, probably…
 
Thank you all for your replies so far.

I understand that point about BIOS and recognizing the tape as a boot device. I know upon power up, before my GELI is decrypted and host controller finds the discs, it sees the tape drive and an optical drive. I can boot from that optical. Sometimes I can boot from internal USB, if I select an option in the BIOS menus.

I was wondering if one could just provide a nanobsd install as the first file on tape. Nanobsd and live discs get read in somehow. But, it could go back to the drive controllers and host controller to pick up those first few sections.

Unfortunately, I have since seen a suggestion that the LTO will not be a bootable drive. I will experiment and find out.

If I am successful, I will let you know; but, I fail a lot. Sometimes I learn something from it.

Thank you for your thoughtful responses.
 
Nobody boots from tape any more. This was done in the '70s and '80s, early computing history. Until things like hard and floppy drives became more prevalent. Nowadays tapes are only used for backups, nothing more. And even that is dwindling, although there are still some companies that use tape for long-term backups.
Challenge accepted.
:)
 
Did not find a way to get the tape drive to be considered a bootable drive. My drive is a SCSI TBU; however, the BIOS-setup menus for that device do not recognize it as a bootable device. I could assign a LUN or an IRQ through those interfaces; but, there is no mechanism to understand why the DVD drive was considered bootable and the tape drive not. The console presents me with boot devices to choose from, and the tape drive is simply not listed.

I did find these FreeBSD 4.3 directions on booting from tape.
https://docs.freebsd.org/44doc/smm/01.setup/paper-2.html
That looks like it might be valuable; however, we can see this is mostly about transferring a copy from tape media to a disc drive.

Maybe we can see if using the shell on a live optical disc will allow us to do the dds we'd need to move a nanobsd from tape into memory or otherwise activate it. Not sure. I recall some "read only filesystem" warnings; but, I haven't tried to write in that shell that I can remember, either.

I did find a better manual for an LTO3 drive; but it is not the model which came with my machine. I mention this, though, because there is a section at the end about taking tape drives apart to recover damaged tape cassettes which might be valuable to someone.
https://www.tandbergdata.com/default/assets/File/PDFs/Tandberg_Ultrium_LTO3_User_Guide_433233-01.pdf
 
... but, there is no mechanism to understand why the DVD drive was considered bootable and the tape drive not.
There are different kind of SCSI devices. The one we're most familiar is direct access devices, colloquially known as disks. They have in common that you can seek to a different place, and read there. Reads are of a fixed size, usually known as the block size (wrongly called the sector size). Examples include hard disks (spinning rust), SSDs, various SD card and USB devices (think of them as SSDs with different interfaces), floppies, CDs and DVDs. Today's BIOSes know how to boot from many of them.

Then there is sequential access devices, colloquially known as tapes. Seeking on them is somewhere between hard and impossible. Today's BIOSes don't know how to boot from them. Using today's boot loader code in the BIOS on them makes no sense ... they have no MBR or GPT, you can't seek to a boot partition, you can't read specific blocks (wrongly called "sectors") from them, and so on. In the earlier days of computing, booting from tape was great, and implemented: You prepared a tape that had the executable code right at the beginning, and the boot code simply copied whatever data was at the beginning of the tape (up to the first tape mark) into RAM starting at address zero, and then branched to zero, and we're off to the races. The world isn't that simple any more.

And then there are lots of other types of SCSI devices. For example printers, scanners, media changers (the little or giant robots that put the correct tape into the drive), and so on. Clearly, you will never boot from a SCSI-attached printer. You could in theory boot from a scanner (it is at least capable of reading data), but clearly that is completely impractical.

In the old days, computers booted from lots of other media. I still have some cp/m machines in the basement that are theoretically capable of booting from paper tape. Alas, I don't have a paper tape reader or punch. Early computers used to "boot" from punched card readers, but here the term "boot" is kind of misapplied: they didn't have what we would call an operating system, so if you wanted to run a program, you would compile it and link it with the necessary IO libraries. When you want to run that program, you stop your computer, put the compiled/linked deck of cards into the card reader, press the buttons on the console to start executing whatever is in the card reader, and it would "boot" that program.

Getting back to how to boot from tape: The functionality of distinguishing "disks" (meaning direct access devices) from "tape" (meaning sequential devices) from others is very fundamental to the SCSI interface, and to today's SATA implementation (in the old IDE/ATA that was fuzzy). Matter-of-fact, SCSI has a concept of "peripheral device type" which is baked deep into the protocol, and disks are device type 0, and tapes are device type 1, and then the fun ones start. I always use SCSI printers (which do exist, but are very rare today) to scare people who think they understand IO systems. Ever tried to create a file system on a printer?

To get a BIOS to boot from tape, the problem isn't LUNs or IRQs, but the basic strategy for booting: where on the tape do you find the executable code? What commands do you use to read it? Doing this would require a major rewrite of the BIOS. There are open-source BIOS implementations, but (a) they are hard to work with (16-bit C code, yuck yuck), and (b) they only support very limited hardware.
 
I heard rumours, there were some unix flavours that had a block device driver for the tape, so you could create a filesystem on it. Don't recall which one, and I wonder how long tapes would survive that.
But that doesnt help here, because a device driver works only after we have a kernel.

Actually it is a lot easier to boot a tape than a disk. Because what we actually need to do when booting is, get a certain number of bytes copied from the media to some place in memory where we can run it - and then help ourselves.

This is dead simple with a tape: just get the correct blocksize, start right from the beginning and stop when an EOF occurs. With a disk it is complicated: the loader needs to understand the filesystem, know how to gather the blocks of a file together, It also needs to understand the bsdlabel, the disk partitioning, or, in modern times, geli encryption or a zfs pool.

Now the UEFI bios again has it's own assumptions about how devices should behave. With the old bios it usually didn't even know what a SCSI device is, and some firmware from LSI would be added that does the job. I think these LSI bios had a setup menu where you could configure which device should be bootable.
 
I realized that one big problem with my proposal is that at least part of the UEFI firmware is loaded from disk. I think Ralphbsz is right, and you'd need to modify something like Coreboot or maybe U-Boot to read from tape.
 
I think that LSI menu was available on my computer. It did allow configuring which devices were boot devices; but, the tape drive wasn't in the list to select from. In there were also the opportunities to change IRQ and some other values.

There were submenus in there about adding a boot device. Tried that; but, again, only the optical drive was on that list.

I am using a T610. During the startup process, several configuration menus are available. SCSI, RAID/PERC, iDRAC, PXE, "System Configuration" which is like a regular BIOS screen : they all come up or offer opportunities to edit them. It was in those that I was not seeing the tape drive being offered as a boot device.

When one of the posters above mentioned device numbers, I was curious. I want to say my machine was assigning a 6 and a 7 to the tape and the optical. I wonder if I should tinker with that six and try a 1. Not sure. I'll try soon. I saw a lot of data that I'm unfamiliar with; so, it could just be that I was not remembering it right.

https://en.wikipedia.org/wiki/SCSI_Peripheral_Device_Type

It's clear that any heavy motherboard hacks will be beyond my skill level or desire, but if I don't ask these stupid questions then I might never find out about some stuff. What if we just have to make some small changes to awaken a capability that was ignored for commercial reasons? The tape drives themselves are probably not much different than they were. The BIOS is recognizing the device, sometimes.

It's like we're walking right up to the edge of what we would need, but there's a gap.
 
In the old days, booting from tape worked exactly like PMc described: Put the tape on the correct drive, execute a few instructions by hand to instruct the IO system to start reading from the hardware and copy to memory (real computers have fully automated IO controller, IBM calls them "channels", CDC calls them "PP", and with a few channel control words they will do the DMA for you). No need for a block size on 9-track tape (RECFM=V), just keep reading records sequentially until the EOF marker (which is written in hardware). Then one more toggling in from the front panel to go to the start address, and the computer is up and running.

The problem with this idea is that modern computers no longer have a front panel, and you don't have the ability to execute individual instructions from there. And modern computers need so much code to actually perform IO, it would be unreasonable to enter it as binary instructions: OpenBoot and OpenBIOS are thousands of lines of code.

This is how some backup software used to work: since by construction you need to read a backup when the disk is empty (for example because the computer has only one disk drive, and you had just put a new blank disk in, picture of a relatively modern drive here: https://www.computerhistory.org/storageengine/cdc-disk-drive-departs-from-ibm-standards/), the backup tapes were usually written so that at the very beginning was a small executable program that was bootable. You put the tape on the drive, boot it, the little program then asks you to confirm (with switches on the console, not a terminal) which drive to write the data to, and it then copies the backup to the drive.

Anecdote: backup was invented by a gentleman named Norm Pass; he worked at Bell Labs around 1964, and came up with the idea that you could make an extra copy of data that's on one media (disk or tape) onto a second media, in case the first media gets destroyed. He actually did not get a patent for that. He did later get a patent for defragmentation. In the early 2000s, Norm (at this point a very old but still bright and dapper gentleman) was my manager.

I heard rumours, there were some unix flavours that had a block device driver for the tape, so you could create a filesystem on it. Don't recall which one, and I wonder how long tapes would survive that.
The DEC-10 when running TOPS would do that, using DECtapes. Those were small spools (about 4" diameter), and when running they would madly zoom back and forth. We used to call it shoe-shining. These old tapes were very reliable, and used to last at least months. I've heard horror stories of DECtapes being thrown like a frisbee (with a tail of tape unrolling as it flies), and fortunately never witnessed it.

The modern version is called LTFS, and is an industrial strength file system that runs on LTO tape (and a lot of others). A friend of mine got an Emmy for it. Yes, I do mean the little statue that usually goes to actors. But LTFS is big, complicated, and powerful, and putting into a BIOS would be insane. Fun but insane.
 
I am using a T610.
The IBM T61 (I presume you mean that, or T61p) is a little bit too small to be used with tape drives. Here is a picture of what a type drive looks like:
with the tapes in the foreground. The T61 could be slipped underneath the tape drive cabinet and would become invisible. Also, it doesn't have the right connector: The two bus and tag cables https://en.wikipedia.org/wiki/Bus_and_Tag wouldn't fit on it.

Clearly, this is a staged publicity photo. In the real world, nobody would wear a nice blouse in the computer room, because it is always freezing cold, windy, noisy, and messy. Real tape operators wear jeans, jogging shoes, and a hooded sweatshirt.

OK, now seriously. Booting from modern tape drives (which are about the same size as a 3.5 or 5.25 disk, and yes, I have both LTO and 8mm drives at home) would be a nice dream, and a fun hobby project, but completely impractical. Not that I want to dissuade anyone from having fun hobbies.

Just thought of another little factoid. A former colleague supervises the restoration and operation of the IBM 1401 at the Computer History Museum. The tape drives (the computer has no disk, only tapes, printer, and card reader/punch) are a huge maintenance problem, because the 50-year old hardware keeps wearing out. And for lack of spare parts, a lot of stuff has to be custom-machined. So for normal demos, they have replaced the tape drives with a little RaspberryPi and custom-built electronics, so the CPU box thinks it's talking to an actual tape.
 
I've officially spent too much time on this now. I think a workable approach might be to write something like FILO but that reads from tape. FILO claims to be able to read from "raw devices" which sounds promising, but vague. FILO relies on Libpayload which appears to give you the bare-bones environment you'd need to get started trying to read files from tape. I guess you'd have to read two files, first a root filesystem that you'd write to a ramdisk, and then the kernel. I read on some Freebsd mailing list that then you'd "jump to the kernel". I have a vague idea of what this means, but am a long ways away from being capable of doing any such thing.

Not having to worry about a filesystem to read from would be nice, as Pmc says, but you'd still have to worry about a filesystem for the root ramdisk.

OK, I'm really putting the Internet down now and walking away.
 
Wow. I'm learning so much from you all. It's a Dell T610. It has a LTO3 drive built-in.

I was able to change the SCSI ID number by changing some jumpers on the device, but somehow I have not been able to get back into one of the menus I saw last night. I don't think I achieved much of anything by changing this ID; although, I did notice its numbers for "SYNC" and "WIDE", which used to match the one for the optical drive, changed to blanks. I probably confused the machine by changing the pins.

The drive still functions with the operating system; like, with regular tar. Send a file up; read the file down; but, I was not able to work any magic with the booting.

I do see a notice on the LCD. There is a tiny display on the machine. It only shows about a dozen characters of information. It does say, "System booting ...," while the console screen is still dark. This is all before anything happens that you would see on the display. During this time, the machine will exercise the tape drive a little. I suppose it is in those moments that the machine would have to decide if it could boot from tape.

I was able to find some more documentation on the machine; but, I can't suggest that this will be worth much more time for now. Thanks for your advice.

Still in love with the tape, though. ;)
 
Back
Top