Andrew Benton wrote:
Let's teach people to administer their own system and not have them rely
on magic scripts.
Agreed. I can understand why distro maintainers want/need to have all
these magic scripts/automatic rule generation. For LFS though, it makes
more sense to educate folks as to how
Jeremy Huntwork wrote:
Alexander E. Patrakov wrote:
Manual creation is also consistent with the situation with network
devices in
http://www.linuxfromscratch.org/lfs/view/development/chapter07/network.html.
From what I've read so far, I'm leaning towards the manual creation.
It's consiste
On Sun, May 14, 2006 at 10:20:57PM -0700, Jim Gifford wrote:
> Dump the cdsymlinks scripts altogether and use the existing tools that
> we have installed with udev. Use path_id and setup the rules based on that.
This doesn't give device persistence, but rather location persistence.
I've started a
Dump the cdsymlinks scripts altogether and use the existing tools that
we have installed with udev. Use path_id and setup the rules based on that.
On the systems, the users will need to run
/lib/udev/path_id /dev/{cdrom-device}
which would give output like this for SCSI
path_id /block/sr0
ID_PA
Bruce Dubbs wrote:
Alexander E. Patrakov wrote:
So I propose to ditch the script from LFS and optionally move it to BLFS
or to a hint. LFS should provide readers with instructions to create the
relevant rules manually:
# Begin 82-persistent-cd.rules
# SAMSUNG_CD-ROM_SC-148F (pci-:00:07.1-
Alexander E. Patrakov wrote:
Manual creation is also consistent with the situation with network
devices in
http://www.linuxfromscratch.org/lfs/view/development/chapter07/network.html.
From what I've read so far, I'm leaning towards the manual creation.
It's consistent with the rest of the bo
Archaic wrote:
On Mon, May 15, 2006 at 09:39:45AM +0600, Alexander E. Patrakov wrote:
So I propose to ditch the script from LFS and optionally move it to BLFS or
to a hint. LFS should provide readers with instructions to create the
relevant rules manually:
Manual would certainly avoid any and
Alexander E. Patrakov wrote:
> So I propose to ditch the script from LFS and optionally move it to BLFS
> or to a hint. LFS should provide readers with instructions to create the
> relevant rules manually:
>
> # Begin 82-persistent-cd.rules
>
> # SAMSUNG_CD-ROM_SC-148F (pci-:00:07.1-ide-0:1)
On Mon, May 15, 2006 at 09:39:45AM +0600, Alexander E. Patrakov wrote:
>
> So I propose to ditch the script from LFS and optionally move it to BLFS or
> to a hint. LFS should provide readers with instructions to create the
> relevant rules manually:
Manual would certainly avoid any and all race
On Sun, May 14, 2006 at 08:09:49PM -0700, Jim Gifford wrote:
>
> So far my system that has 4 ide cd drives and 4 scsi devices, hasn't
> seen any problems. From what I can see there has to be some way in sysfs
> that we can use instead of using the Debian method, which something
> about that scr
Jim Gifford wrote:
Alexander E. Patrakov wrote:
NAK: racy. The helper script assumes that new devices don't appear in
/sys during operation.
So far in the testing we have had done, no issues have come up, we have
tried it with older hardware along with newer hardware.
Testing alone is insuf
Alexander E. Patrakov wrote:
NAK: racy. The helper script assumes that new devices don't appear in
/sys during operation.
So far in the testing we have had done, no issues have come up, we have
tried it with older hardware along with newer hardware.
So far my system that has 4 ide cd drives
Jim Gifford wrote:
Archaic and all I came around an interesting way to fix the cd-symlink
issue, without having to use the script that is in LFS.org repo. Just
passing on the information I just learned hopefully it will be useful to
someone. These new rules are in the udev-cross-lfs packages as
The thread was about the udev rules, cdsymlinks are in the rules that
are in the archive. That's why I thought this would be the appropriate
thread.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
On Sun, May 14, 2006 at 02:52:02PM -0700, Jim Gifford wrote:
> Archaic and all I came around an interesting way to fix the cd-symlink
> issue
Jim, this thread is for discussion of what I posted. There was nothing
about disks in my OP. Please start a new thread so people can
distinguish between th
Bruce,
Actually I made some bigger changes than that here's the link to the
svn with the udev rules in it.
http://trac.cross-lfs.org/browser/trunk/udev/35-helper.rules?rev=1640
http://trac.cross-lfs.org/browser/trunk/udev/cdsymlink_helper.sh?rev=1640
--
http://linuxfromscratch.org/mailman/l
Bruce Dubbs wrote:
>
> Joe,
> I was asking about the situation where I have my hard disk on sda and
> a cdrom on hda AND hdb. It's probably not a smart way to go, but its
> possible.
>
> -- Bruce
>
I set my vm back to normal and it's doing some work now so I'm not going
to test. But what wo
Joe Ciccone wrote:
> Bruce Dubbs wrote:
>> That's cool. What happens if there is a cdrom on hda too?
>>
> I put my harddrive on hdb and created a cdrom on hda. This has the same
> pattern as the last one.
>
> lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom -> hda
> lrwxrwxrwx 1 root root
Bruce,
I added a just in case feature. What do you think.
KERN_NAME="$1"
if [ "$KERN_NAME" = "" ]; then
mesg Bad invocation: \$1 is not set
exit 1
fi
FILES="`ls /sys/bus/ide/drivers/ide-cdrom | grep '\.' `"
for file in $FILES; do
TEST="`ls /sys/bus/ide/dri
Bruce Dubbs wrote:
>
> That's cool. What happens if there is a cdrom on hda too?
>
I put my harddrive on hdb and created a cdrom on hda. This has the same
pattern as the last one.
lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom -> hda
lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom0
Bruce Dubbs wrote:
I'm by no means an expert here, but does the GROUP do anything for a
symlink that has 777 permissions? Or does that apply to the name when
the actual device is created?
I need to remove a lot of things in these rules before we go to production.
How robust is this? It
Joe Ciccone wrote:
> Bruce Dubbs wrote:
>> How robust is this? It would seem to work if there are two cdroms, but
>> does it generalize to the admittedly unusual case where there are more
>> than two? I'm not sure how the drives are recognized. I only have one
>> and it is at "/sys/bus/ide/driver
Bruce Dubbs wrote:
> How robust is this? It would seem to work if there are two cdroms, but
> does it generalize to the admittedly unusual case where there are more
> than two? I'm not sure how the drives are recognized. I only have one
> and it is at "/sys/bus/ide/drivers/ide-cdrom/0.0" What do
Jim Gifford wrote:
> Archaic and all I came around an interesting way to fix the cd-symlink
> issue, without having to use the script that is in LFS.org repo. Just
> passing on the information I just learned hopefully it will be useful to
> someone. These new rules are in the udev-cross-lfs package
Archaic and all I came around an interesting way to fix the cd-symlink
issue, without having to use the script that is in LFS.org repo. Just
passing on the information I just learned hopefully it will be useful to
someone. These new rules are in the udev-cross-lfs packages as of today,
if you w
Archaic wrote:
KERNEL=="rtc", MODE="664"
# Changed from 666. The distros disagree on mode, but none allow world write.
They are right: you don't want random users to set the hardware clock. And
read-only access is still useful for high-precision timing (and used, e.g., by
qemu).
Jim Gifford wrote:
Archaic wrote:
This is preliminary. I'm still working through the rest of the rules.
This covers the first 3 sections of the current 25-lfs.rules file.
**NOTE** Due to the size of this email, PLEASE make heavy use of
trimming (like stripping my comments and keeping just the r
On Sat, May 13, 2006 at 01:12:17PM -0600, Archaic wrote:
> This is preliminary. I'm still working through the rest of the rules.
> This covers the first 3 sections of the current 25-lfs.rules file.
>
> KERNEL=="capi", NAME="capi20",
> SYMLINK+="isdn/capi20"
>
> K
Archaic wrote:
This is preliminary. I'm still working through the rest of the rules.
This covers the first 3 sections of the current 25-lfs.rules file.
**NOTE** Due to the size of this email, PLEASE make heavy use of
trimming (like stripping my comments and keeping just the rule you are
replying
On Sat, May 13, 2006 at 01:12:17PM -0600, Archaic wrote:
>
> KERNEL=="vcs*", GROUP="tty"
Forgot one that isn't matched by the above:
KERNEL=="vcs", GROUP="tty"
# Added
# (clfs) doesn't have this rule
last_rule - redhat
--
Archaic
Want control, educatio
This is preliminary. I'm still working through the rest of the rules.
This covers the first 3 sections of the current 25-lfs.rules file.
**NOTE** Due to the size of this email, PLEASE make heavy use of
trimming (like stripping my comments and keeping just the rule you are
replying to) so the threa
31 matches
Mail list logo
