Opened 18 years ago
Closed 18 years ago
#1963 closed task (fixed)
Textual issues in chapter07/symlinks.xml
Reported by: | Owned by: | ||
---|---|---|---|
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 , 18 years ago
comment:2 by , 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 , 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:5 by , 18 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Should be fixed in r7927 (note added). Let me know if it doesn't sound right.
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?