On 2012-12-25, Dale wrote:
> Nuno J. Silva wrote:
>> On 2012-12-25, Dale wrote:
[...]
>>> I might add, I have ALWAYS had a separate /usr. Darn near a decade
>>> now. It has never failed to boot because /usr was on a separate
>>> partition. NOT ONCE. Now I am told it is going to fail. Go figure.
>>> Go try to tell me that it was broken all these years. Yea, right.
>> Would it be too much trouble to ask you to share the output of
>>
>> egrep 'usb-db|pci-db|FROM_DATABASE|/usr' /*/udev/rules.d/*
>>
>> and the version of udev you're running? I'm curious to see. Of course
>> that, if you don't have some packages installing their udev rules, you
>> may not have the issue at all. But maybe you have, so why don't we give
>> it a try?
>>
>> Also, if you actually read the linked URL, it does explain it won't fail
>> to boot. You do realize these are two different issues here, right? One
>> is people saying that udev-181 will fail to boot, other is the issue
>> described on the URL linked on the news item, which is about stuff in
>> /usr breaking udev rules, which has been around for a long time and will
>> *silently* fail. I remind you that "silently fail" implies that your
>> system will still boot, even if it is affected by the issue.
>
> root@fireball / # egrep 'usb-db|pci-db|FROM_DATABASE|/usr' /*/udev/rules.d/*
[...]
> $$D; printf %%03i:%%03i $$B $$D'", RUN+="/bin/sh -c '/usr/bin/python
> /usr/bin/hp-check-plugin -m %c &'"
> /lib/udev/rules.d/86-hpmud_plugin.rules:SUBSYSTEM=="usb",
> ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="03f0",
> ATTRS{idProduct}=="??2a", PROGRAM="/bin/sh -c 'X=%k; X=$${X#usbdev};
> B=$${X%%%%.*}; D=$${X#*.}; logger -p user.info loading HP Device $$B
> $$D; printf %%03i:%%03i $$B $$D'", RUN+="/bin/sh -c '/usr/bin/python
> /usr/bin/hp-check-plugin -m %c &'"
> /lib/udev/rules.d/90-alsa-restore.rules: RUN+="/usr/sbin/alsactl
> restore $attr{number}"
> root@fireball / #
>
>
> Yikes, almost enough for a attachment.
>
> root@fireball / # equery list udev
> * Searching for udev ...
> [IP-] [ ] sys-fs/udev-171-r9:0
> root@fireball / #
Thanks. So you don't have udev-181, but you already need stuff under
/udev for these rules to work. Which is what that URL is about.
> I will not allow my system to upgrade to anything listed in the new
> item. I'm not going to chance it.
>
> As to a silent fail. I watch my system really close when booting. If I
> see any error message, I hit Scroll lock and make a note of it. I have
> one now about rc.conf. I have the file in the new place but have not
> rebooted yet to test. So far, I have not seen any error except for
> sound card stuff when booting. Since a sound card is not needed when
> booting, I'm not worried about it.
You happen to understand that the "silent" part in "silent fail" implies
that you won't see any error message? If it wasn't silent, it would not
be called silent fail.
In fact, I'd say that the article the URL points to was written exactly
because this has been this way for some time, but as the fail is silent,
many people simply don't notice that it fails, and assume that, as far
as the system reachs the login prompt with no visible errors, then
everything is OK.
> Again, this comes to this that has been around for decades. Anything
> needed for booting, should be on the / file system, /bin, /sbin, /lib or
> /etc. Nothing needed for booting should be placed in /usr or /var since
> a lot of people put those on separate file systems, including me. What
> I don't get is this, that has been working for decades so why change
> it?
Then perhaps you should do, for example,
equery belongs '/usr/bin/hp-check-plugin'
equery belongs '/usr/bin/python'
equery belongs '/usr/bin/hp-mkuri'
equery belongs '/usr/sbin/alsactl'
[and so on, for executables and scripts used in the udev rules the
command found on your system]
And file bugs on these packages (ALSA, python and perhaps some CUPS
drivers?), as these commands are needed for booting (they're called by
udev as soon as there is a device matching the rule) and, so, they
should live under /, not under /usr.
--
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/
