FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 01-11-2008, 08:57 AM
Nils Philippsen
 
Default Linux is not about choice

On Thu, 2008-01-10 at 21:30 -0600, Chris Adams wrote:
> Once upon a time, David Zeuthen <david@fubar.dk> said:
> >
> > On Thu, 2008-01-10 at 12:45 -0600, Chris Adams wrote:
> > > And how do you know automatically that one of my USB-to-RS232 adapters
> > > is my UPS (should be /dev/ups), one is my GPS (/dev/gps0), and one is a
> > > cell phone (/dev/modem)?
> >
> > Either we look at the USB device it's hanging off (vendor, product or
> > class id's), the driver or we provide a simple interface in
> > gnome-device-manager or similar (including command line apps) to set it.
>
> Since they are all USB-to-RS232 adapters, you can't tell anything by USB
> info (they are all interfacing to RS232 devices). Two of them use the
> same driver, and annoyingly, the chip vendor for that USB-to-RS232
> doesn't set a serial number, so the only way to distinguish them is via
> USB port.

I guess such a simple interface would tie the custom configuration of
such a USB device to its hardware info and the USB path where to device
is plugged.

> Also, some GNOME thing is not a solution, as I'd like my UPS and GPS to
> be active on boot (the GPS is used by NTP for clock sync), not some time
> later after a user logs in.

The resulting policy shouldn't depend on any desktop.

> > That's the answer to this (very real)
> > problem, not a silly program that generates udev rules.
>
> So then we have to have two things running trying to name devices? I
> thought udev was supposed to be "the" solution. Using udev rules is
> easy, it is just that writing them is beyond the point-n-click user.

It might just be that the result of "a simple interface in
gnome-device-manager or similar" is a bunch of udev rules (which
ironically would belong into /etc instead of /lib/udev as this is the
exceptional case where we talk about configuration, not working around
omissions in udev rules).

Nils
--
Nils Philippsen / Red Hat / nphilipp@redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-11-2008, 09:16 AM
Andrew Farris
 
Default Linux is not about choice

Les Mikesell wrote:

David Zeuthen wrote:

On Thu, 2008-01-10 at 11:00 -0600, Les Mikesell wrote:
But the old names were predictable; the new ones aren't - when I move
a disk to a new controller/drive position, I know about it.


Uhm, no. You were just relying on a) limitations in the Linux kernel to
probe devices in a sequential fashion (see big-iron boxes with tens of
thousands of disks why this won't work); and b) the order of your
controllers on the PCI bus. Trying to argue it was "predictable" when it
was a "coincidence" is an interesting spin on reality. It's also wrong;
there's a reason that RHL and Fedora been using LABEL= for ages.


OK, that's at least partly right but you forgot to tell me what to call
the device when creating the label for filesystems that support it - or
what name to use for access to the raw device for operations like image
copies and addition/removal from raid arrays. The underlying problem
can't be solved at the filesystem layer.


Try cat /etc/mtab. The device being used for the particular label is clearly
shown after its mounted, even when auto mounted by label in /etc/fstab. I fail
to see what is so hidden here. When the device is connected to the machine its
also identified in log messages as to which device node it is assigned.


What I actually would argue is that a distribution making such
changes should supply tools to migrate configurations based on old
conventions to the new ones. Maybe Fedora doesn't have users with
hundreds of machines and data that needs to span years of operation,
but a unix-like system should be designed to make that practical.


No, Fedora is about being on the bleeding edge and creating a system
where you don't *need* to migrate configuration files because the files
will be correct if they are using stable identifiers for devices.


I haven't found that to be the case. And I don't see any reason for
today's experimental change to end up being the one that sticks.


Anaconda should have handled changing your configuration change in /etc/fstab
for you at install if all your partitions were labeled. If they aren't all
labeled this doesn't happen, which is a short-coming of anaconda in that it will
not apply labels to FAT32 or NTFS disks that do not have them (and maybe other
filesystems). There are also bugs against anaconda about this and I think a
number of them are closed rawhide so it should be better now.


--
Andrew Farris <lordmorgul@gmail.com> <ajfarris@gmail.com>
gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
---- ----

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-11-2008, 01:14 PM
Les Mikesell
 
Default Linux is not about choice

Andrew Farris wrote:


OK, that's at least partly right but you forgot to tell me what to
call the device when creating the label for filesystems that support
it - or what name to use for access to the raw device for operations
like image copies and addition/removal from raid arrays. The
underlying problem can't be solved at the filesystem layer.


Try cat /etc/mtab. The device being used for the particular label is
clearly shown after its mounted, even when auto mounted by label in
/etc/fstab. I fail to see what is so hidden here. When the device is
connected to the machine its also identified in log messages as to which
device node it is assigned.


Am I not making it clear that I want to be able to add and move disks
that may or may not have a linux filesystem on them? You know, things
that a unix-like operating system is supposed to let you do in some
deterministic manner. I want the disks to work in dual-boot scenarios
with earlier/later versions of linux. I want to be able to duplicate
disks by copying the raw device or even raid-mirroring then failing and
removing the device.



No, Fedora is about being on the bleeding edge and creating a system
where you don't *need* to migrate configuration files because the files
will be correct if they are using stable identifiers for devices.


I haven't found that to be the case. And I don't see any reason for
today's experimental change to end up being the one that sticks.


Anaconda should have handled changing your configuration change in
/etc/fstab for you at install if all your partitions were labeled.


When does anaconda run? I want to be able to install an OS, then add
disks or move them. Right now a machine by my desktop has 2 scsi and 8
sata drives in hot-swap bays plus an assortment of pluggable firewire
and USB external drives, and only the scsi pair were installed when
anaconda ran. I'd much, much prefer that the raw devices for the
swappable bays always had fixed device names for the drive inserted by
position regardless of insertion order but I realize that's not likely
to happen, so I'll settle for a reasonable description of how to figure
out the right name for a newly inserted drive with the understanding
that it may not have a filesystem lable and I may not want to mount it.
At the moment, the most likely thing I'd want to do is add a partition
from a newly inserted disk to an existing md array, but at some point in
the setup (and not while anaconda is running...) it is necessary to
partition and build the arrays out of a bunch of disks that mostly look
the same. Is fedora suitable for jobs like this?


> If
they aren't all labeled this doesn't happen, which is a short-coming of
anaconda in that it will not apply labels to FAT32 or NTFS disks that do
not have them (and maybe other filesystems). There are also bugs
against anaconda about this and I think a number of them are closed
rawhide so it should be better now.


Anaconda isn't the solution unless I can run it anytime new
unpartitioned devices are added or if I want something on the device
other than a typical file system.


--
Les Mikesell
lesmikesell@gmail.com

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-11-2008, 05:25 PM
Andrew Farris
 
Default Linux is not about choice

Les Mikesell wrote:

Andrew Farris wrote:
Anaconda should have handled changing your configuration change in
/etc/fstab for you at install if all your partitions were labeled.


When does anaconda run? I want to be able to install an OS, then add
disks or move them. Right now a machine by my desktop has 2 scsi and 8
sata drives in hot-swap bays plus an assortment of pluggable firewire
and USB external drives, and only the scsi pair were installed when
anaconda ran. I'd much, much prefer that the raw devices for the
swappable bays always had fixed device names for the drive inserted by
position regardless of insertion order but I realize that's not likely
to happen, so I'll settle for a reasonable description of how to figure
out the right name for a newly inserted drive with the understanding
that it may not have a filesystem lable and I may not want to mount it.
At the moment, the most likely thing I'd want to do is add a partition
from a newly inserted disk to an existing md array, but at some point in
the setup (and not while anaconda is running...) it is necessary to
partition and build the arrays out of a bunch of disks that mostly look
the same. Is fedora suitable for jobs like this?


Well in that particular situation where you know when the disk is inserted and
you can do them one at a time it should be easily determined which device nodes
are assigned just by 'tail -F /var/log/messages' prior to the disk insertion.
I'd agree thats not exactly as elegant as the assumption that the device will
consistently be assigned a certain device node but it works. When the disk is
inserted the kernel messages very clearly identify it if a usable disk is found
whether it is partitioned or not.


You can also just look into /dev/disk/by-id for links that give you the device
if you know which id is which (and if only one of the disks inserted doesn't
have partitions you know which it is immediately). /dev/disk/by-path even tells
you the controller you're connected to for each device node (with the caviat
that it calls them all scsi, but primary controller to secondary controller
should still make sense). That gives you all you should need to handle those
disk management jobs...


If thats still just not how you want it to be, thats understandable I suppose.

--
Andrew Farris <lordmorgul@gmail.com> <ajfarris@gmail.com>
gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
---- ----

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-11-2008, 07:30 PM
Les Mikesell
 
Default Linux is not about choice

Andrew Farris wrote:

Anaconda should have handled changing your configuration change in
/etc/fstab for you at install if all your partitions were labeled.


When does anaconda run? I want to be able to install an OS, then add
disks or move them. Right now a machine by my desktop has 2 scsi and
8 sata drives in hot-swap bays plus an assortment of pluggable
firewire and USB external drives, and only the scsi pair were
installed when anaconda ran. I'd much, much prefer that the raw
devices for the swappable bays always had fixed device names for the
drive inserted by position regardless of insertion order but I realize
that's not likely to happen, so I'll settle for a reasonable
description of how to figure out the right name for a newly inserted
drive with the understanding that it may not have a filesystem lable
and I may not want to mount it. At the moment, the most likely thing
I'd want to do is add a partition from a newly inserted disk to an
existing md array, but at some point in the setup (and not while
anaconda is running...) it is necessary to partition and build the
arrays out of a bunch of disks that mostly look the same. Is fedora
suitable for jobs like this?


Well in that particular situation where you know when the disk is
inserted and you can do them one at a time it should be easily
determined which device nodes are assigned just by 'tail -F
/var/log/messages' prior to the disk insertion. I'd agree thats not
exactly as elegant as the assumption that the device will consistently
be assigned a certain device node but it works. When the disk is
inserted the kernel messages very clearly identify it if a usable disk
is found whether it is partitioned or not.


You can also just look into /dev/disk/by-id for links that give you the
device if you know which id is which (and if only one of the disks
inserted doesn't have partitions you know which it is immediately).
/dev/disk/by-path even tells you the controller you're connected to for
each device node (with the caviat that it calls them all scsi, but
primary controller to secondary controller should still make sense).
That gives you all you should need to handle those disk management jobs...


If thats still just not how you want it to be, thats understandable I
suppose.


It doesn't seem as sensible as being able to plug into a known
controller position and get a known device name, particularly in the
scenario where the drives aren't hot-plug and you want to access a bunch
of new ones after a reboot and know which is which. But I'm not
interested in turning this into a helpdesk session about special case
procedures. The same scenario happens even more often when I build a
disk and ship it to a remote location where someone else (who doesn't
know anything about linux...) swaps it into a server with multiple NICs
- and now we have to associate the right NIC configuration with the
right cable connection. In the old days if it was eth0 yesterday it
would still be eth0 today, but that doesn't happen anymore. The servers
typically have 4 nics with 2 in use and it can be painful figuring how
to assign the addresses and routes so the network connections work on a
new box or a replacement OS.


So, the generic question is, now that the system uses essentially random
names for devices, is there a way, or a plan for a way, to deal with
situations where many choices of new devices appear as a result of
hardware changes, disk moves, backup/restores on new hardware, etc. and
if so, will it require a GUI to deal with it? So far I've only heard
the notion that these things should "just work" and I want to make sure
that everybody knows it can't "just work" because the system can't
possibly know want I want to do with a newly attached device or a whole
bunch of them and I normally don't want anything to happen automatically
other than being able to know the device name to access them. Someone
mentioned a scenario with usb->serial converters which would be a
similar case - no matter how much you want to guess and do something
friendly, you aren't going to know what's on the serial side of that
thing or what to do with it.


--
Les Mikesell
lesmikesell@gmail.com

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-11-2008, 07:36 PM
"Arthur Pemberton"
 
Default Linux is not about choice

On Jan 11, 2008 2:30 PM, Les Mikesell <lesmikesell@gmail.com> wrote:
> It doesn't seem as sensible as being able to plug into a known
> controller position and get a known device name, particularly in the
> scenario where the drives aren't hot-plug and you want to access a bunch
> of new ones after a reboot and know which is which.


Frankly i like this idea, but I'm unsure of the practicality of it:

What is the highest level which is even aware of the physical location
of said device? I would imagine the BIOS knows, and maybe some really
low level kernel modules but anything above that?


--
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-11-2008, 08:01 PM
"Horst H. von Brand"
 
Default Linux is not about choice

Les Mikesell <lesmikesell@gmail.com> wrote:

[...]

> It doesn't seem as sensible as being able to plug into a known
> controller position and get a known device name, particularly in the
> scenario where the drives aren't hot-plug and you want to access a
> bunch of new ones after a reboot and know which is which. But I'm not
> interested in turning this into a helpdesk session about special case
> procedures. The same scenario happens even more often when I build a
> disk and ship it to a remote location where someone else (who doesn't
> know anything about linux...) swaps it into a server with multiple
> NICs - and now we have to associate the right NIC configuration with
> the right cable connection. In the old days if it was eth0 yesterday
> it would still be eth0 today, but that doesn't happen anymore. The
> servers typically have 4 nics with 2 in use and it can be painful
> figuring how to assign the addresses and routes so the network
> connections work on a new box or a replacement OS.

Get them by MAC, not as ethX. I.e., here I have in
/etc/sysconfig/network-scripts/ifcfg-eth0:

# Intel Corporation 82573L Gigabit Ethernet Controller
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
HWADDR=00:a0:d1:78:d7:c5

and the correct name is given to that eth.

> So, the generic question is, now that the system uses essentially
> random names for devices, is there a way, or a plan for a way, to deal
> with situations where many choices of new devices appear as a result
> of hardware changes, disk moves, backup/restores on new hardware,

... random hot(un)plugging, ...

> etc. and if so, will it require a GUI to deal with it? So far I've
> only heard the notion that these things should "just work" and I want
> to make sure that everybody knows it can't "just work" because the
> system can't possibly know want I want to do with a newly attached
> device

The systen /can/ tell e.g. this is still the FooLaser printer serial
XYZ-ABCDE, even though it is connected through a different USB port today.
AFAICS, as things stand, the system is /not/ doing anything funky, it just
gives a way of finding out what is where (and the device has a clear ID);
and uses this if the device had been configured before. Things do get
tricky if you want to dd(1) disk images around, or are fond of serial
devices connected through USB-serial dongles, etc. But then you want the
system to do non-obvious stuff...
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-11-2008, 08:06 PM
Andrew Farris
 
Default Linux is not about choice

Arthur Pemberton wrote:

On Jan 11, 2008 2:30 PM, Les Mikesell <lesmikesell@gmail.com> wrote:

It doesn't seem as sensible as being able to plug into a known
controller position and get a known device name, particularly in the
scenario where the drives aren't hot-plug and you want to access a bunch
of new ones after a reboot and know which is which.


Frankly i like this idea, but I'm unsure of the practicality of it:

What is the highest level which is even aware of the physical location
of said device? I would imagine the BIOS knows, and maybe some really
low level kernel modules but anything above that?


udev is fully aware of the physical location, because it knows the communication
bus addressing to the device itself (/dev/disk/by-path). What Les is asking for
is a consistent guaranteed device node naming scheme, which makes good sense for
machines with few devices (desktops, small servers) and less sense for larger
systems. The facts are the older scheme wasn't guaranteed to be deterministic,
it just seemed to be because the kernel would probe / name the devices in
sequential order, and its no longer guaranteed to do that (that still doesn't
mean anything is named randomly).


I suppose someone could have additional udev rules that would follow the older
naming scheme at the same time as the new one... just doing the 'magic
guesswork' to make sure things always got named in the predictable ordering.


--
Andrew Farris <lordmorgul@gmail.com> <ajfarris@gmail.com>
gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
---- ----

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-11-2008, 08:44 PM
Les Mikesell
 
Default Linux is not about choice

Arthur Pemberton wrote:

On Jan 11, 2008 2:30 PM, Les Mikesell <lesmikesell@gmail.com> wrote:

It doesn't seem as sensible as being able to plug into a known
controller position and get a known device name, particularly in the
scenario where the drives aren't hot-plug and you want to access a bunch
of new ones after a reboot and know which is which.



Frankly i like this idea, but I'm unsure of the practicality of it:

What is the highest level which is even aware of the physical location
of said device? I would imagine the BIOS knows, and maybe some really
low level kernel modules but anything above that?


The bios doesn't necessarily know anything except for the one(s) that it
might boot. But I think there may be some extra magic in what the
kernel does with the names depending on which drive bios used to boot.
The stuff in /dev/disk/by-path might be useful for the versions that
have it, but I can't see anything for the empty controller positions
where the drives aren't connected so the arrangement doesn't make a lot
of sense.


--
Les Mikesell
lesmikesell@gmail.com

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-11-2008, 08:51 PM
"Arthur Pemberton"
 
Default Linux is not about choice

On Jan 11, 2008 3:44 PM, Les Mikesell <lesmikesell@gmail.com> wrote:
>
> Arthur Pemberton wrote:
> > On Jan 11, 2008 2:30 PM, Les Mikesell <lesmikesell@gmail.com> wrote:
> >> It doesn't seem as sensible as being able to plug into a known
> >> controller position and get a known device name, particularly in the
> >> scenario where the drives aren't hot-plug and you want to access a bunch
> >> of new ones after a reboot and know which is which.
> >
> >
> > Frankly i like this idea, but I'm unsure of the practicality of it:
> >
> > What is the highest level which is even aware of the physical location
> > of said device? I would imagine the BIOS knows, and maybe some really
> > low level kernel modules but anything above that?
>
> The bios doesn't necessarily know anything except for the one(s) that it
> might boot. But I think there may be some extra magic in what the
> kernel does with the names depending on which drive bios used to boot.
> The stuff in /dev/disk/by-path might be useful for the versions that
> have it, but I can't see anything for the empty controller positions
> where the drives aren't connected so the arrangement doesn't make a lot
> of sense.


Then it seems to me that what you/i/we want can be accomplished with
soem clever udev rules.

--
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 06:10 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org