Nuno J. Silva wrote:
> On 2012-12-25, Dale wrote:
>
>
> 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.
Actually, NO. I only built a init thingy to GET READY for the change.
I can still boot WITHOUT the init thingy as it is now. I went through
this early instead of waiting for the upgrade that leaves me with a
machine that may NOT boot or me running around like a chicken with my
head cut off to figure out how to fix it. As it was, it took me a
couple weeks at least to find a init thingy that works. That is one
reason I hate the things. ;-) I suspect you were not around when hal
hit the scene. As bad as I hate hal, I think the init thingy has it
beat. Trust me, ask anyone on this list, I HATE hal!! If it was
physical instead of code, I would use it for target practice. Be nice
for my new .44 magnum rifle. :-)
>
>> 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.
Read above. I can boot withOUT an init thingy still. Also, I check for
errors after about every reboot, especially if I have not rebooted in a
while. I go through dmesg and other logs looking for anything that is
out of place or new. If anything has a issue, I'll find it. That's how
I already know about the sound card issue. It doesn't affect me booting
and never should.
>> 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]
I already know about them and they do NOT affect me booting. The hp is
my printer. The alsactl is my sound card. Again, nothing that affects
me booting. My system can boot if my printer is turned off and it also
boots without a sound card too. I do want to get me a better card tho.
;-)
> 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.
>
Thing is, upstream is not going to fix it. Lennart, and others, has
made it clear, it is their way or go away. This has been discussed a
lot over the past year or two. Some have even posted links to postings
by the udev/systemd folks. They are not interested in it. It gets
marked as 'won't fix' or whatever and that is the end of it.
Again, the point is, what has been working for ages is being claimed
that it is broken for basically everybody because it suites the ones
that want to change it. They use a init thingy to boot their systems,
binary based ones I might add, and they want to push the same on us.
Gentoo should not need a init thingy unless you have some setup where /
is encrypted or something. This is what so many disagree with. I don't
want one because they introduce one more point of failure when booting.
Just imagine the thread about 3.7.1 SATA errors. If he had a init
thingy, he would have to find out what is broken first, the init thingy
or the kernel or even worse, BOTH. I run into enough problems from time
to time. I do NOT want to add yet one more point of failure, especially
given the history of init thingys and me when I was on Mandriva. Been
there, done that, don't want to go back either.
Just my $0.02 worth.
By the way, I do NOT like init thingys. ROFL
Dale
:-) :-)
--
I am only responsible for what I said ... Not for what you understood or how
you interpreted my words!
