Note: this wiki is no longer maintained. If you have any questions related to this wiki, please post them on the CrunchBang forums.

Translations of this page?:

INSTALLATION Use Sneakernet with Crunchbang Statler

Intro

Here's the scenario: You just installed the latest version of Crunchbang and your Internet connection isn't working. How do you get packages over to your new system?

Sneakernet Steps

The easiest way to move packages to your system when you have slow or no Internet access on it is the old fashioned sneakernet. Go to a computer that has Internet access. (It can even be a Windows machine.) Search for the packages you need at http://www.debian.org/distrib/packages. If you're running Crunchbang Statler, you'll probably want the packages for Squeeze. You can currently find them by searching for Distribution: testing. Download a package you want. Now, check the list of all the packages it's dependent on. If those packages aren't already on your system, you'll need to download them as well.

Here's an example for modem users, download wvdial 1.60.4 choosing the Squeeze version and your particular architecture. Then download its dependencies, libwvstreams4.6-base, libwvstreams4.6-extras and libuniconf4.6. The rest of the dependencies should hopefully already be on your system.

Once you have all the packages you need, copy them to USB, CD, DVD, floppy or whatever method you want to use to access the files on your Crunchbang system. Put on your sneakers and carry the files from the computer you downloaded them to over to the system where you want them. (That's the sneakernet.) When you get to your Crunchbang system, copy the files to a directory where you can access them.

Here are a few methods for installing packages obtained by sneakernet. If you have alternative or easier suggestions, please share them.

Installing Packages One at a Time

If you know all the dependencies for a particular package, you can install a package at a time with dependencies added first. Use a command such as:

dpkg -i nameofpackage.deb

Installing Groups of Packages

Copy your packages (files with .deb extension) to /var/cache/apt/archives. Go to the directory where you installed your packages. You'll want to open up a terminal session such as an xterm or urxvt window. If you have any permissions issues with any commands, you can work-around them using sudo. Type the following:

cd /var/cache/apt/archives dpkg-scanpackages . |gzip > Packages.gz

Move the Packages.gz file to somewhere on your system where you can find it. You'll need to add that location to the /etc/apt/sources.list as well. Add a line similar to this to the file: deb file:/home/myhomedir/mydir/ squeeze main

The above line will have the package manager looking for your Packages.gz file in /home/myhomedir/mydir/dists/squeeze/main/binary-i386/ Change the directory paths to suite where you want things on your machine.

You can now run Synaptic and reload or whatever package manager interface you use and update. It should find your local archive and let you add packages as usual.

Upgrading

When it comes time to upgrade your system, this can be one of the hardest things for users with no Internet or very slow Internet who are forced to use sneakernet. I'll cover 4 different upgrade strategies. Would love to hear from other sneakernet users who have some alternative ideas.

Don't Fix It

The first strategy is the 'if it's not broken, don't fix it strategy'. If you don't have Internet access, you won't have as many security issues to worry about. Once you get your system set up with all the programs you want, just leave it as is.

Kernel Upgrades

There's some really nice new feature in the kernel. Maybe you need version x.x.x of it just to get a certain piece of new hardware running. Leave the rest of your programs and operating system as is. Do not upgrade your GNU compiler. Just download and rebuild the kernel from source. You can set up grub2 to boot your choice of kernels, so you can test out the new one and fall back to the old one if it doesn't work.

Minimal Upgrade

When you install Crunchbang, install it to its own hard drive partition and install your home directories with all your important data to another partition. Only keep the minimal amount of programs you need to run on the Crunchbang partition. When it comes time to update, you can reinstall just the Crunchbang part (latest version) totally from scratch from DVD, CD or USB.

If you're anything like me, then you may be thinking, I can't get by with just the programs from the Crunchbang installation disk. I have to have my favorite applications or certain applications to do specific tasks. Below are some options keeping inline with minimal upgrades. You can use programs like zero install or xstow or the concepts from them to keep these programs apart from the rest of the programs on your system. If they're in your home partition, they hopefully won't get wiped out when you reinstall.

* Use a lot of interpreted programs. Run programs based on Perl, Python, Ruby, Javascript, etc. When it comes time to upgrade, you only need to worry about finding a compatible version of the interpreter (or browser for some Javascript based applications). The drawback, interpreted programs are slower, especially on older systems.

* Use a lot of emulators. You can run programs in DOSBox. For CLI enthusiasts, try some of the many DOS applications available in a console based version for DOSBox (using SDL with directfb or a similar solution). Check Free Software for DOS for some great options. You can run programs in XMess. You can run some Windows programs under Wine. Windows is great for backward compatibility and binary stability. Windows XP can run DOS and Win 3.1 programs out of the box. So if a program will run under Wine, it can offer a more stable solution than trying to run it directly under Linux. The drawback to emulators is that like interpreters they can also be slower than programs compiled specifically for a system. This doesn't have to be the case. The BSD systems offer compatibility layers for other POSIX based programs and claim these programs can run about as fast as they would on the original operating systems. It depends on how the emulator or compatibility layer is implemented. I won't mention all the virtual machine alternatives like VirtualBox, because then you might as well be running another operating system.

* Statically build your programs. You can use other compilers such as tcc or OpenWatcom to build executables statically. It's common practice to link programs dynamically. Conventional wisdom says having one copy of a library used for multiple programs takes less room than building that library into each program. Projects like sta.li and PC-BSD are finding that if you have a good compiler, it only needs to bring in the routines from the library that it needs and that executables aren't that much larger than dynamically linked ones. If you have optimized runtime libraries and an efficient compiler, the executables may even be smaller than ones created by a the GNU compiler with standard glibc. Also, OpenWatcom was first developed on DOS and Windows systems, so hopefully it'll maintain greater backward compatibility in its Linux runtime libraries as it does for DOS, Windows and OS/2 systems.

* Build using LSB. You may be thinking that you can statically link against GNU compiler libraries and not have to use an alternative compiler. However, the GNU compiler isn't designed for that. Certain parts of it such as the nss routines must be dynamically linked in later versions of the GNU compiler. You can still use the GNU compiler, but when it updates, you need to have two copies of the dynamic libraries it uses. The technique of keeping multiple libraries with slightly different names (different version numbers) works fine for any dynamically linking library that needs to be updated in theory. However, in practice, if the library isn't renamed every time it is no longer backwardly compatible, you have issues. From what I've been reading, this can happen often with the GNU compiler libraries and they're usually the basis for most of the compiled programs on your system. The LSB gives you an alternative set of GNU compiler libraries for specific versions of the GNU compiler in an attempt to provide better binary compatibility across Linux distributions. There's no reason you can't use LSB across different versions of the same distribution either. It's like having two GNU compilers on your system. If you build your applications with the LSB libraries and commands, your programs should work on any distribution that supports that version of the LSB libraries. If you upgrade, reinstall the LSB libraries and that programs that you've built with them should continue to work.

Full Upgrade

Wipe out all your programs and reinstall from scratch. If you've compiled and built a lot of programs from source as I do, I hope you've automated your building processes. This could take a while, especially if you need to use sneakernet to reinstall all those missing programs from the repositories yet again.

Projects like Keryx make good resources for people with no local or slow Internet access as well.

 
howto/sneakernet_for_crunchbang_statler.txt · Last modified: 2012/05/25 18:45 by machinebacon
Except where otherwise noted, content on this wiki is licensed under the following license:CC Attribution-Share Alike 3.0 Unported

Powered by DokuWiki. Hosted by Linode.
Copyright © 2010 CrunchBang Linux.
Proudly powered by Debian GNU/Linux.
Debian is a registered trademark of Software in the Public Interest, Inc.