Alexander E. Patrakov wrote:
+1, because I don't believe in educational value with udev. For most of
BLFS editors, it's a black box. Editors just expect someone to configure
udev properly, so that they don't have to think about it. Unfortunately,
udev is one of the packages that _require_ compl
Jim Gifford wrote:
There is one more solution, which will prevent all udev issues
altogether. Going to MAKEDEV.
+1, because I don't believe in educational value with udev. For most of BLFS
editors, it's a black box. Editors just expect someone to configure udev
properly, so that they don't ha
On Sun, May 14, 2006 at 10:29:30PM -0700, Jim Gifford wrote:
> There is one more solution, which will prevent all udev issues
> altogether. Going to MAKEDEV.
I fail to see how that cooresponds to anything I said. This thread is
about persistence with udev, not udev vs. MAKEDEV. Please provide
com
There is one more solution, which will prevent all udev issues
altogether. Going to MAKEDEV.
http://people.redhat.com/nalin/MAKEDEV
--
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 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
Creating a new thread as this is OT for the original thread. The message
being replied to can be found here:
http://linuxfromscratch.org/pipermail/lfs-dev/2006-May/057173.html
On Mon, May 15, 2006 at 10:19:37AM +0600, Alexander E. Patrakov wrote:
>
> that's even more variables to look for. Theref
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
The LFS LiveCD team is pleased to announce the latest pre-release of the
x86-6.2 LiveCD, x86-6.2-pre4. This latest version features a change in
the method used to allow write access to the root filesystem. Instead of
unionfs, which has proven to be unstable, device-mapper and an ext2
image are
On 5/13/06, Archaic <[EMAIL PROTECTED]> wrote:
On Sat, May 13, 2006 at 10:10:45PM +0200, Stef Bon wrote:
>
> Is the newest udev compatible with older kernels, like 2.6.11.12?
No.
If I recall, it wants 2.6.15.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linux
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
34 matches
Mail list logo
