Opened 18 years ago

Closed 18 years ago

#1963 closed task (fixed)

Textual issues in chapter07/symlinks.xml

Reported by: alexander@… Owned by: lfs-book@…
Priority: normal Milestone:
Component: Book Version: SVN
Severity: normal Keywords:
Cc:

Description

The text says:

Note that it is not necessary to create the rules files or symlinks at this time, because you have bind-mounted the host's /dev directory into the LFS system, and we assume the symlinks exist and are correct on the host. The rules will be created, along with the symlinks, the first time you boot your LFS system.

But it doesn't say that, if both /dev/hdb and /dev/hdd are CD-ROMs, /dev/cdrom may point to /dev/hdb at the host, but to /dev/hdd on LFS, and a reader might complain that the symlinks are "not correct" (i.e., they are swapped).

Also, the video device examples use the obsolete SYSFS{...} syntax instead of ATTR{...}.

Change History (5)

comment:1 by bryan@linuxfromscratch.org, 18 years ago

The last part (about the video symlinks) is fixed in r7926.

I'm not sure how to fix the first part, though -- do you have any suggestions? I'd rather not modify the host's /dev directory symlinks (even though it would be undone the next time the host reboots, it still seems "unclean" to me). Maybe just a note about what could go wrong would be enough?

comment:2 by alexander@…, 18 years ago

Changing symlinks in /dev on the host will do nothing with the generated rules, so it is not necessary. A note and a suggestion to look at the generated files would be enough.

comment:3 by bryan@linuxfromscratch.org, 18 years ago

What about a loop to run write_cd_rules for each of the block devices on the system that all of cdrom_id, path_id, and either ata_id or scsi_id print values for? It'd be ugly-looking, but it'd be the equivalent of the write_net_rules all_interfaces command that gets run in section 7.13.1 for network cards.

That way, the user pre-generates their rules, so they have something to look at, but those rules don't actually run until the new system boots. But the write_cd_rules script also prints out any symlinks that it creates rules for, so the user can tell which symlinks get generated for each block device (with the appropriate echoing inside the loop for each block device). Here's what I'm thinking for the loop:

for dev in /sys/block/* ; do
    export DEVPATH=${dev##/sys}
    BLKDEV=/dev/${DEVPATH##/block/}
    echo "Inspecting $BLKDEV:"

    CDVARS=`/lib/udev/cdrom_id --export $BLKDEV`
    [ -z "$CDVARS" ] && continue

    PATHVARS=`/lib/udev/path_id`
    [ -z "$PATHVARS" ] && continue

    ATAVARS=`/lib/udev/ata_id --export $BLKDEV || \
        /lib/udev/scsi_id --export $BLKDEV`
    [ -z "$ATAVARS" ] && continue

    eval $CDVARS $PATHVARS $ATAVARS /lib/udev/write_cd_rules $MODE
done

$MODE will be set based on the method the user wants to use (when modifying the udev rules files).

Or maybe I should try to get something like that merged in upstream (at least the minimum all_interfaces equivalent, which wouldn't print anything)? Though that would still require this loop (or something like it) until the next Udev is released, if it's accepted.

Or were you thinking much simpler, like a note saying "inspect the symlinks created on your first boot, since they may be different from your host's CD device symlinks"? I suppose that would work too.

comment:4 by alexander@…, 18 years ago

A simple note similar to what you suggested is enough.

comment:5 by bryan@linuxfromscratch.org, 18 years ago

Resolution: fixed
Status: newclosed

Should be fixed in r7927 (note added). Let me know if it doesn't sound right.

Note: See TracTickets for help on using tickets.