Freitag, 30. November 2012

Making yast2-ncurses look better when using through screen

In openSUSE on CuBox (Day 5) I posted a screenshot of how yast looks terrible when used in ncurses mode over the serial connection (i.e. when you connect to e.g. the CuBox using screen /dev/ttyUSB0 115200). Here is that screenshot again.
 As you can see, the background is really messed up. Things get much worse if there is any "movement" involved - for example progress bars.

I think I have found a solution - or at least a workaround. Alex Graf got me thinking that the problem is more than likely that yast in ncurses mode just can't deal with the $TERM that is set when coming through the serial connection. I researched this a little more.

When coming over a serial connection
echo $TERM
told me "linux".

When coming over SSH
echo $TERM
told me "xterm"

Now, that probably isn't altogether incorrect. Alex Graf and Juergen Weigert got me thinking that maybe the screen/ncurses combination just didn't support color in "linux" or "xterm" $TERM modes. I tried using TERM=vt100, TERM=vt200 and TERM=vt500 (as well as the color modes TERM=screen256-color, TERM=vt200-color) but that made things worse, in my opinion. What happened was that YaST was displayed in black and white with no highlighting to show which entry was selected. YaST became pretty much impossible to use.

It turned out that there is an informative page on the openSUSE wiki which deals with YaST Tips and Tricks. There I saw the information "The default setting of the YaST ncurses UI is that the init routine detects the terminal type and automatically chooses the appropriate color theme." However, then I saw the hint:

Since openSUSE 10.3 it's possible to set the color theme manually in /etc/sysconfig/yast2. E.g. if you want a black/white YaST set Y2NCURSES_COLOR_THEME to "mono". 
After some playing around and testing I found that, to get YaST working in ncurses mode over the serial connection (without messing up YaST over SSH), the following combination did the job:

Change the line Y2NCURSES_COLOR_THEME in the file /etc/sysconfig/yast2 from:
Y2NCURSES_COLOR_THEME=""
to
Y2NCURSES_COLOR_THEME="linux"
and also change:
TERM=screen; export TERM

For me, I then got an acceptable YaST. This is probably a bit of a hacky workaround, but maybe it could help somebody in the know identify the real problem and fix it properly.

That's all for now folks! Here's a screenshot of YaST in ncurses mode on the CuBox, over the serial connection...




openSUSE on CuBox (Day 7)

I started off today with the status that my CuBox image would boot into yast2-firstboot without manual intervention. After configuring the system in yast2-firstboot, I tried rebooting. On reboot, the boot process did not get past "loading initrd". I was told on the opensuse-arm mailing list that the initrd automatically gets overwritten after yast2-firstboot. Given that it was necessary to change ramdiskaddr from 0x300 to 0x500 to even get to yast2-firstboot, I knew where to look to address the reboot problem - to whatever script was called to rewrite the initrd.

Alex Graf put me on the right track. He pointed out that the uboot-setup.tgz file in the JeOS-cubox package also needs to be updated. The contents of this .tgz are used to rewrite the initrd. When you unpack uboot-setup.tgz,  you get a directory called kiwi-hook. In this directory are two files. I had forgotten to modify the setupUboot.sh file so that the ramdiskaddr there is also update to 0x5000 from 0x3000.

Once I fixed the setupUboot.sh and recreated uboot-setup.tgz, I called the precheckin.sh script (also in the JeOS-cubox package). This script regenerates the JeOS-cubox.kiwi file using the modifications I had made to the Images.kiwi.in file (i.e. changing the console line from ttyS0,115200n8 to ttySO,115200).

After recreating the new image, I dd'd it over to a mini SD card and tried it out. I got past yast2-firstboot and rebooted. This time I got past the "loading initrd" but the this error occurred:

High Capacity: Yes
Capacity: 3965190144
Bus Width: 4-bit
Loading file "/boot.scr" from mmc device 0:1 mmcda1
723 bytes read
## Executing script at 02000000
## Error: "kerneladdr" not defined
## Error: "ramdiskaddr" not defined
Loading file "uImage" from mmc device 0:1 (mmcda1)
3927920 bytes read
Loading file "initrd" from mmc device 0:1 (mmcda1)
undefined instruction
pc : [<9e34e23c>]          lr : [<036352b8>]
sp : 035ff530  ip : 03604478     fp : c6b2fd2b
r10: aad350f6  r9 : d13d13bf     r8 : 035fffcc
r7 : 8d7ea4d5  r6 : b697c9bf     r5 : 45f7c8d6  r4 : 4a59273d
r3 : ffffffff  r2 : 00000001     r1 : 007a1200  r0 : 00000000
Flags: nzcv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

The bootloader will continue looping to that point, until the power cable is pulled. So now it looks as though the new initrd - the one that is automatically created out of the setupUboot.sh in the kiwi-hooks directory (i.e. the contents of uboot-setup.tgz) somehow contains an illegal instruction. The next task is to identify what is going on there - which instruction is illegal.

Stay tuned! We're getting close.

Mittwoch, 28. November 2012

openSUSE on CuBox (Day 6)

It's been a couple of days since my last update but that's not because I was doing nothing. In fact, I've been investing more work than normal in openSUSE on CuBox these last couple of days. At the end of my last update, I had an image which basically worked and booted without manual intervention. I achieved this by modifying the uboot-image-setup script included in the JeOS-cubox package in the openSUSE:12.2:ARM:Contrib:Cubox project.

It turns out that, whereas my modifications lead to a system that boots each time (without manual intervention through uboot), the same modifications are problematic. This is because they depart from the generic structure that all other openSUSE on ARM devices use to boot. This means that we essentially create a kind of proprietary branch and would have to maintain this all by ourselves - without benefiting from all the hard work going on in the rest of the ARM port (well, not automatically benefiting, that is).

Another issue that my modifications created was the situation where the network interface on the CuBox would not be brought up automatically at each boot. What was happening is that the interface eth0 would not be found on reboot because the MAC address changed. The change happened because of the resetenv that I had inserted in the uboot-image-setup file. Because of this, it was necessary to log in to the CuBox over the serial interface in order to configure the "new" interface through (e.g.) YaST. This meant that each time the network interface id would increment by one - e.g. eth0, eth1, eth2. This was also not ideal.

Thus, what was suggested was that I revoke my submit request and try to continue editing the uboot-image-setup script (as well as the corresponding .kiwi file) to try to figure out exactly what change is needed to get the CuBox to boot. Thus far I think I've narrowed it down to the bootargs line. This line gets added to boot/boot.script in the image by the .kiwi file (in the same uppermost directory as the uboot-image-setup file). In the .kiwi file, the bootargs line appears to have ttyS0,115200n8 whereas the bootargs line I was using in uboot-image-setup had ttyS0,115200 only. I don't know what the 115200n8 is for or if it could even have an effect, but I'm going to change it in the .kiwi file to see if that is the place that is causing the trouble.

I'm out of the house today, without a CuBox, so I won't be able to test (well, I'm in the office in Nuremberg, where there are a couple of CuBox so if I get time, I may be able to test one).

Stay tuned! Check out some of the mail threads that have been generated around openSUSE on CuBox over on the opensuse-arm mailing list:

Freitag, 16. November 2012

openSUSE on CuBoX (Day 5)

Today I decided to try to get to grips with building a new, modified image for the CuBox. In my last post I explained how easy it is to build the standard openSUSE image for CuBox by simply checking out the project and using the osc tool to build. The procedure here is basically the same, except this time I'm going to edit some files to try to make the CuBox boot automatically (you'll remember from my first post that manual intervention is currently needed at the Uboot stage).

I cd'd into my branch of openSUSE:12.2:ARM:Contrib:Cubox/JeOS-cubox and ran 'osc up' to make sure I was working on the latest sources.

Given that the openSUSE image itself actually works (i.e. once you get past the Uboot stage, the image boots and you can log in and play around with it), I figured that the real issue must be the boot.scr script, which is a generated file. You can't just go and edit boot.scr and hope to be successful - that file is created by a mkimage command.

In the checked out branch I found a file called uboot-image-setup. "Aha", I thought, "this has to be it". That file contained the following:

#!/bin/bash

set -x

file=boot/boot.script
echo 'printenv kerneladdr || setenv kerneladdr ${kernel_addr_r}'   >> $file
echo 'printenv ramdiskaddr|| setenv ramdiskaddr ${ramdisk_addr_r}' >> $file
#CuBox Hack
echo 'if itest 1$arcNumber == 13905; then'                         >> $file
echo '  setenv kerneladdr 0x2000000'                               >> $file
echo '  setenv ramdiskaddr 0x3000000'                              >> $file
echo 'fi'                                                          >> $file
echo -n 'setenv bootcmd "'                                         >> $file
echo -n 'ext2load mmc 0:1 ${kerneladdr} boot/linux.vmx; '          >> $file
echo -n 'ext2load mmc 0:1 ${ramdiskaddr} boot/initrd.uboot; '      >> $file
echo 'bootm ${kerneladdr} ${ramdiskaddr}";'                        >> $file
echo 'boot' 
mkopts="-A arm -O linux -a 0 -e 0 -T script -C none";
inputf="boot/boot.script";
result="boot/boot.scr";
if ! mkimage $mkopts -n 'Boot-Script' -d $inputf $result;then
        echo "Failed to create uboot script image"
        exit 1
fi

For whatever reason, this was simply not working. You can see why in my first and second posts about openSUSE on CuBox (i.e. systems hangs where the kernel is supposed to boot). I decided to see if I could add the commands that I used when manually intervening (see http://c-farrell.blogspot.de/2012/11/opensuse-on-cubox-day-2.html) to the script and see would it work. It did - kind of. Without getting into further details, here is the uboot-image-setup that worked for me:



#!/bin/bash

set -x

file=boot/boot.script
echo 'resetenv' >> $file
echo 'setenv kerneladdr 0x2000000' >> $file
echo 'setenv ramdiskaddr 0x3000000' >> $file
echo 'ext2load mmc 0:1 0x2000000 boot/linux.vmx' >> $file
echo 'ext2load mmc 0:1 0x3000000 boot/initrd.uboot' >> $file
echo -n 'setenv bootargs "'  >> $file
echo 'console=ttyS0,115200 root=/dev/mmcblk0p2"' >> $file
echo 'bootm 0x2000000 0x3000000' >> $file
echo 'boot' >> $file
mkopts="-A arm -O linux -a 0 -e 0 -T script -C none";
inputf="boot/boot.script";
result="boot/boot.scr";
if ! mkimage $mkopts -n 'Boot-Script' -d $inputf $result;then
        echo "Failed to create uboot script image"
        exit 1
fi
I'm not entirely sure if the resetenv is absolutely necessary. I hope not, and I'll have to test without that line, but for now, the CuBox boots without manual intervention. You get a dog ugly YaST firstboot, which you can use to initially configure your CuBox. I've already asked Juergen Weigert if there is anything that can be done to get YaST to look a bit better when using screen. Here's a screenshot - as you can see the colours are all screwed up. YaST is functional, though.



 I submitted my change to uboot-image-setup to the openSUSE project. If it's accepted, we'll hopefully have a new CuBox image available for download here soon.

I'm going to have a look through the Solid Run Wiki and Forums next, to see if I can get an idea of what we'd need to do to get graphics up and running. I imagine there will be a hard brick (proprietary graphics driver) wall that we'll run into, but maybe we can make some progress before that and then try to solve the brick wall problem some other way.

Savita Halappanavar

It is quite difficult to decide on how to start to address this topic. The bare facts of the matter are, that an Indian national in the seventeeth week of pregnancy was brought to a hospital in Galway (Ireland) as she was suffering intense pain. Upon examination it was discovered that the foetus was no longer viable and that a severe risk to the life of the woman had been brought about. I think that it is relatively safe to state that those facts are undisputed, though I learned of them through hearsay only.

It is at this stage that the reports of what happened begin to differ and it becomes evident that there are various tales being told. Apparently, reasonable medical opinion would advise that an immediate termination of the pregnancy be brought about to mitigate the danger to the life of the woman. However, the husband of the woman was (apparently) told that such a termination was not possible in the Republic of Ireland because "[the Republic of Ireland is] a catholic country" and that as long as a foetal heartbeat could be detected, a termination would not be (legally) possible.

The sad facts of the matter are that the woman died thereafter. I believe it is undisputed that a timely termination would have saved her life. The story attracted huge attention in Ireland and was also reported in Germany. In India, there were also various newspaper reports. Almost invariably, the reaction appeared to be that the unfortunate woman died because Ireland's legal system protected the right of her unborn child to a higher degree than it protected her right to life.

Without getting involved in relatively futile quasi religious debate on whether the termination of pregnancy is morally acceptable or not, I think it is useful to look at the actual legal background behind abortion in Ireland.

The Irish Constitution was approved by referendum in 1937. Historians agree that the catholic church (which was by far the strongest religious body in Ireland back then and still remains dominant today) - in particular Archbishop McQuaid (he  later became Archbishop, that is) exerted considerable influence on the drafters. In fact, while protecting freedom of religion and prohibiting an established church, the 1937 constitution did (in Art 44.1.2) "[recognise] the special position of the Holy Catholic Apostolic and Roman Church as the guardian of the Faith professed by the great majority of the citizens". This reference was only removed in the Fifth Amendment in 1972. At the time the consitution was approved by referendum, abortion was officially illegal according to Section 57 of the Offences Against the Person Act from 1861. No provision of the original constitution specifically addressed abortion. The Eighth Amendment to the constitution in 1983 introduced a new clause into the Fundamental Rights section - Article 40.3.3 which stated: "The State acknowledges the right to life of the unborn and, with due regard to the equal right to life of the mother, guarantees in its laws to respect, and, as far as practicable, by its laws to defend and vindicate that right." This clause served to make it impossible for the legislature to create a law in the future that would legalise abortion.

As can be seen from the text of the Eighth Amendment, however, that amendment did not per se completely outlaw abortion - what it did do was put the right to life of the unborn child on par with the right to life of the mother - meaning that it was at least perceivable that the legislature could still pass a law which allowed abortion when there was a danger to the life of the mother.

In 1992 the Supreme Court (the most superior court in Ireland which is ultimately responsible for interpreting the constitution - akin the Supreme Court of the United States) decided the Attorney General vs X case. This was a case where a 14 year old girl was raped and as a result of this was pregnant. The girl and her parents wished to travel to England to terminate the pregnancy (in fact, they had already arrived in England). The Attorney General applied for (and was granted, in the High Court) an interlocutory injunction to prohibit the girl from travelling outside the country for the purpose of terminating the pregnancy. The girl appealed to the Supreme Court.

The Supreme Court overturned the interlocutory injunction, ruling that the real test to be applied should be:

"if it is established as a matter of probability that there is a real and substantial risk to the life, as distinct from the health, of the mother, which can only be avoided by the termination of her pregnancy, such termination is permissible, having regard to the true interpretation of Article 40,s.3, sub-s. 3 of the Constitution"

(see paragraph 37 http://www.bailii.org/ie/cases/IESC/1992/1.html - this was delivered by Chief Justice Finlay but see also Justice Egan's commentary at paragraph 183).

Thus, after Attorney General vs X it seemed as though it would not be unconstitutional for the legislature to enact a law which allowed termination of pregnancy if it could be established "as a matter of probability that there is a real and substantial risk to the life, as distinct from the health ... of the mother".

In the wake of the death of the woman in the hospital in Galway, much of the outrage seems to be aimed at a perceived prohibition of abortion in Ireland. As can be seen from the Supreme Court decision, however, in the case of the woman in Galway, it would have been perfectly legal to terminate the pregnancy had the irish legislature enacted a law since the X case (1992) to create the exception to allow an abortion where there is a real and substantial danger to the life of the mother.

The real scandal here is, that successive governments did absolutely nothing to enact such legislation. In fact, just a couple of months ago the United Left (a relatively new political group in the parliament) introduced a bill which would have at least brought about a parliamentary debate on legislating for the X Case. It did not even receive enough votes for that! You can read one side of those developments here: http://www.claredaly.ie/labour-and-fine-gael-bear-responsibility-for-death-of-woman-who-was-denied-abortion/

In summary, it was successive irish governments' failure to enact legislation that brought about the situation where the doctor(s) in the Galway hospital departed from what reasonable medical practitioners would have done - to terminate the pregnancy to save the woman's life (that last sentence is opinion only - I do not know the full facts necessary).


Mittwoch, 14. November 2012

openSUSE on CuBox (Day 4)

I left off yesterday wondering how difficult it would be to start building openSUSE images for the CuBox. After searching a bit I found that the KIWI tool seems to be the right one for the job - and indeed it is the tool that is used in the openSUSE Build Service to get this kind of job done on a huge scale. So far, so good. I read through the instructions over on http://en.opensuse.org/SDB:KIWI_Cookbook_Start_Cooking to see what the basic steps for cooking up a raw image are.

First off, I needed the actual content of the image - i.e. the kernel and root filesystem. Conveniently, the openSUSE ARM contributors have already got one cooked up that they "made earlier". To get in on my development machine (my laptop), all I needed to do was (I already had the osc tool installed):

osc bco openSUSE:12.2:ARM:Contrib:Cubox JeOS-cubox

That left me with the project fully checked out on my local disk. I started fooling around with kiwi, trying to configure, prepare and build an image for CuBox - a complete waste of time. It turns out that the Build Service has this covered already. No need for messing around with local kiwi builds. To get a raw image for CuBox all I had to do was:

osc build images armv7l JeOS-cubox.kiwi

Make sure qemu-linux-user is installed beforehand though - actually, you'd be well advised to follow all the (brief) instructions about getting started with ARM development for openSUSE  over at http://en.opensuse.org/openSUSE:ARM_distribution_howto in order to get your development machine ready.

I didn't go making changes to the image yet - I just wanted to see how easy or difficult it is to create an image by myself.

In summary, building images for CuBox is child's play - the openSUSE ARM people have already done the grunt work and the Build Service takes all the sweat and cursing out of the actual cooking.

Next, time for some real work - debugging the booting of the CuBox to find out why manual intervention is needed during UBoot, to get the kernel to boot.

Dienstag, 13. November 2012

openSUSE on CuBox (Day 3)

My CuBox uses very very little power, which makes it ideal for my use as a NAS server. So it sits here on my desk 24/7 and is "always on". That's why I started today pretty much where I left off yesterday - with openSUSE 12.2 running on the CuBox, but pretty much unconfigured.

YaST works quite well on the CuBox. It didn't have all the modules installed that I typically need, but all modules are available for installation and are only a quick zypper install yast2-<module> away. Here's a video I recorded for example's sake - I use the YaST samba client module to change the group membership.


Other than that, I didn't get around to doing much with the CuBox today. I still haven't found any serious bugs that stop me from using openSUSE 12.2 as a production NAS. My samba setup is back up and running and the CuBox is successfully exporting the contents of my NTFS formatted external USB drive (note, you'll need the ntfs-3g package in order to do this - luckily this is also just a zypper in away).

I'm now looking into (re)building the openSUSE image for CuBox using kiwi and the Build Service. I'd like to make the boot process work out of the box, so the workarounds described yesterday aren't needed anymore. On the other hand, if this image is as stable as the debian image I had deployed since last year, I may not need to boot again...

Montag, 12. November 2012

openSUSE on CuBox (Day 2)

I blogged a couple of days ago about how there is an openSUSE 12.2 image for the CuBox and how I wasn't getting past the line that stated something like "loading kernel". Well, after some time on the #opensuse-arm channel and some help from mmeister there, the CuBox has now really lifted off on openSUSE.

So, what is needed to get the CuBox up and running on openSUSE? Here's the juicy stuff (first connect up your serial connection with screen /dev/ttyUSB0 115200 and hit any key on startup to stop autoboot and to get into the uboot command prompt).

setenv kerneladdr 0x2000000
setenv ramdiskaddr 0x3000000
mmcinfo
ext2load mmc 0:1 $kerneladdr boot/linux.vmx
ext2load mmc 0:1 $ramdiskaddr boot/initrd.uboot
setenv bootargs "console=ttyS0,115200 root=/dev/mmcblk0p2"bootm $kerneladdr $ramdiskaddr

That should work for you and you should now be looking at openSUSE booting. There are a couple of interesting points to observe though - probably issues that need attention:

1. ext2load mmc 0:1 $kerneladdr boot/linux.vmx takes a long time
2. ext2load mmc 0:1 $ramdiskaddr boot/initrd.uboot takes ages (a minute)
3. once past that, booting itself takes a long time too

Other than that, the first thing that happens after booting is that you get landed into YaST - a very ugly YaST as the colours don't seem to work properly through screen. You get to choose your keyboard layout and language (works), your timezone (works) and you get to set up the root password and configure a local user (works).

As DHCP was automatically set up, you can check your ip address with ifconfig and try to log in through SSH - this is way more comfortable than messing about through the serial console.

So, the next things that need to be done (IMO) are:

1. see can we get a working boot.scr (i.e. so the above workaround isn't needed)
2. check to see if memory is being reserved for graphics (if so, stop this)
3. see if we can sort out the missing update repo

Freitag, 9. November 2012

openSUSE 12.2 on CuBox (Day 1)

On November 6th (2012) Jos announced openSUSE 12.2 for ARM. Devices like the BeagleBoard and PandaBoard are "officially" supported. Some other boards, including the CuBox are supported as "best efforts".

To get started, I had a look at the Wiki pages over on the Solid Run site. I noticed that there were entries for Fedora, Ubuntu and Gentoo etc under "Linux Distributions", but no entry for openSUSE (except that the wiki pointed out that Solid Run donated hardware to openSUSE - which they did). I figured that I might as well get a wiki page for openSUSE started. I copied the basic download and installation information from http://en.opensuse.org/HCL:CuBox and added some more information on how to get started as an openSUSE ARM developer/packager.

My own CuBox has been in action as a NAS server for almost a year now. Up until tonight, it was running on Debian. I never had a single issue with it - it ran the bones of twelve months without crashing once. An occasional apt-get update and apt-get upgrade kept it up to date and never caused grief. Thus, it was with a certain degree of apprehension that I decided to give openSUSE a spin.

To get a linux distribution "installed" on a CuBox all you really need to do (for a supported distribution) is to copy the distribution image to a micro SD card, stick the card in the CuBox and reboot - preferably watching the whole process on a connected serial console - using e.g. screen /dev/ttyUSB0 115200.

I first downloaded the appropriate openSUSE image (see http://en.opensuse.org/HCL:CuBox) and extracted it and dd'd it to the SD card as instructed. I stuck the SD card in the CuBox and started tracking the goings on of the bootloader through screen. I noticed pretty much immediately that not all was well in openSUSE land on CuBox. There were a series of nasty looking error messages, but it did look as though the bootloader finally found the linux kernel image, decompressed it and tried to boot from there. That's where nothing else worked. It is currently hanging at the "booting linux" statement.

Out of interest, I flashed my backup debian image to a different SD card and booted up on the CuBox. It booted as expected and got me into a root shell within seconds.

Thus, I anticipate a deal of debugging of the openSUSE image over the next couple of nights. Of the error message I did see, the ones relating to "kerneladdr" not defined and "ramdiskaddr" not defined seemed most serious.

You can have a look at the boot process here: http://pastebin.com/hHxiZJ5C