Tag Info

New answers tagged

0

You can take a look at how facter does it here. As Jan said, lsb_release is probably the best way to go, but it cannot be your only way. For example, lsb_release is not present by default on any of my RHEL servers: [damaya@damaya-sandbox script]$ lsb_release -bash: lsb_release: command not found [damaya@damaya-sandbox script]$ yum provides "*/lsb_release" ...


1

Most programs and scripts I've seen parse the usual files in /etc, AFAIK there's no other way: On Redhat, look for /etc/redhat-release On Debian, look for /etc/debian_version Mandriva has /etc/version and Slackware has /etc/slackware-version You could also use uname to get the ARCH or, probably the most sane way, use lsb_release.


0

Do you know for certain that your device works with the driver? If so: Firmware Some devices also need additional firmware. Unfortunately, the method needed to extract the firwmware and install it, depends on the device. Some require you to download a copy of the Windows driver and use tools to extract the firmware. Google will help you here. Changed ...


1

I found the files that where blacklisting my module here: /lib/modprobe.d/


1

/etc/modprobe.d/blacklist.conf search in this file for a module name and if it's indeed in there then comment out or delete the string.


1

You're correct about the location of the WARN, this code is from the upstream kernel tag v2.6.38: net/ipv4/tcp_input.c 2953 static void tcp_fastretrans_alert(struct sock *sk, int pkts_acked, int flag) 2954 { ... 2964 if (WARN_ON(!tp->sacked_out && tp->fackets_out)) 2965 tp->fackets_out = 0; 2966 This is discussed ...


7

Because those programs are build to use things defined in the kernel headers: busybox-1.22.1]$ egrep -RHn '^#include <linux' modutils/modutils-24.c:194:#include <linux/elf-em.h> include/fix_u32.h:17:#include <linux/types.h> libbb/loop.c:11:#include <linux/version.h> console-tools/openvt.c:23:#include <linux/vt.h> ...


1

It's possible that the kernel includes support for loop devices, but that the entries in /dev are missing. Check for loop? entries in /sys/class/block. If they're absent, your kernel lacks the loop device driver. If they're present, and /dev is static, then you can create the missing entries with MAKEDEV loop (if available) or with for i in `seq 0 15`; do ...


0

If you look at the output of lsmod it'll typically tell you which modules are loaded due to being a dependency of some other module. For example, in the case of bridge, it looks like stp & llc required it. $ lsmod | grep brid bridge 116006 1 ebtable_broute stp 12868 1 bridge llc 13941 2 stp,bridge ...



Top 50 recent answers are included