[ N O C T E R N I T Y ] Contributing to the general pollution of the internet

27Mar/130

Playing with Asterisk (4/?) – Voice mail

Even in the context of a home set-up, voice mail is a "must-have" feature. My idea is to have a set of voicemail boxes - one per person, and a global "family" mailbox. Ideally, local phones / softphones should be able to access the corresponding mailboxes (the mailbox of the phone's owner and the family mailbox) without having to type a password, but other mailboxes should still be available with an identifier and passwords on all internal phones.

Basic set-up

Before trying to do that, I created a simple set-up that only worked for one of the test lines, and always required credentials to access. The first thing to configure is the voice mail application itself. I had to re-enable the app_voicemail.so module, and write a configuration file for the application (aptly named voicemail.conf). I also wanted email notifications with the message attached. Finally, I noticed the options of having the system force setting greeting messages and password when initially logging in, and that seemed interesting. Here is the resulting configuration file.

[general]
format=wav49|gsm|wav

serveremail=phones@nocternity.net
fromstring=Téléphonie
attach=yes
emaildateformat=%A, %d %B %Y at %H:%M:%S
sendvoicemail=yes
charset=UTF-8

maxmsg=100
maxsecs=180
minsecs=3 
maxgreet=90
maxsilence=2 
silencethreshold=128

moveheard=yes
review=yes
forcename=yes
forcegreetings=yes

maxlogins=3
minpassword=4 

[zonemessages]
; Empty

[default]
1 => 1,Emmanuel Benoît,tseeker@nocternity.net

I left the zonemessages section empty, because I really don't care about that feature; as for the password, it is set to "1" on my user in order to cause the voice mail application to force me to set it when I connect to it.

The next thing to configure was the dial plan. I had to modify one of the extensions for the internal phones in order to have it fall back on the voice mail when necessary. I initially used the following configuration:

exten => 100,1,Dial(${DIAL_TEST1},10,tT)
	exten => 100,n,Voicemail(1@default)
	exten => 100,n,Hangup()

The new argument to Dial() simply indicates the maximal ringing time before falling back to the voice mail. In this case, "ring for 10 seconds and fall back to the voice mail if there is no response".

I also had to add an extension that would give users (namely, me) access to their voice mail:

exten => 666,1,VoiceMailMain()
	exten => 666,n,Hangup()

Finally, I modified the voice mail fall-back  in order to play either the "busy" greeting or the "unavailable" greeting, depending on the Dial() application's result. This took me a while to figure out due to the somewhat twisted syntax.

exten => 100,1,Dial(${DIAL_TEST1},10,tT)
		exten => 100,n,Voicemail(1@default,${IF($["${DIALSTATUS}" = "BUSY"]?b:u)})
		exten => 100,n,Hangup()

Note about voice mail notifications

I tried setting up voice mail notifications for the SIP clients, by adding the following to their section in the sip.conf file:

mailbox=1@default

However, linphone does not appear to support this (it causes a warning on Asterisk's side), and the other free (not as in beer) softphones I tried had a tendency to blow up in my face.

General set-up

I needed to make quite a few changes in order to implement the idea I mentioned in this post's introduction.

Voice mail fall-backs for all phones

First, having a voice mail fall-back for all phones. In order to do that without the configuration becoming a copy-pasted mess, I had to learn about macros, which are basically dial plan sections which can be invoked from other areas of the dial plan. Here's the macro I used for the voice mail fall-back:

[macro-internal-call]

exten => s,1,Dial(${ARG1},10,tT)
	exten => s,n,Voicemail(${ARG2}@default,${IF($["${DIALSTATUS}" = "BUSY"]?b:u)})
	exten => s,n,Hangup()

This macro takes two arguments: the phone(s) to dial, and the voice mail box to fall back to. It then needs to be used in place of the internal phones' extensions:

exten => 100,1,Macro(internal-call,${DIAL_TEST1},1)
exten => 101,1,Macro(internal-call,${DIAL_TEST2},1)
exten => 102,1,Macro(internal-call,${DIAL_TEST3},2)

(I'd added box #2 and #9 in the meantime.) I also had to "emulate" that family voice mail box. I simply added the following extension:

exten => 999,1,Macro(internal-call,${DIAL_TEST1}&${DIAL_TEST2}&${DIAL_TEST3},9)

... which will cause all phones to ring when dialed, and fall back on mailbox #9.

Password-less access to voice mail

The next step was to allow clients to access their own voice mail, as well as the global one, without password. I started by changing the contexts for SIP clients to something that corresponds to their owners in sip.conf:

; ...

[test1](test-template)
        context=phones-tseeker
        ;...

[test2](test-template)
        context=phones-tseeker
        ;...

[test3](test-template)
        context=phones-ju
        ;...

Of course, I then needed to define these contexts in the dial plan. However, I wanted to avoid having to copy/paste common configuration; this is where the include thing comes in. It allows the extensions listed in another section to be considered. The modified extensions.conf looked somewhat like this:

[phones-tseeker]

        include => tests
        include => phones

[phones-ju]

        include => tests
        include => phones

[tests]

        ; Various 8378-prefixed tests here

[phones]

exten => 100,1,Macro(internal-call,${DIAL_TEST1},1)
; etc...

exten => 666,1,VoiceMailMain()
        exten => 666,n,Hangup()

Finally, I added the lines allowing direct access to the voice mail to each "owner-specific" section:

[phones-tseeker]

        include => tests
        include => phones

exten => 700,1,VoiceMailMain(1@default,s)
        exten => 700,n,Hangup()
exten => 701,1,VoiceMailMain(9@default,s)
        exten => 701,n,Hangup()

[phones-ju]

        include => tests
        include => phones

exten => 700,1,VoiceMailMain(2@default,s)
        exten => 700,n,Hangup()
exten => 701,1,VoiceMailMain(9@default,s)
        exten => 701,n,Hangup()

Some thoughts for later

I think it would be best if all internal numbers were prefixed with something that is not associated with outgoing calls at all. The "star" key seems like a decent prefix. In addition, it would be a good idea to make the various extensions and voice mail box numbers a little more rational and consistent.

26Mar/130

Playing with Asterisk (3/?) – A menu (sort of)

I wanted to try adding something that sort of feels like a menu to the dial plan. I am not sure that I will actually use one in the final setup, but it wasn't that much effort anyway.

A menu (or something with similar functionality) can be implemented using either Background() or WaitExten(). Or both, actually. Since I don't have anything to play as a prompt, I chose to do with the latter only. After all, this is only a test.

First, I replaced the previous test with the following:

[test]

exten => 8378,1,Answer()
        exten => 8378,n,Set(TESTCOUNT=0)
        exten => 8378,n,Goto(numbers,0,1)

This will cause Asterisk to answer calls to 8378 ("test"), set a channel-specific variable called TESTCOUNT to zero, and jump to extension 0 of the numbers section in the dial plan. The idea is to accumulate the digits typed by the user, and then to have Asterisk say that number. So, for each possible digit, the section will contain something like this:

[numbers]

exten => 0,1,Set(TESTCOUNT=$[ ${TESTCOUNT} * 10 ])
        exten => 0,n,WaitExten()
exten => 1,1,Set(TESTCOUNT=$[ ${TESTCOUNT} * 10 + 1 ])
        exten => 1,n,WaitExten()
; ... Same thing for 2 - 9 here ...

Finally, pressing the star key will cause the system to say the number (using SayNumber()) that was typed and to hangup.

    exten => *,1,SayNumber(${TESTCOUNT})
	    exten => *,n,Hangup()
21Mar/130

Playing with Asterisk (2/?)

Last time I managed to get a very basic Asterisk setup to work. Since then, I haven't had the time to really work on it, but I've made a few improvements here and there.

Dial plan improvements

In quite a few documents I read, dial plans always include a Hangup() line for all extensions, whatever they contain. I'm not 100% sure it's actually useful, but I added it anyway:

exten => 100,1,Dial(SIP/test1)
        exten => 100,2,Hangup()

exten => 101,1,Dial(SIP/test2)
        exten => 101,2,Hangup()

One of the things that was a little scary about the dial plan in general was the fact that I would have needed to renumber all lines for an extension if I wanted to insert stuff in one of its parts. That would have been rather annoying. As it turns out, Asterisk supports using "n" as the priority field in the dial plan's extension definitions. Using it causes Asterisk to handle the "line numbering" automatically (with the exception of the first line that still needs to be 1):

exten => 8378,1,Answer()
        exten => 8378,n,Playback(hello-world)
        exten => 8378,n,Hangup

exten => 100,1,Dial(SIP/test1)
        exten => 100,n,Hangup()

exten => 101,1,Dial(SIP/test2)
        exten => 101,n,Hangup()

Finally, I started using global variables to define the dialing targets, which would make it much easier to change if I needed to:

[globals]
        DIAL_TEST1=SIP/test1
        DIAL_TEST2=SIP/test2

[test]

; ...

exten => 100,1,Dial(${DIAL_TEST1})
        exten => 100,n,Hangup()

; ...

Granted, it is "a little" pointless in this context, but it will come in handy later.

Caller IDs for SIP clients

I also added caller IDs for SIP clients. It is extremely simple to do that by simply adding a line that looks like this...

        callerid="TSeeker's mobile" <101>

...to a SIP client's configuration.

Transferring calls

One other thing I added is the ability to transfer calls. First, I started by creating a features.conf file in order to define the DTMF sequences to use. Here's what it contains:

[general]
        ; Empty

[featuremap]
        blindxfer => #1
        atxfer => #2

[applicationmap]
        ; Empty

This is not strictly necessary, as the defaults can be used. Anyway - the next step is to enable the functionality when calls are being made. This is done from the dial plan:

; ...
exten => 100,1,Dial(${DIAL_TEST1},,tT)
; ...

In this specific case, I want to allow both sides to transfer the calls, as these are internal phones anyway (I added a third client on Ju's also-microphone-less PC to run tests).

Miscellaneous changes

Amongst other minor changes, I also re-configured logging using the following configuration in logger.conf:

[general]
        ; Empty

[logfiles]
        console => notice,warning,error,debug
        messages => notice,warning,error

No need for Asterisk-based log file rotation as the Debian package handles that using logrotate.

I also modified modules.conf to remove more currently useless modules (it's just a bunch of noload's for stuff I know I'm not gonna need so I'm not pasting this here).

Finally, I did not add IPv6 support yet, as I need to upgrade to 1.8 for that and I figured IPv4 would be fine for testing purposes; I don't expect many things to change because of IPv6 support anyway (although I may be wrong).

19Mar/130

Playing with Asterisk (1/?)

The long term "plan" here at home is to switch over to VoIP for all phone calls. This includes getting rid of our old POTS phones, using softphones on the PCs, possibly buying hardware VoIP phones or, if I ever get the time to finish playing with the STM32 board, making our own; it also implies subscribing to a pair of SIP lines and using a board to connect our POTS line to the network.

There's a catch, tho: I've never used Asterisk (or any other kind of VoIP software), and it seems to be rather complex. So before we do anything, I'm going to be exploring its configuration a little when I have some time and nothing more important to do.

Since I'm basically a complete newbie when it comes to it, I'll try and post about it as it might be useful to someone in a similar situation.

System

Before I go on, it should be noted that I am working with a Debian Squeeze system, running inside a Xen VM. That VM is on a network that has both IPv4 and IPv6 stacks. The idea is to have everything local going through IPv6, with support for IPv4 through NAT (which means the Linux routers here need to have nf_conntrack_sip and nf_nat_sip loaded; the VM itself only has nf_conntrack_sip). While I've read that NAT is terrible when it comes to SIP (and for everything else), I'm afraid I don't have much choice on the matter.

For now I won't be doing anything that requires specific hardware, as it is a bit pointless to buy a €700 board if you're not even remotely sure you can do what you need to with it.

I have ordered a pair of webcams that include microphones, and they should arrive in a few days. At the moment, however, the PCs here have no way to record sound, so my ability to test with them is limited. I figured I could use my mobile phone for testing, though. I installed Linphone on both my PC and my smartphone.

Installing Asterisk

This is a Debian system so  it's rather easy to install Asterisk and its various dependencies:

apt-get install asterisk

Ok, I actually removed some recommended dependencies I won't be needing (either "for now" or "permanently").

The Debian package comes with a metric ton of sample configuration files under /etc/asterisk; while these are rather handy to have around as they are very well commented, I moved them out of the way as I prefer writing my own configuration from scratch.

First steps

So, the first thing I want to do is set up the server so it is possible to connect to it. That's the definition of "minimal configuration", but one has to start somewhere.

I left both asterisk.conf and modules.conf mostly untouched (with the exception of comments being removed), although I'll probably have to remove some modules when I have a better idea of what I'm doing. Most of the action here takes place in sip.conf:

[general]
        context=default
        allowoverlap=no
        udpbindaddr=0.0.0.0
        tcpenable=no
        srvlookup=yes

[test1]
        type=friend
        host=dynamic
        canreinvite=no
        nat=yes
        context=default
        dtmfmode=rfc2833
        allow=all
        username=test1
        secret=...

The general section is basically the default, followed by a test user which I can use to try and connect to the server. I also included an empty dial plan (while I'm not sure it was necessary, I figured it wouldn't hurt):

[general]
static=yes
writeprotect=no
clearglobalvars=no

[globals]
; No variables

[default]
; Empty context

After some tinkering with the Linphone configuration (I needed to add a proxy account, using sip:test1@server-ip as the identity and sip:server-ip as the proxy address), I was able to get it to connect to the server.

A basic dial plan

The next logical step was to try and have the client dialing, with the server responding with something. Fortunately, Asterisk comes with a lovely hello-world.gsm file.

First I modified my test user so that its default context would be something other than default. I called that new context test. For some reason.  Then I created a simple dial plan that would cause the server to answer, play the "hello world" sound, and hangup, when the client dials "1".

[test]
exten => 1,1,Answer()
exten => 1,2,Playback(hello-world)
exten => 1,3,Hangup

And "1" was dialed, and "Hello world" was heard, and it was good.

Two accounts

Having done that, I decided to try implementing calls between SIP clients. Of course, since only one of the two SIP clients has a microphone, my ability to test is limited.

So, I wanted to add a second SIP client. Since its configuration would end up being mostly the same as the one I already had, I decided to use a template for the clients. Here's the resulting sip.conf:

[test-template](!)
        type=friend
        host=dynamic
        canreinvite=no
        nat=yes
        context=test
        dtmfmode=rfc2833
        allow=all

[test1](test-template)
        username=test1
        secret=...

[test2](test-template)
        username=test2
        secret=...

Then I had to add a few lines to the dial plan in order to allow dialing between one client and the other. It only takes two new lines in the dial plan:

exten => 100,1,Dial(SIP/test1)
exten => 101,1,Dial(SIP/test2)

Because I don't have WiFi here, I had to whitelist the phone carrier's IP range on the firewall to let it connect to the server. The configuration of Linphone uses the server's internal IPv4 address (i.e. its address on the LAN here) as the domain, and the IPv4 address of the DSL connection as the proxy. With this configuration, I was able to call the phone from the PC and vice-versa.

25Oct/110

Mass destruction

The first stage of the repairs in the house wasn't quite in the "repair" category. Indeed, most of the work implied getting raw plaster on the walls and ceilings, removing carpet from the floor, and so on.  This task kept us busy from July to October 2009. Since it would be boring to present that kind of activities everywhere in the house, I'll present a few emblematic spots.

The hall is a good example of what we had to face in most rooms on the ground floor.

The wallpaper is quite easy to get rid of, but there's something much, much worse : polystyrene tiles glued on all ceilings. Not only they are  quite difficult to remove because of the position you have to be in in order to remove them, but you usually leave pieces of skin on the ceiling and end up bleeding after a few hours. Last but not least, it is impossible to remove the glue without removing pieces of plaster from the ceiling. In the end, we have ceilings which look like fields of round holes.

We ended up with:

  • on the one hand somewhat "correct" walls and ceiling, if you ignore the holes which will have to be filled
  • plenty of junk which we had to bring to the waste collection centre on a regular basis. We were going there so often that the employees were almost on a first name basis with us !

Another rather interesting place was the living and dining rooms. If you remember the pictures from the origins, these rooms not only had the wonderful polystyrene tiles on the ceiling but also panelling on the walls. Manu had great fun removing them and... the glue...The work in progress provides a wonderful idea of the extent of the issue.

In the end, this allowed us to reach that kind of stage:

Last but not least, the "situation" on the first floor... We had:

  • The ever-present polystyrene tiles on the ceilings, of course, which were impossible to unglue without removing part of the paper of the drywalls,
  • Moquette on the floors. These went off easily, even if part of them were hidden under a floating floor.
  • Moquette on the walls. That was the real pain because some kind of paper layer remained glued on the drywalls and it was awful to unglue it.

For instance, we went through that kind of stage regarding the corridor on the first floor:

... or in one of the bedrooms:

And with much effort, we managed to reach these almost final conditions:

  • In the corridor

  • In the bedroom:

To be honest it was quite a depressing activity: indeed we were destroying what was somewhat decent in order to reach the raw skeleton of the house. However things would soon improve, which I will explain in a later post.

16Oct/110

The house: origins

So far most posts which we have written and were related to our house were posts regarding the garden. Of course, it was way easier to write them: I had already written them for a gardening forum and all was required was simply copying them and translating them into English. At some point we had to start with the repairs inside the house. However, before getting into that, it is logical to present what we started with. So here are picture we took in Spring 2009 while the former owners still lived there. The idea is to introduce the extend of the work we have to do...

I expect I'll be able to post a few plans to accompany the pictures at some point. For now we only have paper versions and I'll have to scan them first...

Regarding the repairs we intended to do we chose to get some help from a general contractor to help us define exactly what we intended to do, choose the companies who would do the work and manage the day-to-day oversight of the project. In the end here is what was planned (roughly):

  • earthwork:
    • install a rain water collection tank
  • joinery:
    • change the kitchen French window, which wasn't of the same model as the others on the ground floor of the house
    • install insulated doors in the basement
    • install new doors on the 1st floor
  • plaster works:
    • in the basement, insulate the ceiling and create a new room which would become the server room
    • on the ground floor, remove the wall between the hall and the living room, add walls to create cupboards in the hall and the 3 rooms
    • on the first floor, line the vertical parts of the walls to increase the insulation and add new walls to fit with the new plan
  • electricity:
    • replace completely the whole electric installation of the house
    • add network cables to connect the whole house for either computer network, phone or TV
    • install a network distribution rack in the future server room
  • plumbing:
    • change completely the heating system (boiler, heaters and network)
    • install a new bathroom on the first floor
    • connect the house to the town gas network
    • set up the rain water network
    • replace the old water pumps in the basement
  • tiling:
    • replace the ugly tiles in the hall, living room, dining room, kitchen and ground floor corridor
    • tiling of the toilets and bathroom on the first floor
    • tiling of the new server room in the basement
  • painting:
    • repair and painting of the walls and ceiling of both staircases

We asked for the estimates in July 2009, signed them in September 2009 and actual work by the various contractors started in October. So you can guess there are plenty of opportunities to describe how it went !

15Oct/110

Minefield v3.0

I hadn't had the time until now to finish telling the story of our earthwork adventures. Now we're getting close to the end of this episode, so it's probably a good time.

While we were waiting for our friend the plumber to come and save the water tank's pump, I added some sand to make the soil a little less compact; I also replanted the flower beds that had been removed or damaged during the earthworks.

In the flower bed under the balcony, the gaura and the Graham's sage had suffered quite a lot from their staying in buckets (there was a lot of rain then, the buckets were full and the water didn't flow away). The gaura's roots were rotten, and it's dead. I'm giving the sage a chance. I also took the opportunity to make a few changes: adding one of the rosebushes and the caenothus that used to be above the water tank, as well as a few new plants, and making sure the plants were far enough from the path (last time their branches were quite annoying as they were in the way). It looked mostly OK mid-September.

Now, on the side of the water tank's flower bed, I replanted most of the plants that were there before, and I added a few. Still mid-September, it was looking mostly decent again, although one part of it is still quite empty (on the right) and I have a few worries regarding the creeping rosebush which got removed rather brutally by the earthwork contractors. At the time it was quite impossible to break the clods as they were really sticky - and that did not help.

Right now I'm rather encouraged: both the creeping rosebush and the sage are growing new leaves again, so they're not dead. And everything else looks like it's doing OK:

  • Under the balcony:

  • Above the water tank:

 

OK, I have to admit it's covered in various weeds I need to remove, and attentive readers will have noticed that there's still a hydrangea in a bucket and a pile of earth in the back above the water tank. The "save the water pump" turned out to be quite epic, as the plumber had to come here 3 times.

  • The first time he came, he noticed that the leak was on the outside after he cut through the wall of the server room. And after digging on the outside he discovered that the water junction (which had been changed last year) at the bottom of the drainpipe was leaking. Probably yet another consequence of the earthwork contractor falling :( In addition, he didn't have the right pipes to fix the water circuit and when he tried to "hack" it together it ended up with a few geysers. According to Manu he barely avoided being shot in the face by one of these.
  • The second time he fixed most of the problem but there was still a leak further down the pipe which he didn't see as he couldn't test the circuit.
  • The third time he was finally able to complete the repairs.

For now we've kept the hole in the server room's wall for now, until the earthwork contractors come back to fix the water junction. Just in case. In addition, the mini-excavator destroyed the concrete paths, so we'll have to replace them earlier than we'd anticipated...

Who said making the foundations waterproof was a simple job, eh?

14Oct/112

Installing Debian GNU/Linux on a LaCie NAS

Since I recently set up Azathoth's 6th revision, I had the old LaCie NAS on a shelf, completely useless. I had to do something with it; however, the system which comes pre-installed on that thing is definitely not too customisable beyond the basics, so I decided to try and install Debian GNU/Linux on it.

The NAS, with its cover removed

One important thing about this old NAS - it uses an Intel EM7210 motherboard, with an Intel 80219 CPU. As it happens, that board is more or less supported by Debian.

The NAS's EM-7210 motherboard

However, it is necessary to access the system's RedBoot bootloader, which is only possible using a serial cable whose connector is directly on the motherboard.

IDC10 serial connector on the motherboard

Building the cable

The serial cable that allows access to the system's console needs to be plugged on an IDC10 connector. While it might have been possible to use the connector from an old PC along with a null-modem cable, I no longer possess either of these items, so I built my own cable. This is what you need to connect:

Female DE9 Female IDC10
2 5
3 3
5 9

And if you need a picture for the IDC10 side (I had to look it up, so I might not be the only one in this case):

Pins on the motherboard's IDC10 connector

I hadn't done any soldering for 16 years, so I was a little anxious about that. As it turns out, soldering was the easy part; the wires I used were apparently a little too big for my IDC10 connector, and I broke it. I had to rip connectors from an unused audio front panel and solder them to my wires instead. In addition, since none of my computers here have RS232 interfaces, I had to use an USB<->RS232 adapter.

I should really be ashamed

Minicom settings

The next step was to connect to the NAS's console using Minicom (any serial terminal would do, but I'm used to this one). The settings that need to be used are:

  • transfer rate: 115200 bps
  • data bits: 8
  • parity: none
  • stop bits: 1

It is also important to make sure that both hardware and software flow control are turned off.

 Booting the Debian installer

Obviously, the next thing to do is to try and start the Debian installer.

In order to do that, it is necessary to boot into the NAS's bootloader, which can be achieved by pressing Ctrl+C in the console before the bootloader's script starts executing (you need to be rather quick, as you only have one second to do so). This leads you to a command prompt.

You will also need to download kernel and RAM disk images for the architecture. Both images can be found on Debian's server (you need to download zImage and initrd.gz).

Once you are ready to proceed, you will need to upload the images to the NAS through the serial cable. Start by telling the bootloader that you want to load the RAM disk image:

load -v -r -b 0x1800000 -m ymodem ramdisk.gz

The bootloader will then expect you to send it the RAM disk's data (the initrd.gz file mentioned above) using YMODEM. In Minicom, that can be done by pressing Ctrl+A followed by S, then selecting "ymodem" in the list, and finally selecting the file to send.

(Wait. Wait some more. Wait even more.)

When that transfer has been completed, you will also need to send it the kernel image by typing

load -v -r -b 0x1008000 -m ymodem zImage

and then sending the zImage file.

(Wait. Wait some more. Wait even more.)

Once both files have been uploaded, you are ready to start the installer. The following command will do just that:

exec -c "console=ttyS0,115200 rw root=/dev/ram mem=256M@0xa0000000" -r 0x01800000
Completing the installation

I've skipped the part about installing Debian, because that's pretty much the usual process. However, there's one additional operation to perform once the installer is done running, as the system will not boot without that. You need to edit the boot script.

In order to do that, when the installer reboots, enter the bootloader by pressing Ctrl+C, then enter the following command:

fconfig boot_script_data

The prompt will change to >> to indicate that you are editing the configuration. You need to set the boot script to this:

fis load -b 0x01800000 ramdisk.gz
fis load -b 0x01008000 zImage
exec -c "console=ttyS0,115200 rw root=/dev/ram mem=256M@0xa0000000" -r 0x01800000

Don't forget to exit the boot script editor by finishing with an empty line. RedBoot will ask you to confirm the changes then write the configuration to flash memory.

A few notes
  1. I initially removed the HDDs from the box while trying to boot it in order to avoid unnecessary power cycles. However, if you try to insert them while the Debian installer is running, they will not be detected, and you will end up having to reboot anyway.
  2. Setting up the partitions takes an awful lot of time, and so does RAID array resynchronisation if that's what you want to use.
4Oct/110

Somewhat epic lawn mowing session

Ju and myself both like keeping the lawn a little high, so mowing only occurs once per month under normal circumstances. Lately however we've both been busy with other stuff, and it was bloody hot outside, so the lawn was left to fend for itself for at least 2 months. Today, there were clouds and a rather cool breeze, so I thought I'd do it.

Keep in mind that:

  • the lawn isn't that big (400 square meters, give or take),
  • something between one fourth and  one third of it looks like this:
    (I don't know what's to blame; maybe the soil being its usual charming self, or the cherry tree's roots, or the recent heat wave, or maybe some combination of the above),
  • I had mowed another quarter of it a few weeks ago as I needed something to use as mulch.

And the result is:

... And yes, I did step on both heaps to pack them a little.

Tagged as: , No Comments
3Oct/110

Gig in Rennes – Samael and others

So, sometimes we do get out of here. We'd bought tickets for a Samael gig in Rennes last Saturday - the gig also included 5 other bands we didn't even know of. As it turned out, it was well worth it.

While the Antipode [fr - site down at the moment] hall wasn't really small compared to other gigs we've been to, for example the Ubu (also in Rennes), it was definitely not gigantic. 500 people would probably fit in there, but it wasn't full either. In any case, it has been my experience so far that metal gigs are always more enjoyable in this type of settings.

The first band we saw was Six Reasons to Kill, which delivered a rather good death metal performance. Unfortunately for them, being the first band to play, the audience was rather sleepy, and the hall was still mostly empty. They were followed by Dead Shape Figure. I'm really not too fond of thrash metal, and on that point they were no exception. The live performance itself, however, was rather enjoyable. While the audience was still a little comatose, they definitely contributed to waking it up.

The next band to take the stage was Noctem. First thing we noticed about them was... Ah well, the cliché. They came on stage with (presumably fake) leather armours. Julie went as far as telling me "Look, Klingons!" Honestly, we both sort of expected basic (and annoying) black metal. Fortunately, it wasn't the case - what they delivered was a bit of a hybrid, including really brutal rhythmic guitar riffs, sometimes thrash-like, sometimes definitely more black metal-like, as well as slow and heavy melodic parts which reminded us of melodic death metal. And while I mentioned the cliché earlier, well, they exploited it quite well (singer throwing up strawberry-smelling fake blood? check!).

Then came Keep of Kalessin, who also plays a black metal-inspired kind of music (but not strictly black metal). While it is one of the bands I enjoyed the less, it was still a good show. Next, we got to see Melechesh. I would have a hard time trying to classify what they play - to me it sounded like oriental-inspired death metal with a bit of black metal thrown in. Whatever. I really, really enjoyed it, in any case. We had a good laugh as well, as one of Dead Shape Figure's guitarists was in the audience with a tray of fries, trying to feed his on-stage colleague (hint: it didn't work too well).

And finally there was Samael. We've been listening to them for a rather long time, and we'd already seen them as the opening act for Paradise Lost two years ago (and we'd enjoyed it more than the main act). They played quite a lot of tracks from the latest album, as well as a few older tracks. Not that I mind either, really - I enjoy both :) Good music and, unsurprisingly, good on-stage performance. The only thing I could complain about was that we were starting to be tired by then.

On the next day, my neck was sore and I was voiceless, so it was definitely a good (5h-long) gig. My only regret is that I forgot to bring my phone, hence the lack of pictures.

Tagged as: , , No Comments