Archive for 15 noviembre 2015

Debian Live NG

noviembre 15, 2015


I am the main Rescatux developer so I use live-build and many other live-* tools in order to be able to produce Rescatux live cd images. Rescatux is a Debian GNU/Linux derivative. Despite of the way the article is written I am not expert at all in Debian so please take this with a grain of salt. I am not a lawyer so please take the legal explanation with a grain of salt.

TL;DR: Debian core members taking control of Debian Live build upset current maintainer. Many people get angry because of nearly absent communication skills. Quite similar to systemd mess.

Probably the easiest way of explaining what it’s happening around Debian Live is explaining what has happened in the last days in Cambridge MiniDebconf and in the Debian Live mailing list chronologically. But that would mean having to repeat everything again in order to make sense of it. So, I’ll try to first explain some terms and background, then I will explain two main processes which are going on, and finally I will clarify some misunderstandings. Don’t forget the media predictions. Let’s begin!

What is Debian

That it’s a good question. When you ask someone about Debian they say that it’s a distribution. If you ask about Ubuntu, yes, it’s also distribution. But what about its developers ? Canonical is the main developer / company behind Ubuntu. It might not code most code but Canonical makes the decisions. Who makes the decisions at Debian? Well, it’s a conglomerate of Debian Developers and community. In some special occasions the technical committee (like a council of wise people) needs to decide about it. They went recently public because of being asked about systemd.

Official Debian is the contents of the main archive and the installation and live images that are produced by debian-cd. The Debian Project is larger than that however, and there is a lot of infrastructure provided to assist in the development of Debian.

What is an Upstream

In the open source world they usually use the river paradigm to show how program source code is reused. So basically everything begins at the top of a mountain where there are plenty of snow flakes. These are the developers ideas which need to be heat into something usable.

So the water begins to flow from the mountains downstream. However let’s suppose that those waters don’t mix to make rivers but just creeks or little streams. There are too many creeks and their waters are not always drinkable. Someone needs to try them, to purge the ones which are too bitter and to put the best ones of them into a simple preserving jar.

That’s the work of distributions. Put third party open source together if they meet some minimum requirements.

So an upstream is someone that provides source code to another party (usually they are offered to the world thanks to free software licenses) so that it can be reused. A downstream is someone who consumes previously offered source code.

So Apache it’s upstream to Debian. Debian is downstream to Apache. Debian is upstream to Ubuntu. Ubuntu is downstream to Debian. Ubuntu is upstream to Mint. Mint is downstream to Ubuntu. I hope you get the idea.

What are not Debian upstreams

Those projects which development is done inside official development machines. Those projects which are usually only useful for Debian or derivatives. This is what I call pure Debian, well, official Debian if you want to.

Development done on Alioth are an special case. As Alioth machines are not managed by Debian System Administrators that means that it’s not pure Debian. However projects and documentation hosted there are usually considered part of the Debian Project.

What is a trademark

A trademark is a recognizable sign, design, or expression which identifies products or services of a particular source from those of others. (Adapted from wikipedia).

The Coca Cola example is very easy. But you should think when there were not trademarks. One could try to mimic the Coca Cola taste thanks to some powder and gas. Then one could just photocopy the Coca Cola logo and say that it was the same thing. Coca Cola will not earn anything and the final customer will be mislead.

So, basically, you cannot pretend to sell any trademark goods if you aren’t allowed by them in one form or another. And, of course, you cannot say that you are related to that trademark if you are not.

What about Debian trademark

The same way as Ubuntu enforces its trademark Debian also enforces his. Not everyone can claim to be Debian in theory. Not any should project should have Debian in its name in order not to be mistaken for Debian. Some clarification on these trademark policies is projected though.

What is Debian Live

Debian Live project or Live Systems project maintains the components to build Debian based Live systems and the (prior to 2016 at least) official Debian Live images themselves.

A Debian Live system is a Debian operating system that does not require a classical installer to use it. It comes on various media, including CD-ROM, USB sticks, or via netboot.

The project also offered some prebuilt images. Currently, builds for four main desktop environments GNOME, KDE, LXDE, and Xfce as well as Cinnamon and MATE. A gui-less “standard” system was available too.

Special facts about Debian Live

Debian Live is an upstream project to Debian. Why? Because, as we explained before, it’s not being developed inside official Debian machines. was not hosted on Debian infrastructure but on Daniel Baumann’s private server.

Debian Live is probably violating Debian trademark. It has been so many years that the project has been entangled with Debian itself that’s it’s quite picky. Copyright on the source code files seems fine but the project has been using debian-live in both the irc channel and mailing list.

I’m not a lawyer but the point I want to make here about the trademark is that what we know as Debian Live is not Debian per se. It’s not official Debian because of two main reasons: It’s being developed outside Debian development machines and because it’s an upstream to Debian.

You cannot be part of ‘pure Debian’ and ‘upstream to Debian’ at the same time. Well, you can actually be but you know what I mean. That’s not usually the case.

I don’t know the exact history but it seems that at the beginning Debian Live was more Debian than Daniel Baumman. You know what I mean, Debian Live were the people which within Debian wanted Debian to be able to boot as a Live system.

Then, slowly each year Debian Live was mistaken as the Daniel’s project. Yes, it’s mainly the Daniel project, don’t get me wrong, he has been the main contributor over all these years.

Debian Lack of Manpower

Many open source projects lack of manpower for being updated and patched. The pure Debian projects suffer the same problem. Donations cannot be used to hire developers because of most Debian development is volunteer work. Former ways of trying that Debian itself redirect funds to that task has failed.

That lack of manpower on pure Debian projects make developers to struggle to meet on debconfs and minidebconfs doing sprints to finish their pending work. More on that later.

Debian CD

It’s a team inside Debian that produce CDs and DVDs to help people install Debian. Among other teams they work closely with debian-installer, release team an architecture porters.

Its main work consist of two tasks:

  • Developing the debian-cd software itself
  • Using that software regularly to generate and publish CD and DVD images, both daily/weekly for testing images and straight after each release for official stable images

Debian CD and Debian Live

If we take a look at one daniel’s messages on the mailing list we will see that he mentions:

when we agreed that the official live-images are built on petterson, we did exactly that – we delegated only the “execution” of our build system over to debian-cd, not the “authority” to decide which/how images are built or built with.

That would mean that prior to this agreement the official live-images were built somewhere else, probably on Daniel’s servers.

Debian CD, as their duty is, they would have decided that official cds need to be built on Debian machines so they would have convinced Daniel not to continue to build official live-images on his machines.

That, in my opinion, it was something to be done. So instead of saying: Don’t build the images yourself or we will sue you they got on well on terms.

As long as the Debian CD team has the duty of releasing the official cds it’s them whom decide which/how images are built or built with. There would be nothing wrong about that contrary to what Daniel says.

Yes, there might a problem with the way of communicating or not communicating these changes but we wll take a look at them later.

What it’s UEFI

Basically it’s a new BIOS (A program run in the computer before the OS is loaded and takes control of the computer) which replaces the old BIOS standards (actually there were no standards before). Some computers supports both UEFI and BIOS, old computers only support BIOS and more and more new machines will only support UEFI.

The Unified Extensible Firmware Interface (UEFI) is a specification that defines a software interface between an operating system and platform firmware. UEFI replaces the Basic Input/Output System (BIOS) firmware interface originally present in all IBM PC-compatible personal computers, with most UEFI firmware implementations providing legacy support for BIOS services. UEFI can support remote diagnostics and repair of computers, even with no operating system installed.

On the PC architectures (amd64 and i386), UEFI-based firmware is a relatively new replacement for the ancient BIOS (Basic Input/Output System) that has existed ever since the PC was first developed in the 1980s. The old BIOS systems have strict limitations due to their ancient design, running in 16-bit mode with access to only 1MB of memory, and limited access to other resources like disks. UEFI firmware is normally fully native and so should be able to access all the system memory and all the devices.

For the sake of backwards compatibility, most current PCs using UEFI also include a Compatibility Support Module (CSM), extra support code that will continue to boot in the old BIOS style. Over time, this support will most likely be phased out. Some systems were already being sold UEFI-only (i.e. with no CSM) in 2014.

Debian CD, UEFI and Debian Live

Debian CD needed UEFI support on their released cds. So after many tests they released Debian Jessie with UEFI support on them.

However on the Debian Live side:

RFE bug for UEFI on Debian Live was sent on November 2013 and has been updated till September 2015 to reflect new patches and ideas.

Daniel blocked this bug on March 2014 by saying that:

right now i’d perfere not merge patches introducing other copyright
holders. that probably changes in ~october this year though.

Even when October 2014 did end he did not update if he accepted the patch or not due only to the Copyright issues. It would seem that not accepting a patch for Copyright issues would be innaceptable from the Debian side.

I asked myself Daniel on Debconf15 about UEFI support. He told me that two ways of implementing UEFI went sent but that none of them were technically enough accurate. I think he told me that he was finally going to implement himself but I’m not sure on this point. He never told anything about the copyright issues though.

Later on on the same Debconf15 we were  at the Debian Derivatives Panel discussion where the Lernstick guys were convinced its UEFI work to be sent to the UEFI bug just in case it helped.

Debian CD sprints

As I mentioned earlier the Debian work is a volunteer work and so it is the Debian CD one. That means that Debian CD people usually meet in Debconfs and minidebconfs to try to fullfill some goals. Adding UEFI support to Debian Installation CDs was one of these and has been worked out for about three or four years right now.

Debian CD team Debian Live impression

According to a recent message from Neil Williams on the name conflicting bug: it would seem that:

to be able to solve the existing problems with live-build. These problems include reliability issues, lack of multiple architecture support and lack of UEFI support.

Then we learn that a replacement for Debian Live was needed in urge.

It is the team. Steve has been asking me for this support in vmdebootstrap for months and months. Every time there is a release or a point release, I get more nagging because he has to struggle with fixing live-*.


This comes from the debian-cd team. Steve has been nagging me for vmdebootstrap support to replace live-build since about a week after vmdebootstrap arrived in Debian, certainly before the Jessie release.

Later on in the same bug we learn the same thing, that live-build not being appropiated was an old issue (but probably not made public):

The debian-cd team deprecated live-build and have been looking for a replacement since before the Jessie release. I made a set of changes which underpin that support at DebConf15. Iain developed the code based upon that to deliver the missing support which is required by the debian-cd team.

As we have discussed before take into account that this deprecated scope is inside Debian CD team or pure Debian scope, not within Debian project scope. Then, as we are going to discuss later, these Debian CD concerns were not made public, e.g. they were not sent to the Debian Live mailing list.

In the debian-live irc channel Iain R. Learmonth from the Debian CD team would have suggested that Daniel was aware of the vmdebootstrap development despite of what he said.

[00:04:16] <irl> dba was told this work was happening at debconf
[00:04:33] <irl> he was well aware, and had not talked to us since or fixed any of the bugs that debian-cd considered important

This was also arised in the namespace bug by Iain itself:

Communication was attempted and failed. Serious problems include:

#718225: live-build should authenticate files it downloads (from 2013)
#731709: support uefi (from 2013)

Neither of these issues have been fixed

Debian CD and the world goes on

Debian CD releases have to met today world needs. UEFI is a must nowadays. Debian is used in companies all around the world and has to work as best as possible. That also includes boot. It would seem that since 2013 UEFI is more and more common. So that means that some isos prior to Jessie did not even boot on those systems (if they did not have a CSM (BIOS emulation) support).

Act I: debian-cd team deprecates live-build

Act II: debian-cd team tries to register live-build-ng as a package

Act III: debian-cd team tries to make Debian Live an official Debian project

This was already planned because Debian Live not being in pure Debian infrastructure or at least in Alioth infrastructure was an anomaly. I guess that Debian CD team had already communicated Daniel these concerns but I’m not sure about that. It depends on what exactly it was said to Daniel during Debconfs.

Act IV: dba ends Debian Live

So Daniel has said that Debian Live is dead, once again hijacking the Debian name or Debian Live if you want in his interest. As I explained before there has to be a distinction made between ‘Daniel’s Debian Live’ and ‘Debian Live’ project inside of Debian. Current Debian Live development is done outside Debian (or Alioth) infrastructure thus, in practice, making ‘Daniel’s Debian Live’ an upstream to Debian.

So… ‘Daniel’s Debian Live’ has come to end.

So what ?

live-* packages from former ‘Daniel’s Debian Live’ can be forked and improved within Debian (or outside of it) if Daniel does not envision to maintain his own fork in the public. These are not privative programs. These are free as freedom packages.

About dba and Debian last years worsen relationship


I was aware of Debian not wanting to rollback a package and delaying a Debian release. But I was not aware of other of his issues with Debian organisation itself in the last years. And I was not aware that he was the first Debian Developer to be demoted into a Debian Maintainer for some of these problem. I am going to mention some of them although they would seem initially to be offtopic.

These issues might explain why from the Debian side in the namespace bug they seem to be so rude with expressions like:

this has been a long time coming

. The reason might be is that they are upset with the current situation which in some extent is Daniel’s responsibility. Kind of they are fed up with him, but, well, difficult to know if my suspicion is true or not.

Some of these issues are also pointed out by Daniel in his Bye letter because Daniel truly believes he is right on the decisions he makes. So, they are also needed to understand why Daniel, out of a suddent, decides to close in his own. We will these that there is a confrontation, at least in the Debian Live matter, between what an upstream or an individual think that it needs to be done in order to be logical or technically sound and what the Debian Project needs in terms of release matters.

Moreover these issues arise some learnings on how the Debian Project should interact with individual developers if there are problems with them.

UEFI support bug

Daniel-side: No copyright holder changes accepted.

Debian-side: There’s no reason why you should not accept copyright holder changes.

Consequence: 2015 and Debian Live does not have UEFI boot support yet.

live-build should authenticate files it downloads

Debian-side: This is a critical bug because an attacker could replace the kernel

Daniel-side: I wait for someone to write a patch. Even if it’s critical I prefer it to be applied on 5.x and not in 4.x.

sarge images have syslinux binaries without source

Daniel-side: Make sure you complain with GPL-2+ and upload the source code.

Debian-side: After so many time we have been unable to find the correct source code.

(I’m with Daniel on this one.)

please use syslinux-utils instead of isolinux

Debian-side: Do not break reverse dependencies.

Daniel-side: You should update your package instead.

Debian-side: I don’t need to update it. You would have not to have break it in the first place as you have done other times.

ITP: cgmanager

Debian-side: There are two packages to be uploaded. Which one?

Daniel: We will sort out between the two of us.

Debian-side: It’s rather impolite because your upload did not have an ITP. Later on this delayed the package for one week and there were systemd problems.

Common pattern

I wanted to discuss these issues more in depth but I prefer to move on so I will just mention the common pattern. Some decisions that make sense to a package maintainer might not make sense or make nuissance to the rest of the Debian Project specially when a new release is being frozen. It also happens the other way round. Sometimes the Debian Project does not react fast enough for the needs of a Debian maintainer.


Trademark and downstream

As I said earlier current Debian Live, due to its development it was more ‘Daniel’s Debian Live’ than ‘Debian Live’. So Debian Live was a de facto upstream to Debian.

Live-build is not deprecated in Debian Project

Live-build is not deprecated in Debian Project but in the eyes of Debian CD team. That means that they will not use this tool (they will use live-wrapper instead) for building the official Debian Live CDs in the future. It does not mean anything more.

Iain said in the namespace bug:

live-build has been deprecated by debian-cd, and live-build-ng is replacing it. In a purely Debian context at least, live-build is deprecated.

Later on Neil Williams stated in the same bug:

The debian-cd team deprecated live-build

but people understood that Debian CD team was deprecating live-build inside the Debian project and also pushing out live-build-ng as a replacement to it.

You can see that misunderstanding multiple times on the Debian Live mailing list in the november archive.

Even if a message from Iain tried to clear out things:

The naming of the package live-build-ng was not intended to serve as a request for live-build development to stop, or for the packages to be removed from Debian.

it was Ben Armstrong a recognised Debian Live developer and contributor which explained it quite well:

live-build has not been removed from the archive, nor has anyone threatened to remove it from the archive. Furthermore, while it is certainly less than ideal from Debian’s perspective that the lead upstream developer has quit, so long as the software has value to Debian’s users and contributors are willing to keep it in good shape, it could remain in the archive indefinitely.

Debian is a meritocracy. Not a democracy.

When the systemd controversy started many people thought that Debian was a democracy and that the Debian Technical Committee should have not used their duties and asked for a public democrating voting on the issue.

Debian is a meritocracy or a do-ocracy.

Leasons to be learned

  • Be careful when choosing a package name
  • If you are worried about a package status, e.g. for being able to use it in Debian CD, please make that concern public so that you can reference it later. It’s nice to complain face to face on Debconf meetings but, then, if things get worse then there would be a public misconception about Debian being a dictatorship. It happened with systemd, it happens with Debian Live and it will happen again, but, well, maybe we can try to minimise it.
  • If you are part of the pure Debian teams make sure that when you no longer use a package for your needs not to use the word: deprecated. Use the expression “would not be used” instead. If you are ever decided to use “deprecated” please make sure that it’s understood that the scope of deprecation only applies to a set of packages, tools or teams. Also make an statement about the package not being removed from the archive. Some people even do not understand what ‘scope’ means, so that last part is a must.
  • If an upstream package which has a ‘debian’ in its package name is going to be included into Debian Project as a package… make sure… if its development is outside Debian…  that you force it to change its name not to have ‘debian’ in it.

What it’s going to happen

  • live-wrapper (The new name for live-build-ng) is going to continue for sure. Debian Live will be included into official Debian properly. That means that the Debian Live development will be moved into Alioth.
  • dba might continue inside Debian or not depending on debian-cd apologies and probably some sort of arrengement.
  • live-wrapper is going to have better support for Debian CD team, blend and derivatives needs.
  • Some media will make these problems public making references to systemd hate.

My opinion on all these things

Many people did not know that Debian Live was not official or pure Debian. Neither that something like pure Debian existed. Debian Live, in my humble opinion, has been rotten in the last years. Yes, there was an effort from Daniel to rewrite it in Python but it was not completed. There are some requirements for derivatives, e.g. UEFI support that were not met. Although good quality code is needed so many problems on getting patches into Debian Live was a problem.

I suspect that some of these patches would have been improved from the Debian CD team and accepted instead of asking once again and again to the submitter to improve it. I might be wrong on that though. I have not submitted any patch at all to the Debian CD team.

Debian Project has to learn from this episode and, well, Debian Live support has to be continued. live-build will continue to be updated inside Debian probably by Ben Armstrong and, I don’t know how, there would be a need to find an upgrade path from live-buid 2.x, 3.x, 4.x and 5.x to live-wrapper. An upgrade-path would be documentation based.

Is Daniel an evil person? No, not at all. Even if you have seen in this article that he has many times done things that made the ftpmaster and other people gone crazy I think the average overall is good for Debian. Daniel is a hard work person and gives great attention to the detail. I am bit concerned about Daniel not longer being a Debian Developer though.

Are the Debian CD people a de facto ditactorship on Debian ? No. They only decide on what goes on the official CDs. And, despite what Daniel said, this also includes how the official Debian Live CDs are built. Although they used some misunfortunated words they never wanted the live-build to be removed from the archive.

Despite of the technical problems which can encounter live-wrapper many Debian Live people which thought of Daniel as a God (he’s very good at giving support) are kind of upset because of the Debian CD team movements. First of all it was because they were (supposedly) deprecating live-build and secondly because they finally made to Daniel to shutdown Debian Live (which they finally know that it’s not exactly true).

What I mean is that the acceptance of live-wrapper among Debian Live users will not be easy because of this rough start. And, well, because many people will have to migrate their scripts to use live-wrapper instead of live-build.

What about Rescatux

Rescatux uses live-build which can be forked at any moment so no worries. It might use live-wrapper in the future if it outweights the drawbacks of rewriting all the stuff based on live-build. The most probable move is to port the current live-wrapper UEFI support into live-build in my own fork. That is if the current patches are not as good as the Debian CD implementation.

I am not going to wait for live-wrapper to be in an stable release in order to support UEFI and thus release a Rescatux stable release. Too much time between Rescatux stable releases has already taken.

Feedback welcome

I repeat from the disclaimer: Despite of the way the article is written I am not expert at all in Debian so please take this with a grain of salt. I am not a lawyer so please take the legal explanation with a grain of salt. I’m open to constructive comments on this post. Being them for correcting my suspicions or Debian descriptions. Or being them for improving how Debian deals with these issues.

Why I wrote this post

As Ben Armstrong said:

I think feelings are running so high it’s almost impossible to have any productive public discussion about what went wrong and what it means to the project. Not right now. Maybe in time, we can sort it out.

I will keep this post in my blog which does not seem to be very famous in order to avoid new discussions on the mailing list. If discussions happen again I hope this post will help on having a broader view on it. Probably not an objective view, probably not an exact view but, at least, it will be somewhat different than the dominant opinion on the mailing list that believes everything that Daniel says without questioning anything.

If anyone ask me my opinion in this matter I will point him here. Given so many things and background to be explained there was no way of explaining my own thoughts on this matter without writing an article as this one. That was the reason. Not being able to explain all of this in two sentences.

The other reason is that I need to turn this page on the Debian dramas book and continue to work on technical stuff.

About Rescue tools in GNU/Linux systems in 2014 (Draft)

noviembre 13, 2015

Read first

I wrote these lines about a year ago. I was very busy at work and trying to put a Rescatux release in shape. So I did not finish this work. My objectives were too high. Try to study all the rescue-aimed packages from different distros. Try to identify non-specific rescue tools on Rescue disks. Then I want to produce three lists:

  • Packages for Debian Live Rescue cd tasksel package
  • Packages for next Rescatux release
  • Packages for Rescatux in a future

and, of course, if a program was not Debian package I also had to tag it.

The discovery of new tools and distribution also was going to modify the article itself. Let’s say that we find some password crackers packages. That would have meant having to search all distributions which have them. And maybe ophcrack would have been discovered. Ophcrack will have shown us more rescue packages that we might have not been aware.

If we discover another taxonomy name that fits into rescue we can then discover new programs related to that taxonomy.

I am not sure if I had thought on checking also private programs but, well, that would make sense more for Rescatux implementing new features already present on those disks.

SynrG has arised in Debian Live irc his concerns on having a Debian Live rescue cd or a Debian rescue blend. I was shy on showing this non finished draft but… well… here there is… if SynrG or another one can gather from it then it’s fine.

You know the final objetive is gathering an useful list of rescue packages for submitting an ITP for tasksel-rescue package (if that’s the right name). It can be done by one person (as I pretended to do initially so that a good clasification was done) or maybe in the mailing list in a collaborative manner.

Good luck!


I have offered myself to review current packages for Debian Live Rescue cd. Currently there is a Debian Live Rescue cd however its packages are defined in a list inside a text file. This was the old method and people from Debian Live want it to be replaced by a tasksel- task package. A tasksel task package is, as far as I understand, a Debian metapackage which depends on other packages so that you can define, i.e. a LXDE desktop, just by these packages. It’s something similar to the ubuntu-desktop or kubuntu-desktop packages from Ubuntu.

As a tasksel package needs to be defined from scratch it would be nice if we could review current packages available at Rescue disk and do a tasksel task package properly.

This article will also dive into many packages, rescue tools, or GNU/Linux live cds so that we can fully understand what rescue tools are available.

Finally, as I am also the Rescatux developer I will also comments on some tools being or not in Rescatux, or some tools that it would be fine to have into Rescatux.

The journey begins… .

 Current packages for Debian Live Rescue cd

  • Debian forensics . These set of packages might make sense. We will see it later in the taxonomy section.
  • Installer . These packages only make sense in the Debian Live CD. You don’t want to install the debian-installer-launcher when you install these packages to your system.
  • Live . Specific tools for Debian Live. Once again ignoring.
  • Localization . Basically it forces task-english to be installed. We will see it later in the taxonomy section.
  • Memtest . This is the program for testing memory at boot. We will see it later in the taxonomy section.
  • Rescue . Most of its contents need to be included. However we will discuss some of the in the taxonomy section.
  • Standard . I suppose these are packages usually added to a live cd. task-laptop and task-ssh-server. They don’t make sense in a rescue tasksel package.

Rescue tools taxonomy


As most things we can also classify rescue tools or programs. I’ll add some group names for these packages from several places and later on we will discuss them.

Package groups

  • Forensics. That is tools aimed at computer forensics. The goal of computer forensics is to examine digital media in a forensically sound manner with the aim of identifying, preserving, recovering, analyzing and presenting facts and opinions about the digital information.
  • Boot loaders . Tools aimed at recovering or reconstructing mbrs, pbrs, or boot loaders.
  • System . In the case of system section at Debian Live rescue cd current list these are some tools related to system, but that do not have too much in common.
  • Editors. Some console editors. Some of them as hexedit are specific for non standard text editing.
  • Hard disk. Tools for dealing with cdrom and hard disks.. Check hard disk status. Secure delete.
  • Browser. Some console Internet browsers.
  • Compression. Compression tools similar to well known zip tool.
  • Backup. Some handy tools for doing backups.
  • File comparison. Tools for comparing files.
  • General. Similar to system section. Many tools that you might need but that do not fit somewhere else.
  • Special hardware. Some special hardware packages.
  • Network
    • Network – Firewall. Tools for avoiding having ports open.
    • Network – Essential networking. These tools make easier to connect the live cd to the Internet.
    • Network – Bridging. Tools for doing network bridges.
    • Network – Routing. More toos for dealing with networks.
    • Network – Monitoring. Tools for monitoring the network.
    • Network – Testing. Mainly tools for testing the network.
    • Network Analysers. Some of these tools help debugging networks.
    • Network servers. Some useful tools when you want to serve some network services.
  • Log Analysers . These tools help you to analyse log files.
  • Filesystem tools. Filesystem tools for doing operations over filesystems.
  • Microsoft tools. Some filesystem and network tools that only make sense for Microsoft systems.
  • Miscellanea. Whatever does not fit in the rest of groups.
  • Flab. Not sure what it means.

Package groups analysis

Now I’m going to go through all these groups and argue if they need to be inside Rescatux or in rescue tasksel.

 Gnu/Linux Rescue Live CDs

Now I’m going to go through most of the current GNU/Linux Rescue Live CDs. The idea is having a little description of the cd, what it’s main purpose and relation to rescue tools. We will try to find its packages groups to add them to taxonomy section above. Finally we will have a link to its packages, specially the rescue ones.

In order not to forget any GNU/Linux Rescue Live CDs is interesting to use some rescue cds listings:



  • Debian Live Rescue CD
  • Rescatux
  • Parted Magic
  • System Rescue CD
  • Ultimate Boot CD



non-free packages. This is Debian specific.

 Non GNU/Linux tools


Super Grub2 Disk