OpenBSD livecd/liveusb/combo persistent?

[Noobification]

Hi all,

I've done in the past mounting the fedora livecd then label my usb as a persistent storage while inside the live system (so the livecd stores things like /home and additional /usr/bin on the usb and not somewhere else(there is nowhere else, actually), so that every time I boot the livecd(w/ the usb plugged in), I get all my saved configuration files/ additional binaries not included w/ the default boot)

nowadays I use something wa-aaay easier. The fedora LiveUSB creator gives me the entire live system install + persistent storage... in one click!

so,

how can I (without blindly following tutorials and using BSD-based tools that I have no idea how it works/where to start) - put the OpenBSD install on a usb, encrypt the filesystem and make it bootable?(so systems like M$ windoze can't automatically mount it and @#$! the partition & make unbootable (yes, every time I plug a bootable usb into a running windows machine, it somehow automagically kills it) (especially windows 7, I just hate how it automatically assumes the usb is not bootable and searches the entire drive for things like *.mp3)...

note - I am using a new lexar 8GB, my old kingston 8GB had some serious cylinder errors and no matter how I fdisk/parted it, things won't work

thanks all

[ocicat]

Originally Posted by Noobification

how can I (without blindly following tutorials and using BSD-based tools that I have no idea how it works/where to start) - put the OpenBSD install on a usb, encrypt the filesystem and make it bootable?

You won't find tutorials, & even if you did, I wouldn't trust them. The OpenBSD community does not place trust in howto's found in the wild. If you do blind Google searches, what you will find are documents either out of date, incorrect, or the author only explored a topic far enough to get past their problem; it may or may not address your problem. The best thing you can do is maintain skepticism, & correlate any information found back to the source code manpages, In fact, the order of what you can trust can be rank-ordered as follows (most trusted to least trusted):

1. The source code itself.
2. The manpages.
3. Documentation posted on project's Website. This includes the official FAQ which is the single best document on the current state of OpenBSD.
4. Pronouncements by the project developers on the project's mailing lists.
5. Information found at third-party sites (including this one...).
6. Cold Google searches.

Having said that, here are some vetted links you should consider.

I don't think the following encrypts, but here it is nonetheless:

http://liveusb-openbsd.sourceforge.net/

It is not difficult to create an installable USB drive having done homework. Understanding how OpenBSD boots on i386 can be learned by studying the biosboot(8), boot(8), boot_i386(8), & installboot(8) manpages.

Further help on constructing an installable USB boot drive can be found at the following:

http://azbsd.org/~marco/openbsd/flashkeyinstaller/

Encryption of an entire OpenBSD system is not possible given that the kernel cannot be encrypted, but you may find the following useful:

http://marc.info/?l=openbsd-misc&m=125694732231127&w=2

Of course, jggimi's live CD's can be found here:

http://jggimi.homeip.net/

The real work is now up to you.

[Noobification]

Thanks!, I'll check these out. I'll come back if I encounter any errors/problems burning OpenBSD on my usb.

[Carpetsmoker]

I built a small FreeBSD LiveUSB a while ago using syslinux and isolinux. I can use the same image & syslinux config for booting both from USB and CD.

In my case I just load the entire image in memory and go from there, since the image is fairly small in my case (~15M) this is not a problem. More advanced solutions would be required for larger images.

For FreeBSD I use:

KERNEL /boot/syslinux/memdisk
APPEND initrd=/boot/freebsd.img.gz harddisk raw

I would expect that this will also work for OpenBSD. Now the `raw' keyword, this is vital.

The main advantage of using syslinux is that you can just format your drive as FAT32 and use it for other things too.

[BSDfan666]

I don't believe that solution will work for OpenBSD, but I may be wrong.

[jggimi]

how can I (without blindly following tutorials and using BSD-based tools that I have no idea how it works/where to start) - put the OpenBSD install on a usb, encrypt the filesystem and make it bootable?(so systems like M$ windoze can't automatically mount it and @#$! the partition & make unbootable (yes, every time I plug a bootable usb into a running windows machine, it somehow automagically kills it) (especially windows 7, I just hate how it automatically assumes the usb is not bootable and searches the entire drive for things like *.mp3)...

1. Encryption does not equal protection. Encryption makes the information at rest on the storage device unreadable without decryption. That is all. It does not disable a "write" instruction. Any device can be written on unless it has a physical way to be made read-only.
2. I understand Windows will scribble on devices if those devices have Windows-usable partitions. The obvious solution: don't keep NTFS or FAT partitions on your USB device. Problem solved.

A USB attached mass storage device, on OpenBSD, attaches to the kernel as if it were a standard SCSI device. So .... If the platform can boot from the USB device, then a standard installation can be performed and the device treated as any other disk drive. It need not be "live media" at all. This is my recommendation for "USB Stick" installations. Live media, a read-only environment, is a completely needless complication.

As stated above, the entire drive cannot be encrypted. The kernel must come from an unencrypted partition, and the root partition must also be unencrypted. But structures that might contain "user data" of interest that are desired to remain private (such as /home and /var/tmp) can be mounted on encrypted partitions with two different built-in methods: softraid with the crypto discipline, or vnode encryption.

To repeat: encryption can provide only data privacy, not data protection.