Posts Tagged ‘debian’

Debian installation on Lenovo h50-50

septiembre 27, 2016

Introduction

I am going to describe some notes on how to install Debian on Lenovo h50.

BIOS / UEFI modification

First of all you need to press F1 several times at boot time so that Lenovo BIOS Setup Utility appears.

Under Security tab I enter into Secure Boot menu and I change Secure Boot into Disabled. Windows seems to boot ok despite this change.

Under Startup tab I see that CSM is disabled. I keep it disabled because Debian supports UEFI out of the box. I disable Quick Boot to avoid Windows starting in its own and bypassing out Boot order.

While we are still in Startup tab we open Primary Boot Sequence  and make sure the USB HDD entry is in the first place.

Finally I press F10 to save the changes and exit.

Shrink Windows

I won’t explain it here but you usually need to shrink Windows (even using Gparted live disk) so that you can install Debian in a partition of its own.

Boot from Debian AMD64 Netinst installation disk

I used Debian 8.6.0 Debian AMD64 Netinst installation disk myself. I used dd to put the iso image into a usb stick (also known as pendrive).

You just insert the usb stick into the computer and press the ON/OFF switch. The installation disk should appear.

Installation

You can add an additional usb stick so that the integrated wifi dongle works out of the box. I have not tested it myself. I used the Etherned card. Other than that it’s a pretty straight-forward Debian installation.

Enable Debian as the first OS

Once again you need to press F1 several times at boot time so that Lenovo BIOS Setup Utility appears.

Under Startup tab we open Primary Boot Sequence and under SATA 1 it shows:

  • Windows Boot Manager
  • debian

I modify its order thanks to + or – keys so that it shows:

  • debian
  • Windows Boot Manager

Finally I press F10 to save the changes and exit.

Nvidia boot

The first boot test was done with screens connected to the Nvidia video card. Grub was shown but then somehow it froze. By removing the quiet boot parametre at boot (press ‘e’ key) I saw the error:

fb: switching to nouveaufb from simple

As I don’t need a full effect desktop I decided to remove nouveau driver altoghether:

First of all at grub I need to edit the Debian entry with ‘e’ and at the kernel line which shows:

linux /boot/vmzlinuz... root=UUID=e39...    ro quiet

where I remove quiet and I blacklist nouveau driver on the fly:

linux /boot/vmzlinuz... root=UUID=e39...    ro modprobe.blacklist=nouveau

I press F10 to be able to boot.

Nvidia boot final fix

Once I am able to boot into my system I edit the file:

/etc/default/grub

so that the line:

GRUB_CMD_LINUX_DEFAULT="quiet"

becomes:

GRUB_CMD_LINUX_DEFAULT="modprobe.blacklist=nouveau"

.

We save the file and apply changes by running:

update-grub

.

Next time we reboot everything is working fine. However the simple xserver configuration does not detect the additional attached screen. Maybe nouveau with additional switches (or an updated nouveau driver) would do it.

Using Intel Graphics card

As I don’t need nvidia I don’t mind using Intel graphics card. But this BIOS does not enable it by default if it detects the Nvidia cards.

So we have to modify the BIOS once again to use the Intel Graphics card.

Once again you need to press F1 several times at boot time so that Lenovo BIOS Setup Utility appears.

Under Devices tab we open Video setup and in Select Active Video we select IGD instead of Auto .

Finally I press F10 to save the changes and exit.

 

Of course you don’t have to forget to connect the screens into the Intel graphics plugs (instead of the Nvidia) ones.

Now both screens are autodetected.

Anuncios

Debian Live NG

noviembre 15, 2015

Disclaimer

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. live.debian.net 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

Introduction

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 live.debian.net 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.

Misunderstandings

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!

Introduction

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

Introduction

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

 

Miscellanea

non-free packages. This is Debian specific.

 Non GNU/Linux tools

Memtest

Super Grub2 Disk

 

 

Debian Jessie post-installation August 2015

octubre 24, 2015

I recently installed Debian Jessie from scratch in my laptop. Take in mind that I already had a Sid installation and I wanted its same functionality. I am going to describe here some of the post-installation tasks that I did. Some of them are much needed for me. Other ones won’t be interesting for the  most of people.

Activivities

Somehow activities in Debian Jessie’s KDE 4.14.2 did not work out of the box. I cannot live without activities ! I finally found that activities are disabled by default and that you need to install an specific package for them to be installed.

apt-get install libkactivities-bin

Multiarch support

I have an amd64 system and I need i386 support for some applications like Skype.

dpkg --add-architecture i386

apt-get update

Skype with two accounts

I happen to use Skype with two accounts at once. So I needed to recover my /usr/local/bin/skype script which has:


#!/bin/bash
/usr/bin/skype &
/usr/bin/skype --dbpath=~/.SecondInstallation/ &

from my old Sid installation.

FX keys not working as a regular PC

I don’t like FX keys to work as a Mac. In my case, contrary to my old howto (Use Xorg in mac book pro (ES)), I just had to edit:

/etc/modprobe.d/function.conf

add to it:

options hid_apple fnmode=2

and run:
sudo update-initramfs -u
After that you just need to reboot your machine and FX keys worked as I expected for me.

Flash

I tried the recommended Ubuntu partner repository instructions but it used an old flash version. I just used the PepperFlashPlayer Installing Debian wiki page instructions.

Gnome Network Manager

I use gnome network manager instead of the kde one (Maybe I’m wrong on that but I think I found out that kde’s network manager package is no longer there in Jessie). I installed:

apt-get install network-manager-openvpn-gnome

and I recovered files from my old system so that old connections were alive again. I reused files from these two directories:

/etc/NetworkManager/system-connections

and

/etc/NetworkManager/VPN

.

Recover my sound settings

So I want to be able to control my actual device controls from kmix. Not the fake global volumes from pulseaudio which might hide some specific settings.

  • I install: plasma-widget-veromix package to be able to control pulseaudio if needed.
  • Add veromix plasmoid to my kde panels (In order to control pulseaudio from it easily)
  • Thanks to : kmix does not show all channels (part 2) I just edit: /etc/environment and I add to it: KMIX_PULSEAUDIO_DISABLE=1

Oracle Java

Yes, I need sometimes to use official Java. I just used instructions found on: HOW TO INSTALL ORACLE JAVA 8 IN DEBIAN VIA REPOSITORY [JDK8] in order to do it.

How to live stream to Youtube thanks to simplescreenrecorder from Debian

marzo 1, 2015

First of all you need to install simplescreenrecorder in Debian.

So the youtube side is quite explained in the official documentation. There is an explanation on how to create a live event. Then check the live encoder settings, bit rates and resolutions. I personally choose 480p because my upload bandwith is not so good.

The trick here is to choose “Other encoders” under the Select your encoder question.

This will show some special data that you need to feed into your encoder.

What you see is similar to:

youtube_live_encoder_settings

Recording name: username-1234.abcd-efgh-1ab2c-335ds (This will change for each new live event)

Main server URL: rtmp://a.rtmp.youtube.com/live2

Secondary server URL: rtmp://b.rtmp.youtube.com/live2?backup=1 (We will not use it)

.

Then you go to Live Control Room to check that the stream status is “Without data”.

youtube_live_control_room_no_stream

Now, it’s time to run simplescreenrecorder.

  • Click on Continue on the welcome screen
  • simple_screen_recorder_welcome
  • Profile
  •  simple_screen_recorder_input_options
    • I just created a new one
  • Video input
    • Record the entire screen (I record my second screen which I previously setup as 1024×768 so that everything is read ok. Your settings may vary).
    • Photograms rate: 30 (I just used the default one)
    • Record cursor: Yes
    • Scale video: I have it unchecked so that it does not use so much cpu
  • Audio Input
    • Record audio: PulseAudio. Internal Audio
  • Finally we press on Continue button
  • Profile
  •  simple_screen_recorder_output_options
    • Live Stream 1000 kbps which we will adapt for 500 kbps
  • File
    • Save as:
      • This is the main server URL concatenated with the recording name thanks to /.
      • This is what should be explained on Youtube site and it is not.
      • So here there is what would be based on our example:
      • rtmp://a.rtmp.youtube.com/live2/username-1234.abcd-efgh-1ab2c-335ds
    • Container: Other
    • Container name: flv
  • Video
    • Codec: Others
    • Code name: libx264
    • Bitrate (bps): 500 (Changed from 1000 default)
    • Custom options:  preset=faster,minrate=500,maxrate=500,bufsize=500,keyint=60 (Change appropiated settings to 500)
  • Audio
    • Codec: MP3
    • Bitrate (kbps): 128
  • We press on Continue button
  • We check the input size to be 1024×768 as expected and press “Start recording”. That’s ok. We are not actually going live yet.

simple_screen_recorder_start_streaming

So, now back to Youtube we can click into Basic Info tab and then again into the Live Control Room where we should see if our emission is right or not. If it’s right we can check a preview. You just have to click on Generate Preview button in Youtube. A youtube player will appear which will let you check how the streaming goes. Even if you record at 480p somehow the preview is 240p or 360p only.

youtube_live_control_room_stream_ok

So, that’s it.

If you ever want to go live once in the youtube preview page you have a button that says: Start streaming. So you just click on it and you are done.

youtube_live_control_room_ready_streaming

By the way, you can click on “Cancel Recording” in Simplescreenrecorder if you want to go live later (some hours later). But, that needs to be done before going into Live Streaming (before clicking on Start streaming button on Youtube) else you will finish your event.

How to install simplescreenrecorder in Debian

marzo 1, 2015

In order to install simplescreenrecorder in my Debian GNU/Linux Sid I just used the Debian instructions on the github page.

sudo dpkg --add-architecture i386
 sudo apt-get update
 sudo apt-get install build-essential pkg-config qt4-qmake libqt4-dev libavformat-dev \
 libavcodec-dev libavutil-dev libswscale-dev libasound2-dev libpulse-dev libjack-jackd2-dev \
 libgl1-mesa-dev libglu1-mesa-dev libx11-dev libxfixes-dev libxext-dev libxi-dev g++-multilib \
 libx11-6 libxext6 libxfixes3 libxfixes3:i386 libglu1-mesa:i386
cd /usr/lib/i386-linux-gnu
 sudo ln -s libGL.so.1 libGL.so
 sudo ln -s libGLU.so.1 libGLU.so
 sudo ln -s libX11.so.6 libX11.so
 sudo ln -s libXext.so.6 libXext.so
 sudo ln -s libXfixes.so.3 libXfixes.so
 sudo ldconfig

 

Then I run the suggested script that takes care of compiling and installing it.

 

./simple-build-and-install

 

and that’s it!

 

 

Cloning Debian system in extra partition before update (with EFI boot support)

noviembre 30, 2014

Note: This is an update for my Cloning Debian system in extra partition before update article so that it takes my efi boot support into account. It also works in a systemd system. The explanation is: Linux has the mount tree by default not shared. systemd changes this default setting while booting up. If you don’t do it this way you will have double mount when using –bind.

My system among others has a home partition, a main Debian system and an extra Debian system. My extra Debian system is for saving current Debian Unstable just before updates or upgrades. That’s what I’m going to describe here.

So my current partition is sda4. The Debian clone partition is /dev/sda6.

The overall process is:

  • Copy system data
  • Change fstab to reflect new partition as root partition
  • Update grub

I do not install grub from Debian clone partition because I’m updating the current system and not the clone one.

In order to copy system data I need to mount the current system in a special directory so that only the sda4 partition is seen and not all of the partitions mounted in it (we do not want to copy /home).

mkdir /mnt/origen
mount -o bind --make-private / /mnt/origen

We also need to mount the destination partition

mkdir /mnt/destino
mount -t ext4 /dev/sda6 /mnt/destino

Now we are going to do a live copy. I’m not stopping any services because I personally do not use any of them. If this was a production server you would need to run the commands twice making sure the last time you run it you stop all the services you want to preserve previously.

rsync -aHK --delete --delete-during /mnt/origen/ /mnt/destino/

This is the most efficient way of copying the files because if the files are the same ones they are not copied… although I think Rsync in local copies does not help too much because usually all the destination file has to be read to decide to overwrite it or not. But I’m not quite sure. Anyway… let’s continue.

Now we are going to edit fstab and reinstall grub

mount -o bind /dev /mnt/destino/dev
mount -o bind /proc /mnt/destino/proc
mount -o bind /sys /mnt/destino/sys
mount -o bind /boot/efi /mnt/destino/boot/efi
chroot /mnt/destino/
vim /etc/fstab

Now inside fstab I’m going to replace:

/dev/sda4 /               ext4    errors=remount-ro 0       1

with:

/dev/sda6 /               ext4    errors=remount-ro 0       1

and save the file. You might probably want to use LABELs or UUIDs instead of me.

Once we have saved it we are going to update grub:

update-grub

Now we just need to exit from chroot and umount all the partitions and folders.

exit
umount /mnt/destino/proc
umount /mnt/destino/boot/efi
umount /mnt/destino/sys
umount /mnt/destino/dev
umount /mnt/destino
umount /mnt/origen

So that’s it! If you boot your system with Super Grub2 Disk or another tool you will be able to load your grub.cfg and boot this SDA6 system without too much effort.

Now I’m ready to upgrade or update my Debian Unstable system in sda4 without fear for loosing my daily functionality because it has been cloned in sda6.

 

Waiting for btrfs to be stable in Debian so that I can use snapshots :).

Init systems choice in Debian the Debian way

noviembre 29, 2014

Disclaimer

I am a Debian user. I am not neither a Debian Developer nor a Debian maintainer. I develop a Debian derivative named Rescatux. There is no such a Debian way so please re-read this article title as: Init systems choice in Debian in the way that adrian15 think the Debian way it is.

This article serves as a one place to redirect everyone who asks me about what I think about all this fuzz about Debian making systemd as their init default choice in x86 and amd64 platforms.

I did not want to write a-yet-another-systemd-article but, as I don’t want to keep searching the Internet to find another article which mostly fits my views, I am writing it.

Background

Debian Background

According to wikipedia Debian entry:

Debian is the name for a Linux distribution that is composed primarily of free and open-source software, most of which is under the GNU General Public License, and packaged by a group of individuals known as the Debian project. At each point in time the Debian project offers three branches named “stable”, “testing” and “unstable”.

The Debian Stable distribution is one of the most popular for personal computers and network servers, and has been used as a base for several other Linux distributions.

Debian is known for its manifesto, social contract, and policies. Debian’s policies and team efforts focus on collaborative software development and testing processes. As a result of its policies, a new major release tends to occur every two years with revision releases that fix security issues and important problems.

systemd Background

Once again according to Wikipedia systemd article:

systemd is a suite of system management daemons, libraries, and utilities designed for Linux and programmed exclusively for the Linux API. Systemd authors characterize the software suite as a “basic building block” for an operating system.

For systems using it, the daemon systemd is the first process that is executed in user space during the Linux startup process. Therefore, systemd serves as the root of the user space’s process tree. The name systemd adheres to the Unix convention of making daemons easier to distinguish by having the letter d as the last letter of the filename.

Systemd is not just the name of the init daemon but can also refer to the entire software bundle around systemd. This includes the daemons systemd, journald, logind and networkd and many other low-level components such as libraries and utilities. In January 2013, systemd author Lennart Poettering described systemd not as one program, but rather a large software suite that includes 69 individual binaries.

Systemd in Debian Background

After the Debian Technical Committee was asked to vote on default Linux init system for jessie  in February 2014 systemd was the winner.

Ian Jackon proposed a general resolution named: init system coupling in October 2014 which tried to:

This GR seeks to preserve the freedom of our users now to select an init system of their choice, and the project’s freedom to select a different init system in the future. It will avoid Debian becoming accidentally locked in to a particular init system (for example, because so much unrelated software has ended up depending on a particular init system that the burden of effort required to change init system becomes too great). A number of init systems exist, and it is clear that there is not yet broad consensus as to what the best init system might look like. This GR does not make any comment on the relative merits of different init systems; the technical committee has decided upon the default init system forLinux for jessie.

The general resolution was not approved in November 2014.

Problem about systemd controversy

Systemd controversy as I understand it means discussing about systemd without understanding it once and once again. There are many articles about debunking systemd myths so I will not enter into details. You probably know that systemd is not an init per se. One of the systemd components is init yes.

Keeping aside the possible dependencies problem (Gnome pulling out systemd which I think it’s no longer true) what raises my attention, as a sysadmin, is that people are arguing that updating from sysv to systemd leaves their system unbootable.

That’s a pity because Debian is supposed to avoid these problems because it’s stable. These problems should be reported so that next stable Debian Jessie release fixes them if needed. That also means that you cannot draw systemd conclusions from using Debian testing without checking if it’s actually a bug or not. The other concern is that this admin is not worth of his name if he does not know how to get back to the machine previous state (thinking of virtual machine snapshots here). And, also, it’s not worth of his name if he does not learn about systemd and its specific issues.

So, there is an explanation on an Slashdot comment by Tollef Fog Heen which explains a practical view on systemd:

 

It’s a new system, so some things work differently. Many people seem to fail to see the line between bugs and intentional behaviour. If something doesn’t work as before, it might not be because we’re evil bastards who are out to steal your logs. It might just be that there’s a bug in some package which means your logs aren’t correctly forwarded from the journal.

Sometimes it might be that systemd makes other assumptions about what something means and we’re just failing to catch that in an upgrade check that should warn you about this. An example here is missing devices/mount points in fstab: sysvinit will happily ignore them, systemd won’t consider local-fs.target reached and you’ll have to fix your system for it to boot correctly.

Assumptions, as so often before, are the mother of all fuckups. Asking (preferably in a civilized manner) will get you a long way: “Hey, I’m not seeing my logs appear in syslog, is this supposed to be that way, and if not, can you help debug?”

This might not be the greatest misconception, but I think it’s the most common one. The greatest is possibly the conspiracy theory that this is all a takeover attempt from RH to kill other Linux distributions and that people pushing systemd are either shills or just unwittingly working against the distro they’re pushing systemd into. I’m not sure how adopting a free software component (which sure, happens to be largely maintained by RH engineers, like many other free software components we use to build a distro) will turn us all into corporate-loving robots giving up freedom to be near the source of systemd.

 

You can also read the Tollef Fog Heen summary on Systemd and Debian which it’s pretty nice.

systemd controversy among Debian is more than one year old at Debian and keep arising once and once again. Some (pro or con systemd) Debian Developers have been upset about some many discussion and have resigned in several of their tasks.

systemd developers also repeatedly suffer the anger of final users which do not like Systemd. If you do not like Systemd do not use it. No one is forcing you to use it. Not even Gnome and if it’s the case fork Gnome but do not complain on systemd people.

What I want to say is that you own the right for complaining but please do complain but only after you have read and tested all you can about systemd and about how Debian works.

Debian lack of resources

If you take a look at Debconf videos you will see that many projects lack manpower and that help is always welcome. Yes, Debian has a lot of users, and a lot of developers but most of them do not get paid for their work. So don’t assume Debian has manpower for meeting your expectations. More than that when people from Debian are asked about Debian Org paying them there’s concern because it goes against Debian spirit.

Another thing Debian is rejecting code that it’s not easy maintainable or similar. You cannot assume that Debian is going to accept everything you request to.

Debian way

Debian CD should let me opt for sysv

The newest Debian Jessie installer will not have an option for letting you not to install systemd. If you want Debian CD to let you install a systemd free system and presumably with sysv as the default init you need to program yourself it.

Then please contribute back your patch to the debian-cd and debian installer packages as needed.

As you have waited so long at helping Debian people to implement it you will notice that it won’t do it in Jessie. Not in the first release at least.

Too many packages depending on systemd

If you are concerned about so many packages depending on systemd please patch these packages either on upstream or in Debian packages so that they are no so dependent on systemd (There is an init metapackage). Then submit back the patch the Debian

What if my patches do not get accepted

Then fork Debian but not before my previous suggestions are tried. Or, well, if you cannot wait for your changes to be approved please fork but, keep in mind, that your best move is to contribute back to Debian.

Pragmatic steps for avoiding systemd

Just take a look at: Without systemd debian – jessie page. Even if you decide to upgrade to Jessie you can then choose to remove systemd and change your system behaviour so that it makes impossible for systemd to be installed.

First install a good init system

# apt-get install sysvinit-core sysvinit sysvinit-utils

Then reboot your machine and remove all the systemd crap

# apt-get remove --purge --auto-remove systemd

To keep systemd away from your system you should prevent the package from being installed again.

# echo -e "Package: systemd\nPin: origin ""\nPin-Priority: -1" > /etc/apt/preferences.d/systemd

There is also an attempt to release a Debian Jessie installer without systemd but it’s not an official one (as any fork).

What do I think about systemd

As a sysadmin I’m interested in being able to use cgroups so that in a multi web hosting like Virtualmin you can assign resource usage limits to the different webpages. I’m also interested in the declarative ways of setting a system. It seems smarter.

As a Rescatux and Super Grub2 Disk is a new field of opportunities because I can just add an option for bypassing systemd and using sysv at boot (if sysv was not uninstalled) if the former ever fails. But not sure if I will ever implement it.

Conclusions

As per many other open source and free as freedom software projects what really counts is the source code. It’s what your contributions are, not what you think a project should do. So, please, the next time you complain about Debian including systemd by default (only in Linux kernel) just step aside to think carefully about what you can do for Debian and, even, for systemd.

Upgrading Debian Unstable system at 22th Feb 2014

febrero 22, 2014

I am going to upgrade my Debian Unstable system. First of all I am going to check my sources.list and my sources.list.d directory.

I’ve seen this entry:

# Needed for oyranos Check preferences
deb http://ftp.de.debian.org/debian squeeze main

which I am going to remove because I’m not using oyranos as a colour management system.

I am going to leave:

deb http://www.deb-multimedia.org sid main non-free

although I suspect that it’s the reason why I cannot install pidgin without uninstall kvirc.

I’m also going to disable some old stuff that I supposedly do not use:

# No need for apple-bl-gmux because Linux 3.10 includes it
deb http://ppa.launchpad.net/sforshee/apple-bl-gmux/ubuntu precise main
# Another colour management tool that I do not use
deb http://download.opensuse.org/repositories/multimedia:color_management/xUbuntu_13.04/ /
# This repo let me install an Orange 3G pendrive even if the repo is for Movistar
deb http://www.tgcm.es/repo/ubuntu stable main
# Oyranos repository
deb http://download.opensuse.org/repositories/multimedia:color_management/Debian_6.0/ /
# I bet this is for trying to do some hibernating in my mac without loosing my mind
deb http://ppa.launchpad.net/thomas.tsai/ubuntu-tuxboot/ubuntu precise main
deb-src http://ppa.launchpad.net/thomas.tsai/ubuntu-tuxboot/ubuntu precise main

So that’s it. Let’s update and upgrade. I use it inside byobu so that if ever Xorg system gets wrong it continues to run.

apt-get update
apt-get dist-upgrade

Now I’m getting this error:

Se encontraron errores al procesar:
 /var/cache/apt/archives/python-mysql.connector_1.1.5-1_all.deb
Error: GDBus.Error:org.freedesktop.DBus.Error.Spawn.PermissionsInvalid: The permission of the setuid helper is not correct
E: Sub-process /usr/bin/dpkg returned an error code (1)

I’m going to run apt-get install -f and if it fails again I will remove that package for installing it later.

Well, actually the problem is about not having free space. I will run apt-get clean right now just after running apt-get install -f. And then I will re-run apt-get install -f. I always tell myself to remove libreoffice packages before updating but I sometimes forget about it.

Finally I remove some packages I do not need:

syncevolution
jack-audio-connection-kit

and I remove local packages to make some free space in root partition:

apt-get clean

.

After updating my system I have had to remove special windows settings for KVirc because I was not seeing it when it was setup to be found in all of the desktops. I will need to add that special settings again and see if it’s a configuration version problem or if it’s KWin window special settings which are faulty.

Cloning Debian system in extra partition before update

febrero 21, 2014

My system among others has a home partition, a main Debian system and an extra Debian system. My extra Debian system is for saving current Debian Unstable just before updates or upgrades. That’s what I’m going to describe here.

So my current partition is sda4. The Debian clone partition is /dev/sda6.

The overall process is:

  • Copy system data
  • Change fstab to reflect new partition as root partition
  • Update grub

I do not install grub from Debian clone partition because I’m updating the current system and not the clone one.

In order to copy system data I need to mount the current system in a special directory so that only the sda4 partition is seen and not all of the partitions mounted in it (we do not want to copy /home).

mkdir /mnt/origen ; mount -o bind / /mnt/origen

We also need to mount the destination partition

mkdir /mnt/destino ; mount -t ext4 /dev/sda6 /mnt/destino

Now we are going to do a live copy. I’m not stopping any services because I personally do not use any of them. If this was a production server you would need to run the commands twice making sure the last time you run it you stop all the services you want to preserve previously.

rsync -aHK --delete --delete-during /mnt/origen/ /mnt/destino/

This is the most efficient way of copying the files because if the files are the same ones they are not copied… although I think Rsync in local copies does not help too much because usually all the destination file has to be read to decide to overwrite it or not. But I’m not quite sure. Anyway… let’s continue.

Now we are going to edit fstab and reinstall grub

mount -o bind /dev /mnt/destino/dev
mount -o bind /proc /mnt/destino/proc
mount -o bind /sys /mnt/destino/sys
chroot /mnt/destino/
vim /etc/fstab

Now inside fstab I’m going to replace:

/dev/sda4 /               ext4    errors=remount-ro 0       1

with:

/dev/sda6 /               ext4    errors=remount-ro 0       1

and save the file. You might probably want to use LABELs or UUIDs instead of me.

Once we have saved it we are going to update grub:

update-grub

Now we just need to exit from chroot and umount all the partitions and folders.

exit
umount /mnt/destino/proc
umount /mnt/destino/sys
umount /mnt/destino/dev
umount /mnt/destino
umount /mnt/origen

So that’s it! If you boot your system with Super Grub2 Disk or another tool you will be able to load your grub.cfg and boot this SDA6 system without too much effort.

Now I’m ready to upgrade or update my Debian Unstable system in sda4 without fear for loosing my daily functionality because it has been cloned in sda6.