[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [pcmcia] ".unconfigured" kills `depmod -a'.



>>>>> "Randolph" == Randolph Chung <tausq@debian.org> writes:

    >> There is a file ".unconfigured" in the PCMCIA modules directory that
    >> causes `depmod -a' to fail, and thus the `modconf' to fail.  Who is
    >> responsible for that file being in there?

    Randolph> boot floppies is. .unconfigured is part of the modules.tgz that we build. 

    Randolph> after you configure pcmcia and activate it, the file is removed. given the
    Randolph> depmod behavior you described below, we probably should remove that file
    Randolph> altogether, or move it to /root/.pcmcia.unconfigured or something like that.

 Yes, that sounds good.  /tmp or /root is a better location for it.

    >> symbol errors.  It may be that the pcmcia modules package I made
    >> didn't really match the kernel-image package I made after
    >> all... (probably).

    Randolph> this is not a modconf problem, this is a packaging problem. I'll talk to
    Randolph> Brian Mays. I think we need a new pcmcia modules package for the new compact
    Randolph> kernel. 

 It's probably MY fault.  I built custom kernel and pcmcia packages
 for installing Internet gateway masq/proxy hosts with... and likely
 didn't get the pcmcia matched to the kernel or something.  (I really
 need no pcmcia for this purpose, but it's built into boot-floppies
 with no option to ommit it right now.)

 No need for a bug report on the official packages unless someone else
 reports it also or something.

    >> Anyway, after that I `rm -rf pcmcia' and ran `depmod -a' agian, then
    >> switched back to vt1 and selected "Configure modules" again.  It
    >> failed again with the same error, "device or resource busy".  I
    >> switched back to vt2, and ran `modprobe ne', and got the same error
    >> again.  (I think I had to use `dmesg' to read the error.)  Now I ran
    >> `modprobe ne io=0x300 irq=10', and it worked.  I had used the same
    >> arguments in `modconf', so all of this leads me to believe that
    >> `modconf' is NOT passing the arguments entered in the dialog box on
    >> to the `modprobe' command it ostensibly executes.  I have NOT looked
    >> to see for myself yet.

    Randolph> There should be a file in /etc/modutils/<module name> (/etc/modutils/ne in
    Randolph> your example) that has the options you entered. is it not there? What does
    Randolph> it say?

  I'm sorry, but I can no longer look.  The machine I installed is
  sitting by the door waiting for pickup tomorrow afternoon.  I
  finished the install and configure by hand so I could get it out the
  door and some cash in my pocket so I can keep my DSL Internet link
  another month.

  I'm a pentium CPU and some EDO RAM away from having another
  machine's worth of parts to assemble.  I've got everything but that.
  Anyone want to loan or donate some parts for me to test on?  I have
  a bin full of several brands of ethernet cards...  on loan from a
  business associate.  My VMware beta trial licence will expire this
  week.

    >> I want it to know that this is an ethernet driver, and that the
    >> arguments I give in the dialog need to be written out to
    >> "/target/etc/modutils/$driver_name" as an "options $driver_name ..."

    Randolph> what does it put there now? 

 ? I will look next time.

    >> line.  Then I want it to write a file called
    >> "/target/etc/modutils/ethernet-aliases", and put "alias eth0
    >> $driver_name" in there.  If I configure a second ethernet card by
    >> inserting another module, I want it to alias that one to "eth1", &c.

    Randolph> please file a wishlist bug against modconf for this.

 Ok... done.

    >> In "/etc/modules", it should put a line in for "eth0", calling it by
    >> the alias, rather than by the $driver_name.  After it finishes, it
    >> needs to call on `update-modules' to build the "/etc/modules.conf"
    >> file.

    Randolph> it *does* call update-modules already.

 Good.

    >> "Configure the Network" already asks you which interface to
    >> configure, I found.  I don't think it loops for the second
    >> interface... (cannot recall if it did.)  It ought to, just as a
    >> convienience.

    Randolph> Karl, most of these are good comments/suggestions, but realistically I'll be
    Randolph> happy if we concentrate on fixing actual *bugs* for now. There are certainly
    Randolph> still bugs in modconf (which, by the way, is separate from boot floppies.
    Randolph> It's not clear from your message if you realize this already). I'll try to
    Randolph> fix bugs as they are filed, but I need more specific info... exact error
    Randolph> messages that you see, etc. 

 I know they are "separately maintained"; but both are in the
 /cvs/debian-boot repository and both are critical elements of our
 installation system.

 Live and learn...  Next time I install a machine like that, I will
 keep a peice of paper or my laptop nearby and take notes, rather than
 trying to get it done in a hurry and reporting problems a day later
 from memory.

    Randolph> At least some of these problems come from the fact that the .unconfigured
    Randolph> file is not removed. There also seems to be a race condition in modconf that
    Randolph> i need to fix (doing that now)

 Ok, good.  Any idea how to fix that change vt and it redisplays on
 the wrong console bug?  I have no way of knowing why it does that...
 Is it for some reason sending output to /dev/console or /dev/tty0
 rather than to /dev/tty1?  The script is not trivial, and I did not
 spend very long on it when I looked at it, to be shamefully honest.


Reply to: