Weblogs for mcortese

Posted by mcortese on Tue 17 Apr 2012 at 15:02
Tags: none.
It is amazing to count the number of substitutions and expansions that the PS1 variable undergoes before Bash splits it out as a prompt. Besides the documented 1-letter codes like \h or \w, and the general variable expansion like $EUID or even $?, I've recently learned that arithmetic expansion is possible as well.

The following code produces a green prompt in normal cases, which turns to red when the last command returned a non-zero code:

PS1='\[\e[$(($? ? 31 : 32))m\]whatever you want\[\e[39m\]'

How does it work? You should recognize the arithmetic expansion $(( ... )). Inside that, $? stands for the return code of the last command, and the construct expr ? expr-then : expr-else works like in C. So the whole arithmetic clause is evaluated as either 31 (if the return code is anything but zero) or 32 (if the return code is zero).

Now the sequence ESC[31m happens to be interpreted by the terminal as 'switch to red ink', while ESC[32m means 'switch to green ink'. That's it.

A complete example is then:

PS1='\[\e[$(($??31:32))m\]$? \w\[\e[39m\]: '


Posted by mcortese on Mon 18 Jul 2011 at 14:06
Tags: none.

As I posted in another weblog entry, I'm experiencing a curious shortage of entropy in my system. The one feature that constantly drains the pool is the address space layout randomization (ASLR), coupled with a unique choice of drivers (e.g. the ethernet adapter) that do not contribute any random data to the kernel. Forgetting the latter issue, for which I've laready worked out a patch, I'd like to focus on the ASLR topic.

My first reaction was of disbelief: is it possible that an apparently harmless feature, that has presumably received extensive scrutiny, is able to do so much damage? To answer this question, I made up a test to measure how much entropy is consumed every time a new process is spawned.

The quantity of entropy available to the kernel, expessed in bits, can be read from /proc/sys/kernel/random/entropy_avail. But even a simple cat used to get this number is deemed to spawn a new process, thus to further drain the entropy pool. Why not using this to actually measure the entity of such drain? Here is the code:

e0=$(cat /proc/sys/kernel/random/entropy_avail); \
e1=$(cat /proc/sys/kernel/random/entropy_avail); \
echo $((e1 - e0))
The result is the difference of entropy in bits before and after a cat invocation.

Note that this compound command must be entered in one go: you cannot split it into 3 lines, as the interrupts caused by your typing would contribute extra random bits and spoil the measurement.

Just to prove that this command has no other effect on the entropy than the one stated, let's try this counter-example:

e0=$(</proc/sys/kernel/random/entropy_avail); \
e1=$(</proc/sys/kernel/random/entropy_avail); \
echo $((e1 - e0))
This is the same code as before, but the cat is replaced by a Bash trick that does the same without spawning a new process. The expected result is zero.

Now a quick comment on the results I found: my 32-bit kernel with ASLR enabled, consumes exactly 128 bits of entropy for every new process. Missing any other source of random data, it takes as few as 32 commands to exhaust a full 4096-bit pool. No surprise, then, my system comes to a halt after just some minutes of unattended aptitude upgrade!


Posted by mcortese on Thu 30 Jun 2011 at 12:10
Tags: none.
After installing a 2.6.38 kernel, I've seen the machine unexpectedly pausing when I'm not in front of it (typical scenario: while aptitude installs or upgrades things). It then recovers immediately as soon as I move the mouse.

Tracking /proc/sys/kernel/random/entropy_avail reveals it is constantly below 1000, quickly going down to ~100 in just a few seconds of inactivity.

I'm curious to track down who's eating up my entropy. Anybody knows how?

Then I wonder what changed in the latest kernel that's causing this behaviour.

Anybody has the same issue?


Posted by mcortese on Fri 25 Mar 2011 at 15:35
Tags: ,
I'm fighting with Grub2 to get a completely quiet boot... without success! I edited /etc/default/grub:
but nevertheless the Squeeze background flashes for about 1 second.

I also tried with GRUB_HIDDEN_TIMEOUT=0, but likely the Shift key is not detected on my Asus EeePC 901.

Any clue?


Posted by mcortese on Fri 15 Oct 2010 at 11:15
Tags: none.
Waiting for Debian CUT, my upgrading scheme has always been: upgrade when there's and upstream change, don't upgrade when there's a Debian release adjustment. I can tell in which of the two situations I am by checking whether the major version number (the part before the dash) changes or not.

To make it automatic is just 3 steps away:

  1. Get from aptitude the list of packages ready for upgrade (aptitude search '~U'), complete with the current and new versions (-F '%p %V %v').
  2. Pass the list through awk, which splits the version strings at the dash (split($2,Cur,"-");split($3,New,"-")) and prints the package name only if the major versions differ (if (Cur[1] != New[1]) print $1).
  3. If the output is not empty ([ -s file ]) upgrade.

The final script (omitting sanity checks etc.) is following.

aptitude search '~U' -F '%p %?V %?v' | awk \
  '{split($2,Cur,"-");split($3,New,"-"); if (Cur[1] != New[1]) print $1}' >$tmp
[ -s $tmp ] && aptitude install $(<$tmp)
rm $tmp


Posted by mcortese on Mon 27 Sep 2010 at 13:18
Tags: none.
I'm a happy user of vi(m), but sometimes I find myself trying to use Shift+arrows for selection, a habit shaped into my muscles by too many hours spent in Visual Basic Editor debugging macros for my employer.

Of course, Vim supports this selection model:

:set selectmode=key
:set keymodel=startsel,stopsel
After setting these options (either on the command line or in the .vimrc file), pressing Shift+arrow starts or extends the selection, while any unshifted arrow key clears it. This selection differs from the "usual" Visual mode in that any printable key replaces the selection, instead of being interpreted as command like in Visual mode.

The drawback is that the keymode option also affects the Visual mode, so that any unshifted arrow key after v, V or ^V obeys the stopsel and immediately stops Visual mode.

The solution I found is to remap the arrow keys with :xmap, a command that applies a mapping to Visual mode only (:vmap on the other hand, applies the mapping to both Visual and Selection modes):

:xmap <Up> k
:xmap <Down> j
:xmap <Left> h
:xmap <Right> l


Posted by mcortese on Wed 7 Apr 2010 at 09:54
Tags: none.
Has anybody really understood the logic behind the twin hwclock* init scripts?

Personally, having compiled the RTC support into the kernel, I disabled both of them at boot, and it works like a charm.


Posted by mcortese on Thu 24 Sep 2009 at 19:16
Tags: none.
I've recently upgraded Xorg from 7.3 to 7.4 (the version currently in testing), only to discover that mouse and keyboard were not recognized any more. Booting in single user mode and typing
# /etc/init.d/gdm start; sleep 10; /etc/init.d/gdm stop
was enough to get myself a useful log to inspect.

The issue showed up in two surprisingly innocent lines:

(II) Cannot locate a core pointer device.
(II) Cannot locate a core keyboard device.
You have read correctly: they are classified "(II)", merely informational.

I, like many other users, have done without a conf file for a long time, as Xorg is perfectly able to configure itself without the user's help. Or so I thought...

Apparently, the new Xorg put all the burden of detecting and supporting input devices on HAL's shoulders, unless you specify otherwise in the conf file. HAL is the Hardware Abstraction Level, a subsystem that is supposed to take care of the low-level management of the hardware and just exposes a common interface to the applications that use it.

The new version of Xorg trusts HAL so much that it has the option AllowEmptyInput enabled by default. This means that if HAL, for some reason, does not pass any valid input device over to Xorg, the latter will be happy nonetheless. Hence the (II) non-warnings.

Now, I still have to understand why HAL fails to detect my pretty standard keyboard and mouse, but, at least, I discovered how to make my Xorg work in spite of this.

As I said before, Xorg defaults to blindly rely on HAL, but the old, legacy mouse and keyboard modules still work, if properly configured in the conf file. Setting the option AutoAddDevices to off, prevents HAL from getting in the way. A minimal conf file like the following worked for me.

Section "InputDevice"
  Identifier  "My beloved keyboard"
  Driver      "kbd"
  Option      "CoreKeyboard"
Section "InputDevice"
  Identifier  "My beloved mouse"
  Driver      "mouse"
  Option      "CorePointer"
  Option      "Device"        "/dev/input/mice"
Section "ServerFlags"
  Option      "AutoAddDevices" "False"

Of course, disabling the AutoAddDevices also drops the possibility to hotplug input devices. This is only a workaround while waiting to understand what HAL does not like in my mouse and keyboard.


Posted by mcortese on Thu 23 Apr 2009 at 14:15
Tags: none.
A poll showed up on this site some time ago about how "Debian" is pronounced.

Now I've just noticed that this question is answered, at last, on the About page and the answered is /'de.bi.ən/

Whether this is short-e, long-e, or what else, remains a mystery for us non English speakers (and is indeed the reason why IPA was defined in the first place).


Posted by mcortese on Fri 13 Mar 2009 at 11:42
Tags: none.
I received a broadband wifi USB dongle provided by Italian telecom company TIM. The commercial name is Alice Mobile Broadband, the dongle is labeled ONDA MT505UP.

When you plug it into a Windows machine, it is seen as a disk containing the Windows drivers. After installing those drivers, it is seen as a HSDPA/UMTS/GPRS modem.

Of course, no Linux drivers or instructions are provided. When you plug it into your Linux box, it is seen as an USB storage and that's all. The telecom company's help desk simply said that Linux is not supported.

Of course "not supported" doesn't mean "not possible"! This is how to make it work.

First of all, download usb_modeswitch and put the executable in /sbin (I haven't tried the debianized package).

Create a new udev rule /etc/udev/rules.d/45-onda.rules:

# Udev rules for Onda MT505UP

# When seen as a storage, switch it:
SUBSYSTEM=="usb",SYSFS{idVendor}=="19d2",SYSFS{idProduct}=="2000", \
  RUN+="/sbin/usb_modeswitch -c /etc/usb_modeswitch_onda.conf"

# When seen as a modem, use it:
SUBSYSTEM=="usb",SYSFS{idVendor}=="19d2",SYSFS{idProduct}=="0002", \
  RUN+="/sbin/modprobe usbserial vendor=0x19d2 product=0x0002 maxSize=4096"
And this is /etc/usb_modeswitch_onda.conf:
# ONDA MT505UP (most likely a ZTE model)
# Contributor: Alex Scortegagna

DefaultVendor=  0x19d2
DefaultProduct= 0x2000

TargetVendor=   0x19d2
TargetProduct=  0x0002



# udevadm monitor
to see what's happening and plug the dongle.
  • udev recognizes it as a storage device (idProduct=0x2000)
  • udev obeys my rule and runs usb_modeswitch
  • usb_modeswitch makes the magic and the dongle switches to modem-mode
  • udev recognizes it as a modem (idProduct=0x0002)
  • udev obeys my rule and runs modprobe to load the usbserial kernel module
  • usbserial creates the /dev/ttyUSB* special files (please note that it's /dev/ttyUSB1 the one which works).
There may be a certain delay for the last steps while the dongle switches mode and udev recognizes it.

Test it with minicom: run

# minicom --setup
and select /dev/ttyUSB1 as serial port, then try some AT commands (e.g. ATI) to see if it is working.

Now, next problem: the SIM is locked with PIN, and the modem config strings provided with ppp etc. usually don't handle this situation. The solution is the little-known AT command +CPIN=xxxx to unlock the SIM.

The other AT commands to fill in the ppp configuration (the second line is provider-specific, this works for Alice by TIM):

Q0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
and finally the "number" to call is *99#