Recreating LSPRO fw_env.config

In the process of upgrading my LSPRO to Debian Squeeze I found that I had no fw_env.config. That is, when I attempted to get the boot parameters I only got an error and bogus values:

# fw_printenv
Cannot parse config file: No such file or directory

Bummer...

As it happens, that file only contains the device, offset and length of the parameters in the flash memory. Also, there is a nice example already present in

/usr/share/doc/uboot-envtools/examples/

but I found that one after I made my own fw_env.config by hand.

So, the easy way to fix it:

# cp /usr/share/doc/uboot-envtools/examples/linkstation_pro_live.config /etc/fw_env.config

Here is the hard-ish way I actually used. Find the flash device info according to the kernel:

# cat /proc/mtd
dev: size erasesize name
mtd0: 00040000 00001000 "phys_mapped_flash"

With that, we know the device is "/etc/mtd0" and the erase size is 0x1000.

Then we can examine the flash device to figure out where is the actual data. It is probably aligned to the erase size and it is all text (except for a small header) so it should be easy to spot by simple visual inspection:

# hexdump -C /dev/mtd0 | less

Lo and behold, it is there near the end.

00038f70 90 6a f4 00 00 00 00 00 00 00 00 00 ff ff ff ff |.j..............|
00038f80 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
0003f000 48 aa b0 1a 62 6f 6f 74 61 72 67 73 3d 24 28 62 |H...bootargs=$(b|
0003f010 6f 6f 74 61 72 67 73 5f 62 61 73 65 29 20 24 28 |ootargs_base) $(|
0003f020 62 6f 6f 74 61 72 67 73 5f 72 6f 6f 74 29 00 62 |bootargs_root).b|
0003f030 61 75 64 72 61 74 65 3d 31 31 35 32 30 30 00 6c |audrate=115200.l|
... sipped for brevity ... 0003f3e0 6f 64 65 3d 68 6f 73 74 00 00 75 73 62 31 4d 6f |ode=host..usb1Mo|
0003f3f0 64 65 3d 68 6f 73 74 00 00 00 00 00 00 00 00 00 |de=host.........|
0003f400 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00040000

It begins at 0x3f000. Given that the erase size is 0x1000, it ends at 0x3ffff. And with that we can reconstruct the file:

/etc/fw_env.conf

#device   start   size   flash block size
/dev/mtd0 0x3f000 0x1000 0x1000

My first ext4 dataloss!

I guess it was to be expected. Let's see:

1. Ubuntu Jaunty, kernel 2.6.29. Check.

2. An ext4 single partition (or at least a /home in a ext4 partition). Check.

3. Intel driver, using UXA. Check.

Bonus:

4. In a laptop after several sleep/power-up cycles. Check

5. Trying to save power by powering wireless up/down as needed. Check!!

Result: the laptop froze just as I had checked my last 5 minutes of work into Mercurial and was pushing it to my home server. Hard lockup. No emergency SysReq + Sync possible!! Upon reboot it was as if I had never saved the last 5 minutes of work.

Very interesting. Not much was lost and I could not detect any corruption. So I am kind of optimistic. I'll keep using ext4 for the time being.

I am considering making a fsync button, though!! ^_^

Towards easier suspend for my PC

I have several PCs at home (Debin Sid). It uses a lot of power. I fear the elctric bill, but I like my PCs to boot fast...

Suspend (suspend to ram) to the rescue!!! ^_^

That is, when it works. But fixing things is already discussed elsewhere. In my case it meant not using the forcedeth Ethernet card on the mother board, but a an oldish PCI 3com instead (although I'd still like to be able to WoL so I might change the 3com for another one).

But I digress. What I've done so far has been to:

1. Convince pm-tools that yes, it is OK to force s2ram.



2. Coax GDM to use s2ram -f



3. Get into every account I have at home and set power management preferences to suspend after 1 hour of inactivity and to suspend on the power button.



4. Modify the ACPI power button script to suspend instead of powering down. ACPI calls this script to make KDE and/or GNOME aware of the power button action or to shutdown by default otherwise

In short, I wanted to make it really easy to suspend instead of powering down.

For 1) I edited some file in /etc... Unfortunately I had to try so many things I do not remember what I did to successfully make suspend to work, even tough s2ram complains the machines are unknown.

For 2) one I edited /etc/gdm/gdm.conf and added under [daemon]

SuspendCommand=/usr/sbin/s2ram -f

For 3) I just logged into every account (I am root afer all) and changed the power settings for KDE and gnome. I am sure there is a way to change the default. I just got lazy. After fixing everything else.

For 4) I edited /etc/acpi/powerbtn.sh to to s2ram -f instead of the usual shutdown:

# If all else failed, just initiate a plain shutdown.
#/sbin/shutdown -h now "Power button pressed"

# regelatwork: canged to sleep instead of shutdown
/usr/sbin/s2ram -f

This is still not good enough, though. It is still too easy to shutdown from inside a session. It'd be nice to have a simple way to do a logout+suspend instead. Better still for that to be the default logout option and for shutdown to ask something like "are you sure you do not want to logout and suspend instead?"

Also, it is too easy to Shutdown from GDM (it is the default Action). I'd like a similar warning message along with suspend as the default.

Pehaps I'll have to bite the bullet, get my hands dirty and code some scripts and modify some Gnome/KDM code to have things my way.

Unlearning bash

At debian's IRC someone asked how to replace ***.png to ***.jpg. To which I replied a "bashism."
Fortunately someone else corrected my bash-istic ways on time.

So how to unlearn those pesky bash-ways? It seems the IEEE comes to our rescue with the Open Group Specification.

Other tools seem to be debian's checkbashism command and the ol' technique of using dash instead (with some dose of cursing in between ^_^).

Update: It is a bashism to use the nifty regexp substitution

${var/\.oldext/.newext}

One should instead use the standard way of cutting trailing substrings from a var:

${var%.oldext}.newext

Lost Trashcan

It seems I am like other people with respect to icons on the Desktop. One day I love them, the next they are a nuisance on my beautiful wallpaper.

I use Gnome and today I wanted my icons back. Do not panic, says the ol'book. Someone else already figured it out.

Neat, ain't it?

Now, if KDE and Gnome could just agree on how to represent these pesky icons so I did not have to delete/add/recycle them every time I decide KDE Gnome is the best thing in the world.