[26203] in Source-Commits
Re: /svn/athena r25452 - trunk/debathena/scripts/installer/pxe/natty/debathena
daemon@ATHENA.MIT.EDU (Jonathan Reed)
Thu Feb 16 15:49:26 2012
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Jonathan Reed <jdreed@MIT.EDU>
In-Reply-To: <alpine.GSO.1.10.1202161529070.26794@multics.mit.edu>
Date: Thu, 16 Feb 2012 15:49:24 -0500
Cc: source-commits@MIT.EDU
Message-Id: <E6E4E47A-A979-45A8-B1DC-31C4619C8910@MIT.EDU>
To: Benjamin Kaduk <kaduk@MIT.EDU>
Content-Transfer-Encoding: 8bit
The directory has files in it that have in them the filenames the driver thinks it wants. So, for example, the driver wants /lib/firmware/rtl_nic/rtl8168d-1.fw so the path that exists is /dev/.udev/firmware-missing/rtl_nic\x2frtl8168d-1.fw.
It's possible that we should change this to only remove the Realtek firmware, since I test for the r8169 module. OTOH, the PXE installer is never guaranteed to work with not-cluster hardware. Also, note that this only affects the installer environment, not the target system. So it's more of a "You have a Realtek card and a device that requires firmware AND that device needs to be up and running during the install".
Let me think harder about this and also take another look at the directory structure when I'm in front of a machine.
-Jon
On Feb 16, 2012, at 3:30 PM, Benjamin Kaduk wrote:
> On Wed, 15 Feb 2012, Jonathan D Reed wrote:
>
>> Author: jdreed
>> Date: 2012-02-15 13:13:53 -0500 (Wed, 15 Feb 2012)
>> New Revision: 25452
>>
>> Modified:
>> trunk/debathena/scripts/installer/pxe/natty/debathena/installer.sh
>> Log:
>> A better solution for the Vostro/r8169 problem.
>>
>> Modified: trunk/debathena/scripts/installer/pxe/natty/debathena/installer.sh
>> ===================================================================
>> --- trunk/debathena/scripts/installer/pxe/natty/debathena/installer.sh 2012-02-14 21:34:55 UTC (rev 25451)
>> +++ trunk/debathena/scripts/installer/pxe/natty/debathena/installer.sh 2012-02-15 18:13:53 UTC (rev 25452)
>> @@ -1,9 +1,15 @@
>> #!/bin/sh
>>
>> -# Live Poultry Fresh Killed
>> -if grep -q "^Vostro 320" /sys/class/dmi/id/product_name; then
>> - echo "Scribbling over check-missing-firmware"
>> - echo > /bin/check-missing-firmware
>> +# Sigh. check-missing-firmware is too stupid to reconfigure the NIC after
>> +# removing and reloading the module. So we lose network in the middle
>> +# of the install. The card works just fine without firmware, so we
>> +# just convince hwdetect and friends that there is no missing firmware.
>> +# NOTE: Although the nic-firmware udeb does not include the Realtek
>> +# firmware, shipping the firmware ourselves does not fix the problem,
>> +# because check-missing-firmware still insists on reloading the module
>> +# and we lose the network configuration.
>> +if grep -q "^Vostro 320" /sys/class/dmi/id/product_name || lsmod | grep -q r8169; then
>> + rm -f /dev/.udev/firmware-missing/*
>
> Not having one of these hardwares on me, what does that directory structure look like? Are the files within it empty or do they contain content?
> (I worry that someone could get screwed over if they have a realtek nic and say a video card that actually needs firmware.)
>
> -Ben
