Prev: Debian and sd card-reader
Next: Flash plugin problem - cant click - amd64 unstable
From: Chris Jones on 3 Dec 2009 00:00
On Wed, Dec 02, 2009 at 08:48:49PM EST, Stefan Monnier wrote:
> > 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.

Crystal-clear.

Thanks for doing my homework for me :-)

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 3 Dec 2009 18:30
On Wed, Dec 02, 2009 at 08:48:49PM -0500, Stefan Monnier wrote:
> > 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).
>
Except for wireless interfaces, which I've seen labeled as ethX, wlanX,
raX, etc.

-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: Stefan Monnier on 3 Dec 2009 22:40
>> > 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).
>>
> Except for wireless interfaces, which I've seen labeled as ethX, wlanX,
> raX, etc.

That's another issue: the base name is provided by the driver.
Most drivers included in the vanilla kernel use wlanX nowadays, but
older ones or drivers provided from elsewhere (or not yet
well-integrated) often use other names.

For that I added a udev file /etc/udev/rules.d/10-monnier.rules that
overrides the default names. I've used rules like:

kernel=="eth*", SUBSYSTEM=="net", DRIVERS=="ipw3945", NAME="wlan0"
kernel=="ath*", SUBSYSTEM=="net", DRIVERS=="madwifi", NAME="wlan0"


-- 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 4 Dec 2009 04:20
On Sat, Nov 28, 2009 at 05:19:56PM EST, Chris Jones 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.
>
> Since I can't be sure I'll have a machine with available space on the
> HDD or be allowed to partition the drive, what I thought was that I
> could have a bootable system on the USB stick and boot into it pretty
> much as I would off of a live CD.
>
> What I had in mind was as simple as:
>
> . 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.
>
> Adjustments that I had in mind:
>
> . /etc/fstab
> . /boot/grub/menu.lst (grub.cfg with grub2)
>
> Naturally, reconfiguring network & internet access, Xorg, printers, etc.
> will be necessary, but they cannot be done ahead of time - although it
> may be possible to make it less of a pain with some preparation and a
> bit of scripting.
>
> 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.
>
> I'm sure there are other issues, but unfortunately, I can't take the
> trial and error approach.
>
> So, I was wondering if anyone had done anything comparable, and would
> care to point out possible gotchas?

I now have-a-proof of concept system on the USB stick and have been able
to boot into it by doing the following:

1. Power up the laptop

2. On the grub2 menu, hit 'c' to escape to a shell of sorts and load the
USB modules:

insmod uhci�
insmod usbms

The light on the USB stick should come on telling you it's alive

3. Escape back to the grub menu and Ctrl+X to boot a stanza with
something like the following:

search --no-floppy --fs-uuid --set fb796a23-e59e-4e15-ba92-15f0cd087714
linux /boot/vmlinuz-2.6.26-1-686 root=UUID=fb796a23-e59e-4e15-ba92-15f0cd087714 ro
initrd /boot/initrd.img-2.6.26-1-686

where the UUID was determined by:

# vol_id --uuid /dev/sda1 # blkid on more recent systems

Since I'm running it on the same hardware as the cloned system, it
wasn't too hard, network, X, etc. came up with no problems, just very
slowly, since on top of the thumb drive's limitations, the laptop only
supports USB 1.1.

The challenges that I see now are getting rid of any customization
specific to my laptop and come up with something generic that will boot
on just about any machine, and set it up so that personal data is
clearly separated from the software and configuration files.

After that, it's just only a matter of writing a couple of trivial rsync
scripts to keep the data on the HDD and the USB stick in sync'.

Kinda boils down to what Rob Owens initially recommended after all..

Thanks to those who have responded.

CJ

� There is a bug in grub2 that can be worked around by issuing a
'debug=uhci,ohci,usbms' command jut before issuing the insmod uhci,
and resetting it immediately afterwards by issuing a 'debug='


--
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  | 
Pages: 1 2 3
Prev: Debian and sd card-reader
Next: Flash plugin problem - cant click - amd64 unstable