On how tech enthusiasts become tech detractors

Submitted by gwolf on Tue, 05/27/2014 - 10:04
On how tech enthusiasts become tech detractors

As often is the case, the Saturday Morning Breakfast Cereal webcomic (http://smbc-comics.com/ gets it right. And I cannot help but share today's comic.

The picture explains it much better than what I ever could.

( categories: )

Guest class: Jose Juan "Kaz" Casimiro ( @brit_kazito ) dissects the Ext4 filesystem module

Submitted by gwolf on Sat, 05/17/2014 - 16:49

Yesterday night, we had the opportunity to have –for the first time– my friend Kaz as a guest in my Operating Systems class. We are about to finish the semester, and he took the opportunity not just to show how the Ext4 filesystem is structured, but how it is implemented in a current Linux release.

Kaz took a very different approach from what I do: He did it really hands-on, starting with the explanation on how a hello world module would be created, and then digging in following the code of the ext4 module in Linux 3.14 (and some bits in the general filesystem-related includes).

Of course, for a ~2hr session, he did not go into the full details, but did show where the main structures of a filesystem are defined, including a general walkthrough on the general kernel coding style.

The class was very enjoyable and clear. We had the bad luck of the projector's lamp burning out at the beginning of the class, but still, you can see in the pictures the students were really into his exposition. I think the exposition did make it through and got the students involved and interested — And that makes it really worth it!

Now... Sadly, due to a (most probably) human factor, I tried to record this talk but lost most of it :-( I have only the first part, but lost most of the second one. I have some bits recorded by a second camera, but have to check if they make sense by themselves, or do need the whole context. Anyway, I'll be reviewing those bits, and will update this post when I get around to cleaning+fixing+integrating them.

Some more photos...

Guest class: César Yáñez (@caesarcomptus) talks about virtual memory

Submitted by gwolf on Sat, 05/17/2014 - 15:05

Shame on me... I should have uploaded this video a long time ago. I wanted to edit this video to remove pauses, add some in-band indications on who and what it is, and stuff... But after a month, I have not yet got around to do it.

On April 23, I invited César Yáñez to present a talk on virtual memory management to my students (for the Operating Systems class). As always (this is the third time I invite him — The previous iteration was on process scheduling, and is on my site as well), he gave a great class.

I still have some pending videos to upload from the other guests we had this semester, they should come shortly.

Correction for @osupiita

Submitted by gwolf on Mon, 05/05/2014 - 12:37

I was invited to give a talk at a local conference, OS-UPIITA. I have been invited to this conference before, and will gladly be there again. But I was recently pointed at the invitation poster they are distributing (which I reproduce here for your convenience) — And I must make a couple of corrections here:

  1. First and foremost: I don't want to trick anybody. I am not the Director of Debian Mexico. In fact, Debian Mexico does not exist. I am just a humble Debian Developer.
  2. I accept the conference title, because that's what they requested from me. I'm trying to come up with a coherent exposition, but whoever knows me must be perfectly aware that I don't know (nor really care about) how to make money with Free Software. I have lived all of my professional life thanks to Free Software, but I'm against the entrepenurial culture. I will talk about my vision, of course, so if you want to hear me rant, you are invited to join us ;-)
  3. I specifically asked the organizing committee by mid-April, when they gave me the talk title, to replace "Open Source" with "Free Software" in my talk. Even though the conference is called "OS UPIITA" (as it is the Open Source conference in the UPIITA unit of Instituto Politécnico Nacional), I cannot identify with the Open Source monkier. And if we are talking about a deeply ideological issue, which is the case here, I request to use the name I can relate with. For my talk only, of course.

</rant>

But anyway, I will be very happy to be there, and believe me, am working to come up with a good talk.

OS-UPIITA friends: Please correct your online banners carrying this wrong data.

[update] OS-UPIITA changed the poster! I'm just keeping this one for the memory ;-)

[update 2] I was there, and gave the talk. And it was even a success, yay! \o/ Care to see it? Here is the presented material.

( categories: )

Split regarding Docker

Submitted by gwolf on Tue, 04/29/2014 - 13:15

I have heard many good things about Docker, and decided to give it a spin on my systems. I think application-level virtualization has a lot to offer to my workflow...

But the process to understand and later adopt it has left me somewhat heart-torn.

Docker is clearly great technology, but its documentation is... Condescending and completely out of line with what I have grown used to in my years using Linux. First, there is so much simplistic self-praise sprinkled throughout it. There is almost no page I landed on that does not mention how user-friendly and user-centric Docker's commandline arguments are — They let you talk in almost plain1 English. What they don't mention is that... Well, that's the way of basically every command-line tool. Of course, as soon as you start specifying details to it, the plain-Englishness starts dilluting into a more realistic English-inspiredness...

Then... Things that go against our historical culture. It is often said that Windows documentation tends to be repetitive because users don't have the patience to read a full document. And our man pages are succint and to the point, because in our culture it is expected that users know how to search for the bit of information they are after. But reading documentation that's so excited with itself and praises again and again the same values and virtues, but never gets to the point I am interested in getting at (be it deployment, interoperation, description of the in-disk images+overlays layout, or anything moderately technical) never gets there... makes me quite unhappy.

Last (for now)... Such a continuous sales pitch, an insistence on the good virtues, makes me wary of something they might be hiding.

Anyway, at least for now, I just wanted to play a bit with it; I will wait at least until there is a backport to the stable Debian version before I consider moving my LXC VMs setup over to Docker (and a backport does not seem trivial to achieve, as Docker has several updated low-level dependencies we are unlikely to see in Wheezy).

But I had to vent this. OK, now go back to your regular work ;-)

  • 1. Of course, plain as long as you agree to a formal grammar... Details, details
( categories: )

DrupalCamp starting in 5... 4... 3... 2... ( → #DrupalCampMX )

Submitted by gwolf on Wed, 04/23/2014 - 09:26

Ok, so the day has come: Today begins the much awaited Drupal Camp Mexico City, yay!

For those that cannot make it to Mexico City, I understand understood1 we would have live streaming of at least one of the rooms, but anyway, talks will be recorded, and will be put online later on.

As for the talks schedule, here you have it. Yes, today my workmate and I will be giving a simple introduction to having a useful basic Drupal install. Today is the tutorials / workshops / BoF / hackathon day, and Thursday and Friday will be the more traditional talks days. Several of the talks on Thursday are grouped under the SymfonyDay track and will refer to the framework that serves as a base for Drupal 8.

Anyway, for the Tweetheads among the readers of this post, I understand information will flow under the #DrupalCampMX tag.

  • 1. I cannot find the link to the information, but it might appear later on... /mehopes
( categories: )

Mozilla: So our communitary echobox *does* resound with social issues

Submitted by gwolf on Thu, 04/03/2014 - 20:16

I woke up to the news that, after a very short tenure, Brendan Eich steps down as the Mozilla CEO.

Why? Because of the community outcry. Because some years ago, Eich pubilcly supported (and donated funds) the ban of any kind of marriages in California that were not between a man and a woman. The world has advanced enormously in this regard in the last years/decades, and so many individuals and organizations opposed and announced they would boycott Mozilla that either him or Mozilla could not stand the pressure anymore.

So, of course, it's sad the person had to resign. Many people talked about freedom of speech, freedom of harbouring his own personal opinion — But when it comes to the rights of minorities, particularly of minorities that have suffered such hard prejudice and abuse as the gay, lesbian and all the other non-orthodox sexual- and gender- orientations, righting a wrong is much more important than preserving an individual's freedom of opinion. Besides, it's not just thinking or talking about something — The concrete proposition Eich supported (and eventually made him resign) is about bringing the life of thousands of people to a hellish state of uncertainty, and going back to not having a way for the society to legally recognize their way of being, their love, their lifes.

But anyway — What prompts me into writing this is that, once again, the Free Software (and related denominations) community has shown that a set of core values, seemingly shared by a very large amount of our own people with no coordination or correlation with what conforms us as a community (and thus, being emergent traits), are strong enough to create a critical mass, to achieve cohesion. And that ours is not just a technical community of people writing software at all layers of the stack, but –first and foremost– is a group of social activists, committed to making the world better.

I will quote from Matthew Garrett's post on this topic, clearly more contundent and thorough that what I'm trying to come up with:

The Mozilla Manifesto discusses individual liberty in the context of use of the internet, not in a wider social context. Brendan's appointment was very much in line with the explicit aims of both the Foundation and the Corporation - whatever his views on marriage equality, nobody has seriously argued about his commitment to improving internet freedom. So, from that perspective, he should have been a fine choice.

But that ignores the effect on the wider community. People don't attach themselves to communities merely because of explicitly stated goals - they do so because they feel that the community is aligned with their overall aims. The Mozilla community is one of the most diverse in free software, at least in part because Mozilla's stated goals and behaviour are fairly inspirational. People who identify themselves with other movements backing individual liberties are likely to identify with Mozilla. So, unsurprisingly, there's a large number of socially progressive individuals (LGBT or otherwise) in the Mozilla community, both inside and outside the Corporation.

A CEO who's donated money to strip rights from a set of humans will not be trusted by many who believe that all humans should have those rights. It's not just limited to individuals directly affected by his actions - if someone's shown that they're willing to strip rights from another minority for political or religious reasons, what's to stop them attempting to do the same to you? Even if you personally feel safe, do you trust someone who's willing to do that to your friends? In a community that's made up of many who are either LGBT or identify themselves as allies, that loss of trust is inevitably going to cause community discomfort.

( categories: )

DrupalCamp Mexico City: April 23-25

Submitted by gwolf on Thu, 04/03/2014 - 08:30

We are organizing a DrupalCamp in Mexico City!

DrupalCamp Mexico City logo

As a Drupal user, I have so far attended two DrupalCamps (one in Guadalajara, Mexico, and one in Guatemala, Guatemala). They are –as Free Software conferences usually are– great, informal settings where many like-minded users and developers meet and exchange all kinds of contacts, information, and have a good time.

Torre de Ingeniería

Torre de Ingeniería, UNAM

This year, I am a (minor) part of the organizing team. DrupalCamp will be held in Torre de Ingeniería, UNAM — Just by Facultad de Ingeniería, where I teach. A modern, beautiful building in Ciudad Universitaria.

Talks, tracks

So, who is this for? You can go look at the accepted sessions, you will find there is a lot of ground. Starting from the very introduction to how Drupal is structured and some tips on how to work with it (delivered by yours truly), through workflows for specific needs, to strong development-oriented talks. The talks are structured along four tracks: "Training", "Theming", "Development", "Business" and "SymfonyDay".

"SymfonyDay"? Yes.

Drupal is a fast-evolving Free Software project. Most users are currently using versions 6 and 7, which are as different between each other as day and night... But the upcoming Drupal 8 brings even greater changes. One of the most interesting changes I can see is that Drupal will now be based on a full MVC framework, Symfony. One of the days of our DrupalCamp will be devoted to Symfony (dubbed the Symfony Day).

...And... Again, just look at the list of talks. You will find a great amount of speakers interested in coming here. Not just from Mexico City. Not just from Mexico. Not just from Latin America. I must say I am personally impressed.

Sponsors!

Of course, as with any volunteer-run conferences: We are still looking for sponsors. We believe being a DrupalCamp sponsor will greatly increase your brand visibility in the community you want to work with. There are still a lot of expenses to cover to make this into all that we want. And surely, you want to be a part of this great project. There are many sponsor levels — Surely you can be part of it!

( categories: )

Getting rid of rodents

Submitted by gwolf on Thu, 03/27/2014 - 12:28

So a good friend of mine talked about something in the debian-private mailing list. And we should not disclose that something outside such a sensible space without his approval.

But Jakub is right. Once the discussion goes over to only messages talking about non-private stuff, the discussion should be moved to a non-private area. After all, we will not hide problems yada yada, right?

So, not knowing where in the Debian lists this should go to, it will land on my blog, reformatting mail to make sense in this media:

Luca Filipozzi dijo [Wed, Mar 26, 2014 at 03:36:49PM +0000]:

Or don't use a mouse. When I started getting shoulder strain from using a mouse too much, I switched to an Adesso touchpad keyboard and was very happy with the positive outcome. I'm a touch (that's punny) less efficient with the touchpad compared to a mouse, but the lack of permanent injury and ongoing pain is worth it.

Right. I also have this keyboard (same brand even, different model). The keyboard is not that good (keys are not as smooth as in my previous, stock-Dell keyboard), but not having to move my right hand just to feed the rodent has made my back way way happier. I even feel better using a trackpad than a mouse (mabye because I use too much my netbook?).

Luca, just out of curiosity: Did you ever manage to recognize the keyboard under the Synaptics driver, or to get it running under ChordMiddle or Emulate3Buttons? I had to fall to a ugly hack, mapping the "XF86Search" key to the middle button by telling my window manager (i3) to "bindsym X86Search exec xdotool click 2".

[ this can be declassified at any time ]

my contributions to this thread too...

my contribution unclassified, also

My classifications remain contributed. Do as you will with my bits of this message.

( categories: )

Trying to get Blender to run in the CuBox-i (armhf): Help debugging Python!

Submitted by gwolf on Sat, 03/15/2014 - 22:10

As I posted some weeks ago, I have been playing with my CuBox-i4Pro, a gorgeous little ARM machine by SolidRun, built around an iMX6 system-on-a-chip.

My first stabs at using it resulted in my previous post on how to get a base, almost-clean Debian distribution to run (Almost? Yes, the kernel requires some patches not yet accepted upstream, so I'm still running with a patched 3.0.35-8 kernel). After writing this step by step instructions, I followed them and built images ready to dd to a SD card and start running (available at my people.debian.org space.

Now, what to do with this little machine? My version is by no means a limited box: 4 ARM cores, 2GB RAM make a quite decent box. In my case, this little machine will most likely be a home storage server with little innovation. However, the little guy is a power server, at only 3W consumption. I wanted to test its capabilities to do some number crunching and aid some of my friends — The obvious candidate is building a Blender render farm. Right, the machines might be quite underpowered, but they are cheap (and look gorgeous!), so at least it's worth playing a bit!

Just as a data point, running on an old hard disk (and not on my very slow SD card), the little machine was able to compile the Blender sources into a Debian package in 89m13.537s, that is, 5353 seconds. According to the Debian build logs (yes, for a different version, I tried with the version in Wheezy and in a clean Wheezy system), the time it took to build on some other architectures' build daemons was 1886s on i386, 1098s on PowerPC, 2003s on AMD64, 11513s on MIPS and 27721 on ARMHF. That means, my little machine is quite slower than desktop systems, but not unbearably so.

But sadly, I have hit a wall, and have been unable to do any further progress. Blender segfaults at startup under the Debian armhf architecture. I have submitted bug report #739194 about this, but have got no replies to it yet. I did get the great help from my friends in the OFTC #debian-arm channel, but they could only help up to a given point. It seems the problem lies in the Python interpreter in armhf, not in Blender itself... But I cannot get much further either. I'm sending this as a blog post to try to get more eyeballs on my problem — How selfish, right? :-)

So, slightly going over the bug report, blender just dies at startup:

  1. $ blender -b -noaudio
  2. Segmentation fault

After being told that strace is of little help when debugging this kind of issues, I went via gdb. A full backtrace pointed to what feels like the right error point:

  1. (gdb) bt full
  2. #0 0x2acd8cce in PyErr_SetObject ()
  3. from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0
  4. No symbol table info available.
  5. #1 0x2acd8c9a in PyErr_Format ()
  6. from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0
  7. No symbol table info available.
  8. #2 0x2ac8262c in PyType_Ready ()
  9. from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0
  10. No symbol table info available.
  11. #3 0x2ac55052 in _PyExc_Init ()
  12. from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0
  13. No symbol table info available.
  14. #4 0x2ace95e2 in _Py_InitializeEx_Private ()
  15. from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0
  16. No symbol table info available.
  17. #5 0x00697898 in BPY_python_start (argc=3, argv=0x7efff8d4)
  18. at /build/blender-dPxPUD/blender-2.69/source/blender/python/intern/bpy_interface.c:274
  19. py_tstate = 0x0
  20. py_path_bundle = 0x0
  21. program_path_wchar = L"/usr/bin/blender", '\000' <repeats 1007 times>
  22. #6 0x0044a1ca in WM_init (C=C@entry=0x1d83220, argc=argc@entry=3,
  23. argv=argv@entry=0x7efff8d4)
  24. at /build/blender-dPxPUD/blender-2.69/source/blender/windowmanager/intern/wm_init_exit.c:176
  25. No locals.
  26. #7 0x0042e4de in main (argc=3, argv=0x7efff8d4)
  27. at /build/blender-dPxPUD/blender-2.69/source/creator/creator.c:1597
  28. C = 0x1d83220
  29. syshandle = 0x1d8a338
  30. ba = 0x1d8a840
  31. (gdb)

I'm not pasting here the full bug history (go to the bug report for the full information!), but it does point me to this being a problem in Python-land: It points to something not found at line 59 of Python/errors.c. And what I understand from that line is that some kind of unknown exception is thrown, and the Python interpreter does not now what to do with it. The check done at line 59 is the if (exception != NULL ** ....:

  1. void
  2. PyErr_SetObject(PyObject *exception, PyObject *value)
  3. {
  4. PyThreadState *tstate = PyThreadState_GET();
  5. PyObject *exc_value;
  6. PyObject *tb = NULL;
  7.  
  8. if (exception != NULL &&
  9. !PyExceptionClass_Check(exception)) {
  10. PyErr_Format(PyExc_SystemError,
  11. "exception %R not a BaseException subclass",
  12. exception);
  13. return;
  14. }

So... Dear lazyweb: Any pointers on where to go on from here?

kthxbye.

( categories: )

Pushing keyring updates. Let us bury your old 1024D key!

Submitted by gwolf on Mon, 03/03/2014 - 13:09

I have just pushed our pseudo-monthly batch of keyring updates to Debian. I am happy to inform you that, while the situation described in Clint Adams' interesting assessment of the state of the Debian keyring (and the quite constructive conversation that followed) still holds, and we still have way too many weak (1024D) keys in the Debian keyring, we got a noticeable effect as a result of said thread: 20 key upgrade requests in somewhat over a one week period! (mostly from DDs, with two from DMs IIRC).

So, for any DD or DM reading this and not following the debian-project list where this thread took place:

As keyring maintainers, we no longer consider 1024D keys to be trustable. We are not yet mass-removing them, because we don't want to hamper the project's work, but we definitively will start being more aggressively deprecating their use. 1024D keys should be seen as brute-force vulnerable nowadays. Please do migrate away from them into stronger keys (4096R recommended) as soon as possible.

If you have a key with not-so-many active DD signatures (with not-so-many ≥ 2) waiting to get it more signed, stop waiting and request the key replacement.

If you do not yet have a 4096R key, create a new one as soon as possible and get some signatures on it. Once ≥2 DDs have signed it, please request us to replace your old key. If you cannot get to meet two DDs in person, please talk to us and we will find out what to do.

( categories: )

Like a Lord and Lady, with my dearest passions...

Submitted by gwolf on Sat, 02/15/2014 - 11:03
Like a Lord and Lady, with my dearest passions...

For those of you who didn't yet know it: My mother is a painter. A serious, professional, respected painter. But she sometimes goes to the funny side as well — Of course, with all due professionalism!

So, she gave us this great gift: She took one of our pictures from DebConf12 (from the "Conference Dinner" night), and painted it. Real size even!

So, next time you come to our house, even if we are not around to greet you, we will be glad to welcome you to the Residence!

( categories: )

CuBox-i4Pro

Submitted by gwolf on Sun, 02/02/2014 - 11:44
CuBox-i4Pro

Somewhere back in August or September, I pre-ordered a CuBox-i — A nicely finished, completely hackable, and reasonably powerful ARM system, nicely packaged and meant to be used to hack on. A sweet deal!

There are four models (you can see the different models' specs here) — I went for the top one, and bought a CuBox-i4Pro. That means, I have a US$130 nice little box, with 4 ARM7 cores, 2GB RAM, WiFi, and... well, all of its basic goodies and features. For some more details, look at the CuBox-i block diagram.

I got it delivered by early January, and (with no real ARM experience on my side) I finally got to a point where I can, I believe, contribute something to its adoption/usage: How to get a basic Debian system installed and running in it.

The ARM world is quite different to the x86 one: Compatibility is much harder, the computing platform does not self-describe properly, and a kernel must first understand how a specific subarchitecture is before being able to boot on it. Somewhere in the CuBox forums (or was it the IRC channel?) I learnt that the upstream Linux kernel does not yet boot on the i.MX6 chip (although support is rumored to be merged for the 3.14 release), so I am using both a kernel and an uBoot bootloader not built for (or by) Debian people. Besides that, the result I will describe is a kosher Debian install. Yes, I know that my orthodox friends and family will say that 99% kosher is taref... But remember I'm never ever that dogmatic. (yeah, right!)

[update]: Read on if you want to learn the process. If you just want to get the image and start playing with your box, you can go ahead and download it from my people.debian.org space.

Note that there is a prebuilt image you can run if you are so inclined: In the CuBox-i forums and wiki, you will find links to a pre-installed Debian image you can use... But I cannot advise to do so. First, it is IMO quite bloated (you need a 4GB card for a very basic Debian install? Seriously?) Second, it has a whole desktop environment (LXDE, if I recall correctly) and a whole set of packages I will probably not use in this little box. Third, there is a preinstalled user, and that's a no-no (user: debian, password: debian). But, most importantly, fourth: It is a nightly build of the Testing (Jessie) suite... Built back in December. So no, as a Debian Developer, it's not something we should recommend our users to run!

So, in the end and after quite a bit of frustration due to my lack of knowledge, here goes the list of steps I followed:

Using the CuBox
On the i2 and i4 models, you can use it either with a USB keyboard and a HDMI monitor, or by a serial consoles (smaller models do not have a serial console). I don't have a HDMI monitor handy (only a projector), so I prefer to use the serial terminal. Important details to avoid frustration: The USB keyboard has to be connected to the lower USB port, or it will be ignored during the boot process. And make sure your serial terminal is configured not to use hardware flow control. Minicom is configured by default to use hardware flow control, so it was not sending any characters to the CuBox. ^A-O gets you to the Minicom configuration, select Serial port setup, and disable it.
Set up the SD card
I created a 2GB partition, but much less can suffice; I'd leave it at least to 1GB to do the base install, although it can be less once the system is set up (more on this later). Partition and format using your usual tools (fdisk+mke2fs, or gparted, or whatever suits your style).
Install the bootloader
I followed up the instructions on this CuBox-i forums thread to get the SPL and uBoot bootloader running. In short, from this Google Drive folder, download the SPL-U-Boot.img.xz file, uncompress it (xz --decompress SPL-U-Boot.img.xz), and write it to the SD card just after the partition map: As root,
# dd if=SPL-U-Boot.img of=/dev/mmcblk0 bs=1024 seek=1 skip=1.
Actually, to be honest: As I wanted something basic to be able to debug from, I downloaded (from the same Google Drive) the busybox.img.gz file. That's a bit easier to install from: xz --decompress busybox.img.xz, and just dump it into the SD from the beginning (as it does already include a partition table):
# dd if=busybox.img of=/dev/mmcblk0
This card is already bootable and minimal, and allows to debug some bits from the CuBox-i itself (as we will see shortly).
After this step, I created a second partition, as I said earlier. So, my mmcblk0p1 partition holds Busybox, and the second will hold Debian. We are still working from the x86 system, so we mount the SD card in /media/mmcblk0p2
Installing the base system
Without debian-installer to do the heavy lifting, I went for debootstrap. As I ran it from my PC, debootstrap's role will be for this first stage only to download and do a very initial pre-unpacking of the files: Bootstrapping a foreign architecture implies, right, using the --foreign switch:
debootstrap --foreign --arch=armhf wheezy /media/mmcblk0p2 http://http.debian.net/debian
You can add some packages you often use by specifying --include=foo,bar,baz
So, take note notes: This board is capable of running the armhf architecture (HF for Hardware Float). It can also run armel, but I understand it is way slower.
First boot (with busybox)
So, once debootstrap finishes, you are good to go to the real hardware! Unmount the SD card, put it in the little guy, plug your favorite console in (I'm using the serial port), and plug the power in! You should immediately see something like:
  1. U-Boot SPL 2013.10-rc4-gd05c5c7-dirty (Jan 12 2014 - 02:18:28)
  2. Boot Device: SD1
  3. reading u-boot.img
  4. Load image from RAW...
  5.  
  6.  
  7. U-Boot 2013.10-rc4-gd05c5c7-dirty (Jan 12 2014 - 02:18:28)
  8.  
  9. CPU: Freescale i.MX6Q rev1.2 at 792 MHz
  10. Reset cause: POR
  11. Board: MX6-CuBox-i
  12. DRAM: 2 GiB
  13. MMC: FSL_SDHC: 0
  14. In: serial
  15. Out: vga
  16. Err: vga
  17. Net: phydev = 0x0
  18. Phy not found
  19. PHY reset timed out
  20. FEC
  21. (Re)start USB...
  22. USB0: USB EHCI 1.00
  23. scanning bus 0 for devices... 1 USB Device(s) found
  24. scanning usb for storage devices... 0 Storage Device(s) found
  25. scanning usb for ethernet devices... 0 Ethernet Device(s) found
  26. Hit any key to stop autoboot: 3

Let it boot (that means, don't stop autoboot), and you will soon see a familiar #, showing you are root in the busybox environment. Great! Now, mount the Debian partition:
# mount /dev/mmcblk0p2 /mnt
Finishing debootstrap's task
With everything in place, it's time for debootstrap to work. Chroot into the Debian partition:
# chroot /mnt
And ask Debootstrap to finish what it started:
# /debootstrap/debootstrap --second-stage
Be patient, as this step takes quite a bit to be finished.
Some extra touches...
After this is done, your Debian system is almost ready to be booted into. Why almost? Because it still does not have any users, does not know its own name nor knows I want to use it via a serial terminal, and does not know how the filesystems should be mounted and made available. And having a Debian system means having its very extensive software repository collection handy! Five very simple tasks to fix:
  1. Set a password for root:
    1. # passwd
    2. Enter new UNIX password:
    3. Retype new UNIX password:
    4. passwd: password updated successfully
  2. Setting your hostname is trivial:
    1. # echo cubox-i.gwolf.org > /etc/hostname

    So you have now a usable root user, and when you boot with it you can create further users.
  3. Now, to get the serial console working (you might not need it, if you use the CuBox-i via keyboard+monitor) add a line to /etc/inittab specifying the details of the serial console. You can just do this:
    1. # echo 'T0:23:respawn:/sbin/getty -L ttymxc0 115200 vt100' >> /etc/inittab
  4. Create a /etc/fstab specifying how the system will be laid out. Right now, it is quite trivial (and in fact, I used my machine for some time without even thinking about this, just using the parameter provided to the kernel, this setting will just give you an easier and even faster experience):
    1. # cat > /etc/fstab
    2. /dev/mmcblk0p2 / ext3 noatime 0 0
    3. /dev/mmcblk0p1 /boot ext2 ro 0 0
    4. proc /proc proc defaults 0 0
    5. tmpfs /tmp tmpfs defaults 0 0
    6. tmpfs /run tmpfs defaults 0 0
  5. Tell your computer where to get the Debian packages. I suggest you use the http.debian.net meta-mirror, which will resolve to the mirror closest to you, but you can of course choose from the worldwide list of Debian mirrors.
    # echo deb http://http.debian.net/debian wheezy main > /etc/apt/sources.list
    # echo deb-src http://http.debian.net/debian wheezy main > /etc/apt/sources.list
    
Boot into Debian!
So, ready to boot Debian? Ok, first exit the chroot shell, to go back to the Busybox shell, unmount the Debian partition, and set the root partition read-only:
  1. # exit
  2. # umount /mnt
  3. # mount / -o remount,ro

Disconnect and connect power, and now, do interrupt the boot process when you see the Hit any key to stop automount prompt. To see the configuration of uboot, you can type printenv — We will only modify the parameters given to the kernel:
  1. CuBox-i U-Boot > setenv root /dev/mmcblk0p2 rootfstype=ext3 ro rootwait
  2. CuBox-i U-Boot > boot

So, the kernel will load, and a minimal Debian system will be initialized. In my case, I get the following output:
  1. ** File not found /boot/busyEnv.txt **
  2. 4703740 bytes read in 390 ms (11.5 MiB/s)
  3. ## Booting kernel from Legacy Image at 10000000 ...
  4. Image Name: Linux-3.0.35-8
  5. Image Type: ARM Linux Kernel Image (uncompressed)
  6. Data Size: 4703676 Bytes = 4.5 MiB
  7. Load Address: 10008000
  8. Entry Point: 10008000
  9. Verifying Checksum ... OK
  10. Loading Kernel Image ... OK
  11.  
  12. Starting kernel ...
  13.  
  14. Unable to get enet.0 clock
  15. pwm-backlight pwm-backlight.0: unable to request PWM for backlight
  16. pwm-backlight pwm-backlight.1: unable to request PWM for backlight
  17. _regulator_get: get() with no identifier
  18. mxc_sdc_fb mxc_sdc_fb.2: NO mxc display driver found!
  19. INIT: version 2.88 booting
  20. [info] Using makefile-style concurrent boot in runlevel S.
  21. [....] Starting the hotplug events dispatcher: udevd. ok
  22. [....] Synthesizing the initial hotplug events...done.
  23. [....] Waiting for /dev to be fully populated...done.
  24. [....] Activating swap...done.
  25. [....] Cleaning up temporary files... /tmp. ok
  26. [....] Activating lvm and md swap...done.
  27. [....] Checking file systems...fsck from util-linux 2.20.1
  28. done.
  29. [....] Mounting local filesystems...done.
  30. [....] Activating swapfile swap...done.
  31. [....] Cleaning up temporary files.... ok
  32. [....] Setting kernel variables ...done.
  33. [....] Configuring network interfaces...done.
  34. [....] Cleaning up temporary files.... ok
  35. [....] Setting up X socket directories... /tmp/.X11-unix /tmp/.ICE-unix. ok
  36. INIT: Entering runlevel: 2
  37. [info] Using makefile-style concurrent boot in runlevel 2.
  38. [....] Starting enhanced syslogd: rsyslogd. ok
  39. [....] Starting periodic command scheduler: cron. ok
  40.  
  41. Debian GNU/Linux 7 cubox-i.gwolf.org ttymxc0
  42.  
  43. cubox-i login:

And that's it, the system is live and ready for my commands!

So, how big is this minimal Debian installed system? I cheated a bit on this, as I had already added emacs and screen to the system, so yours will be a small bit smaller. But anyway — Lets clear our cache of downloaded packages, and see the disk usage information:

  1. root@cubox-i:~# apt-get clean
  2. root@cubox-i:~# df -h
  3. Filesystem Size Used Avail Use% Mounted on
  4. rootfs 689M 228M 427M 35% /
  5. /dev/root 689M 228M 427M 35% /
  6. devtmpfs 881M 0 881M 0% /dev
  7. tmpfs 177M 144K 177M 1% /run
  8. tmpfs 5.0M 0 5.0M 0% /run/lock
  9. tmpfs 353M 0 353M 0% /run/shm
  10. tmpfs 881M 0 881M 0% /tmp

So, instead of a 4GB install, we have a 228MB one. Great improvement!

For this first boot, and until you set up a way to automatically (or configure it to be static) determine the network configuration, you can use dhclient eth0 to request an IP address via the wired network port (configuring the wireless network is a bit more involved; I suggest you install the wicd-curses package to help on that regard). With the network working, update the Debian package lists:

# apt-get update
Get:1 http://http.debian.net wheezy Release.gpg [1672 B]
Get:2 http://http.debian.net wheezy Release [168 kB]
Get:3 http://http.debian.net wheezy/main Sources [5956 kB]
Get:4 http://http.debian.net wheezy/main armhf Packages [5691 kB]              
Get:5 http://http.debian.net wheezy/main Translation-en [3849 kB]              
Fetched 15.7 MB in 1min 27s (180 kB/s)                                         
Reading package lists... Done
Reading package lists... Done
Building dependency tree... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Yay, all of Debian is now at your fingertips! Now, lets get it to do something useful, in a most Debianic way!

[note]: I have tried to keep this as true as possible to the real install. I have modified this text every now and then, looking at ways to make it a little bit better. So, excuse me if you find any inconsistencies in the instructions! :)

[update]: I finally followed through the instructions again and produced a downloadable image, where I did all of this work, and you can just download it and play with your CuBox-i! You can download it from my people.debian.org space. You will find there instructions on how to get it installed.

( categories: )

Ligatured iceweasel

Submitted by gwolf on Thu, 01/23/2014 - 13:34
Ligatured iceweasel

I am not (yet?) reporting this as a bug as this happened with a several days old session open, and just while I was upgrading my Sid system, after a long time without doing so (probably since before the vacations started... In December 2013). But I cannot avoid sharing this interesting screenshot.

Of course, this does not happen in other browsers. And AFAICT it only happens while reading the Debian Policy (either online or locally, even recoding it to UTF-8). Funniest thing, the Debian policy specifies no Javascript, no stylesheets at all...

(Hey, and FWIW... Why is the online copy of the Debian policy still in iso-8859-1‽ It's not 1995 anymore...)

[update] Of course, it's the default font, not only the Debian policy. Just as an example, the following text:

  1. <html><body><p>Ufffiii flat different!</p></body></html>

Yields the following output:

[update 2] And, of course, after finishing the update process... I got a new version of Iceweasel. Restarted it, and everything is back to normal :-}

( categories: )

Finally: A student once again

Submitted by gwolf on Tue, 01/21/2014 - 21:47

Formally, today is my first day as a student on a formal, scholarized institution — Basically for the first time in almost twenty years!

Yes, those that know me know that I aspire to live the life of academia. I have worked at public universities for almost all of my adult life (between 1997 and 1999 I worked at a local ISP and at a private school), and have had a minor academic position («Técnico Académico») for almost ten years. And not having a proper degree limited me from pursuing anything further.

Then, in early 2010 I presented the written exam. By late 2010, the corresponding oral exam. That allowed me to get my formal diploma in December 2010. By the end of 2011, I requested to be a teacher in the Engineering Faculty of UNAM, and started teaching Operating Systems a year ago, in January 2012.

So, a good advance in the last few years... But I know that if I just sit here, I won't be able to advance my position towards really entering the Sacred Halls of Academia. And there are some rituals I have to comply with. One of those rituals is... Devoting some long time to studying under the formal structures.

Ok, so I'm finally a postgraduate student — I have enrolled in Especialidad en Seguridad Informática y Tecnologías de la Información, a short (one year) postgraduate program in ESIME Culhuacán, of Instituto Politécnico Nacional (a small campus of Mexico's second-largest university).

Some friends have asked me, why am I starting with a Specialization and not a Masters degree. Some simple reasons: Just as when I went to Tijuana in 2010 to do my written exam, once I got and started with the paperwork, I didn't want to let it go — If I postpone it, I will probably lose the push to do it by May-July, when the Masters admission process starts. Also, this specialization can be linked with the masters degree on the same topic given at the same campus. This program is one year long, and the masters two — But having them both takes 2.5 years. So, not such a bad deal after all. And finally, because, after such a long time without being scholarized, I fear not having an easy time getting to grips with the discipline. I can commit to overworking myself for a year — If it's too much for me, I'll just stay with that degree and give up. I expect to like it and continue... But it's also a safe bet :-)

Now, there has to be a downside to picking up this path: Of course, my free time will be harshly reduced. I have reduced my Debian involvement in the last year, as I devoted a huge chunk of my time to teaching and book-writing... This year... We shall see what happens. I can for now only confirm what I have said publicly but inside our team only: I have requested to my peers and to our DPL to step down as a DebConf chair. I love organizing DebConf, but I don't want to be formally committed to a position I just cannot fulfill as I did when I started with it. As for package maintenance, by far most of my packges are team maintained, and those that are not are relatively easy to keep track of. And of course, I'll keep an eye on my keyring-maint duties as well — Will even try to link that work with what I do at school!

Anyway, lets see what comes now!

( categories: )
Syndicate content