[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Quick and dirty "debian live" on USB stick.



On Mon, Nov 30, 2009 at 09:45:11AM EST, Stefan Monnier wrote:

> > I'm playing with the idea of copying my laptop's debian lenny
> > partition to a USB stick that I can take with me when traveling.
> 
> I have a "Live USB Debian" system that follows this idea (i.e. it's
> just a plain normal Debian install, except it works off of a USB
> stick).

> > . clone the lenny partition to /dev/sda1
> > . install grub to /dev/sda
> > . make adjustments to the contents of /dev/sda1

> > The trouble is that I don't have a machine that can boot off of a
> > USB stick to test ahead of time.
> 
> You can do some of the tests by putting the vmlinuz and initrd.img on
> your harddrive and telling them to mount / from the USB stick.

Good point - I guess simply adding an entry to grub.cfg with the UUID of
my root partition on the the USB stick should do it. 

I guess the only thing that I won't be able to test will be grub on the
USB stick. Probably wise to bring a rescue CD along first time around.

> That will already help you figure out some of the tricky things
> (e.g. how to specify the right device to use to mount the USB stick:
> either use partition labels, UUIDs, or use LVM volumes).

I'll definitely use the UUID.

> > Since I'm running the stock lenny kernel, I shouldn't have problems
> > with differences in hardware, but I'm a little concerned that udev
> > might not cooperate.
> 
> The only typical problems are things like the
> /etc/udev/rules.d/70-persistent-* files, so every time you use your
> system on a new machine, the "new" ethernet device will appear under a
> new name (eth0, eth1, eth2, ...).  You can solve it by adding a script
> which removes those files at boot.

Well, I guess that since my pcmcia nic won't be there on the target
system(s), I should remove the corresponding udev rule for instance. 

What does udev do in this respect, anyway? Probe the system at startup
and set up the devices for the hardware it detects?

So I guess the rules need to be cleaned up every time you know you are
using a given system for the last time?

> > I'm sure there are other issues, but unfortunately, I can't take the
> > trial and error approach.
> 
> In my case the main issue was space, so I ended up using a jffs2
> install (the only compressing file-system back then), which is
> inefficient and inconvenient.
> 
> But even with today's large sticks, space will probably still be an
> issue.  So you may want to keep /var/cache/apt on tmpfs (and add
> "mkdir -p /var/cache/apt/lists" to /etc/rc.local), for example (I even
> keep /var/lib/apt on tmpfs as well, but that's mostly because these
> files can't be on jffs2 because jffs2 doesn't support mmapping files).

> Also you may want to avoid log files.  For that I use busybox's
> syslogd with the following script:

>    # cat /etc/init.d/syslog-busybox 
>    #!/bin/sh
>    
>    ### BEGIN INIT INFO
>    # Provides:             sysklogd
>    # Required-Start:       $remote_fs $time
>    # Required-Stop:        $remote_fs $time
>    # Should-Start:         $network
>    # Should-Stop:          $network
>    # Default-Start:        2 3 4 5
>    # Default-Stop:         0 1 6
>    # Short-Description:    System logger
>    ### END INIT INFO
>    
>    case "$1" in
>        start )
>            echo -n "Starting Busybox syslog:"
>            if busybox syslogd -C16; then
>                echo -n " syslogd"; else echo -n " !syslogd!"; fi
>            if busybox klogd; then
>                echo -n " klogd"; else echo -n " !kogd!"; fi
>            echo "."
>            ;;
>    esac
>    # 
> 

> you can then read your logs (which are kept in a cyclic buffer in
> memory) with "busybox logread", or just "logread" if you first create
> a symlink "ln -s busybox /bin/logread".

It's an 8G stick, 7.4GB as computed by df -h, and my partition is 5.9GB,
so I should be OK.

Thanks for confirming feasability.

CJ


Reply to: