0. first I tried ChrUbuntu - it installed a 64-bit environment with
kernel 3.13, but the system had problems resuming from sleep.
1. install Bodhi Linux with E17 from here:
http://jeffhoogland.blogspot.cz/2014/01/howto-bodhi-linux-on-acer-c720.html
(this installs a 32-bit environment with kernel 3.11 and a slightly outdated
Bodhi Linux based on Ubuntu 12.04 -- however, it has one big advantage:
IT WORKS)
2. to prevent packet loss, I had to disable hardware encryption in the ath9k
driver based on advice from here:
http://crunchbang.org/forums/viewtopic.php?id=35160
- create a file: /etc/modprobe.d/ath9k.conf
- enter the following into that file: options ath9k nohwcrypt=1
- reboot
Showing posts with label hardware. Show all posts
Showing posts with label hardware. Show all posts
2014-07-07
Hardware notes: Acer C720 Chromebook
To get Linux running on the Acer C720 Chromebook, I had to do the following:
2013-10-31
2013-02-24
How to write UDEV rules
No, I'm not an expert on this topic. But if you wanted to become one, this page seems like a good place to start:
"Writing udev rules" by Daniel Drake
"Writing udev rules" by Daniel Drake
2012-11-17
Linux: How to identify installed hardware
Studying for the LPI Certification (Level 1), one of the first things you learn is how to identify hardware in a running Linux system.
From a high-level perspective, there are two basic views of the hardware: yours, and the computer's. It's good to keep in mind that these two views can and often are very different. In this case, when we say "the computer", we mean the kernel, because it is the kernel's job to interface between the software and the hardware, via device drivers. The kernel always maintains a clear picture of what hardware it thinks is installed.
What tools does the system administrator have to find out what hardware the kernel thinks is installed? There are several. Far and away the most user-friendly of these are kinfocenter in KDE and 'hardinfo' in Gnome. These tools, however, are available only if a desktop environment is installed, which on servers is usually not the case.
Without a desktop environment, you have to rely on the lower-level (i.e. command-line) tools. On openSUSE, for example, there is 'hwinfo' (see the intro for details). One particularly useful example:
For a more detailed overview, see HowToIdentifyADevice on the Debian Wiki.
The following area is reserved for future notes on the various command-line tools:
These are virtual files in the
Most Linux distributions these days have more-or-less a single kernel which is used for large swathes of users. The installation app probes the hardware and attempts to install all the drivers automatically. In such environments, the drivers take the form of kernel modules. Looking at what modules have been loaded into the kernel can be very useful when troubleshooting hardware issues:
From a high-level perspective, there are two basic views of the hardware: yours, and the computer's. It's good to keep in mind that these two views can and often are very different. In this case, when we say "the computer", we mean the kernel, because it is the kernel's job to interface between the software and the hardware, via device drivers. The kernel always maintains a clear picture of what hardware it thinks is installed.
What tools does the system administrator have to find out what hardware the kernel thinks is installed? There are several. Far and away the most user-friendly of these are kinfocenter in KDE and 'hardinfo' in Gnome. These tools, however, are available only if a desktop environment is installed, which on servers is usually not the case.
Without a desktop environment, you have to rely on the lower-level (i.e. command-line) tools. On openSUSE, for example, there is 'hwinfo' (see the intro for details). One particularly useful example:
# hwinfo --disk 17: IDE 00.0: 10600 Disk [Created at block.245] Unique ID: 3OOL.1NQWI8jrVC4 ... [output truncated]
For a more detailed overview, see HowToIdentifyADevice on the Debian Wiki.
The following area is reserved for future notes on the various command-line tools:
/proc/interrupts /proc/dma /proc/ioports
These are virtual files in the
/proc hierarchy, accessible using cat. They provide a low-level view of the hardware.lsusb lsusb -t
lsdev lspci lspci -t
Most Linux distributions these days have more-or-less a single kernel which is used for large swathes of users. The installation app probes the hardware and attempts to install all the drivers automatically. In such environments, the drivers take the form of kernel modules. Looking at what modules have been loaded into the kernel can be very useful when troubleshooting hardware issues:
lsmod insmod modprobe modprobe -v rmmod modprobe -r modinfo
2011-12-27
udev[566]: renamed network interface eth0 to eth3
This came up when I moved a disk containing an existing Debian 6.0 installation to a different machine. The original machine had two NICs and at one point I had tried a third. At boot-time, udev looked for the MAC addresses of these three NICs, but didn't find them. Instead, it found a *fourth* (the integral NIC in the new machine). Since it already had MAC addresses registered for eth0, eth1, and eth2, it went on to register the NIC to the next number in line (eth3).
Now, in my case, this is not really desirable. I'd rather have udev forget the old NICs and assign the new NIC to eth0.
Here's how to do it. Whenever udev detects a new NIC, it writes an entry to /etc/udev/rules.d/70-persistent-net.rules. So, edit that file, deleting the old, stale entries and leaving the latest one (as eth0).
(This works on Debian and openSUSE, and presumably on all other modern Linuxes.)
Subscribe to:
Posts (Atom)