Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 23216 - baselayout file /etc/init.d/modules doesn't check whether /usr is mounted before running module post-install commands
Summary: baselayout file /etc/init.d/modules doesn't check whether /usr is mounted bef...
Status: RESOLVED WORKSFORME
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] baselayout (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-06-21 01:25 UTC by Chris Horler
Modified: 2006-06-25 00:27 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Horler 2003-06-21 01:25:58 UTC
This is the second such type of error of Gentoo depending on /usr being on the root 
partition I've noticed (the first one was catastropic and fixed quickly - by me). 
 
If you have emu10k1 emerged look at /etc/modules.d/emu10k1 you'll notice it calls 
/usr/bin/emu10k1-script.  I don't think this is a bug, but others may disagree. 
 
I believe the correct solution would be to call /etc/init.d/modules twice with a check for 
a mounted /usr, and then make it group the modules according to whether they call 
anything on /usr.  This is one method of ensuring users who need modules to mount 
/usr can continue. 

Reproducible: Always
Steps to Reproduce:
1.  Find a system with /usr on a separate partition 
2.  emerge emu10k1 
3.  boot up and watch for error message about failed to load emu10k1 (it does load 
but fails to run the post-install command. 
4.  Check the post-install command works by running it from the shell when logged in. 
Actual Results:  
emu10k1 reported as failed to load by boot script (not entirely accurate) 
emu10k1 was configured alright from the shell after login. 

Expected Results:  
Not required user interaction.
Comment 1 Martin Schlemmer (RETIRED) gentoo-dev 2003-06-23 00:24:44 UTC
I *think* it will be too much complexity to do it as you suggests.

The better way will be to move the scripts in /usr/bin to /bin.  BTW,
why is these scripts not rather put in sbin ?

Daniel, Mike .. what do you think ?  Could we move it to /bin (or /sbin rather) ?
Comment 2 SpanKY gentoo-dev 2003-06-23 15:32:39 UTC
i dont think it would be a good idea to move said script into /bin or /sbin ... 
 
those dirs really should be reserved for needed system files ... files that you need to 
recover from a failure of some sort ... 
 
a different solution might be to categorize modules the same way we have /sbin and 
/usr/sbin ... some modules are needed for proper bootup of a system while others are 
just nice to have (like emu10k1) ... 
Comment 3 Martin Schlemmer (RETIRED) gentoo-dev 2003-06-23 16:19:24 UTC
This is the sort of complexity I wanted to avoid.
Comment 4 SpanKY gentoo-dev 2003-06-23 16:36:03 UTC
welp if emu10k1 is the *only* module that does this ... you'd have to move most of its 
binaries/scripts ... 
 
i still dont like it but you're right, it would lead to a lot of complexity ... 
Comment 5 Martin Schlemmer (RETIRED) gentoo-dev 2003-06-30 14:54:00 UTC
Erm, does /usr/bin/emu10k1-script call any other scripts ?  If not, then
only it could be moved ?
Comment 6 Martin Schlemmer (RETIRED) gentoo-dev 2003-07-17 12:56:38 UTC
And?
Comment 7 Aron Griffis (RETIRED) gentoo-dev 2004-10-25 14:30:26 UTC
Why not just package an init-script with emu10k1 that loads its module?  Don't put emu10k1 in modules.autoload and we should be golden, right?
Comment 8 Jakub Moc (RETIRED) gentoo-dev 2006-05-29 18:50:13 UTC
emu10k1 has been long time obsolete and removed one year ago... About time to close this irrelevant bug.
Comment 9 SpanKY gentoo-dev 2006-06-25 00:27:36 UTC
this bug is not "irrelevant", it's just a pain

i'm content with saying "dont make modules utilize /usr" for now