# Hotplug issues?

## decoleur

I am running gentoo-dev-sources and tried to emerge sys-apps/hotplug-20040923 and then ran dispatch-conf and accepted all updated files... only to loose networking (among others).

lsmod reveals:

 *Quote:*   

> KM-99391 ~ # lsmod
> 
> Module                  Size  Used by
> 
> usbcore                96996  1 
> ...

 

but if i back down to an older version of sys-apps/hotplug-20040401 i get a load of stuff from lsmod:

 *Quote:*   

> KM-99391 ~ # lsmod
> 
> Module                  Size  Used by
> 
> i915                   73444  3 
> ...

 

is this common?

Thanks in advance,

Timur

----------

## dsd

hotplug no longer loads modules on bootup. if you want that, use coldplug.

----------

## alchemyx

Could you then, please, explain what hotplug init script does in that case? I am confused, because for long time it was hotplug  :Smile: 

----------

## anz

Hello,

 *dsd wrote:*   

> hotplug no longer loads modules on bootup. if you want that, use coldplug.

 

I also was very surprised, that after updating hotplug no networking was running. Well, a putting the modules in the /etc/modules.autoload.d/kernel-2.x and everything run as normal.

I think, in future I will read the infos about in the "Online package database" before emerging ...

----------

## dsd

hotplug init script does nothing. it is not needed (and never was) for hotplugging.

----------

## alchemyx

Funny thing is that after those changes (coldplug appearead), my network card stopped working properly - I had to add an alias 'alias eth0 via-rhine', so  it works again. Sad.

----------

## Cintra

 *anz wrote:*   

> Hello,
> 
>  *dsd wrote:*   hotplug no longer loads modules on bootup. if you want that, use coldplug. 
> 
> I also was very surprised, that after updating hotplug no networking was running. Well, a putting the modules in the /etc/modules.autoload.d/kernel-2.x and everything run as normal.
> ...

 

Sorry if its a dumb question, but I am extremely confused by this.. 

what modules did you put in /etc/modules.autoload.d/kernel-2.x ?

Luckily I have a reserve copy of Gentoo on another disk or I would be totally up shit creek now..

regards

----------

## frilled

Man, I am seriously pi**ed.  :Evil or Very Mad:  I had the same thing, did an "update world" and had almost no peripheral support after booting and no idea why.

We *desperately* need some good* logging facility for portage. The way it is is simply bound to break one box after another. The only thing that keeps it from smashing directly into the wall is this incredibly good forum.

PLEASE, please, please, put some serious logging of important ebuild messages into portage!

----------

## Cintra

Right..

Happily I can restore the pre-emerge status within 10 minutes, but I hate to throw away the compile time if there's a simple fix..

mvh

----------

## soulwarrior

 *wgi wrote:*   

> PLEASE, please, please, put some serious logging of important ebuild messages into portage!

 

The functionality is already available, just activate it   :Wink: 

In /etc/make.conf uncomment:

 *Quote:*   

> 
> 
> # PORT_LOGDIR is the location where portage will store all the logs it
> 
> #     creates from each individual merge. They are stored as YYMMDD-$PF.log
> ...

 

Then to filter out the important messages, use a programm like portlog-info:

 *Quote:*   

> postlog-info |less

 

----------

## dsd

let me do a quick clarification for anyone who's a little lost:

Previously, hotplug scanned your hardware and loaded the relevant modules on bootup. Some people relied on this to autoload the relevant drivers such as network.

Autoloading modules like this is *not* hotplugging - 'true' hotplugging is where you plug a device in after the system has booted up. When this happens, hotplug aims to ensure that it is ready for use.

As such, the "autoloading modules on bootup" part of hotplug has been removed. the /etc/init.d/hotplug script now does pretty much nothing (it is not needed for 'true' hotplugging)

The autoloading-modules-at-bootup code has been split off into the more appropriately named coldplug package. To restore the old hotplug-autoloading-modules-at-boot functionality, all you need to do is:

```
emerge coldplug

rc-update add coldplug boot
```

Alternatively, you can simply list the modules you wish to load in /etc/modules.autoload.d/kernel-2.6

(or, /etc/modules.autoload.d/kernel-2.4 if you run a 2.4 kernel)

I hope that clears things up a bit

----------

## dsd

as to some way of getting this message over better, well, does anyone have any suggestions?

we describe the new behaviour in the ebuild, in the changelog, in the hotplug init script (which you must have seen with etc-update) and by spamming messages at the end of the emerge. i'm going to submit an article for the GWN but thats not going to get out to everybody.

yes, a good portage message log enabled by default would be perfect, but we dont have that just yet  :Sad: 

----------

## frilled

 *dsd wrote:*   

> as to some way of getting this message over better, well, does anyone have any suggestions?
> 
> we describe the new behaviour in the ebuild, in the changelog, in the hotplug init script (which you must have seen with etc-update) and by spamming messages at the end of the emerge. i'm going to submit an article for the GWN but thats not going to get out to everybody.
> 
> yes, a good portage message log enabled by default would be perfect, but we dont have that just yet 

 

As you said, a good logging mechanism would be the best thing (thankt for the info on portlog-info, soulwarrior) and the only thing that has a good chance to work.

I suggest collecting all ewarns, writing them to a file and displaying them via user's paging program after emerge is done. That is, by default. So even if you booted immediately or the box crashed you could still read all the important info without having to genlop and inspect every of those ebuilds for potential caveats.

Gentoo works great, generally (I can only say it again: the best thing that happened to Linux, ever), but things like this are really, really bad. I just imagined I had this problem on my production boxes. Hell. Since they are production boxes, they do not get updated all the time like my personal boxes do, so there are a lot of packages and no way anybody would sit through the emerge process...

Then they all come up halfway dead. You know you just made my day. Heaven forbid. I was lucky I ran into the problem on my personal boxes before I b0rked the other ones.

Autoloading modules is okay for me, but I'd actually have to figure out what modules are possibly loaded by various init scripts and what modules I'd have to load myself. So coldplug is just convenient for me even if I don't change the hardware often (as I like to on my personal boxes  :Very Happy:  ).

Anyway, sorry for ranting. I can understand why the changes were made, but breaking fundemantal functionality and leaving the user in the dark is a really serious issue.

----------

## Cintra

 *soulwarrior wrote:*   

>  *wgi wrote:*   PLEASE, please, please, put some serious logging of important ebuild messages into portage! 
> 
> The functionality is already available, just activate it  
> 
> Then to filter out the important messages, use a programm like portlog-info:
> ...

 

Thanks for the tip - it works very nicely!  :Smile: 

mvh

----------

## Cintra

 *dsd wrote:*   

> let me do a quick clarification for anyone who's a little lost:
> 
> ...The autoloading-modules-at-bootup code has been split off into the more appropriately named coldplug package. To restore the old hotplug-autoloading-modules-at-boot functionality, all you need to do is:
> 
> ```
> ...

 

It certainly did for me, now I'm back on the air!

many thanks...  :Smile: 

----------

## alchemyx

Everything would be fine, but one of developers is terribly wrong and doesn't want to force coldplug before network initialisation...

----------

## altstadt

 *dsd wrote:*   

> let me do a quick clarification for anyone who's a little lost:
> 
> Previously, hotplug scanned your hardware and loaded the relevant modules on bootup. Some people relied on this to autoload the relevant drivers such as network.

 

And some of us just had hotplug thrust upon us when we first installed our systems, so we didn't even think of questioning it.

 *dsd wrote:*   

> The autoloading-modules-at-bootup code has been split off into the more appropriately named coldplug package. To restore the old hotplug-autoloading-modules-at-boot functionality, all you need to do is:
> 
> ```
> emerge coldplug
> 
> ...

 

I just tried this on a sacrificial workstation and it didn't work. eth0 was not loaded and every service that depended on it was borked.

 *dsd wrote:*   

> Alternatively, you can simply list the modules you wish to load in /etc/modules.autoload.d/kernel-2.6
> 
> (or, /etc/modules.autoload.d/kernel-2.4 if you run a 2.4 kernel)
> 
> 

 

I guess I will have to figure out what is actually being loaded by the old hotplug and move to this method long term.

----------

## dsd

 *altstadt wrote:*   

> And some of us just had hotplug thrust upon us when we first installed our systems, so we didn't even think of questioning it.

 

well, if you were using the autoload-on-bootup thing, you would have added it to a runlevel yourself...

re. coldplug

 *Quote:*   

> I just tried this on a sacrificial workstation and it didn't work. eth0 was not loaded and every service that depended on it was borked.

 

please file a bug for this

----------

## dark_glaive

instead of doing 

```
rc-update add coldplug default
```

how about

```
rc-update add coldplug boot
```

On my system that runs coldplug before it gets to the networking stuff. I didn't need hotplugging for my system but may it'll help one of you guys out.

----------

## alchemyx

You are probably right but shouldn't be issue solved by adding "before net" to those damn coldplug scripts?

----------

## altstadt

 *dsd wrote:*   

>  *altstadt wrote:*   And some of us just had hotplug thrust upon us when we first installed our systems, so we didn't even think of questioning it. 
> 
> well, if you were using the autoload-on-bootup thing, you would have added it to a runlevel yourself...

 

Oh, undoubtedly, but there is a difference between reading instructions that say "to install your system, do this, that, 'n the other" and actively seeking out a package to solve a problem. I wasn't even aware that hotplug existed, let alone existed on my systems until a maintenance emerge system this morning broke the first machine I rebooted.

At some point I must have mindlessly followed some directions to rc-update hotplug. Since I don't remember a time when my eth0 didn't work, and there is no mention of any enet stuff in my modules.autoload.d, I must have run this rc-update in the first hours of a fresh install.

 *dsd wrote:*   

> re. coldplug
> 
>  *Quote:*   I just tried this on a sacrificial workstation and it didn't work. eth0 was not loaded and every service that depended on it was borked. 
> 
> please file a bug for this

 

Done. See bug 70891.

Now a question. To migrate over to use the modules.autoload.d files as originally intended, is there some way I can find out what modules the old hotplug is loading at boot?

----------

## mc_barron

Here's the problem:

- I emerge the "new" hotplug that now does nothing

- My network is completely borked (don't know why - I thought all the drivers were compiled into the kernel, so it shouldn't matter right?  Strange...)

- I now have no network to emerge coldplug, or to copy the coldplug filesfrom another computer.

I know, I know - I can revert back to the old hotplug.  But I don't want to do that.  A simple update to the world should not break my system this badly!  Besides, I'll learn nothing if I just go back to the old way.

I want to know the answer to altstadt's qustion too:

To migrate over to use the modules.autoload.d files as originally intended, is there some way I can find out what modules the old hotplug is loading at boot?

----------

## GenKreton

 *mc_barron wrote:*   

> 
> 
> I want to know the answer to altstadt's qustion too:
> 
> To migrate over to use the modules.autoload.d files as originally intended, is there some way I can find out what modules the old hotplug is loading at boot?

 

```
ls -R /lib/modules/`uname -r`
```

That will list all the modules you have.

----------

## mc_barron

Yes, you are correct in that it lists ALL of the modules I have compiled for my currently running kernel.  The question was what modules were actually loaded by hotplug?

----------

## GenKreton

 *mc_barron wrote:*   

> Yes, you are correct in that it lists ALL of the modules I have compiled for my currently running kernel.  The question was what modules were actually loaded by hotplug?

 

All the modules in that list that are specifically for a hardware device on your computer and their dependencies. For example the crypt modules would not have been loaded unless some piece of hardware needed it, like a wifi driver needing one for wpa.

----------

## frilled

I guess the best way would be to to an lsmod BEFORE and AFTER booting with the new hotplug, note the differences and put them into autoload. Unfortunately most people will realize it too late. The best fix in this situation would be to emerge coldplug, but then again who would want to use "manual autoloading" once they got coldplug? And non-geeks may have trouble getting the package once their network is down  :Smile: 

----------

## altstadt

 *GenKreton wrote:*   

> All the modules in that list that are specifically for a hardware device on your computer and their dependencies. For example the crypt modules would not have been loaded unless some piece of hardware needed it, like a wifi driver needing one for wpa.

 

Incorrect. All the modules in that list are modules that were compiled at the time the kernel was compiled. They have no relationship with the hardware installed in the system. For example, the drivers/net directory contains 94 *.o files. I am pretty certain that I don't have 94 different ethernet cards plugged into the box.

----------

## Cintra

Hei

Shouldn't coldplug be made a requirement for running the hotplug upgrade, so that at least one would have it in portage..?

I was fortunate in having a 2nd copy of Gentoo sharing a portage partition with the screwed-up copy, so could dl coldplug, and get copy 1 back on line..

mvh

----------

## GenKreton

 *altstadt wrote:*   

>  *GenKreton wrote:*   All the modules in that list that are specifically for a hardware device on your computer and their dependencies. For example the crypt modules would not have been loaded unless some piece of hardware needed it, like a wifi driver needing one for wpa. 
> 
> Incorrect. All the modules in that list are modules that were compiled at the time the kernel was compiled. They have no relationship with the hardware installed in the system. For example, the drivers/net directory contains 94 *.o files. I am pretty certain that I don't have 94 different ethernet cards plugged into the box.

 

When booting it figures out what devices you have plugged in...That's why you can do dmesg and use your kernel logs to see things like usb drives without have the modules loaded. Hence the "specifically for a hardware device" on your computer statement.

If it has anything to do with the modules compiled at kernel time why was I able to compile ipw2200 when the ebuild came and hotplug knew to load it?

So where is this list on my machine?

----------

## GenKreton

 *Cintra wrote:*   

> Hei
> 
> Shouldn't coldplug be made a requirement for running the hotplug upgrade, so that at least one would have it in portage..?
> 
> I was fortunate in having a 2nd copy of Gentoo sharing a portage partition with the screwed-up copy, so could dl coldplug, and get copy 1 back on line..
> ...

 

Why should we be forced to use coldplug? If something doesn't work it isn't hard to modprobe it. And if people read the warnings and the information in the new config file when they ran etc-update or dispatch-conf then there wouldn't be any confusion either.

I dread to think of what other problems people run into who don't pay some semblance of attention to their config file changes.

----------

## Cintra

I am thinking only of avoiding the situation where one cannot even download it...

mvh

----------

## anz

Hello Cintra,

 *Cintra wrote:*   

> 
> 
> Sorry if its a dumb question, but I am extremely confused by this.. 
> 
> what modules did you put in /etc/modules.autoload.d/kernel-2.x ?
> ...

 

Cause I am a really stupid anf lazy guy, I put only the network card module (3c59x) into the /etc/modules.autoload.d/kernel-2.x. 

After an /etc/init.d/net.eth0 start network was reachable.

Then I emerged coldplug,

deleted hotplug from the rc-update (rc-update del hotplug default)

and added coldplug to the rc-update (rc-update add coldplug default).

Now the lsmod-list shows the same modules before emerging the new hotplug-version.

.... yes, yes, I know, this is a clumsy way - but it's working (without knowing which modules I need before plugging something onto my compi).

Greetings - anz

----------

## Cintra

Thanks anz

I just did 'rc-update add coldplug default' and left 

'rc-update del hotplug boot' where it was for now.

Need to spend more time finding out what hotplug does in my situation before removing it  :Wink: 

Happy to say 'emerge auDtv world' is again up-to-date

regards

----------

## groovec

 *dsd wrote:*   

> as to some way of getting this message over better, well, does anyone have any suggestions?
> 
> we describe the new behaviour in the ebuild, in the changelog, in the hotplug init script (which you must have seen with etc-update) and by spamming messages at the end of the emerge. i'm going to submit an article for the GWN but thats not going to get out to everybody.
> 
> yes, a good portage message log enabled by default would be perfect, but we dont have that just yet 

 

the problem is (at last for me) that when doing a big emerge (emerge -uD world) mostly there are beeing a bunch of packages emerging and the important messages, like hotplug has changed, appear somewhere in the middle of everything.

as i think that i am not the only one that dont look through the hole portage logs after the emerge, i would suggest to display important messages at the end of the hole emerge process, so that you would see them directly.

----------

## kevmille

 *anz wrote:*   

> Hello Cintra,
> 
> Cause I am a really stupid anf lazy guy, I put only the network card module (3c59x) into the /etc/modules.autoload.d/kernel-2.x. 
> 
> After an /etc/init.d/net.eth0 start network was reachable.
> ...

 

I had commented out 3c59x in /etc/modules.autoload.d/kernel-2.6 so I had to /etc/init.d/pcmcia start to get my notebook to detect my nic.

emerge coldplay and rc-update add coldplay boot got my system working again.

----------

## sl70

I don't know if this is relevant to this thread or not, but upgrading to hotplug 20040923 completely borked the usb on my computer. All the usb modules (usbcore, usbserial, usb-storage, usbhid, visor) load without errors from /etc/modules.autoload.d/kernel-2.6, but there is NOTHING in /proc/bus/usb. It was very disoncerting. emerging 20040401 brought everything back to normal.

(I have an EPoX KHA+ motherboard with the VIA KT266A chipset, and an Athlon XP 2100+)

----------

## GenKreton

 *groovec wrote:*   

>  *dsd wrote:*   as to some way of getting this message over better, well, does anyone have any suggestions?
> 
> we describe the new behaviour in the ebuild, in the changelog, in the hotplug init script (which you must have seen with etc-update) and by spamming messages at the end of the emerge. i'm going to submit an article for the GWN but thats not going to get out to everybody.
> 
> yes, a good portage message log enabled by default would be perfect, but we dont have that just yet  
> ...

 

Regardless, if you could not see that you should have been paying attention during etc-update or dispatch-conf. They changed the /etc/init.d/hotplug file so it was more than clear of the changes.

Moving ewarns to the end of the whole emerge process wouldn't be a negative thing on the other hand.

----------

## Dana Merrick

I want to emerge coldplug, but I don't have any network connection...

How do I know what drivers I need to activate?

...When I boot with Knoppix, I don't get internet either. That's bad.

----------

## frilled

 *GenKreton wrote:*   

> Regardless, if you could not see that you should have been paying attention during etc-update or dispatch-conf. They changed the /etc/init.d/hotplug file so it was more than clear of the changes.

 

Well, you underestimate the pain of etc-updating with a lot of packages. You can easily have changes in 25+ files. Since this is very tedious I ususally pick out the files I *know* I changed, patch them interactively, and leave the rest I know I did *not* touch to "-5". That usually works nice and gives me good results fast. Unless something like this happens.

BTW: The coldplug script is very funny, because it just calls the 'hotplug' scripts. Ho, ho, ho - now I have a machinegun  :Evil or Very Mad: 

 *Quote:*   

> Moving ewarns to the end of the whole emerge process wouldn't be a negative thing on the other hand.

 

YES, YES, YES!

----------

## frilled

 *aragostaragazzo wrote:*   

> I want to emerge coldplug, but I don't have any network connection...
> 
> How do I know what drivers I need to activate?

 

Start with "lspci" which should tell you what network card you have.

Then have a look under /lib/modules/<kernelversion> to see what modules you built when everything was still working <g> and 'modprobe <modulename without file extension'  it. Then try to get /etc/init.d/net.ethX start to work.

 *Quote:*   

> ...When I boot with Knoppix, I don't get internet either. That's bad.

 

Did you have it working before?

----------

## andr0z

 *dsd wrote:*   

> 
> 
> ```
> emerge coldplug
> 
> ...

 

That worked fine 4 me! THX DSD!

Now I've a much clear idea of modules hotplugging  :Smile: 

----------

## DLF

 *dsd wrote:*   

> as to some way of getting this message over better, well, does anyone have any suggestions?
> 
> we describe the new behaviour in the ebuild, in the changelog, in the hotplug init script (which you must have seen with etc-update) and by spamming messages at the end of the emerge. i'm going to submit an article for the GWN but thats not going to get out to everybody.
> 
> yes, a good portage message log enabled by default would be perfect, but we dont have that just yet 

 

I suppose the problem is for most people they only have hotplug because the udev guide told them to install it.  I missed the warnings because of the nature of emerge -uDpv world (left to run overnight).  I missed the warning in the init script because I only worry about scripts I have changed myself.  I didn't check the emerge log because I didn't know there was one.  I may even have missed the significance of the warning because I associate hotplugging with my printer and USB stick and forgot about udev.  I was also lulled into a false sense of security because x86 is supposed to be stable.  Maybe the answer would be for udev to have a dependency on coldplug because when I first set up udev, auto-detecting modules at startup is precisely what it was advertised to do!

----------

## GenKreton

 *DLF wrote:*   

> 
> 
> I suppose the problem is for most people they only have hotplug because the udev guide told them to install it.  I missed the warnings because of the nature of emerge -uDpv world (left to run overnight).  I missed the warning in the init script because I only worry about scripts I have changed myself.  I didn't check the emerge log because I didn't know there was one.  I may even have missed the significance of the warning because I associate hotplugging with my printer and USB stick and forgot about udev.  I was also lulled into a false sense of security because x86 is supposed to be stable.  Maybe the answer would be for udev to have a dependency on coldplug because when I first set up udev, auto-detecting modules at startup is precisely what it was advertised to do!

 

I see no reason for udev to require cold plug when the file to autoload modules is there, we don't need the bloat!

And no hot plug is not supposed to load modules at boot, look at their main page

 *Quote:*   

> Hotplug lets you plug in new devices and use them immediately. 

 

Those little cards in your boxes weren't just plugged in while the system was running so hotplug was never meant to deal with it.

----------

## dsd

 *DLF wrote:*   

> Maybe the answer would be for udev to have a dependency on coldplug because when I first set up udev, auto-detecting modules at startup is precisely what it was advertised to do!

 

i really dont know where you read this. udev is advertised _not_ to support loading kernel drivers. (taking the typical unix philosophy style approach, udev is designed to manage device nodes and nothing else..)

also, adding a dependancy on coldplug won't help the situation. coldplug is pretty useless unless the user adds it into a runlevel. we cant modify runlevels from inside ebuilds.

also, i'll be getting an announcement about this on the front page pretty soon. we also have some kernel changes to announce and i'll slip in a note about hotplug too.

----------

## DLF

 *dsd wrote:*   

>  *DLF wrote:*   Maybe the answer would be for udev to have a dependency on coldplug because when I first set up udev, auto-detecting modules at startup is precisely what it was advertised to do! 
> 
> i really dont know where you read this. udev is advertised _not_ to support loading kernel drivers. (taking the typical unix philosophy style approach, udev is designed to manage device nodes and nothing else..)
> 
> 

 

I have no idea where I got this idea from either.  I am sure I read something about no longer needing initrd once udev was enabled.  Some bl**dy forum no doubt  :Wink: .  Anyway hotplug did it and it shouldn't have is what you are saying.

 *Quote:*   

> 
> 
> also, adding a dependancy on coldplug won't help the situation. coldplug is pretty useless unless the user adds it into a runlevel. we cant modify runlevels from inside ebuilds.
> 
> 

 

No but they would have been able to do that, they can't emerge coldplug because they can't download it!  As you point out though it isn't what udev is for.

 *Quote:*   

> 
> 
> also, i'll be getting an announcement about this on the front page pretty soon. we also have some kernel changes to announce and i'll slip in a note about hotplug too.

 

I am sure those people busy re-installing Gentoo will be delighted to read it once they have finished  :Wink: .  Seriously though, I hope you get my point that it is quite easy to miss the warning if you use emerge -uDv world.  Perhaps the emerge should pause with the warning message and only continue if prompted by the user *1.  Alternatively how about a line at the end of the emerge process "check file `emergemessages`, important info..." *2.

*1 - ISTR an upgrade to portage aborts the emerge world and prompts you to emerge portage first before proceeding.

*2 - Similar to the prompt you get when you need to use etc-update.

----------

## DLF

 *GenKreton wrote:*   

> 
> 
> I see no reason for udev to require cold plug when the file to autoload modules is there, we don't need the bloat!
> 
> 

 

Quite right, my mis-recollection of what udev is for.  Time and beer does that to a man.

 *GenKreton wrote:*   

> 
> 
> And no hot plug is not supposed to load modules at boot, look at their main page
> 
>  *Quote:*   Hotplug lets you plug in new devices and use them immediately.  
> ...

 

Sorry mister user, I know your printer was working earlier but you have just rebooted and it is more than my jobsworth to acknowledge its existence.  You could try unplugging then plugging it in again  :Smile: .

Perhaps you can help me.  I have a solitary module in my autoload file (nvidia) yet straight after booting lsmod tells me I have dozens of modules loaded.  This is with the 'new' hotplug and no coldplug BTW.  What else  causes modules to be loaded at startup?

----------

## dsd

 *DLF wrote:*   

> Seriously though, I hope you get my point that it is quite easy to miss the warning if you use emerge -uDv world.  Perhaps the emerge should pause with the warning message and only continue if prompted by the user *1.  Alternatively how about a line at the end of the emerge process "check file `emergemessages`, important info..." *2.

 

yes..thats mostly what this thread is about. hopefully you can see that we are doing our best to get this message out with the resources we have available, without doing anything that is just wrong.

pausing the ebuild is not an option - its against our policy and would have probably caused more havoc from people who start a big update and leave it..plus the portage functionality you are referring to is built into portage, only applies to portage upgrades, and can't be accessed by other ebuilds.

spewing out a message at the end of the emerge is again not an option, there is no functionality in ebuilds that allows us to do this. the message you are referring to about etc-update is again a portage internal and not controlled by any ebuilds.

yes, portage should allow us report these messages better. i believe its being worked on. i'm not a portage developer and the work i do is totally separate from portage internals most of the time.

still, thanks for the suggestions.

----------

## altstadt

 *dsd wrote:*   

> pausing the ebuild is not an option - its against our policy and would have probably caused more havoc from people who start a big update and leave it..plus the portage functionality you are referring to is built into portage, only applies to portage upgrades, and can't be accessed by other ebuilds.

 

You should try setting FEATURES=maketest and then emerge cups.

The Makefile does exactly that, pause the ebuild. Unfortunately the Makefile does not also flush stdin before portage starts the test phase, but that is another matter. No more running ebuilds from cron if you want to use maketest.

----------

## GenKreton

 *DLF wrote:*   

> 
> 
> Perhaps you can help me.  I have a solitary module in my autoload file (nvidia) yet straight after booting lsmod tells me I have dozens of modules loaded.  This is with the 'new' hotplug and no coldplug BTW.  What else  causes modules to be loaded at startup?

 

When running the autoload files it's supposed to calculate dependencies and load them in the necessary order. I am assuming that your nvidia module requires other things like agp modules and such.

----------

## veezi

Got to this point reading the whole thread, and still have one *silly* question:

Do I still need hotplug in boot or default runlevel? 

is 'rc-update del hotplug boot' the correct thing to do after this split of functionality?

Thanks,

----------

## GenKreton

 *veezi wrote:*   

> Got to this point reading the whole thread, and still have one *silly* question:
> 
> Do I still need hotplug in boot or default runlevel? 
> 
> is 'rc-update del hotplug boot' the correct thing to do after this split of functionality?
> ...

 

It is completely not necessary to have it in boot. The only thing the init.d script does now is verify that people built their kernel with hotplug support.

----------

## DLF

 *GenKreton wrote:*   

> 
> 
> When running the autoload files it's supposed to calculate dependencies and load them in the necessary order. I am assuming that your nvidia module requires other things like agp modules and such.

 

I removed nvidia and tried again but still 21 modules are loaded (fat,vfat,usbcore, gameport and loads of sound related stuff).  I suspect that it is a side effect of udev starting at bootup which of course uses hotplug.  Possibly   :Shocked:  .

----------

## rhill

 *altstadt wrote:*   

>  *dsd wrote:*   pausing the ebuild is not an option - its against our policy and would have probably caused more havoc from people who start a big update and leave it..plus the portage functionality you are referring to is built into portage, only applies to portage upgrades, and can't be accessed by other ebuilds. 
> 
> You should try setting FEATURES=maketest and then emerge cups.
> 
> The Makefile does exactly that, pause the ebuild. Unfortunately the Makefile does not also flush stdin before portage starts the test phase, but that is another matter. No more running ebuilds from cron if you want to use maketest.

 

that's not the gentoo devs breaking policy on CUPS tho, it's CUPS breaking gentoo's dev policy.  :Wink:   remember, maketest just came out publically a month or so ago.  there's a ton of these little quirks to iron out.  file a bug report about it so it can be fixed.

----------

## rhill

 *dsd wrote:*   

> as to some way of getting this message over better, well, does anyone have any suggestions?
> 
> we describe the new behaviour in the ebuild, in the changelog, in the hotplug init script (which you must have seen with etc-update) and by spamming messages at the end of the emerge. i'm going to submit an article for the GWN but thats not going to get out to everybody.

 

as one poster suggested, the best thing would be if the user knew to do an lsmod before emerging hotplug.  why not put an 'lsmod >> /etc/loadedmods' at the beginning and a message referring to it at the end.  

granted, anyone who misses each and every one of the warnings isn't going to see that either, but it would make clean up a lot easier if when ppl come here completely oblivious to what's happened you could tell them "cat /etc/loadedmods.  then modprobe netmodule, modprobe lvmmodule, modprobe lifesupportmodule, etc until you reach sanity and then add those modules to /etc/modules.autoload.d/kernel-2.6 and/or emerge coldplug." instead of having to handle each case individually.

----------

## frilled

 *veezi wrote:*   

> Do I still need hotplug in boot or default runlevel? 
> 
> is 'rc-update del hotplug boot' the correct thing to do after this split of functionality?

 

Yes. As you can see in the script it does nothing but generate an error message if you didn't have hotplug support in your kernel.

----------

## altstadt

 *dirtyepic wrote:*   

> that's not the gentoo devs breaking policy on CUPS tho, it's CUPS breaking gentoo's dev policy.   remember, maketest just came out publically a month or so ago.  there's a ton of these little quirks to iron out.  file a bug report about it so it can be fixed.

 

Agreed on all counts. Nasty CUPS.  :Smile: 

Minor bug report created. 71202.

----------

## pbardet

 *dsd wrote:*   

> The autoloading-modules-at-bootup code has been split off into the more appropriately named coldplug package. To restore the old hotplug-autoloading-modules-at-boot functionality, all you need to do is:
> 
> ```
> emerge coldplug
> 
> ...

 

This message is the one on gentoo.org, posted recently ( I found it this morning, from work, since my internet connection is "dead" at home (lost eth0 in the last update).

How do I emerge coldplug, when such an essential service is gone ?

I don't undesrtand why the message during emerge was not as clear as the one on the website. I saw it, didn't understand it was THAT crucial to emerge coldplug before rebooting... Yep, logging may help, but having better info would help as well.

I guess my only option is to try the modules thing, but I was pretty sure my network card was compiled in the kernel, to avoid problems while booting.

----------

## DLF

 *pbardet wrote:*   

>  *dsd wrote:*   The autoloading-modules-at-bootup code has been split off into the more appropriately named coldplug package. To restore the old hotplug-autoloading-modules-at-boot functionality, all you need to do is:
> 
> ```
> emerge coldplug
> 
> ...

 

This is what I did because I couldn't find my Knoppix CD.  I tried 'emerge coldplug' and of course it fell over trying to download something (ironically hotplug-2004_09_20.tar.gz).  I downloaded this file on another machine and put it in '/usr/portage/distfiles'.  'emerge coldplug' will now work.

----------

## dashnu

I have 5 productions machines that want to update hotplug, I have read this thread and I would like to make sure I have everything correct before I follow through with this.

1) If I add all of the modules I need loaded at boot to my /etc/modules.autoload.d/kernel-2.6 I should be all set.

2) If I understand this correcly I would than no longer need hotplug or would not have the need to emerge coldplug because these are servers and I do not plug and unplug hardware.

3) Now on my laptop I would want coldplug due to the fact that I have a wireless card that I do not need loaded at boot but want to load when I plug the card in.

Will someone confirm that I am understanding this correctly.

Thanks.

----------

## dsd

1 and 2 correct

3 : no

coldplugging is the process of scanning hardware *at bootup* . if you run coldplug then your wireless card module will be loaded at boot if its present. i dont think you want coldplug at all.

hotplugging is the process of loading modules when a card is plugged in *during system operation*. sounds like you want this for your wifi.

----------

## STEDevil

Well thank you very much, I just spent 3 hours (including going home to a friend just to access internet to find out just what the hell was wrong with my system) getting my 2 nics back online as well and keyboard in X (luckily I still had keyboard in cli, or I wouldn't even have been able to edit configfiles & emerge to get me out of the mess).

 *DLF wrote:*   

> Maybe the answer would be for udev to have a dependency on coldplug because when I first set up udev, auto-detecting modules at startup is precisely what it was advertised to do!

 

You probaby got this from the exactly the same place as I did, the gentoo  HANDBOOK. It has said for a very long time (and STILL!!! does) 

 *Quote:*   

> 
> 
> Now, let's perform one more step to get our system to be more like the Live CD -- let's emerge hotplug. While the initrd autodetects hardware that is needed to boot your system, hotplug autodetects everything else. To emerge and enable hotplug, type the following:
> 
> Code Listing 19: Emerging and enabling hotplug
> ...

 

Now all of a sudden some devs think that it's a really good idea to break thousands of peoples systems, going compleatly agains what the handbook states, becuse of some noncence "this isn't really hotplugging" argument. Who the hell cares about semantics when the "solution" (to a nonexsisting problem) is to break loads of unsuspecting users systems.

To make matters worse they even implement this on x86, not to mention especially the people that DO NOT want to fiddle around with manually adding modules for every piece of hardware in their box (and are thus using hotplug as it's been advertized as automatically taking care of this for you). In fact why the hell do we have ~arch when shit like this is allowed to hit non ~ straight away? Isn't there supposted to be a 1 month testing in ~arch so normal users won't have to deal with crap like this?  If I wanted an emerge to compleatly break my gentoo I would go to breakmygentoo.com or at the very least use ~x86.

 *Quote:*   

> 
> 
> also, adding a dependancy on coldplug won't help the situation. coldplug is pretty useless unless the user adds it into a runlevel. we cant modify runlevels from inside ebuilds.
> 
> 

 

It is NOT useless. If you HAVE coldplug on your system there at least EXISIST a possibility to get your system back up and running without having to figure out how to start loading all those crucial modules you need but don't even know the name of becuse you where specifically told by the handbook that you don't need to bother with it.

 *Quote:*   

> 
> 
> also, i'll be getting an announcement about this on the front page pretty soon. 

 

Much to litte and for many much too late. And this will KEEP breaking peoples systems for many months (many don't emerge world -uD 2+ times a week). This needs to HARDMASKED NOW, at least as long as the OFFICIAL GENTOO HANDBOOK is not uppdated with correct info. For crying out load, currently you can't even install a working system from scratch by following the handbook...

In a week or two you might begin slowly releasing this to ~arch and then later to non ~, but make sure coldplug is available on peoples systems first.

----------

## dashnu

 *dsd wrote:*   

> 1 and 2 correct
> 
> 3 : no
> 
> coldplugging is the process of scanning hardware *at bootup* . if you run coldplug then your wireless card module will be loaded at boot if its present. i dont think you want coldplug at all.
> ...

 

This is good enough for me..

thx

----------

## dashnu

Ok so my plan was going to be this:

1) One add all my modules to my modules file. 

2) Remove hotplug from system and runlevel. (dont need it on my servers)

3) For backup reasons emerge coldplug just so I could kick that off incase autoload.d didnt work.

coldplug depends on hotplug ?!?? 

According to what was said above in previous post. Coldplug - scans hardware on boot / loads modules (which I want) Hotplug - loads modules when a card is plugged in durring normal system operation. (which I dont want)

Are we just sharing libraies or something here... Why do I _need_ hotplug when I "dont need it".

----------

## DLF

 *init-zero wrote:*   

> Ok so my plan was going to be this:
> 
> 1) One add all my modules to my modules file. 
> 
> 2) Remove hotplug from system and runlevel. (dont need it on my servers)
> ...

 

Probably.  I suspect they have just changed the name of the script because coldplug uses the hotplug code.  It doesn't make sense for the underlying hotplug code to give a sh*t when something was plugged in so I am not surprised.  Why the old hotplug script couldn't have stayed around for a while beats me but hey ho.

----------

## dashnu

This is a mess......  Oh well onwards I go......

----------

## frilled

Well, you might be exaggerating this a bit too much. This was serious b0rkage and completely unneccessary, but OTOH it was fixable. You still had all the modules, you just had to load them by hand. I was caught by surprise, too, and hell I was more than annoyed, I have to admit. And I think it should not have been done like this. But I had worse troubles. So let this be a reminder to the devs that they shouldn't take stuff like this too lightly. Especially the comments on the gentoo handbook raised here were very, very true. It has actually been a difficult month for gentoo in my opinion. Quite some breakage. But that's how it is. It comes and goes in waves...

----------

## pbardet

I don't think the handbook is at fault in this mess. To me, it clearly states (whether it's the current version, or the 1.4 I used to setup my system) that you should add modules in your kernel2.x file in /etc/modules.autoload. And hotplug is used for everything else (I've always been under the impression hotplug was used for USB stuff).

 *Quote:*   

> Now, let's perform one more step to get our system to be more like the Live CD -- let's emerge hotplug. While the initrd autodetects hardware that is needed to boot your system, hotplug autodetects everything else. To emerge and enable hotplug, type the following:

 

I understand that the fact that it used to work without doing the kernel2.x edit can be considered a problem, which could have been pointed a lot more clearly during emerge.

Here is the message that showed up during emerge and that I saved because I was not quite sure what it meant and I would look into it later:

```
* WARNING: The hotplug init script is now gone (dead and burried.)

* WARNING: If you want to load modules for hardware that was already

* WARNING: discovered at boot time, like the old hotplug init script

* WARNING: did, then emerge the coldplug package, and add coldplug to

* WARNING: a runlevel, e.g. # rc-update add coldplug boot

* WARNING: All firmware loaded by the hotplug scripts needs to be

* WARNING: moved to the /lib/firmware directory, as the scripts now

* WARNING: expect it to be in that location.
```

I'm still not quite sure what the last 3 lines mean, but I guess I'll find it out the hard way at some point.

By reading this, I have absolutely no idea that my ethernet card is concerned by this change, unless I remember how I setup my machine more than 12 months ago, while the message available on the web site clearly shows what could go wrong, before you lose your connection by rebooting, or next time you turn your computer on.

At least, I understand better the way all that stuff works, so I learned something new and that's what I hope to remember from this experience. This problem should not happen again since my system is now configured the proper way, without relying on coldplug. Until I compile my next kernel with network enabled in the kernel. I'll have to find out why this was not the case, when I was pretty sure to have done it in the past.

----------

## andyfraser33

 *dsd wrote:*   

> spewing out a message at the end of the emerge is again not an option, there is no functionality in ebuilds that allows us to do this. the message you are referring to about etc-update is again a portage internal and not controlled by any ebuilds.

 

I think it's definitely a good idea though. Like others here, I don't watch the build process and so miss most of the messages that fly by. I also only check configs that I know I've edited so the 18 or so hotplug config changes weren't checked.

I got caught by this issue too but luckily my policy is to load modules for fixed hardware (soundcard, NIC, graphics card) via /etc/modules.autoload.d/kernel-2.6 and only let hotplug (now coldplug) load devices that might change from boot to boot such as USB devices so I didn't lose network access and it was easy enough to workout and fix. I just had no mouse until I loaded the USB modules manually.

I now have PORT_LOGDIR set up and use portlog-info to check for these messages. Having all these warnings displayed at the end of a merge would've been much better. Next time something like this happens it could have a much worse side effect if people miss the warnings.

----------

## STEDevil

 *wgi wrote:*   

> Well, you might be exaggerating this a bit too much. This was serious b0rkage and completely unneccessary, but OTOH it was fixable. 
> 
> You still had all the modules, you just had to load them by hand. I was caught by surprise, too, and hell I was more than annoyed, I have to admit.
> 
> 

 

It is fixable for you and fixable for me, but it sure isn't fixable for eg my mother that lives 1500km from where I do, and if this would have struck here before me I couldn't even have logged in by remote ssh to fix it for her.

This IS SERIOUS, and I don't think I'm exaggerating, becuse it hits the hardest against exactly the group of people that is the LEAST likely to be able to recover from it. My mothers system would have stayed dead until I had had time to buy a planeticket to go there and fix it for here.

----------

## STEDevil

 *pbardet wrote:*   

> 
> 
> ```
> * WARNING: The hotplug init script is now gone (dead and burried.)
> 
> ...

 

A large contributing factor to the mess BTW is the coinciding version rollup of Gnome in stable. I had 92 packages in my world -upD on a system I had fully updated only 3-4 days before. After the emerge had finished I had 50 or so configfiles to update in etc-config. The warnings during emerge and configupdate simply got lost in the information overload (which in it self is a really big flaw in portage), not that eg my mother or ex gf would probably have understood the warningmessages in any case.

I can tell my mother on the phone to boot into CLI-mode (since X & login didn't even have keyboard working) and then tell her to type 

```
rc-update add coldplug default
```

and then reboot.

I can NOT tell her to "try and find the correct modules you need for your system and add them to the modules load file". The solution would most likely have been "open the drawer, take out the Windows 2k CD, insert & install"...

In short, at the very least, GET COLDPLUG ONTO PEOPLES SYSTEMS. Anybody that doesn't want/need to use it don't have to, but for many it can be a life saver.

----------

## DLF

 *STEDevil wrote:*   

> 
> 
> In short, at the very least, GET COLDPLUG ONTO PEOPLES SYSTEMS. Anybody that doesn't want/need to use it don't have to, but for many it can be a life saver.

 

Ah but think of the bloat caused by that 31 line script  :Wink: .

----------

## drescherjm

Thank You dsd for posting the simple fix. It was very annoying to use my laptop without an external usb mouse...

----------

## BServiss

I lost usb functions after upgrading hotplug. After re-emerging hotplug and seeing the reference to coldplug, I did the rc-update.

If you want to find which module(s) will solve your problem, you'd have to look at the compiled modules as directed earlier, and insert each one in turn and see when the problem goes away. Not a solution for all situations to be sure, but if you want to find out why you can'tcommunicate with your usb ups, there are only a few modules that need looking at. Mine was usb-uhci (third on the list).

Just goes to show that a small update can have a large effect on your system.

Overall, I think the hotplug upgrade problem is a good thing as it requires you to really know whats going on in the system, as in my case.

----------

## Gentree

OK , please admit this was not thought through properly and try to learn the necessary lessons that it does not happen again.

I wont repeat what's already been said and STEDevil summed up the situation and my levels of frustration quite well above.

Portage is one of the corner-stones of Gentoo. For it to be useful it has to be reliable. It isnt.

I did emerge -uDav world and ended up with a completely broken system: pam login issues, no X, no LAN. And this is supposed to be "stable"!

I have had to mask and retrograde several packages and am still trying to work out what I can or cant install from what is supposedly stable.

I am now completely reviewing my update strategy.

One certain step will be finding 10Gb free space somewhere for a complete ghost image. This was necessary policy on Windows, it appears now to be needed on Gentoo. 

You ask for SUGGESTIONS:

Number One: put yourself in the user's position , most of us dont have the same familiarity or the ammount of time to invest as devs do.

Dont let this sort of thing happen to stable

If by accident it does, at least put a sticky in the portage forum to help those caught out and to warn other potential victims who do check for issues before updating, this still has not been done!

If by accident it does, use portage masking a.s.a.p. to stop it hitting everyone.

etc-update could make diff files so any changes are clearly documented and backed-up and can be reversed if needs be.

If portinfo is needed to make any use of the (tens of ) thousands of lines output by portage why isnt it part of the base system? I cant even find it in portage! Where do I get it?

Since packages are not often done one at a time , the current method for outputting warnings is inadequate. It needs reviewing.

The whole hotplug/coldplug distinction is nonsense anyway . Coldplugging is when the system is powered-off and is nothing to do with any run-level. 

Thanks for your explaination of what this was all about. Now I know it seems the whole mega-headache was a pendantic whim rather than a system "upgrade".

This week was the first time since I switch from Windows to Gentoo that I came close to kicking the computer.  :Evil or Very Mad:  I hope it's the last.

I had just partitioned a friend's PC to make room for Gentoo but if I need a ghost of the system there wont be enough room. Rethink.  :Confused: 

I hope this thread leads to a better future for portage. Gentoo is great but I waste too much time debugging updates.

Best regards.  :Cool: 

----------

## stalcair

Gentree and STEDevil had a great way to sum up what I have felt, bravo.

Many see Gentoo as Gentoo is described, a customizable and usable system that puts you in control.  Then they use it.

The forums, if you dig long and deep enough, will reveal that Gentoo and "it just works" are not generally terms you hear in the same sentence.  Read: you best like fixing things over and over and over again and spending all your time debugging, troubleshooting, searching, trying, and tweaking to get it to a working condition.

This is much like any hobby and is not in itself a bad thing at all.

When someone uses a computer it may be for the enjoyment of tinkering with every single detail just to feel they accomplished something great and wonderous when they get Tux Racer fired up that glorious first time.

Others want to use it as a tool to help them in a particular task and saw the level of customizability as a means to that end.  (this would include me).

If my car doesn't work after I took it into the shop for regular maintenance (emerge -uDva world) then you can bet I am not a happy camper.  If the mechanic and his company ignore or insult me then that does not help.  If many others have the same problem... yet the company still does not acknowledge and properly post warnings and update their own system (I am inspired here by the 2004.x LiveCD's, especially 2004.2) then we have a serious problem.

So what does the community want from Gentoo?  What is Gentoo exactly?  If extensive QA is required (as opposed to some simple smoke tests as would normally happen) for every update then please add that to the description of Gentoo and "what users can expect."

Otherwise it would be nice to track a system matrix of compatibility (by various degrees, think LinuxPrinter.org") and keep it UP TO DATE with various problems and solutions.  This may even help dev's out (hint: I use this system at work, albeit on spreadsheets and it helps all eyes to see the picture better and avoid foolish duplication)

----------

## STEDevil

 *Gentree wrote:*   

> 
> 
> The whole hotplug/coldplug distinction is nonsense anyway . Coldplugging is when the system is powered-off and is nothing to do with any run-level. 
> 
> 

 

It's in fact beyond nonsence, it's pure idiocracy. Hotswapable PCI is at the moment going mainstream. The new Gentoo disticntion would make eg a hotswapable NIC NOT load drivermodules if it was inserted when I turn on the power, but WOULD load the drivers if i yanked it out and reinserted it while the system was running. 

I ask, where is the logic and unserfirendlyness in this? How is this behaviour beneficial to ANYONE?

 *Quote:*   

> 
> 
> Thanks for your explaination of what this was all about. Now I know it seems the whole mega-headache was a pendantic whim rather than a system "upgrade".
> 
> 

 

Indeed, this thing is as unproductive and pointless for regular use as the for years ongoing FHS squable (what should go exactly where) when the real solution would be to compleatly scrap FHS and simply let packages autodetect where everything they need is (a process already today made compleatly automatic by autotools).

Devs, step up and show that you don't belong to the group of mindless FSH drones that wants to break things just becuse you can for no good reason at all and

a) Make sure people have Coldplug

or even better

b) Just put autodetect hardware back in hotplug where it belongs

----------

## rhill

would you guys please stop screaming at the gentoo devs?  they're not the ones who decide what or how an application will work or not work.  break stuff for the hell of it?  wtf.  they didn't one day say 'hey, we have nothing to do, let's go piss off some users'.  if you want to yell, how about you go chat with the hotplug devs instead.  i'm sure they'll love you telling them how to do their job.

put hotplug back where it belongs? the fact of the matter is hotplug was never intended to be a boot module autoloader.  it doesn't "belong" there in the first place.  hotplug's only purpose is to manage the addition or removal of devices on the fly, and work with udev to manage the /dev entries for said devices.  it is _not_ designed to load modules at boot time.  /etc/modules.autoconf.d/ provides that functionallity, and now has been joined by coldplug.  hotplug was only used to load boot-time modules in the past as a temporary workaround until coldplug stabilized and could take over.

 *Quote:*   

> hotplugging is what happens when a user connects peripherals using connection technologies like USB, Cardbus, IEEE 1394, and networks. He (or she) connects devices with power on, knowing that each system can immediately see and use them and expecting that to mean the device will immediately be usable. Requiring more user input than just plugging in the device should be avoided in almost all cases.
> 
> Closely related is the "cold plugging" problem, which is handling those same kinds of device connections before the OS is fully bootstrapped (to multiuser mode). The simple way to handle that problem is to fake hotplug events that couldn't be handled before hotplugging was running. When hotplugged devices need to be configured for use during system booting (such as mounting a root filesystem using a device on USB, such as a USB disc drive or network adapter) there is a limited-functionality "diet hotplug" tool available for use with the "initrd" mechanism. 

 

http://linux-hotplug.sourceforge.net/?selected=overview

coldplug is the fully-functional replacement to this "diet-hotplug".  it's the way it works now, and the way it was intended to work in the first place.

i know a lot of people are pissed off, and i agree this was handled pretty badly.  any kind of advanced notice would have been nice for starters.  and it should have been phased in - maybe have had hotplug still handling boot modules, but displaying a warning on boot-up about the need to emerge coldplug.  this warning could have been in a revision bump, so anyone would see it when they upgraded.  then, after a reasonable time, make the change.  at the very least, there should have been a fallback to using hotplug if coldplug is not installed on the users system (along with blinking flaming text surrounded by hundreds of exclamation points).

my point is, place the blame on the right people.  yeah the devs make a mistake.  it happens.  but don't go bitching at them to change it back to how it was because they can't.  it wasn't their decision to make.

--de.

----------

## STEDevil

 *dirtyepic wrote:*   

> would you guys please stop screaming at the gentoo devs? they're not the ones who decide what or how an application will work or not work. break stuff for the hell of it? wtf. they didn't one day say 'hey, we have nothing to do, let's go piss off some users'.
> 
> 

 

Actually, it's the gentoodevs that decided to make this change go directly into stable as opposed to ~ or hardmasked. I can't imagine forseeing the possible problems involved with this change was very hard.

It's also gentoodevs that decide if this change should give the dependency on coldplug to be downloaded and put on the system BEFORE a possible loss of networkaccess.

It's also gentoodevs that is responsible for official documentation to actually correspond to how Gentoo behaves in real life.

It's also most certainly the gentoodevs job to try to make sure changes in a single software doesn't break thee entire dist for many users.

Now tell me again how thousands of Gentoousers systems breaking is not the Gentoodevs fault?

That said, noone is infallible, but they need to take imediate action prevent even more people being caught off guard by this change (the minum step being hardmasking for now and making sure coldplug is on peoples systems) becuse this WILL keep breaking peoples systems for a long time to come.

 *dirtyepic wrote:*   

> 
> 
> put hotplug back where it belongs?
> 
> 

 

Uh, where did you pick up that erroneous statement? At least I was talking about automatic hardware detection in general. By that I mean having eg the hotplug rc script automatically start coldplug unless a user changes eg a "also make hotplug autodetect hardware at bootup"-value from 1 to 0 in rc.conf.

 *Quote:*   

> 
> 
>  the fact of the matter is hotplug was never intended to be a boot module autoloader.  it doesn't "belong" there in the first place.  hotplug's only purpose is to manage the addition or removal of devices on the fly, and work with udev to manage the /dev entries for said devices.  it is _not_ designed to load modules at boot time. 
> 
> 

 

Please read my post right above yours about the insanity of making that distinction (hot/cold plug) in a computerworld that is clearly moving towards hotplug/swapability in every area thinkable. Even the new ATA standard is offering it. It's time people wake up and smell the coffee, hotpluging ain't just about USB memories and cameras any more... 

People expect things to work WITHOUT having to yank hardware out and put them back in just becuse it happened to already be inserted/connected at boottime.

 *Quote:*   

> 
> 
> coldplug is the fully-functional replacement to this "diet-hotplug".  it's the way it works now, and the way it was intended to work in the first place.  so deal with it.
> 
> 

 

People like eg my mother shouldn't HAVE to deal with it, at the very least coldplug should be automatically added to users systems (and I see no reason what so ever for not making the Gentoo hotplug rc script also starting coldplug now and for all forseeable future). It's a lot easier to disable things on a working system then enable things on a non working system if one for some reason find autodetection of hardware at bootup to be an abomination.

----------

## veezi

My humble opinion:

If Gentoo's hotplug init script is provided by hotplug developers then I agree with 'dirtyepic', otherwise I agree with 'STEDevil'   :Very Happy: 

Anyway, I really don't see why people have such a strong reaction to the way it was done. For me:

1. hotplug and udev updates always deserve a look at the logs and the scripts to see if something drastic needs to be changed. It's not something that you'd 'emerge -uD world' and just reboot.

2. If someone is running a production system, then he better know what hardware he's running, and so he should have no problem loading the network driver module for his NIC. So, saying 'Oh my god, I can't connect after this' is really an exaggeration!

3. Harsh critisizm for people that do work for free is really something bad. We all better be more polite, even when we critisize.

Just my opinion. Hope I didn't offend anyone  :Smile: 

----------

## dsd

i don't have the time to discuss this further, so this will likely be my final word here. i dont mean to sound like i'm dismissing the issue, its just that this is in the past and i don't have the time to continue debating it - i have too much other work to be getting on with.

first i'd like to clarify something that has been brought up a couple of times in this thread - people are under the impression that this change went straight into the stable tree? that is not correct and very rarely happens with anything other than security fixes across the whole of gentoo. hotplug-20040923 introduced this change, and hotplug-20040923 entered portage (in ~ testing tree) about 10 minutes after it was released upstream (maybe this tells you something about gentoo's relationship with hotplug..) which was almost 2 months ago.

i don't recall seeing any bug reports or feedback about it before it went stable, other than one exsiting bug that it closed

the feedback that i've had has been mixed (referring to this thread, emails sent to me directly, and comments on bugzilla). please, remember that all the gentoo developers do this out of free time and get no payment. if you want to criticize something we've done, thats fine, but please don't make us want to end our lives after reading it (exaggeration, but hopefully you get the point). that won't help me to fix the situation, even if you did include decent suggestions.

on the other hand, some feedback has been well thought out and thankful, that reminds me why i'm doing this...to those who seem to better understand my position, thanks for the emails you sent..

yes, this should have been done better. yes, portage needs a decent message conveying system. remember that gentoo is a huge project, and just because i'm a developer does not put me in a position to fix this with the click of my fingers. this is totally out of my responsibilities and is not something that realistically could have been put in place by myself or the hotplug developers for this change. i will start a developer discussion on the topic of conveying important upgrade messages.

when you are a developer it is easy to lose the sight that you had as a user. it does not help that constructive criticism very rarely happens before something enters stable. i'll probably continue reading this thread, so maybe some people could clear up the following for me:

since genkernel uses something other than hotplug for loading modules at bootup, i can say that pretty much everyone on this thread doesn't use genkernel.

that implies that people configure their kernels manually, i.e. going through all the options and selecting the hardware relevant to their system.

but it appears that many users select their core hardware as modules. why? modules have the advantage of being able to be loaded when you need them, but whats the point compiling your network card driver as a module when you are going to need it all the time? is there some gentoo misconception that recommends people build highly modular kernels for non-dynamic situations?

[ to me, it makes much more sense to build these things built in, and then you dont have to worry about coldplug or modules.autoload.d and this entire mess would be avoided ]

additionally, since users themselves have selected their hardware as modules, does it not cross your mind early on, when your network isnt working, to check that the module is loaded? ok, it seems that quite a few people picked up that network module wasnt being loaded. but i heard about people reinstalling their entire system to get around this. did the thought of a simple "modprobe" not occur? do people really think hotplug is the only way you can load modules?

thanks.

----------

## DLF

 *dsd wrote:*   

> 
> 
> since genkernel uses something other than hotplug for loading modules at bootup, i can say that pretty much everyone on this thread doesn't use genkernel.
> 
> that implies that people configure their kernels manually, i.e. going through all the options and selecting the hardware relevant to their system.
> ...

 

If the dynamic linker fails on your system then only those programs linked statically will work, it isn't a reason not to use shared libraries!  Not quite the same I admit  :Wink: .  To me it seems far more sensible to let the system decide what I need in my kernel than try and work it out for myself.  It's what computers are good at and despite my best efforts I could never work out exactly what I needed.  I started with genkernel and gradually pruned out what I didn't need.  The initrd was one of the things that proved unnecessary!

 *Quote:*   

> 
> 
> additionally, since users themselves have selected their hardware as modules, does it not cross your mind early on, when your network isnt working, to check that the module is loaded? ok, it seems that quite a few people picked up that network module wasnt being loaded. but i heard about people reinstalling their entire system to get around this. did the thought of a simple "modprobe" not occur? do people really think hotplug is the only way you can load modules?
> 
> thanks.

 

Well I tried that for a while, modprobing modules that seemed network important but I gave up after a while and and went online.  Emerge coldplug was far easier than trying to work out what my missing modules were called.  Even without hotplug or coldplug scripts and nothing in the module autoload file I still got 21 modules loaded at startup.  It wasn't as if autoloading had failed, just selectively.  Nobody has been able to tell me what loaded them!

----------

## STEDevil

First I would like to apologize for spreading the missconception that this didn't go through ~ before it went stable, sorry.

 *dsd wrote:*   

> 
> 
> yes, portage needs a decent message conveying system. remember that gentoo is a huge project, and just because i'm a developer does not put me in a position to fix this with the click of my fingers. this is totally out of my responsibilities and is not something that realistically could have been put in place by myself or the hotplug developers for this change. i will start a developer discussion on the topic of conveying important upgrade messages.
> 
> 

 

On that topic, I personally can't understand why something like ehush is not implemented by default in portage. I've used it on another system and I think it's just the thing that would be needed to fix the spammy outpout problem in portage  (after all, the people that actually find the compiletexts passing by to be usefull must be in a clear minority and you can still access it later in the logfile or add an verbose option). 

That should be easy enough to implement (for starters becuse it's already available as a "wrapper" and a basically copy&paste of the code shouldn't take years to implement).

 *Quote:*   

> 
> 
> since genkernel uses something other than hotplug for loading modules at bootup, i can say that pretty much everyone on this thread doesn't use genkernel.
> 
> 

 

It does?

Interesting since I use genkernel and both NICs as well as my (PS/2) keyboard went dead in X with the hotplug update and came back when emerging & adding coldplug.

 *Quote:*   

> 
> 
> that implies that people configure their kernels manually, i.e. going through all the options and selecting the hardware relevant to their system.
> 
> 

 

Yes and no. I use genkernel, but I've found that it does not by default  include everything I need in my system so I've had to change some settings myself. Mayby I accidentally removed something else that I erroneously didn't think I needed.

 *Quote:*   

> 
> 
> but it appears that many users select their core hardware as modules. why? 
> 
> 

 

For me it allows the compliation of a huge ammount of drivers for hardware available on my own or any other of the systems I help others to manage without making the kernel itself absolutely huge. Should I need to change/test someone elses possibly defect hardware I also don't need to first recompile the entire kernel.

In short, lot's of drivers as modules gives lots of flexibility without turning the kernel into an absolute hog.

 *Quote:*   

> 
> 
> [ to me, it makes much more sense to build these things built in, and then you dont have to worry about coldplug or modules.autoload.d and this entire mess would be avoided ]
> 
> 

 

To a degree you are right, but for the 99% of computerusers out there compiling kernels and manually adding drivers (in kernel or as modules) is compleatly beyond their capabilities. The more mainstream Linux gets (lets leave opinion on this to another thread) the more of these people seeking an freeware alternative to MS-OSs will find Linux. Autodetection of hardware will thus out of nessecity soner or later be the norm (like it already is on all other main destop OSs).

Im personally thrilled of how well ADHW is nowdays working on Linux especially Gentoo (some recent lapses excluded) that in combination with eg Portage is actually making Linux a viable choise to many users. 

Auto Detection of HardWare and loads of modules is the future of Linux outside of the programers & geeks world.

----------

## frilled

 *dsd wrote:*   

> but it appears that many users select their core hardware as modules. why? modules have the advantage of being able to be loaded when you need them, but whats the point compiling your network card driver as a module when you are going to need it all the time? is there some gentoo misconception that recommends people build highly modular kernels for non-dynamic situations?

 

Ever tried passing configuration options to drivers in a monolithic kernel?

----------

## truekaiser

i don't know whats worng with the new hotplug version. all i had to do to fix it was move the firmware to /lib/firmware though oddly i didn't get that warning i had to search the config files for hotplug.

----------

## rhill

 *STEDevil wrote:*   

> Actually, it's the gentoodevs that decided to make this change go directly into stable as opposed to ~ or hardmasked. I can't imagine forseeing the possible problems involved with this change was very hard.
> 
> It's also gentoodevs that decide if this change should give the dependency on coldplug to be downloaded and put on the system BEFORE a possible loss of networkaccess.
> 
> It's also gentoodevs that is responsible for official documentation to actually correspond to how Gentoo behaves in real life.
> ...

 

and i agreed.  this was done badly.  i was saying that the actual segregation of hotplug/coldplug was not their idea.

 *Quote:*   

> Uh, where did you pick up that erroneous statement? At least I was talking about automatic hardware detection in general. By that I mean having eg the hotplug rc script automatically start coldplug unless a user changes eg a "also make hotplug autodetect hardware at bootup"-value from 1 to 0 in rc.conf.

 

"or even better

b) Just put autodetect hardware back in hotplug where it belongs"

my point was that autodetecting hardware (at boot) does not belong in hotplug in the first place.  that's not what hotpluggin is.  as for the second statement, i agreed that there should have been a phase-over period to guarantee that most people were actually using coldplug before doing the final switch.

 *Quote:*   

> Please read my post right above yours about the insanity of making that distinction (hot/cold plug) in a computerworld that is clearly moving towards hotplug/swapability in every area thinkable. Even the new ATA standard is offering it. It's time people wake up and smell the coffee, hotpluging ain't just about USB memories and cameras any more... 
> 
> People expect things to work WITHOUT having to yank hardware out and put them back in just becuse it happened to already be inserted/connected at boottime.

 

and what's your point?  you don't like having two terms for two completely different concepts?  when you boot up a computer into say windows, your NIC needs a driver.  the OS sees the card and loads said driver.  in linux, same thing, except you have to load modules, and you have to tell the kernel which modules you need loaded.  neither of these things are hotplugging.  hotplugging is the DYNAMIC loading and unloading of drivers/modules on the fly.  it's not Plug'n'Play.  it's not kudzu.  if you have hardware that needs a module to load at bootup, then put it where it belongs in modules.autoload.d, or use coldplug, and stop whinging because you lost your wobbly hotplug crutch.  especially when it's been replaced with a much better one.

 *Quote:*   

> 
> 
> People like eg my mother shouldn't HAVE to deal with it, at the very least coldplug should be automatically added to users systems (and I see no reason what so ever for not making the Gentoo hotplug rc script also starting coldplug now and for all forseeable future). It's a lot easier to disable things on a working system then enable things on a non working system if one for some reason find autodetection of hardware at bootup to be an abomination.

 

again, i agreed.

why is this pissing you off so much?  emerge coldplug and get on with your life.  seriously.

--de.

----------

## STEDevil

 *dirtyepic wrote:*   

> 
> 
>  *Quote:*   Uh, where did you pick up that erroneous statement? 
> 
> "or even better
> ...

 

I wrote the above yes, but you condensed it to the below that does not mean the same thing. You changed the entire meaning from being about Hardware detection into placement(?) of hotplug.

 *Quote:*   

> 
> 
> put hotplug back where it belongs? 
> 
> 

 

 *Quote:*   

> 
> 
> and what's your point?  you don't like having two terms for two completely different concepts?
> 
> 

 

My point is that it is NOT 2 different concepts. The hot/cold difference is a technical distinction that an enduser could not care any less about. The distinction exsists purely becuse programatically you need to handle detection slightly different but an enduser will expect that the device (eg a SATA HD or hotplugable PCI NIC)  he plugged in will still work after next reboot. It makes no sence what so ever from a users point of view that a device that worked just fine when he plugged it in the first time suddenly stops working just becuse it this time was plugged in already at boottime. Either the drivers are available on the computer and can be autodetected/autoloaded or they can't. Having hot but not coldplug (or vice versa for that matter) just gives inconsistent behaviour.

In short, either you likely want both hot&cold plug, or you probably want neighter. At least I can not even think of any senario where you would not like a previously accessable device to not work depending purely on if it was or wasn't there at booting. Perhaps someone more imaginative then me can think of a when you would want a device to behave this way, but still I'm sure that 99,9% of the time people want & expect a hotplugable device to actually work if it's plugged in (irrespective of the number of reboots since it was plugged in).

To sumarise, there should not be 2 distinctive rc scripts, one each for hot&cold plug, becuse it will only lead to possible inconsistent behaviour for endusers (that fail to read or fully comprehend why they need to add 2 RC scripts for what to them appears as the same thing). Instead there should be one that turns on ADofHW with a setting in rc.conf where the small fragment of users that only want 1 or the other could cater for their specialized needs.

 *Quote:*   

> 
> 
> hotplugging is the DYNAMIC loading and unloading of drivers/modules on the fly. it's not Plug'n'Play
> 
> 

 

Indeed, it's even more P&P then P&P itself...

 *Quote:*   

> 
> 
> and stop whinging because you lost your wobbly hotplug crutch. 
> 
> merge coldplug and get on with your life.  seriously.
> ...

 

Your view on this is purely from the technical user-unfriendly perspective while I try to look at how to make things work in a way that even my mother would understand/find logical. Please realise this difference in point of view instead of resorting to namecalling.

People should not have to learn how to jump through hoops just to get logical behaviour from a computer. Computers & their software should do the jumping to make it intuitive for a human to use them.

Unfortunately way to many Linuxusers are stuck in the "Setting up a computer SHOULD be hard! Logical & userfriendly is for sissies" way of thinking. It's definitly not impossible to combine userfriendly with powerfull & leaving the user in controll (just look at eg Portage).

----------

## gentoo_lan

Why are we debating the merits of hotplug and coldplug in a forum about Kernel and Hardware?  The merits of this should be debated in another section of the forums.

----------

## STEDevil

 *gentoo_lan wrote:*   

> Why are we debating the merits of hotplug and coldplug in a forum about Kernel and Hardware?  The merits of this should be debated in another section of the forums.

 

How is the loading of kernel drivers for hardware not on topic in the Kernel & hardware section?!?!   :Shocked: 

----------

## DLF

 *dirtyepic wrote:*   

>  you don't like having two terms for two completely different concepts?

 

Of course you must see the irony that there are now two different concepts, two different rc scripts but they use the same code!  The common concept is really 'detect thing load stuff'.  Unification will happen again one day, just wait and see.

----------

## Gentree

 *Quote:*   

> People should not have to learn how to jump through hoops just to get logical behaviour from a computer. Computers & their software should do the jumping to make it intuitive for a human to use them.

 

EXACTLY.

I have been "using" Gentoo for about nine months as my main system. It's been a very insteresting and educative experience but if I am realistic I have spent 8 of those 9 months "maintaining" the system not using it.

I now require a system I can use.

I have just WASTED two evenings of my free time working out why I could not print anything.

The bottom line was that portage had pulled in a buggy version of ghostscript and worst of all that this bug had been posted in gentoo.bugzilla.org over six weeks ago!

I should never have encountered this problem.

ghostscript- 7.07.1-r7 is still not masked.

Portage is designed to avoid this sort of problem but is too often failing to do so.

If I compile stable packages it should be just that STABLE.

I currently have four "stable" packages masked and still have some unresolved issues with this system.

I think gentoodevs need to take a step back and take a reality check on what users require from Gentoo.

It has been suggested elsewhere but maybe another "more stable" profile could be added to portage.

Thanks to dsd who has taken a very positive approach to a lot of comments made here. 

I hope some progress can be made: I find it hard to imagine moving to a different distro, Gentoo has a lot going for it. But once I get everything working it will be a long time before I risk updating anything again - like's too short  :Laughing: 

Thanks for listening, back to debugging my Gentoo.  :Cool: 

----------

## chrisstankevitz

 *mc_barron wrote:*   

> A simple update to the world should not break my system this badly!

 

I could not agree more.

----------

## drescherjm

Same has happened to me... I recently did an update world after being disconnected from the internet for about a month and after that I have spent 2 weeks trying to fix the mess it caused. However I do admit I am at fault as quite a few of the packages I have I use the unstable version.

----------

## altstadt

 *altstadt wrote:*   

> Now a question. To migrate over to use the modules.autoload.d files as originally intended, is there some way I can find out what modules the old hotplug is loading at boot?

 

And to answer my own question: do the bleeding obvious.

Install coldplug in boot runlevel.

Edit /etc/init.d/coldplug and add the two calls to lsmod as shown below:

```

start() {

   checkconfig || return 1

   lsmod > /var/log/coldplug.1

   for RC in /etc/hotplug/*.rc

   do

      NAME=`basename $RC .rc`

      ebegin "Coldplugging $NAME devices"

      # We do not want to check the return status, as

      # some of the scripts may fail due to drivers not

      # compiled as modules ...

      $RC start

      eend 0

   done

   lsmod > /var/log/coldplug.2

}

```

Reboot.

diff /var/log/coldplug.*

----------

## Jengu

Everyone is getting a bit too hostile. Deep breaths =)

If you think that users should have had their core hardware listed in a text file somewhere you are completely out of touch with desktop users, and quite a few gentoo users are desktop users. Not everyone who uses gentoo is running a server. Personally, I prefer gentoo over other distributions because portage is the only update/repository mechanism that works for me consistently.

I run gentoo on my laptop, which does not have ssh, apache, ftp, etc. daemons running. My net access with it on the road is limited, and I can't always be carrying a live cd. If something like this breaks my system, and I don't have the linux expertise to fix it, I can be screwed for a long while.

It's all well and good that there is a technical distinction between hotplugging and coldplugging. But the end user doesn't and shouldn't have to care about that technical distinction. Nor is the distinction useful in the world of modern hardware -- the trend is towards making everything hotpluggable. The only possible concern I can see is with security and autoloading of modules, but in that case the sysadmin should be avoiding hotplug and coldplug.

This seems to me to be a clear case of people caring whether or not a name is technically correct over whether or not something works correctly. The latter has always been more important in software design.

I think that gentoo is the best desktop distro if you take the time to set it up. Fedora Core turns on a crapload of services most users will never use. SuSe's mirrors are always giving me trouble, and it's configuration software is extremely bloated. Mandrake's urpmi doesn't treat you well unless you add unofficial mirrors every three seconds.

For all the crap people give gentoo about being hardest to install, it was the first distro where ati's fglrx drivers just worked on my desktop. I got my wireless card on my laptop with a minimum amount of fuss. Installing software is as simple as emerge blah. To ignore gentoo's potential as a desktop distribution by making decisions like this one would be a serious mistake.

The gentoo devs are volunteers. But criticism isn't just hate, it's also useful. Linux developers have a tendency to not realize what is hard for a desktop user and what is not. Threads like this one should help teach them. Hopefully the message isn't lost just because everyone wasn't terribly civil.

I appreciate their work immensely,

Jengu

----------

## Slippery Jim

I want my IDE CD drives and parallel printer to be detected at boot time. I want the correct modules to be selected based on the detected hardware, and I want the modules to be loaded automatically. I also do not want a module to be loaded if hardware for it is not detected, for example because I disconected my IDE CD drive.

Is this possible using the coldplug subsystem?

----------

