I've just pushed biosdevname-0.3.1 into rawhide. This is not yet installed by default as part of @base, nor is it used by anaconda, but those changes will come over the next few days.
biosdevname, on at least Dell 10G and newer, and HP 6G and newer servers, provides "better" BIOS-suggested names for embedded NIC ports, and NIC ports on add-in PCI cards. If you have existing names, as defined in /etc/udev/rules.d/70-persistent-net.rules, those names will continue to be used, and biosdevname won't ever be invoked. Likewise, if you have device names assigned to MAC addresses in /etc/sysconfig/network-scripts/ifcfg-eth*, biosdevname won't be invoked. But going forward, on new installs, biosdevname _will_ be used to change the names.
The naming scheme is thus:
Embedded ports: em<port> PCI cards: pci<slot>#<port>_<virtual function> (the latter on SR-IOV and soon Network Partitioned (NPAR) devices).
If you have a Dell or HP server, and would like to try it out, please: # yum install biosdevname # rm /etc/udev/rules.d/70-persistent-net.rules # sed -i -e '/^HWADDR=/d' /etc/sysconfig/network-scripts/ifcfg-eth* # rmmod <your ethernet drivers> # modprobe <your ethernet drivers> (or reboot instead)
# ifconfig -a will show all the devices with the new naming scheme.
Thanks, Matt
On Mon, Nov 29, 2010 at 12:17:22AM -0600, Matt Domsch wrote:
I've just pushed biosdevname-0.3.1 into rawhide. This is not yet installed by default as part of @base, nor is it used by anaconda, but those changes will come over the next few days.
I've pushed the comps change to pull biosdevname into @base by default. And I've posted a patch to anaconda-devel-list to pull biosdevname into the installtime environment. Cross your fingers, this is gonna be great!
Thanks, Matt
On 11/29/2010 08:27 PM, Matt Domsch wrote:
On Mon, Nov 29, 2010 at 12:17:22AM -0600, Matt Domsch wrote:
I've just pushed biosdevname-0.3.1 into rawhide. This is not yet installed by default as part of @base, nor is it used by anaconda, but those changes will come over the next few days.
I've pushed the comps change to pull biosdevname into @base by default. And I've posted a patch to anaconda-devel-list to pull biosdevname into the installtime environment. Cross your fingers, this is gonna be great!
Can you expand the release notes section of
http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming
Please include the benefits in that.
Rahul
On Mon, Nov 29, 2010 at 08:48:05PM +0530, Rahul Sundaram wrote:
On 11/29/2010 08:27 PM, Matt Domsch wrote:
On Mon, Nov 29, 2010 at 12:17:22AM -0600, Matt Domsch wrote:
I've just pushed biosdevname-0.3.1 into rawhide. This is not yet installed by default as part of @base, nor is it used by anaconda, but those changes will come over the next few days.
I've pushed the comps change to pull biosdevname into @base by default. And I've posted a patch to anaconda-devel-list to pull biosdevname into the installtime environment. Cross your fingers, this is gonna be great!
Can you expand the release notes section of
http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming
Please include the benefits in that.
Done.
On 12/01/2010 12:34 AM, Matt Domsch wrote:
Can you expand the release notes section of http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming
Please include the benefits in that.
Done.
Can you explain why only those particular HP and Dell models are affected by this change? Is there more models expected to adopt this change?
Rahul
On Wed, Dec 01, 2010 at 02:37:04AM +0530, Rahul Sundaram wrote:
On 12/01/2010 12:34 AM, Matt Domsch wrote:
Can you expand the release notes section of
[1]http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming
Please include the benefits in that.
Done.
Can you explain why only those particular HP and Dell models are affected by this change?* Is there more models expected to adopt this change?*
It requires BIOS to expose the information the tool uses (SMBIOS 2.6, or HP's proprietary method). I know recent Dell and HP servers do, I'm not aware of any others at this time, nor do I have visibility into the plans of other vendors. I don't expect desktops to expose this information - they have only 1 NIC.
Matt Domsch wrote:
I don't expect desktops to expose this information - they have only 1 NIC.
Many desktops have dual-NICs. I'm typing from an SMBIOS 2.6 ASUS desktop motherboard with dual-NICs.
Handle 0x002D, DMI type 10, 6 bytes On Board Device Information Type: Ethernet Status: Enabled Description: Onboard Ethernet
Handle 0x003D, DMI type 41, 11 bytes Onboard Device Reference Designation: Onboard Ethernet Type: Ethernet Status: Enabled Type Instance: 0
Will my network interface names change with this feature or is this purely for Dell/HP only? I'm a bit confused by the verbage on the wiki page and the part about SMBIOS 2.6.
On Tue, Nov 30, 2010 at 04:18:10PM -0600, Michael Cronenworth wrote:
Matt Domsch wrote:
I don't expect desktops to expose this information - they have only 1 NIC.
Many desktops have dual-NICs. I'm typing from an SMBIOS 2.6 ASUS desktop motherboard with dual-NICs.
Handle 0x002D, DMI type 10, 6 bytes On Board Device Information Type: Ethernet Status: Enabled Description: Onboard Ethernet
Handle 0x003D, DMI type 41, 11 bytes Onboard Device Reference Designation: Onboard Ethernet Type: Ethernet Status: Enabled Type Instance: 0
This is the interesting field. Type 41 obsoletes Type 10, and adds the Type Instance field.
Will my network interface names change with this feature or is this purely for Dell/HP only? I'm a bit confused by the verbage on the wiki page and the part about SMBIOS 2.6.
Yes, your system, on new install, or if you delete /etc/udev/rules.d/70-persistent-net.rules and the HWADDR lines from /etc/sysconfig/network-scripts/ifcfg-*, will then use the new names.
On Tue, Nov 30, 2010 at 04:22:54PM -0600, Matt Domsch wrote:
On Tue, Nov 30, 2010 at 04:18:10PM -0600, Michael Cronenworth wrote:
Matt Domsch wrote:
I don't expect desktops to expose this information - they have only 1 NIC.
Many desktops have dual-NICs. I'm typing from an SMBIOS 2.6 ASUS desktop motherboard with dual-NICs.
Handle 0x002D, DMI type 10, 6 bytes On Board Device Information Type: Ethernet Status: Enabled Description: Onboard Ethernet
Handle 0x003D, DMI type 41, 11 bytes Onboard Device Reference Designation: Onboard Ethernet Type: Ethernet Status: Enabled Type Instance: 0
This is the interesting field. Type 41 obsoletes Type 10, and adds the Type Instance field.
Will my network interface names change with this feature or is this purely for Dell/HP only? I'm a bit confused by the verbage on the wiki page and the part about SMBIOS 2.6.
Yes, your system, on new install, or if you delete /etc/udev/rules.d/70-persistent-net.rules and the HWADDR lines from /etc/sysconfig/network-scripts/ifcfg-*, will then use the new names.
specifically, em0 for the above device, and em<Type Instance> for the second NIC specified in SMBIOS...
Matt Domsch wrote:
Yes, your system, on new install, or if you delete /etc/udev/rules.d/70-persistent-net.rules and the HWADDR lines from /etc/sysconfig/network-scripts/ifcfg-*, will then use the new names.
specifically, em0 for the above device, and em<Type Instance> for the second NIC specified in SMBIOS...
OK. Perhaps the wiki should be updated to state the feature works more generically (SMBIOS 2.6+) and not for just Dell/HP systems?
Interesting work, Matt. I'm surprised the Unix purists who would fight you to death to keep sendmail on desktops would allow you to change the almighty eth* naming scheme.
On Tue, Nov 30, 2010 at 04:29:32PM -0600, Michael Cronenworth wrote:
Matt Domsch wrote:
Yes, your system, on new install, or if you delete /etc/udev/rules.d/70-persistent-net.rules and the HWADDR lines from /etc/sysconfig/network-scripts/ifcfg-*, will then use the new names.
specifically, em0 for the above device, and em<Type Instance> for the second NIC specified in SMBIOS...
OK. Perhaps the wiki should be updated to state the feature works more generically (SMBIOS 2.6+) and not for just Dell/HP systems?
I've done so now.
Interesting work, Matt. I'm surprised the Unix purists who would fight you to death to keep sendmail on desktops would allow you to change the almighty eth* naming scheme.
I've caught flack for years - that's why this is just now happening. The previous released version of biosdevname was over 3 years ago - the pushback was against changing the eth* naming scheme. But there's no other way to do it. I wish there was.
On Nov 30, 2010, at 4:34 PM, Matt Domsch wrote:
On Tue, Nov 30, 2010 at 04:29:32PM -0600, Michael Cronenworth wrote:
Matt Domsch wrote:
Yes, your system, on new install, or if you delete /etc/udev/rules.d/70-persistent-net.rules and the HWADDR lines from /etc/sysconfig/network-scripts/ifcfg-*, will then use the new names.
specifically, em0 for the above device, and em<Type Instance> for the second NIC specified in SMBIOS...
OK. Perhaps the wiki should be updated to state the feature works more generically (SMBIOS 2.6+) and not for just Dell/HP systems?
I've done so now.
Interesting work, Matt. I'm surprised the Unix purists who would fight you to death to keep sendmail on desktops would allow you to change the almighty eth* naming scheme.
I've caught flack for years - that's why this is just now happening. The previous released version of biosdevname was over 3 years ago - the pushback was against changing the eth* naming scheme. But there's no other way to do it. I wish there was.
As someone who deals with HP DL580 boxes with 6+ NICs routinely, this is good stuff. Deterministic naming of the built in NICs will simplify installation instructions for us.
Are the internal names going to be lomX or emX?
joe
On Tue, Nov 30, 2010 at 06:36:17PM -0600, Joe Nall wrote:
As someone who deals with HP DL580 boxes with 6+ NICs routinely, this is good stuff. Deterministic naming of the built in NICs will simplify installation instructions for us.
Thanks for the good word!
Are the internal names going to be lomX or emX?
embedded NICs are emX Add-in cards are pci<slot>#<port>
in both cases, if the device is an SR-IOV NIC, it will append _<vf> to the name for each virtual function.
Now, oddly, I don't have a lot of HP gear handy - especially not a Flex10. If someone does, I'd love to know how to tell the various partitions of a Flex10 are on the same port, so we can append _<flex10-instance> similar to SR-IOV. I'm asking the same of Broadcom who just published an update to handle NPAR for their 57712 driver to netdev over the weekend.
Than
Michael Cronenworth mike@cchtml.com wrote:
Interesting work, Matt. I'm surprised the Unix purists who would fight you to death to keep sendmail on desktops would allow you to change the almighty eth* naming scheme.
Why? FreeBSD (and other BSDs, I'm sure) have been naming network interfaces based on the manufacturer, at least, for a while now (I personally started with 7.x and am unsure of when that was new). I was always curious why eth* was used on Linux actually.
--Ben
Hi.
On Wed, 1 Dec 2010 01:33:33 +0000 (UTC), Ben Boeckel wrote:
Why? FreeBSD (and other BSDs, I'm sure) have been naming network interfaces based on the manufacturer, at least, for a while now (I personally started with 7.x and am unsure of when that was new). I was always curious why eth* was used on Linux actually.
And I always thought that this was a pretty weird way to do things, after all, why does the userspace care who made which network card?
I think I can live with the biosdevname stuff, though, after all it distinguishes by physical position (which as meaning) instead of vendor (which does not).
On 12/01/2010 07:55 AM, Ralf Ertzinger wrote:
Hi.
On Wed, 1 Dec 2010 01:33:33 +0000 (UTC), Ben Boeckel wrote:
Why? FreeBSD (and other BSDs, I'm sure) have been naming network interfaces based on the manufacturer, at least, for a while now (I personally started with 7.x and am unsure of when that was new). I was always curious why eth* was used on Linux actually.
And I always thought that this was a pretty weird way to do things, after all, why does the userspace care who made which network card?
I think I can live with the biosdevname stuff, though, after all it distinguishes by physical position (which as meaning) instead of vendor (which does not).
Yes indeed thank you!!
I have always found it weird whenever I upgraded a NIC on my firewall, that I had to hand edit the udev rules to keep the firewall rules sane. Having the name associated with the physical location is great.
Now I can change NIC cards and not have to worry the firewall rules will turn the DMZ into the internal side .. :-)
Thank you!!
On Tue, 2010-11-30 at 16:29 -0600, Michael Cronenworth wrote:
Matt Domsch wrote:
Yes, your system, on new install, or if you delete /etc/udev/rules.d/70-persistent-net.rules and the HWADDR lines from /etc/sysconfig/network-scripts/ifcfg-*, will then use the new names.
specifically, em0 for the above device, and em<Type Instance> for the second NIC specified in SMBIOS...
OK. Perhaps the wiki should be updated to state the feature works more generically (SMBIOS 2.6+) and not for just Dell/HP systems?
+1
And also, I'd love to see fewer attacks on Dell here. Matt is doing good work that is generic and uses open standards that can be implemented by many vendors. The fact that some have yet to move on SMBIOS struct type additions reflects on them alone.
Interesting work, Matt. I'm surprised the Unix purists who would fight you to death to keep sendmail on desktops would allow you to change the almighty eth* naming scheme.
Because it makes *sense* and is in keeping with UNIX tradition on many systems. I'm all for making all manner of changes when there is a justification that is rationalized and the benefits can be explained. When it's hand wavy "this is good" type stuff, I feel different :)
Jon.
On 12/01/2010 01:50 PM, Jon Masters wrote:
On Tue, 2010-11-30 at 16:29 -0600, Michael Cronenworth wrote:
OK. Perhaps the wiki should be updated to state the feature works more generically (SMBIOS 2.6+) and not for just Dell/HP systems?
+1
And also, I'd love to see fewer attacks on Dell here.
Can you point out a single attack on Dell in this entire conversation?
Rahul
On Wed, 2010-12-01 at 14:04 +0530, Rahul Sundaram wrote:
On 12/01/2010 01:50 PM, Jon Masters wrote:
On Tue, 2010-11-30 at 16:29 -0600, Michael Cronenworth wrote:
OK. Perhaps the wiki should be updated to state the feature works more generically (SMBIOS 2.6+) and not for just Dell/HP systems?
+1
And also, I'd love to see fewer attacks on Dell here.
Can you point out a single attack on Dell in this entire conversation?
I think I miss-read the tone of Michael's reply on custom Dell bits. Apologies, I don't think there's any attack there.
But while I'm mailing, I'd like to thank Matt for getting this done (esp. the heavy lifting with standards, etc.). It won't help on my little netbook, but it will help on bigger systems (especially many identical systems with hotswap disks that you want to just work).
Jon.
On Tue, Nov 30, 2010 at 04:29:32PM -0600, Michael Cronenworth wrote:
Interesting work, Matt. I'm surprised the Unix purists who would fight you to death to keep sendmail on desktops would allow you to change the almighty eth* naming scheme.
Because it's not so almighty. In BSD-land, including Solaris, the devices are named after the driver, so you get /dev/sis0 and /dev/bge1 and /dev/e1000g0 and whatnot.
Really, despite your insinuation, the people who urge caution on changes to the system are generally doing so based on meaningful experience, not reactionaryism.
On 12/01/2010 10:13 AM, Matthew Miller wrote:
Because it's not so almighty. In BSD-land, including Solaris, the devices are named after the driver, so you get /dev/sis0 and /dev/bge1 and /dev/e1000g0 and whatnot.
That BSD scheme suffers the same pitfalls as the current fedora scheme - change hardware and if its not same driver your firewall breaks.
I like the biosdevname approach better - at least if I understand it correctly.
gene
On 11/30/2010 05:24 PM, Matt Domsch wrote:
On Tue, Nov 30, 2010 at 04:22:54PM -0600, Matt Domsch wrote:
On Tue, Nov 30, 2010 at 04:18:10PM -0600, Michael Cronenworth wrote:
Many desktops have dual-NICs. I'm typing from an SMBIOS 2.6 ASUS desktop motherboard with dual-NICs.
Handle 0x002D, DMI type 10, 6 bytes On Board Device Information Type: Ethernet Status: Enabled Description: Onboard Ethernet
Handle 0x003D, DMI type 41, 11 bytes Onboard Device Reference Designation: Onboard Ethernet Type: Ethernet Status: Enabled Type Instance: 0
^^^^^
specifically, em0 for the above device, and em<Type Instance> for the second NIC specified in SMBIOS...
Huh? so the first device (handle 2D) will be called 'em0' and the second device (handle 3D) will be also called 'em0'?
On Wed, Dec 01, 2010 at 01:18:09PM -0500, Przemek Klosowski wrote:
On 11/30/2010 05:24 PM, Matt Domsch wrote:
On Tue, Nov 30, 2010 at 04:22:54PM -0600, Matt Domsch wrote:
On Tue, Nov 30, 2010 at 04:18:10PM -0600, Michael Cronenworth wrote:
Many desktops have dual-NICs. I'm typing from an SMBIOS 2.6 ASUS desktop motherboard with dual-NICs.
Handle 0x002D, DMI type 10, 6 bytes On Board Device Information Type: Ethernet Status: Enabled Description: Onboard Ethernet
Handle 0x003D, DMI type 41, 11 bytes Onboard Device Reference Designation: Onboard Ethernet Type: Ethernet Status: Enabled Type Instance: 0
^^^^^specifically, em0 for the above device, and em<Type Instance> for the second NIC specified in SMBIOS...
Huh? so the first device (handle 2D) will be called 'em0' and the second device (handle 3D) will be also called 'em0'?
No. Handle 2D and handle 3D are the same object fundamentally. Type 41 obsoleted Type 10 and subsumed all its information, adding more and making it extensable. BIOS is encouraged to present both so that legacy OSs that don't know about Type 41 still continue to work, albeit without the new information Type 41 provides.
This one device will only appear as em0.
Thanks, Matt
On 11/30/2010 01:12 PM, Matt Domsch wrote:
I don't expect desktops to expose this information - they have only 1 NIC.
There are 2 built-in NIC ports on at least a couple ASUS and Gigabyte motherboards that have been sold into the "desktop" market in the last couple years. My desktops also have 2 NIC because I installed a better NIC on a PCIe card.
--
Good day,
Am Dienstag, den 30.11.2010, 13:04 -0600 schrieb Matt Domsch:
On Mon, Nov 29, 2010 at 08:48:05PM +0530, Rahul Sundaram wrote:
On 11/29/2010 08:27 PM, Matt Domsch wrote:
On Mon, Nov 29, 2010 at 12:17:22AM -0600, Matt Domsch wrote:
I've just pushed biosdevname-0.3.1 into rawhide. This is not yet installed by default as part of @base, nor is it used by anaconda, but those changes will come over the next few days.
I've pushed the comps change to pull biosdevname into @base by default. And I've posted a patch to anaconda-devel-list to pull biosdevname into the installtime environment. Cross your fingers, this is gonna be great!
Can you expand the release notes section of
http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming
Please include the benefits in that.
Done.
I was curious and ran $ sudo biosdevname -i wlan0 em1
Does that mean that my wlan0 device would be named em1 when installing - lets say - F15? If so, this change would affect many users I suppose.
Could you clarify what hardware is affected and what devices will get different names?
- fabian
On Tue, Nov 30, 2010 at 10:13:30PM +0100, Fabian Deutsch wrote:
Good day,
Am Dienstag, den 30.11.2010, 13:04 -0600 schrieb Matt Domsch:
On Mon, Nov 29, 2010 at 08:48:05PM +0530, Rahul Sundaram wrote:
On 11/29/2010 08:27 PM, Matt Domsch wrote:
On Mon, Nov 29, 2010 at 12:17:22AM -0600, Matt Domsch wrote:
I've just pushed biosdevname-0.3.1 into rawhide. This is not yet installed by default as part of @base, nor is it used by anaconda, but those changes will come over the next few days.
I've pushed the comps change to pull biosdevname into @base by default. And I've posted a patch to anaconda-devel-list to pull biosdevname into the installtime environment. Cross your fingers, this is gonna be great!
Can you expand the release notes section of
http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming
Please include the benefits in that.
Done.
I was curious and ran $ sudo biosdevname -i wlan0 em1
Does that mean that my wlan0 device would be named em1 when installing - lets say - F15? If so, this change would affect many users I suppose.
Could you clarify what hardware is affected and what devices will get different names?
Can I get a dmidecode dump? Curious... That could be hitting a legacy codepath that I need to delete (looking up the value in the PCI IRQ Routing Table). My intention is to only report for devices that the BIOS explicitly exposes via SMBIOS, or in future, ACPI.
Thanks, Matt
On Tue, Nov 30, 2010 at 10:13:30PM +0100, Fabian Deutsch wrote:
Good day,
Am Dienstag, den 30.11.2010, 13:04 -0600 schrieb Matt Domsch:
On Mon, Nov 29, 2010 at 08:48:05PM +0530, Rahul Sundaram wrote:
On 11/29/2010 08:27 PM, Matt Domsch wrote:
On Mon, Nov 29, 2010 at 12:17:22AM -0600, Matt Domsch wrote:
I've just pushed biosdevname-0.3.1 into rawhide. This is not yet installed by default as part of @base, nor is it used by anaconda, but those changes will come over the next few days.
I've pushed the comps change to pull biosdevname into @base by default. And I've posted a patch to anaconda-devel-list to pull biosdevname into the installtime environment. Cross your fingers, this is gonna be great!
Can you expand the release notes section of
http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming
Please include the benefits in that.
Done.
I was curious and ran $ sudo biosdevname -i wlan0 em1
Does that mean that my wlan0 device would be named em1 when installing - lets say - F15? If so, this change would affect many users I suppose.
Could you clarify what hardware is affected and what devices will get different names?
In your case, system BIOS reports the device in SMBIOS, where biosdevname finds it. Now, it marks it as type "Other", when biosdevname should ignore (it should look for type "Ethernet") - I think that's a bug in biosdevname, so I'll investigate.
Thanks, Matt
On Tue, Nov 30, 2010 at 04:11:52PM -0600, Matt Domsch wrote:
On Tue, Nov 30, 2010 at 10:13:30PM +0100, Fabian Deutsch wrote:
Good day,
Am Dienstag, den 30.11.2010, 13:04 -0600 schrieb Matt Domsch:
On Mon, Nov 29, 2010 at 08:48:05PM +0530, Rahul Sundaram wrote:
On 11/29/2010 08:27 PM, Matt Domsch wrote:
On Mon, Nov 29, 2010 at 12:17:22AM -0600, Matt Domsch wrote:
I've just pushed biosdevname-0.3.1 into rawhide. This is not yet installed by default as part of @base, nor is it used by anaconda, but those changes will come over the next few days.
I've pushed the comps change to pull biosdevname into @base by default. And I've posted a patch to anaconda-devel-list to pull biosdevname into the installtime environment. Cross your fingers, this is gonna be great!
Can you expand the release notes section of
http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming
Please include the benefits in that.
Done.
I was curious and ran $ sudo biosdevname -i wlan0 em1
Does that mean that my wlan0 device would be named em1 when installing - lets say - F15? If so, this change would affect many users I suppose.
Could you clarify what hardware is affected and what devices will get different names?
In your case, system BIOS reports the device in SMBIOS, where biosdevname finds it. Now, it marks it as type "Other", when biosdevname should ignore (it should look for type "Ethernet") - I think that's a bug in biosdevname, so I'll investigate.
In the case of wireless drivers, the current biosdevname RPM includes udev rules that only invoke biosdevname if the kernel names the network device "eth*". Therefore, since the wireless driver named this device "wlan0", udev won't ever invoke biosdevname, and therefore the name will remain "wlan0".
Thanks, Matt
Matt Domsch wrote:
I've pushed the comps change to pull biosdevname into @base by default. And I've posted a patch to anaconda-devel-list to pull biosdevname into the installtime environment. Cross your fingers, this is gonna be great!
Could anaconda not be smart enough to pull this in to only Dell and HP systems? Is there a reason all users need a new package for only a handful of hardware that can use it?
Not that I am attempting to downplay your work, I just wish to understand why all my systems keep getting Dell packages (yum plugin) when I don't own any Dell systems.
On Tue, Nov 30, 2010 at 03:25:45PM -0600, Michael Cronenworth wrote:
Matt Domsch wrote:
I've pushed the comps change to pull biosdevname into @base by default. And I've posted a patch to anaconda-devel-list to pull biosdevname into the installtime environment. Cross your fingers, this is gonna be great!
Could anaconda not be smart enough to pull this in to only Dell and HP systems? Is there a reason all users need a new package for only a handful of hardware that can use it?
Not that I am attempting to downplay your work, I just wish to understand why all my systems keep getting Dell packages (yum plugin) when I don't own any Dell systems.
I fixed the yum plugin bit, so that only gets pulled in (on new installs) if you explicitly install firmware-addon-dell. Before it was part of libsmbios, which was pulled in by hal, so was on everyone's system, but that wasn't intentional.
There's no way in rpm/yum/anaconda to specify installing packages by hardware type. That I know of at least...
devel@lists.stg.fedoraproject.org
-
Ben Boeckel -
Fabian Deutsch -
Genes MailLists -
Joe Nall -
John Reiser -
Jon Masters -
Matt Domsch -
Matthew Miller -
Michael Cronenworth -
Przemek Klosowski -
Rahul Sundaram -
Ralf Ertzinger