Prev: Debian and sd card-reader
Next: Flash plugin problem - cant click - amd64 unstable
From: Stefan Monnier on 30 Nov 2009 09:50
> 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.

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).

> 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.

> 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".


Stefan


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Chris Jones on 1 Dec 2009 01:40
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


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Rob Owens on 1 Dec 2009 20:40
On Tue, Dec 01, 2009 at 01:30:43AM -0500, Chris Jones wrote:
> 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?
>
You could try deleting the file that creates the persistent network
interfaces:

/etc/udev/rules.d/75-persistent-net-generator.rules (on my Lenny system,
anyway)

I'm not sure what negative side-effects there might be, but I did this
on my Debian-Live system so that my wired interface would always be
"eth0". It seems to work, but I'm sure there's a better way.

-Rob


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Chris Jones on 1 Dec 2009 22:30
On Tue, Dec 01, 2009 at 08:35:49PM EST, Rob Owens wrote:
> On Tue, Dec 01, 2009 at 01:30:43AM -0500, Chris Jones wrote:

[..]

> > So I guess the rules need to be cleaned up every time you know you
> > are using a given system for the last time?
> >
> You could try deleting the file that creates the persistent network
> interfaces:
>
> /etc/udev/rules.d/75-persistent-net-generator.rules (on my Lenny
> system, anyway)
>
> I'm not sure what negative side-effects there might be, but I did this
> on my Debian-Live system so that my wired interface would always be
> "eth0". It seems to work, but I'm sure there's a better way.

I guess the "better way" is to read (and digest) whatever udev doc is
available and run enough tests, possibly with differenty hardware, and
get an in-depth understanding of how it really works.

Unfortunately, this is hardly compatible with the QND approach :-)

Thanks,

CJ



--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Stefan Monnier on 2 Dec 2009 20:50
> I guess the "better way" is to read (and digest) whatever udev doc is
> available and run enough tests, possibly with differenty hardware, and
> get an in-depth understanding of how it really works.

I understand just fine how it works: when the network interface is
discovered (typically at boot), udev is asked to choose a name for
that interface. And /etc/udev/rules.d/75-persistent-net-generator.rules
then saves the result as a new rule in
/etc/udev/rules.d/70-persistent-net.rules that associates that
interface's MAC address with the name that was chosen.
There are 2 consequences:
1- next time this interface is found, the same name will be used (good).
2- when another interface is found, another name will be chosen: not so
good, when you use your install on many different machines, since then
each machine's interface will get a different interface name, even
though they'll never be present at the same time.

So I use a boot-time rule which erases
/etc/udev/rules.d/70-persistent-net.rules so the name is chosen anew
each time (and will basically always be eth0).

Same for the cdrom drive names.


Stefan


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Debian and sd card-reader
Next: Flash plugin problem - cant click - amd64 unstable