You are not logged in.
Pages: 1
Hello everyone,
I am very much surprised about the change in the recent kernel.
Requiring each and every user to load such important modules such as acpi by hand seems awkward to me! I know that Arch Linux is a distribution aimed at experienced users, but still I don't like this step. What modules might come next? How many people actually had this problem?
I am sure there must be an easier way to solve the problem for those people who have actually experienced troubles with the former setup, e.g. passing some kernel option in the bootloader to not load these modules.
Please try to explain this change to me and, even more, consider to change it back!
BTW, I did not find an existing thread about this, I hope this is correct.
Best regards,
Niklas.
Offline
I have to admit that I greatly dislike it as well. It feels like a hacky workaround to fix upstream bugs with acpi and could ultimately cause people who had no problems to now have problems if they manually load the wrong modules.
I am a gated community.
Offline
Hmm.. it looks like it wasn't discussed much before being implemented..
I am a gated community.
Offline
The issues about the ACPI changes sound _serious and I would really like to know, what advantage they are supposed to offer in return to the problems they actually arouse. Was this ever mentioned anywhere to avoid these problems beforehand?
I am not happy about the changes as well, that's for sure, but I can find myself a solution, using the information given in the mailing list.
Last edited by chaosgeisterchen (2007-04-20 05:18:37)
celestary
Intel Core2Duo E6300 @ 1.86 GHz
kernel26
KDEmod current repository
Offline
Back in August I requested making the acpi video code as a module, it locked up my laptop (and with the current kernel it still does): http://bugs.archlinux.org/task/5281 I'm grateful for that change, as it saved me quite some bother. cheers.
Offline
I think this is just another level of control people need to get use to. I know when initrd was introduced, I made my own kernels for a good 4 months. Over time, people will get use to it; it's just that initial switch that's awkward.
...
Offline
Not really. Mkinitcpio is essentially an invisible layer for most users. This isn't because it requires manual interaction by everyone since udev cannot autoprobe these modules.
I mean, how would you feel if the codecs package was broken out for every single codec? I like arch because it's simple.
I am a gated community.
Offline
I think this is just another level of control people need to get use to. I know when initrd was introduced, I made my own kernels for a good 4 months. Over time, people will get use to it; it's just that initial switch that's awkward.
No, this isnt 'just another change' it's a change broken by concept, and with no valid reason.
http://bugs.archlinux.org/task/6974
James
Last edited by iphitus (2007-04-22 09:26:31)
Offline
Not sure whats going on, you know reading wiki page it seems more for Laptop users ? Arch is meant to be KIS ok if you are happy messing with kernel but for most users well .....
Would never complain about most packages if I have a problem I will try to fix it, ask for help etc...
If system breaks then what get out the Knoppix CD????
Last edited by Mr Green (2007-04-22 09:40:37)
Mr Green
Offline
No, this isnt 'just another change' it's a change broken by concept, and with no valid reason.
But now we have the situation as running in a circle because instead of having this acpi modules fix in the kernel they get fix loaded in the rc.sysinit. Strange because this makes the whole action useless and the only advantage is that you can blacklist them.
I want to say that from my view the idea of this modularisation is good but the better place to load them is, as other distros did, the mkinicpio.conf where fan and thermal should be the default and the kernel.install should echo an attention for laptop user to inform them that they have to include the other acpi modules if they need them.
Offline
So, basically, if we update to the latest init scripts now, and take out all of the ACPI modules out of the module loading array, we should have them all loaded automatically, like before, when they were compiled into the kernel statically?
Got Leenucks? :: Arch: Power in simplicity :: Get Counted! Registered Linux User #392717 :: Blog thingy
Offline
So, basically, if we update to the latest init scripts now, and take out all of the ACPI modules out of the module loading array, we should have them all loaded automatically, like before, when they were compiled into the kernel statically?
That is what i have recognized after a reboot with the new initscripts and what i have understand if i take a look at the diff on the cvs page.
Offline
But now we have the situation as running in a circle because instead of having this acpi modules fix in the kernel they get fix loaded in the rc.sysinit. Strange because this makes the whole action useless and the only advantage is that you can blacklist them.
I want to say that from my view the idea of this modularisation is good but the better place to load them is, as other distros did, the mkinicpio.conf where fan and thermal should be the default and the kernel.install should echo an attention for laptop user to inform them that they have to include the other acpi modules if they need them.
they aren't needed that early in boot. do you check your battery percentages at initcpio time?
the advantage is a big one, as particular modules cause issues for some users. So now, some people can boot their systems
James
Offline
they aren't needed that early in boot. do you check your battery percentages at initcpio time?
Sure, i don't think that me or anyone else will check this at boot time. I suggest this because of 2 reasons:
1. On the mailing list one person wrote that he got problems with his fan instead that he loads the modul from the rc.conf. So why not loading it at the earliest moment.
2. Other distros what i know (opensuse and debian) load such modules not with boot scripts because they append them to the kernel image. So if i suggest to put thermal and fan in the kernel image than i must suggest to put a module as at example battery there too. I think a mix of having some in the kernel image and some in the rc.conf won't be understandable.-)
It is only a suggestion what i have written and not a MUST HAVE thing.
the advantage is a big one, as particular modules cause issues for some users. So now, some people can boot their systems
That is the most positive case from this action because i have a jmicron controller and so i know who bad it is as the pc won't boot.-)
Offline
Cancel what I said above; I just saw the bug-report. Yeah, that's definitely something that should have gone through testing first.
I only noticed the change when I wasn't getting a battery/charge status. All I did was throw a few modules into the array and everything worked again; didn't know people had issues like that.
...
Offline
Hi,
I have an MSI mainboard (nvidia-based). I use e17 as a wm and for the last several months have been trying to figure out why my monitors were'nt powering down when left idle. SOmetimes they would and sometimes not. They used to work just fine. Now I run the risk of damaging the screens so I have to be sure they go down when I'm done with the system (I use xset dpms 100 and wait). Can anyone tell me which modules I should include rc.conf and which I should exclude?
At present the only entry in my MODULES = entry is forcedeth
Thanks,
Jim
Offline
Cancel what I said above; I just saw the bug-report. Yeah, that's definitely something that should have gone through testing first.
I only noticed the change when I wasn't getting a battery/charge status. All I did was throw a few modules into the array and everything worked again; didn't know people had issues like that.
Which modules did you add, if I may ask? Since this update I haven't been able to get a charge reading of my battery as well.
Who is this doin' this synthetic type of alpha beta psychedelic funkin'?
Offline
I mean, how would you feel if the codecs package was broken out for every single codec? I like arch because it's simple.
I would rejoice, no need to install codecs I didn't want. Installing a whole boat load of things I don't want just to get one thing I need is wrong. That is what meta packages are for. If you want them all install the meta package. If you are more selective you could choose what you want.
I support the modularization. A monolithic kernel in the age of mkinitcpio is silly. The way it is now you have choice. Choice=power. Why give up the ability to not load those modules just to avoid putting a couple words in a text file? I know I'm happy to be able to leave those modules out, I prefer my desktop to stay awake.
Last edited by Kerowyn (2007-06-26 18:44:34)
Offline
I don't have my laptop on me right now, but I can refer you to the page I based it off of in the wiki.
...
Offline
Heh, I have no idea why I have 2 accounts, I must have mistyped it at one point, Unless there is somebody else out there with my nick and using my password.
I wondered where my post count went
Offline
Pages: 1