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-10-2008, 08:00 PM
Les Mikesell
 
Default Linux is not about choice

Arthur Pemberton wrote:


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.

You're wierd dude, this essentially the same thing I suggested and you
discouraged.

The system can't possibly work with multiple choices unless you have an
interface to let a human configure which is which. Now the kicker is
that most of my machines are in remote locations with swappable drives
and I expect to be able to ship a pre-configured drive built locally and
have someone pop it in a known controller position and have it come up
working - and to be able to copy images that will work across a number
of identical machines without individual attention other than setting
the hostname and IP addresses.



I would have thought that with dirves you can jsut mount by labels,
does this not work for your use case?


First, disks aren't born with labels. Second, most of my disks get
created by dd'ing an existing raw disk or the equivalent, generally on a
different machine and not necessarily under an exactly matching kernel
that would know the filesystem or how to label it. Third, you can't use
labels for fdisk/mkfs, or even dump and I'd really like to know which
physical drive is going to be the target of those commands. I realize
it is not an easy question. For example the adaptec SAS raid controller
in an ibm 3550 maps drives to volumes internally and remembers them even
if you only have one drive in a volume. That is, if you build a master
image in the first slot, dd it to the drive in the 2nd slot, take that
2nd disk and put in the first slot of another and attempt to copy again,
your disk with contents will be detected as /dev/sdb (remembered)
instead of sda from being in the first position. This is fun when you
try to repeat the dd command expecting the same thing to happen.


Anyway, the long-winded point is that you do more things with disks than
mount the file systems they contain, so a label doesn't solve the
identification problem.


--
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-10-2008, 08:00 PM
Douglas McClendon
 
Default Linux is not about choice

Les Mikesell wrote:

Dominik 'Rathann' Mierzejewski wrote:

Is it a user program that has changed my /dev/hdX into /dev/sdX more
or less arbitrarily


Can you say "filesystem labels"? I thought so.


I can say it won't fix an existing configuration. I can say that
filesystem label creation wasn't well thought out for people that move
disks around (after you've installed fedora on all your machines,
they'll all have the same labels and the system is not happy when you
rebuild a machine with a different combination of drives).



I can answer this one: Require people to name their system at install
(like windows, like macosx, e.g. john-pc), perhaps with a default coming
from install date (200807110711), and then make the default fslabels be
prefixed with that name and an underscore. e.g. john-pc_/usr


problem solved.

-dmc



I can say
that the design of solaris seems to take machine management over long
intervals of time and large numbers of machines into consideration
whereas Linux does not.


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

David Zeuthen wrote:

On Thu, 2008-01-10 at 09:31 -0600, Les Mikesell wrote:
Is it a user program that has changed my /dev/hdX into /dev/sdX more or
less arbitrarily - or turns what used to be detected as eth0 into eth2
when a different kernel is booted? Admittedly it has been a while since
I've used Solaris, but I can't recall anything like that ever happening
with it. In a unix-like system where access to everything is through
its device/file name, what is more fundamental than that?


This is a flawed example. The problem is that you're relying on names
assigned in an irregular fashion and it will happen on Solaris as well
if you move disks between controllers etc. The way to do this in the
modern world is to rely on persistent names. See /dev/disk/* and the
udev rules for stable network interface names. Of course you can argue
that e.g. /dev/sda or /dev/hda should stay stable but I doubt you're
going to find much sympathy for such a point of view.


And the interesting thing is it looks like /dev/sdX will 'stay stable' as the
way its done after that change. Change happens.


--
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-10-2008, 09:24 PM
David Zeuthen
 
Default Linux is not about choice

On Thu, 2008-01-10 at 14:17 -0800, Andrew Farris wrote:
> And the interesting thing is it looks like /dev/sdX will 'stay stable' as the
> way its done after that change. Change happens.

I wouldn't put my money on it.. maybe it's stable (for some definition
of the word) now, probably not in a few years.

(Interestingly enough, one price Fedora pays for this so-called
stability is that booting is somewhat slower, e.g. crap like
scsi_wait_scan.ko)

David


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

David Zeuthen wrote:

On Thu, 2008-01-10 at 14:17 -0800, Andrew Farris wrote:
And the interesting thing is it looks like /dev/sdX will 'stay stable' as the
way its done after that change. Change happens.


I wouldn't put my money on it.. maybe it's stable (for some definition
of the word) now, probably not in a few years.

(Interestingly enough, one price Fedora pays for this so-called
stability is that booting is somewhat slower, e.g. crap like
scsi_wait_scan.ko)


The sdX names never were related to hardware in the same sense as the
hdX ones were so 'stay stable' is an odd term. If you know the
controller and drive select you knew the hdX name. The sdX names have
always been whimsically assigned depending on what else happens to be
present. There's nothing you can see to relate the name to a physical
device.


--
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-10-2008, 11:35 PM
Les Mikesell
 
Default Linux is not about choice

Arthur Pemberton wrote:


On Thu, 2008-01-10 at 11:28 -0500, David Zeuthen wrote:

udev rules for stable network interface names.

Btw, that would be

/etc/udev/rules.d/70-persistent-net.rules
/etc/udev/rules.d/75-persistent-net-generator.rules

HTH. Follow up with questions on the udev list please.



We are badly in need of system-config-udev. I spent several hours
understanding udev adn building rules for my sound cards and tv cards.
I hadn't done a yum update on my F7 box for weeks/months (lazyness)
did one this week, and it apperently just blew away my custom udev
config


Is this another work-in-progress? I don't have anything handy newer
than FC6 which doesn't have persistent-net.rules and a similar question
on the Centos list mentioned that ethX devices can be renamed when the
the ifup scripts run.


--
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, 02:30 AM
Chris Adams
 
Default Linux is not about choice

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.

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.

> 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.
--
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-11-2008, 04:10 AM
Bill Nottingham
 
Default Linux is not about choice

Les Mikesell (lesmikesell@gmail.com) said:
>> We are badly in need of system-config-udev. I spent several hours
>> understanding udev adn building rules for my sound cards and tv cards.
>> I hadn't done a yum update on my F7 box for weeks/months (lazyness)
>> did one this week, and it apperently just blew away my custom udev
>> config
>
> Is this another work-in-progress? I don't have anything handy newer than
> FC6 which doesn't have persistent-net.rules and a similar question on the
> Centos list mentioned that ethX devices can be renamed when the the ifup
> scripts run.

persistent-net.rules in Fedora is a F8 and later thing.

Bill

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-11-2008, 08:42 AM
Nils Philippsen
 
Default Linux is not about choice

On Thu, 2008-01-10 at 11:00 -0600, Arthur Pemberton wrote:
> On Jan 10, 2008 10:54 AM, David Zeuthen <david@fubar.dk> wrote:
> >
> > On Thu, 2008-01-10 at 10:40 -0600, Arthur Pemberton wrote:
> > > We are badly in need of system-config-udev. I spent several hours
> > > understanding udev adn building rules for my sound cards and tv cards.
> > > I hadn't done a yum update on my F7 box for weeks/months (lazyness)
> > > did one this week, and it apperently just blew away my custom udev
> > > config
> >
> > Hell no. We are in badly need of this crap just working out of the box.
> > Throwing configuration / options at the problem will only make it worse.
> > Trying to explain this to people is apparently impossible since people
> > keep proposing stupid configuration tools with "unbreak my system"
> > options.
>
> Most people don't need to worry about udev issues like mine, unless
> MythTV with multiple video cards very popular soon

The idea is that not even you should have to worry about it -- they
should just work, i.e. if the hardware is present, the modules are
loaded, device nodes are created and PolicyKit has a reasonable default
policy for that class of hardware (e.g. "active sessions have access to
the device"). My guess is that you tweaked the udev files to get access
as a non-root user? In an ideal world this shouldn't be necessary, if
you have to tweak things, please file a bug as well so when your
modifications get overwritten (with an update) your stuff still works
(hopefully).

It's unfortunate that the udev rules are in /etc which conveys the
(wrong) message that changes would be persistent over upgrades, but
reading the thread that might get fixed.

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, 08:50 AM
Nils Philippsen
 
Default Linux is not about choice

On Thu, 2008-01-10 at 13:28 -0600, Arthur Pemberton wrote:
> On Jan 10, 2008 1:02 PM, David Zeuthen <david@fubar.dk> wrote:
> >
> > 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.
>
> You're wierd dude, this essentially the same thing I suggested and you
> discouraged.

I guess throwing around terms like "system-config-udev" might have
gotten something different across than you meant then (sometimes you
just need to spent the time to type out what you mean if you don't want
people to guess ;-).

A user interface to e.g. assign different serial ports to different
functions are okay. GUI tools to fix broken/outdated udev rules are
maybe a workaround, but not a solution. Such tools would possibly delay
things getting fixed up for other users.

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
 

Thread Tools




All times are GMT. The time now is 10:33 PM.

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