Matthew Burgess wrote: > On Mon, 14 Sep 2009 20:51:16 -0700, Bryan Kadzban > <br...@kadzban.is-a-geek.net> wrote: >> It might be that your kernel's SUBSYSTEM is wrong for this device. >> Do you have CONFIG_SYSFS_DEPRECATED turned on in the kernel .config >> file? Udev docs claim it may not work with that setting (though I >> don't know if that will cause this type of failure or not). > > I get the same issue here, but assumed it was because of me running > under a VirtualBox VM. I don't even know whether the BIOS on this > box is set correctly; all I know is that Windows gets the time right > so I naively assume LFS should do too :-)
Heh... :-)
Did you have that setting on? We might want to warn about that in the
book in the kernel-config section, actually. Hmm.
>> What does "/sbin/udevadm info -q path -n /dev/rtc" say? Where does
>> the /sys/$(/sbin/udevadm info -q path -n /dev/rtc)/subsystem
>> symlink point to?
>
> udevadm returns '/devices/platform/rtc_cmos/rtc/rtc0'
OK; here I get:
/devices/pnp0/00:02/rtc/rtc0
which is close (after the PNPBIOS ID), but under PNPBIOS, not a platform
driver. Not sure if that matters or not, though, because:
> The symlink points to /sys/class/rtc.
Yeah, same here. I *think* that means that SUBSYSTEM will be set to
"rtc" at runtime, but if you're not getting that either, then maybe
that's wrong.
What about the standard:
/sbin/udevadm --attribute-walk -n /dev/rtc
for the SUBSYSTEM? (And what about parent devices?) I get:
looking at device '/devices/pnp0/00:02/rtc/rtc0':
KERNEL=="rtc0"
SUBSYSTEM=="rtc"
DRIVER==""
ATTR{name}=="rtc_cmos"
ATTR{date}=="2009-09-16"
ATTR{time}=="03:32:10"
ATTR{since_epoch}=="1253071930"
ATTR{max_user_freq}=="1024"
ATTR{wakealarm}==""
looking at parent device '/devices/pnp0/00:02':
KERNELS=="00:02"
SUBSYSTEMS=="pnp"
DRIVERS=="rtc_cmos"
ATTRS{options}==""
ATTRS{id}=="PNP0b00"
ATTRS{nvram}==""
looking at parent device '/devices/pnp0':
KERNELS=="pnp0"
SUBSYSTEMS==""
DRIVERS==""
...but I'm using the rtc_cmos (rtc-class) driver, not the older setup
that creates its own misc device.
What about adding a simple echo into some random file at the start of
the bootscript, just to see if it runs at all?
Actually, hang on, this might be it: I don't know for sure that udev
passes through any sort of sane $PATH to child processes. (It may not
set any $PATH at all.) If we're trying to call hwclock without an
explicit path, that might be the bug...
...Yeah, it looks like we are doing exactly that. If the simple echo
gets run, and then changing the script to call /sbin/hwclock makes it
work, then my vote is to just "never ever rely on $PATH being set in the
bootscripts", fix *all* the implicit-$PATH instances (since they seem to
be in a couple of places), and call it good.
Not sure what to do about 6.5, though. If this is the bug, do we
release a known-issue, or release a 6.5.1 with updated bootscripts?
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
