rmonk wrote:Well, I apparently have arch linux installed on this computer. It's only hard to boot since the BIOS or whatever it causes screws the devices, so sda becomes sdb becomes sdc whenever I reboot, even though I use UUID's.
EDIT: It is just another funny innovation in Linux (a kind of very advanced "creative chaos"):
...The modules are therefore loaded asynchronously...
...if the machine has two hard drives,
/dev/sda may randomly become /dev/sdb. https://wiki.archlinux.org/index.php/Udev Mixed Up Devices, Sound/Network Cards Changing Order Each BootBecause udev loads all modules asynchronously, they are initialized in a different order. This can result in devices randomly switching names. For example, with two network cards, you may notice a switching of designations between eth0 and eth1.
https://wiki.archlinux.org/index.php/Ud ... _Each_Boot
This problem can be solved through the help of magic rituals and "secret esoteric knowledge".
In short, there are three occult ceremonies, and you can choose one which you like more.
Ritual 1: disable UDev "auto-loading", and load modules yourself (modify /etc/rc.conf ).
NOTE: This ritual seems to be already
deprecated, but you may try to disable UDev's "auto-loading business" in your kernel boot line (e.g. in GRUB, LILO or Syslinux)
http://chakra-project.org/wiki/index.ph ... _parameterhttps://wiki.archlinux.org/index.php/Mo ... mmand_linehttps://wiki.archlinux.org/index.php/Mo ... using_GRUBRitual 2: load modules you need, before UDev begins "auto-loading" (modify /etc/rc.conf ).
Ritual 3 (most advanced): write your own "udev rules" (you may need to study a secret handbook on "esoteric knowledge").
The third ritual is, no doubt, the most complicated route. "That can be a bit of fun", but it may prove to be a kind of "stupid business", because the rules of the game might be changed with the next upgrade.
To summarize: On Linux, kernel modules are loaded by the Invisible Hand. Although it is incomprehensible, there are "secret magic rituals" which may somehow control invisible hands and other invisible entities.
http://www.archlinux.org/news/changes-t ... cklisting/https://wiki.archlinux.org/index.php/Modprobehttps://wiki.archlinux.org/index.php/Rc.conf#Hardwarehttps://wiki.archlinux.org/index.php/InitramfsThe so-called "KISS principle" in Linux-speak means exactly this: the magic techniques and occult ceremonies of Arch Linux (and other Linuxes) should very complicated and incomprehensible. Otherwise, they may not look "very advanced".
http://en.wikipedia.org/wiki/KISS_principlehttps://wiki.archlinux.org/index.php/Be ... e_Arch_Wayhttp://en.wikipedia.org/wiki/NewspeakMoreover,
the rules of the game should be changing very fast in order to keep Linux users ignorant. The best strategy of development is, of course, "permanent radical reforms", a kind of "permanent revolution"
http://en.wikipedia.org/wiki/Permanent_revolution If you read the "explanation" of
udev in Arch Wiki, you may find it incomprehensible largely because, perhaps, the person, who wrote it, might not really understand himself what he is talking about. The is also
Gentoo Wiki. You may try it too
http://www.gentoo.org/doc/en/udev-guide.xmlThere is also
the Chakra Project Wiki:
About modules auto-loadingudev will not do
any module loading for you unless
MOD_AUTOLOAD is enabled in
/etc/rc.conf. If you disable auto-loading you must manually load the modules you want/need by putting the list in the
MODULES array in
rc.conf, you can generate this list with the
hwdetect --modules command.
http://chakra-project.org/wiki/index.ph ... _parameter
However,
MOD_AUTOLOAD seems to be already deprecated in Arch Linux:
MOD_AUTOLOAD: If set to "yes", Arch will scan your hardware at boot-up and attempt to automatically load the proper modules for your system. This is done with udev.
Note: MOD_AUTOLOAD is
deprecated as of initscripts 2011.06.1-1 and has no effect. You can use
udev rules to achieve the same effect.
https://wiki.archlinux.org/index.php/Rc.conf#Hardware
If you do not want to experiment with
udev rules, you may try to disable UDev's "auto-loading business" in GRUB or LILO
Disabling modules auto-loading with the load_modules boot parameterIf you pass load_modules=off on your kernel boot line, then udev will skip all the auto-loading business. This is to provide you with a big ripcord to pull if something goes wrong. If udev loads a problematic module that hangs your system or something equally awful, then you can bypass auto-loading with this parameter, then go in and blacklist the offensive module(s).
http://chakra-project.org/wiki/index.ph ... _parameter
See examples here:
https://wiki.archlinux.org/index.php/Mo ... mmand_linehttps://wiki.archlinux.org/index.php/Mo ... using_GRUBThis means that you can simply
disable this "stupid business", make the list of modules you need (with the standard command) and copy-and-paste it into the
MODULES array in
/etc/rc.conf (the order matters, the first in the list will be loaded first, and so on).
Another option is to use both methods:1. the modules listed in the
MODULES array (of
/etc/rc.conf ) will be loaded first
2. then
udev will start its "auto-loading business" (if it will find new devices, of course, if you plug in a new device, for example).
EXAMPLE:
Arch Linux provides the advantage of specifying the module load order by listing the modules in the
MODULES array in
/etc/rc.conf. Modules in this array are loaded before udev begins auto-loading, so you have full control over the load order.
Code: Select all
# Always load 8139too before e100
MODULES=(8139too e100)
It is very simple:
Code: Select all
$ sudo pacman -S hwdetect
$ hwdetect --modulesIt will produce a long list of modules:
Code: Select all
$ hwdetect --modules
MODULES=(button container processor cdrom pcspkr ... )
Not all of them should be loaded, of course. Some of them (e.g.
pcspkr) should be blacklisted.
It makes sense to load
cdrom module, if you are going to play Audio CDs, or watch DVDs with VLC, or UMPlayer. Otherwise, if
cdrom module is auto-loaded by
udev, you may not find
/dev/sr0 or
/dev/cdrom on your system, see:
https://bbs.archlinux.org/viewtopic.php ... 01#p940101Or you may find
/dev/sr0, but it may not work for some strange reason, see:
https://bbs.archlinux.org/viewtopic.php?id=121109 Code: Select all
$ sudo mkinitcpio -M | sed 1d | sort | uniqCode: Select all
$ yaourt hwinfo
1 community/hwinfo 18.1-9 [installed]
The hardware detection tool from openSUSE
==> Enter n° of packages to be installed (ex: 1 2 3 or 1-3)
==> -------------------------------------------------------
==> On Ubuntu, you may try something like this:
Code: Select all
$ sudo apt-get install hwinfo
$ hwinfo | grep DriverTo find out how the Invisible Hand works on Arch Linux, you can make a simple experiment with
cdrom module (or other not very important module). For example: blacklist
cdrom module in
modprobe conf and load it with
/etc/rc.confhttps://wiki.archlinux.org/index.php/Mo ... probe.d.2Fhttps://wiki.archlinux.org/index.php/Rc.conf#HardwareYou can check which modules are loaded:
Code: Select all
$ lsmod | grep cdrom
$ lsmod | grep pcspkrYou can also google them.
Other useful commands:
Code: Select all
$ lspci -v | grep module
$ lspci -v | grep Kernel
$ lspci -v
$ lsusb1. [Arch Linux]: You can load modules before
udev begins auto-loading. Moreover, you can even specify the module load order by listing the modules in the
MODULES array in
/etc/rc.conf.
2. [Ubuntu]: It is also possible to get full control over the module load order on Ubuntu, see:
http://www.paulgraydon.co.uk/geeky/nixt ... in-ubuntu/The alternative is to write "udev rules" yourself, following the Gentoo manual
http://www.reactivated.net/writing_udev_rules.htmlThe ancient method of "trial-and-error" may help. It a very advanced technology invented in the Stone Age. It is still very effective and it is still in use in any Cargo Cults.
It does not make sense to file bug reports, because it is not a bug. It is a problem which is said to be deliberately created by Arch developers:
This is not a bug. This is the developers cleansing the udev package of every last bastardization we've tacked onto it in the last few years (and there's more to come). Upstream does not provide this functionality, so therefore, Arch should not either. If you want the functionality yourself, add it. Rolling back to udev 168 is a
poor solution. Porting the functionality from udev-168 to an independent set of code that can be posted on the wiki? Fantastic solution.
https://bbs.archlinux.org/viewtopic.php ... 20#p941120
Presumably, the developers are now "cleansing the udev package of every last bastardization", because the "bastardization of udev" might be blamed for
SystemD failures
viewtopic.php?f=3&t=4153&start=15#p17379On the one hand, the Arch developers themselves may not know how write those "udev rules". That is why, perhaps, the udev manual in the Arch Wiki is so obscure. On the other hand, the developers may not be able to predict what kind of troubles might be caused by "udev rules", when
SystemD is installed. Therefore, the esoteric practice of "doing nothing" or "action without action" (
wu wei, or
wei wu wei) may seem to be a practical solution to the problem
http://en.wikipedia.org/wiki/Wu_wei It is not difficult to predict, however, that all sorts of unpredictable troubles may happen, when
SystemD is implemented in Arch Linux.
This funny innovation may, of course, cause troubles for OSS4 users.
Imagine you have OSS4 installed. You make a kernel upgrade and reboot, and you get some hundreds lines of "incomprehensible error messages".
The first thing to do is to reinstall OSS4 (as usual), but it should be a "clean re-install" (preferably recompilation), see:
viewtopic.php?f=3&t=3543&start=30#p15711 You may also want to install
udisks https://wiki.archlinux.org/index.php/Udev#UDisksThe Arch manual is here:
https://wiki.archlinux.org/index.php/Beginners%27_GuideThere also Arch Wiki.
You can also boot an Arch LiveCD and borrow some configs.
rmonk wrote:I managed to boot arch linux and installed oss and ran into the same problem.
If you have the same problem with Arch Linux, you may ask Cesium, whether he has a "magic patch" for it.
rmonk wrote:They all use linux, isn't it?
I do not think so. Each distro tends to make strange innovations, for example:
Unity is subject to Canonical's contributor agreement, requiring contributors to assign copyright to Canonical, and potentially allowing Canonical to release it under a different license.[30]
http://en.wikipedia.org/wiki/Unity_(user_interface)#Licensing
Upstart is subject to Canonical's contributor agreement, requiring contributors to assign copyright to Canonical, and allowing Canonical to release it under a
non-open source license.[13]
http://en.wikipedia.org/wiki/Upstart#Adoption
It looks like they are going to privatize Linux in some way
http://en.wikipedia.org/wiki/PrivatizationThere are precedents, for example:
On November 2, 2006, Novell and Microsoft announced a joint patent agreement to cover their respective products.[5][6] They also promised to work more closely, to improve compatibility of software, setting up a joint research facility. Executives of both companies hope such cooperation will lead to better compatibility between Microsoft Office and OpenOffice.org and better virtualization techniques.
Microsoft CEO Steve Ballmer said of the deal, “This set of agreements will really help bridge the divide between open-source and proprietary source software.”[7]
The deal involves upfront payment of $348 million from Microsoft to Novell for patent cooperation and SLES subscription. Additionally, Microsoft will spend around $46 million yearly, over the next 5 years, for marketing and selling a combined SLES/Windows Server offering and related virtualization solutions, while Novell will pay at least $40 million yearly to Microsoft, in the same period.[8]
One of the first results of this partnership was that Novell adapted the OpenXML/ODF Translator for use in OpenOffice.org.[9]
...Richard Stallman, founder of the Free Software Foundation, said in November that changes coming with the version 3 of the GPL will preclude such deals.[15]
http://en.wikipedia.org/wiki/Novell#Agr ... _Microsoft
Many things have changed during the last months. Now Arch Linux seems to be a distro for Ubuntu refugees. It does not make much sense to ask questions on Arch forums. They are now a kind of "beginners talk", for example:
https://bbs.archlinux.org/viewtopic.php?id=120003and this mythology about modprobe:
OSS crashes system after modprobe changes [Solved]https://bbs.archlinux.org/viewtopic.php?id=120670It is in the nature of human beings to create a kind of mythology, if they cannot understand what is going on. When mythology is created, the faithful tend to derive conclusions from it. This is where troubles begin. For example, the members of Cargo movement known as "Vailala madness" firmly believed that Germans are spirits of dead Papuans (that is why their skin is so pale). The conclusion was that Papuans have to learn German to communicate with their ancestors. The reason was simple. The ancestors were expected to deliver the Cargo, but you have to ask them, of course.
The ancestors who would return with the ship were conceived as being white, an idea which recurs in many post-war cargo cults. Communication with them was possible by using an apparatus described as a 'flag pole' - a tall pole, attached by cane to the movement's 'office'. An expatriate observer suggested this was the imitation of a wireless set, and claimed to have seen a pumpkin hoisted up the pole for transmission to the ancestors. However, Albert Maori Kiki, who grew up in the area, suggested that this device was actually related to a myth whereby Morning Star used a long string of cane to come from his home, which is very distant, to the village to meet a woman he fancied. This is an illustration of the syncretic nature of many cargo cult rituals.
http://en.wikipedia.org/wiki/Vailala_Ma ... _ancestors
The third major feature was the
parakke flagpole... Years before, the LMS [London Missionary Society] had introduced village flagpoles and flags for use on special occasions, especially on Sundays. Out of this, the cult made media of contact with the dead, though not everywhere. Some believed that the spirits could be contacted via the painted flagpole, and sickness cured by appeasing the ancestors. Others merely received messages through them, the leader standing at the foot, with the message coming down the pole into his stomach and out of his mouth in form of meaningless ["German"] songs, which were taken up by the people around him. Some poles possessed personal names, and a few seemed to be treated as actual personalities.
One trader claimed that they were imitations of the Persian Oil Company's wireless.
Peter Worsley,
The Trumpet Shall Sound, 1968.
http://en.wikipedia.org/wiki/Peter_Worsley
CONCLUSION: Human beings are rational. This is the basic postulate of Anthropology. If you see the natives doing something strange, there should be a reason for this. You have to study them to find it out. Anthropology is a science rather than ideology. The purpose of science is to produce "true knowledge". Such "truth does not depend on geography" (George Mikes). Anthropological handbooks contain a lot of interesting analogies and comparisons, such as: a comparison of Russian Marxists (Lenin and Trotsky) and Cargo prophets in Papua New Guinea, a comparison of German religious movements and "Vailala Madness", a comparison of the Great French Revolution (1789-1793) and the most radical Cargo Cults in Melanesia, and so on. The method of Anthropology is universal (in this sense). It can be applied, therefore, to any apparently strange or bizarre social phenomena, including the cult of "advanced innovations" in Linux.
It might be necessary to note that there is a wide range of practical sense in any seemingly bizarre Cargo Cult: struggle for power, political and economic domination, exploitation of the faithful by the cult elite, and ordinary "common sense" as well (see Peter Worsley, The Trumpet Shall Sound, 1968).
Imagine, for example, that your Linux distro works so well that the users do not need to ask any questions on your forum. Just imagine. The absolute perfectness of such an "ideal distro" may inevitably cause troubles. You might not be able to prove that you have users
viewtopic.php?f=3&t=4357#p17279 The most effective medicine for such troubles might be to create a small problem, a kind of "advanced innovation" such as PulseAudio.
Do you want to have "advanced innovations" on your Linux server? Of course, you want.
Debian switching to upstarthttp://lwn.net/Articles/351013/Debian Server vs. Ubuntu ServerOne of the first places that Ubuntu and Debian diverged was with Upstart. Debian teams have been tracking it since 2009 as a possible integration, but due to Debian now supporting FreeBSD and GNU/Hurd the future seems bleak for bug 547235 is fixed allowing for a compatibility mode. While it might not seem like a big deal, this is a big change to the baseline configs. Init scripts will need to be rewritten and much like Solaris 9 –> Solaris 10, there is a lot of bugs still to workout. If your support staff deals primarily in Red Hat and SuSE boxes there will be a learning curve with Ubuntu vs. Debian.
http://geekyschmidt.com/2011/03/11/debi ... ntu-server
Understanding the Linux boot process, subsystem initialization, & udev rules?I'm creating UDEV rules for automounting external drives on a headless server, much in the same way as Gnome-VFS does automounting during a user session.
I'm concerned with the rule's behavior at boot-time. There's a good chance one of these drives will be connected during a boot, and I'd prefer any connected drives get mounted in the right place. The drives might be either USB or Firewire, and they are mounted from a shell script fired off by UDEV on detecting an "add".
Read more: http://serverfault.com/questions/80912/ ... udev-rules
Choosing between portability and innovationIn a lot of domains,
Linux is taking the lead with respect to innovation, and the BSDs are forced to follow this lead if they don't want to be left behind...
Will FreeBSD implement
udev or will the problem be solved another way?...
http://lwn.net/Articles/429597/
Somewhere in the last years I came to the conclusion that Linux is the new Windows.
When you throw portability out of the window to gain "maximum user experience"...
If I wanted to have all the newest bells and whistles, combined with a desktop like a candy box...
http://forums.freebsd.org/showthread.php?t=22441
In other words, Cargo cultists keep innovating. This is the main feature of all Cargo Cults, according to Anthropology.