Testing GNU/Linux live cds on HP 250 G6 2SX60EA

These are some live cds that I tested in an HP 250 G6 2SX60EA laptop and their simple results:

• Rescatux 0.51b3: Show «Progress linux» prompt. This CLI mode does not let me log in with Debian Live default user and password.
• Rescatux 0.62b1 (This is a private release, not a public one): Show «Progress linux» prompt. This CLI mode does not let me log in with Debian Live default user and password.
• debian-live-9.7.0-amd64-gnome.iso: Show «Progress linux» prompt. This CLI mode does not let me log in with Debian Live default user and password.
• debian-live-testing-amd64-gnome.iso: Graphical desktop but without wifi.
• ubuntu-18.10-desktop-amd64.iso: Graphical desktop and wifi.
• debian-live-testing-amd64-gnome+nonfree.iso: Graphical desktop and wifi.

The next batch of tests were done using Super Grub2 Disk 2.02s10 and trying to boot into all the OSes available on the system as it comes from the factory.

• Boots into FreeDOS ok when booted in BIOS mode.
• It is not able to boot HPDOCS (that’s normal because it is started from a syslinux.cfg file).

Quick and dirty Debian package repository published in Sourceforge

Introduction

We are going to build a local repo and then push it to Sourceforge http server so that it’s public.

Requirements

apt-get install apt-utils

Create the new repo

Assumptions

• Binary and source package already available
• We decide to have jessie and jessie-dev
• All our packages are main section packages
• Our architecture is i386

That means, e.g. that we already have:

chntpw_1.0.orig.tar.gz
chntpw_1.0-2.dsc
chntpw_1.0-2.diff.gz
chntpw_1.0-2_i386.deb
chntpw_1.0-2_i386.changes

Directory structure

mkdir -p /home/adrian/gnu/rescatux/repo
mkdir -p /home/adrian/gnu/rescatux/repo/jessie
mkdir -p /home/adrian/gnu/rescatux/repo/jessie-dev
mkdir -p /home/adrian/gnu/rescatux/repo/dists/jessie-dev/main/binary-i386/
mkdir -p /home/adrian/gnu/rescatux/repo/dists/jessie/main/binary-i386/

Directory structure for packages

The packages I want to upload for now are: chntpw and rescapp .
So that everything is tidy.

mkdir -p /home/adrian/gnu/rescatux/repo/jessie/chntpw
mkdir -p /home/adrian/gnu/rescatux/repo/jessie-dev/chntpw
mkdir -p /home/adrian/gnu/rescatux/repo/jessie/rescapp
mkdir -p /home/adrian/gnu/rescatux/repo/jessie-dev/rescapp

Populate repo (chntpw)

I copy:

chntpw_1.0.orig.tar.gz
chntpw_1.0-2.dsc
chntpw_1.0-2.diff.gz
chntpw_1.0-2_i386.deb
chntpw_1.0-2_i386.changes

into this folder:

/home/adrian/gnu/rescatux/repo/jessie-dev/chntpw

Populate repo (rescapp)

I copy:

rescapp_0.51b1-1.debian.tar.xz
rescapp_0.51b1-1.dsc
rescapp_0.51b1-1_i386.changes
rescapp_0.51b1-1_i386.deb
rescapp_0.51b1.orig.tar.gz

into this folder:

/home/adrian/gnu/rescatux/repo/jessie-dev/rescapp

Generate needed files (including source files)

cd /home/adrian/gnu/rescatux/repo

apt-ftparchive packages jessie-dev | gzip -c > dists/jessie-dev/main/binary-i386/Packages.gz
apt-ftparchive packages jessie | gzip -c > dists/jessie/main/binary-i386/Packages.gz
apt-ftparchive sources jessie-dev | gzip -c > dists/jessie-dev/main/binary-i386/Sources.gz
apt-ftparchive sources jessie | gzip -c > dists/jessie/main/binary-i386/Sources.gz

I ignore these messages:

chntpw has no source override entry
chntpw has no binary override entry either

Pushing repo into Sourceforge

First of all you need to create an sftp connection by the means of ssh.
Let’s assume that sfuser is your Sourceforge user and that your project unix name is: sfproject .

ssh -t sfuser,sfproject@shell.sourceforge.net create

Now connect thanks to Filezilla with this quick settings:

• • Server:sftp://frs.sourceforge.net
  • User:sfuser,sfproject
  • Password:TooSecret
  • Port:22

Now browse into:

/home/project-web/sfproject/htdocs

and push there your local repo folder so that you have:

/home/project-web/sfproject/htdocs/repo

and you are done.

Additionally if you want anyone to be able to download your packages without using apt but simply using their browser you should upload:

/home/project-web/sfproject/htdocs/repo/.htaccess

with this single line as its content:

Options +Indexes

Final user use of your repo

They should create the file:

/etc/apt/sources.list.d/myrepo.list

with this content:

deb http://sfproject.sourceforge.io/repo/ jessie-dev main

Finally, make the system aware of this new repo thanks to:

apt-get update

Now my final user can install these packages like this:

apt-get install chntpw

or

apt-get install rescapp

TODO

Sign the packages and maybe provide a keyring package.

Useful links

• The Debian Administrator’s Handbook – Creating a Package Repository for APT
• Sourceforge Project Web Services Documentation

blink SIP client Pulseaudio setup

What is blink

Blink is a state of the art, easy to use SIP client.

Blink Screenshot (Contacts page)

What is the problem with blink?

Blink does not support pulseaudio by default. It only supports alsa (as per November 2017).

Not supporting alsa directly makes Blink setup in a Pulseaudio environment more challenging because when you select an alsa device it’s grabbed by blink.

Otherwise if pulseaudio grabs this same alsa device when you start Blink the same alsa device disappears from audio setup.

Let me show what was my setup before applying the workaround explained here.

 

Blink Input devices setup (Pre workaround)

The default «Playback/recording through the Pulseaudio sound server» device is a pulse plugin based alsa device which connects with pulseaudio. Unfortunately it’s bind to only one physical device at a time. I use it as both as an Input Device and an Output Device.

E.g. if pulseaudio has my headphones as default device then headphones will be used.

E.g. if pulseaudio has my usb speaker as default device then sound will come out from the usb speaker but no sound will be captured!

As an Alert Device I select HDA Intel PCH which it’s a native alsa device and that means that it’s not controlled by pulseaudio but from Blink directly.

How to identify  your ALSA devices

I later found out this section was not necessary but I write down this as extra documentation. You can skip to the How to identify your Pulseaudio devices section below.

With aplay

aplay -L | grep :CARD
hdmi:CARD=HDMI,DEV=0
dmix:CARD=HDMI,DEV=3
dsnoop:CARD=HDMI,DEV=3
hw:CARD=HDMI,DEV=3
plughw:CARD=HDMI,DEV=3
sysdefault:CARD=PCH
front:CARD=PCH,DEV=0
surround21:CARD=PCH,DEV=0
surround40:CARD=PCH,DEV=0
surround41:CARD=PCH,DEV=0
surround50:CARD=PCH,DEV=0
surround51:CARD=PCH,DEV=0
surround71:CARD=PCH,DEV=0
dmix:CARD=PCH,DEV=0
dsnoop:CARD=PCH,DEV=0
hw:CARD=PCH,DEV=0
plughw:CARD=PCH,DEV=0
sysdefault:CARD=Device
front:CARD=Device,DEV=0
surround21:CARD=Device,DEV=0
surround40:CARD=Device,DEV=0
surround41:CARD=Device,DEV=0
surround50:CARD=Device,DEV=0
surround51:CARD=Device,DEV=0
surround71:CARD=Device,DEV=0
iec958:CARD=Device,DEV=0
dmix:CARD=Device,DEV=0
dsnoop:CARD=Device,DEV=0
hw:CARD=Device,DEV=0
plughw:CARD=Device,DEV=0

With proc asound

cat /proc/asound/card*/id

HDMI
PCH
Device

Play your music in your cards

aplay -D hw:PCH your_favourite_sound.wav
aplay -D hdmi:HDMI your_favourite_sound.wav
aplay -D front:Device your_favourite_sound.wav

What I found out in my case

HDMI hdmi:HDMI (Screen – Not used by me)
PCH hw:PCH (USB Speakers)
Device front:Device (USB Headphones)

 

How to identify your Pulseaudio devices

Show different microphones

pacmd list-sources | grep -e device.string -e 'name:'

name:  alsa_output.usb-C-Media_Electronics_Inc._USB_PnP_Sound_Device-00.analog-stereo.monitor >
  device.string = "2"
name:  alsa_input.usb-C-Media_Electronics_Inc._USB_PnP_Sound_Device-00.analog-mono >
  device.string = "hw:2"
name:  alsa_output.pci-0000_00_1b.0.analog-stereo.monitor >
  device.string = "1"
name:  alsa_input.pci-0000_00_1b.0.analog-stereo >
  device.string = "front:1"
name:  alsa_output.pci-0000_00_03.0.hdmi-stereo.monitor >
  device.string = "0"

Show different outputs

pacmd list-sinks | grep -e 'name:' -e 'index'

* index: 0
  name:  alsa_output.usb-C-Media_Electronics_Inc._USB_PnP_Sound_Device-00.analog-stereo >
index: 1
  name:  alsa_output.pci-0000_00_1b.0.analog-stereo >
index: 2
  name:  alsa_output.pci-0000_00_03.0.hdmi-stereo >

.asoundrc workaround

This setups the different alsa devices which I have identified in the How to identify your Pulseaudio devices section with the specific pulse plugin which helps alsa and pulseaudio devices to coexist.

Now, unlike the default «Playback/recording through the Pulseaudio sound server» device now you will be able to select the specific device where you want your sound to be output.

Additionally thanks to the hint entries you can put more human names to the devices which alsa programs see.

My ~/.asoundrc contents are:

 pcm.pulse-my-usb-speaker {
     type pulse
     device "alsa_output.pci-0000_00_1b.0.analog-stereo"
     hint.description "My USB Speaker (Pulse)"
 }

  pcm.pulse-my-usb-headphones-out {
     type pulse
     device "alsa_output.usb-C-Media_Electronics_Inc._USB_PnP_Sound_Device-00.analog-stereo"
     hint.description "My USB Headphones OUT (Pulse)"
 }

   pcm.pulse-my-usb-headphones-mic {
     type pulse
     device "alsa_input.usb-C-Media_Electronics_Inc._USB_PnP_Sound_Device-00.analog-mono"
     hint.description "My USB Headphones MIC (Pulse)"
 }

How blink finally detects new devices

Once ~/.asoundrc is saved you need to quit Blink and restart it so that it recognises the new ‘alsa’ devices.

Here there is the Audio tab in the Blink Preferences dialog after selecting my ‘new’ devices.

 

Blink Audio Preferences – Input Devices – Post pulseaudio workaround

The custom names are pretty obvious. Now I can select my USB speaker as the alert device and as input / output devices I use my headphones.

Alternative setups

Some ALSA purists might say that it would be better for pulseaudio to turn off the devices you want to use from Blink.

So that Blink uses those devices through native alsa where you probably have a better sound.

I don’t care too much about having an slightly better sound. What I want to is all my apps to use the different audio devices and not having to deal with an audio device disappearing in Blink because other programs (e.g. pulseaudio) used it first.

Final words

I have been trying this setup for about three days. The alert device does not disappear when used from another program. And sound quality is ok for me.

I recommend to try this setup (you can easily switch it off by renaming ~/.asoundrc,quitting Blink and starting Blink again ) if you are using Blink in a pulseaudio system and you struggle when dealing with several audio devices like me.

Debian installation on Lenovo h50-50

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.

Debian Live NG

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:

A 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)

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

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

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:

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».

Now, it’s time to run simplescreenrecorder.

• Click on Continue on the welcome screen
• 
• Profile
•  
  • 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
•  
  • 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.

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.

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.

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

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)

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 :).