You know, it actually occured to me the other day to publish a list of
software that I actually liked, instead of ranting about linux again. I
was starting to draft that message in my head, might even have written
it... Then I was planning to spend some quality time with my project car
and play a game called Star Ocean that I picked up the other day..
(That's as good as weekends get in my neck of the woods). But then this
morning happened.
Yesterday evening the server at my company went down. (problem with the
contacts in the memory sockets, the machine seems to date from the
2002-2003 era.) I took the opportunity to rip out the ancient SCSI CD-RW
drive and put in a modern IDE drive.
Because I had spent a great deal of quality time with the machine last
time it went down, it booted just fine after the memory issue was resolved.
So I go into work this morning, and log into it to see how the new drive
was doing. It was connected to the second controller, in CS mode on a
standard 80-pin cable even though the kernel didn't detect the cable
correctly, possibly some other glitch...
There are two HDs in software RAID on the first controller.
So I go into /dev expecting to find hdc and, possibly a symlink to CDROM...
(My local machine -- gentoo -- is currently calling my only optical
drive "cdrom3" and "dvd3" -- who knows?)
Well, on the server there was bubkis,
no hda, no hdb, no hdc, no md1, no md2, no md3 (even though that's what
was in fstab!!!)
I know that udev is supposed to create those so I started googling.
Google doesn't seem to know anything about this. The udev website hasn't
been updated in 5 years (even though the package itself is rewritten
every 20 minutes...)
>>>>> From my local config.
#############################
>>> Emerging (1 of 1) sys-fs/udev-151-r1
* udev-151.tar.bz2 RMD160 SHA1 SHA256 size ;-) ...
[ ok ]
* checking ebuild checksums ;-) ...
[ ok ]
* checking auxfile checksums ;-) ...
[ ok ]
* checking miscfile checksums ;-) ...
[ ok ]
* CPV: sys-fs/udev-151-r1
* REPO: gentoo
* USE: devfs-compat elibc_glibc extras kernel_linux old-hd-rules
userland_GNU x86
* Determining the location of the kernel source code
* Found kernel source directory:
* /usr/src/linux
* Found kernel object directory:
* /lib/modules/2.6.33/build
* Found sources for kernel version:
* 2.6.33
* Checking for suitable kernel configuration options...
* CONFIG_IDE: should not be set. But it is.
* Please check to make sure these options are set correctly.
* Failure to do so may cause unexpected problems.
*
* udev-151 does not support Linux kernel before version 2.6.25!
* For a reliable udev, use at least kernel 2.6.27
* Your kernel version (2.6.33) is new enough to run udev-151 reliably.
##############################
I have not changed my IDE settings in many many years *BECAUSE MY
COMPUTER BASICALLY WORKS*. I have two drives on my first IDE controller
(home PC). What the hell is going on here??? I'm still seeing my full
drive compliment but only because my machine has been running for many
days so it is basically running on inertia. -- IT PROBABLY WON'T WORK IF
I REBOOT IT.
The server is currently so foobar that it can't even mount its boot
partition to install a new kernel.
It's UDEV barf is:
#####################
>>> Emerging (1 of 1) sys-fs/udev-151-r1
* udev-151.tar.bz2 RMD160 SHA1 SHA256 size ;-) ...
[ ok ]
* checking ebuild checksums ;-) ...
[ ok ]
* checking auxfile checksums ;-) ...
[ ok ]
* checking miscfile checksums ;-) ...
[ ok ]
* CPV: sys-fs/udev-151-r1
* REPO: gentoo
* USE: devfs-compat elibc_glibc kernel_linux old-hd-rules userland_GNU x86
* Determining the location of the kernel source code
* Found kernel source directory:
* /usr/src/linux
* Found sources for kernel version:
* 2.6.30.5
* Checking for suitable kernel configuration options...
* CONFIG_SYSFS_DEPRECATED: should not be set. But it is.
* CONFIG_SYSFS_DEPRECATED_V2: should not be set. But it is.
* CONFIG_IDE: should not be set. But it is.
* Please check to make sure these options are set correctly.
* Failure to do so may cause unexpected problems.
*
* udev-151 does not support Linux kernel before version 2.6.25!
* For a reliable udev, use at least kernel 2.6.27
* Your kernel version (2.6.30.5) is new enough to run udev-151 reliably.
### AND ###
* Messages for package sys-fs/udev-151-r1:
* CONFIG_IDE: should not be set. But it is.
* Please check to make sure these options are set correctly.
* Failure to do so may cause unexpected problems.
*
* udev-151 does not support Linux kernel before version 2.6.25!
* For a reliable udev, use at least kernel 2.6.27
*
* Updating persistent-net rules file
*
* restarting udevd now.
*
* If after the udev update removable devices or CD/DVD drives
* stop working, try re-emerging HAL before filling a bug report
*
* persistent-net does assigning fixed names to network devices.
* If you have problems with the persistent-net rules,
* just delete the rules file
* rm /etc/udev/rules.d/70-persistent-net.rules
* and then reboot.
*
* This may however number your devices in a different way than they are
now.
*
* If you build an initramfs including udev, then please
* make sure that the /sbin/udevadm binary gets included,
* and your scripts changed to use it,as it replaces the
* old helper apps udevinfo, udevtrigger, ...
*
* mount options for directory /dev are no longer
* set in /etc/udev/udev.conf, but in /etc/fstab
* as for other directories.
*
* devfs-compat use flag is enabled (by default).
* This enables devfs compatible device names.
* If you use /dev/md/*, /dev/loop/* or /dev/rd/*,
* then please migrate over to using the device names
* /dev/md*, /dev/loop* and /dev/ram*.
* The devfs-compat rules will be removed in the future.
* For reference see Bug #269359.
*
* old-hd-rules use flag is enabled (by default).
* This adds the removed rules for /dev/hd* devices
* Please migrate to the new libata.
* These rules will be removed in the future
*
* For more information on udev on Gentoo, writing udev rules, and
* fixing known issues visit:
* http://www.gentoo.org/doc/en/udev-guide.xml
>>> Auto-cleaning packages...
###################
What the hell is that bit about HAL? Painful experience has shown that
xorg server is incompatible with HAL. It is impossible to achieve
acceptable reliability of my xorg server with HAL installed on the
system, so I don't.
When it comes to the keybord, mouse, and disk drives, no conceivable
failure mode is tolerable. By direct implication, I might have to
replace the operating systems on both my home PC and my company's server
with PC BSD or something if linux cannot be patched in such a way that
it is simply not possible for it to fail to configure it's primary hard
drives. =(
That part at the end, How can you possibly remove /dev/hda??? I mean
Minix had a pretty good system, the HD was (hd 0,1) etc... And that was
a good scheme. I mean I have not read news about this anywhere, It
didn't make slashdot, it's not on the udev website because it has never
been updated. Google has no answers, only other people's questions. Did
someone bother to write even a whitepaper before obliterating 15 years
of my linux experience? I mean I'm open to change, if you have a ***
BETTER *** system, then great! Make sure I know about it before you
break the old system.
Will my main desktop even boot if I power cycle it? On the server I
can't use any of the utilities because all the drives are invisible and
inaccessible. I'm completely helpless at this point. The system is still
running, Some of the volumes are mounted and serving pages but I cant
administer anything.
I mean I'm not even going to be able to get any sleep until I can have a
bronze cast garantee that, YES, Linux will allow me to access my
drives... With DOS, it was never ever a question, it would always work.
If I go boot the machine upstairs, if the drive spins at all, DOS will
be fully functional. Shoot me dead if it fails.
This is a 9-alarm fire, I need help from anyone to re-gain control of
both the server and my home-computer and restore sanity to the linux
developers. The disk drivers CANNOT FAIL, they're the lynchpin of the
entire computer.
Come to think of it, this is probably in the top-5 list of the most
spectacular operating system failures I've seen my entire life. This is
so insane its surreal.
--
DO NOT USE OBAMACARE.
DO NOT BUY OBAMACARE.
Powers are not rights.
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
