Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #178058 > unrolled thread

"Invalid arch-independent ELF magic" in grub after SSD migration

Back to article view | Back to linux.debian.user

Contents

  "Invalid arch-independent ELF magic" in grub after SSD migration Lucio Crusca <lucio@sulweb.org> - 2017-02-22 09:30 +0100
    Re: "Invalid arch-independent ELF magic" in grub after SSD migration Lucio Crusca <lucio@sulweb.org> - 2017-02-22 14:30 +0100
      Re: "Invalid arch-independent ELF magic" in grub after SSD migration Eero Volotinen <eero.volotinen@iki.fi> - 2017-02-22 15:50 +0100
        Re: "Invalid arch-independent ELF magic" in grub after SSD migration Lucio Crusca <lucio@sulweb.org> - 2017-02-22 16:40 +0100
          Re: "Invalid arch-independent ELF magic" in grub after SSD migration Mark Fletcher <mark27q1@gmail.com> - 2017-02-23 00:00 +0100
            Re: "Invalid arch-independent ELF magic" in grub after SSD migration <tomas@tuxteam.de> - 2017-02-23 11:30 +0100
              Re: "Invalid arch-independent ELF magic" in grub after SSD migrationy Mark Fletcher <mark27q1@gmail.com> - 2017-02-23 12:20 +0100
    Re: "Invalid arch-independent ELF magic" in grub after SSD migration Tixy <tixy@yxit.co.uk> - 2017-02-22 17:50 +0100
      Re: "Invalid arch-independent ELF magic" in grub after SSD migration Lucio Crusca <lucio@sulweb.org> - 2017-02-22 19:00 +0100
        Re: "Invalid arch-independent ELF magic" in grub after SSD migration Tixy <tixy@yxit.co.uk> - 2017-02-22 21:20 +0100
          Re: "Invalid arch-independent ELF magic" in grub after SSD migration Lucio Crusca <lucio@sulweb.org> - 2017-02-22 21:50 +0100
            Re: "Invalid arch-independent ELF magic" in grub after SSD migration Lucio Crusca <lucio@sulweb.org> - 2017-02-23 00:30 +0100
    Re: "Invalid arch-independent ELF magic" in grub after SSD migration Richard Hector <richard@walnut.gen.nz> - 2017-02-23 11:10 +0100
    Re: "Invalid arch-independent ELF magic" in grub after SSD migration Stefan Monnier <monnier@iro.umontreal.ca> - 2017-02-23 15:10 +0100
    Re: "Invalid arch-independent ELF magic" in grub after SSD migration Jonathan Dowland <jmtd@debian.org> - 2017-02-23 15:30 +0100
      Re: "Invalid arch-independent ELF magic" in grub after SSD migration <tomas@tuxteam.de> - 2017-02-23 16:10 +0100
        Re: "Invalid arch-independent ELF magic" in grub after SSD migration Stefan Monnier <monnier@iro.umontreal.ca> - 2017-02-23 16:50 +0100
          Re: "Invalid arch-independent ELF magic" in grub after SSD migration <tomas@tuxteam.de> - 2017-02-24 10:50 +0100
            Re: "Invalid arch-independent ELF magic" in grub after SSD migration "Thomas Schmitt" <scdbackup@gmx.net> - 2017-02-24 11:50 +0100
              Re: "Invalid arch-independent ELF magic" in grub after SSD migration <tomas@tuxteam.de> - 2017-02-24 12:30 +0100
                Re: "Invalid arch-independent ELF magic" in grub after SSD migration deloptes <deloptes@gmail.com> - 2017-02-24 17:10 +0100
                  Re: "Invalid arch-independent ELF magic" in grub after SSD migration Lucio Crusca <lucio@sulweb.org> - 2017-02-25 10:20 +0100
                    Re: "Invalid arch-independent ELF magic" in grub after SSD migration Felix Miata <mrmazda@earthlink.net> - 2017-02-25 10:30 +0100
                      Re: "Invalid arch-independent ELF magic" in grub after SSD migration <tomas@tuxteam.de> - 2017-02-25 10:40 +0100
                      Re: "Invalid arch-independent ELF magic" in grub after SSD migration Lucio Crusca <lucio@sulweb.org> - 2017-02-25 11:30 +0100
                    Re: "Invalid arch-independent ELF magic" in grub after SSD migration <tomas@tuxteam.de> - 2017-02-25 10:40 +0100
                    Re: "Invalid arch-independent ELF magic" in grub after SSD migration "Thomas Schmitt" <scdbackup@gmx.net> - 2017-02-25 11:30 +0100
                      Re: "Invalid arch-independent ELF magic" in grub after SSD migration deloptes <deloptes@gmail.com> - 2017-02-25 14:40 +0100
      Re: "Invalid arch-independent ELF magic" in grub after SSD migration Stefan Monnier <monnier@iro.umontreal.ca> - 2017-02-23 16:40 +0100

Page 1 of 2  [1] 2  Next page →

#178058 — "Invalid arch-independent ELF magic" in grub after SSD migration

Hello,

I've just migrated my Debian testing/unstable install from a HDD to a SDD (too many custom configurations to go for a clean install). The hardware is a Dell Precision M4500 notebook.
The HDD is a Seagate 250GB 7200rpm, the SDD is a Samsung 250GB EVO 850. The total capacity matches exactly.

Here is how I copied the disk contents over the SDD.
I booted a live Ubuntu from CD media, checked with fdisk that every partition is starting 4K aligned and used the following command to copy the disk contents:

dd if=/dev/sda of=/dev/sdb status=progress bs=4K

Then I shut off the notebook, swapped disks and booted with the SDD. The result was:

error: invalid arch-independent ELF magic.
Entering rescue mode...
grub rescue>

I've tried suggestions from Google, e.g. live boot, install grub-efi-amd64, grub-install /dev/sda and so on. It worked once only, but I'm not even sure it was thanks to what I did. Please note that I have no EFI partition and the BIOS is configured for Legacy boot, not EFI.

I've also tried the advice here http://stackoverflow.com/questions/18120835/debian-grub-rescue-invalid-arch-independent-elf-magic (first reply, e.g. reinstall grub-pc) but it didn't work, I still get the same error.

Any clues?

[toc] | [next] | [standalone]

#178064

Il 22/02/2017 09:18, Lucio Crusca ha scritto:
> the following command to copy the disk contents:
>
> dd if=/dev/sda of=/dev/sdb status=progress bs=4K
>

P.S. I've just tried cloning again with the SSD in the notebook and the HDD in the external USB/SATA adapter, this time booting Ubuntu from USB instead of CD media. This time the command was

dd if=/dev/sdc of=/dev/sda status=progress bs=4K

Before rebooting I checked that the first ~400MB of data had been correctly copied with these commands:

dd if=/dev/sdc of=./test1 bs=4K count=102400
dd if=/dev/sda of=./test2 bs=4K count=102400
cmp test1 test2

and I got no output from cmp, that means the two files are equal. Upon rebooting I got the same error again.

[toc] | [prev] | [next] | [standalone]

#178071

[Multipart message — attachments visible in raw view] — view raw

Try using clonezilla: http://clonezilla.org/

--
Eero

2017-02-22 15:26 GMT+02:00 Lucio Crusca <lucio@sulweb.org>:

> Il 22/02/2017 09:18, Lucio Crusca ha scritto:
>
>> the following command to copy the disk contents:
>>
>> dd if=/dev/sda of=/dev/sdb status=progress bs=4K
>>
>>
> P.S. I've just tried cloning again with the SSD in the notebook and the
> HDD in the external USB/SATA adapter, this time booting Ubuntu from USB
> instead of CD media. This time the command was
>
> dd if=/dev/sdc of=/dev/sda status=progress bs=4K
>
> Before rebooting I checked that the first ~400MB of data had been
> correctly copied with these commands:
>
> dd if=/dev/sdc of=./test1 bs=4K count=102400
> dd if=/dev/sda of=./test2 bs=4K count=102400
> cmp test1 test2
>
> and I got no output from cmp, that means the two files are equal. Upon
> rebooting I got the same error again.
>
>

[toc] | [prev] | [next] | [standalone]

#178072

Il 22/02/2017 15:39, Eero Volotinen ha scritto:
> Try using clonezilla: http://clonezilla.org/

I can try, but I'd prefer understanding what I'm doing wrong, if possible.

[toc] | [prev] | [next] | [standalone]

#178083

On Wed, Feb 22, 2017 at 04:35:16PM +0100, Lucio Crusca wrote:
> Il 22/02/2017 15:39, Eero Volotinen ha scritto:
> >Try using clonezilla: http://clonezilla.org/
> 
> I can try, but I'd prefer understanding what I'm doing wrong, if possible.
> 
> 
I am not sure I can explain why this would be necessary (theoretically, 
it wouldn't) but you might want to try manually recreating the partition 
structure on the SSD and then using dd (or just cp actually) to copy 
each partition.

So say you have 3 partitions, re-create them on the target disk and then 
copy each of them from HDD to SDD.

Or, go one step further and create both partitions and filesystems on 
the SSD, mount HDD and SSD filesystems and then cp -a the contents from 
HDD filesystems to SSD.

Some months ago I migrated the two disks in my main Jessie machine from 
HDDs to SSDs, and I used the last option above. The consensus on this 
list at the time was that that was the best way to do it. It's certainly 
the most tolerant of subtle differences between source and target disk. 
It does require that grub be re-installed on the target disk, but with 
everything copied over the grub.cfg will be in place so the install is 
easy. 

There was some discussion on this list of how I went about it at the 
time, you can see that in the archives.

Hope that helps

Mark

[toc] | [prev] | [next] | [standalone]

#178088

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Feb 23, 2017 at 07:53:45AM +0900, Mark Fletcher wrote:
> On Wed, Feb 22, 2017 at 04:35:16PM +0100, Lucio Crusca wrote:
> > Il 22/02/2017 15:39, Eero Volotinen ha scritto:
> > >Try using clonezilla: http://clonezilla.org/
> > 
> > I can try, but I'd prefer understanding what I'm doing wrong, if possible.
> > 
> > 
> I am not sure I can explain why this would be necessary (theoretically, 
> it wouldn't) but you might want to try manually recreating the partition 
> structure on the SSD and then using dd (or just cp actually) to copy 
> each partition.

In the OP's context this doesn't make much sense. From the OP's mail

  dd if=/dev/sda of=/dev/sdb [other params elided]

That would copy boot sector, partition table and everything. If

 (a) the one (or the other) disk isn't broken
 (b) no one else is concurrently writing to the copied disk

everything should work. And from the thread up to now, I gather that
there's at least good evidence against (b).

There's nothing magical about the boot sector or partition table, it's
just data which happens to be located (typically, these days) "before"
the partitions proper. Unless...

I have some dim memories of some helpful firmware (was it disk? was it
BIOS? Didn't I say "dim"?) "protecting" the user of rogue software
writing to the boot sector. This was, AFAIR, the heyday of boot sector
viruses and hopefully long gone.

But hard/firmware vendors are known to do strange things: go check
your BIOS whether some funny RAID thingie is enabled.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAliuuKcACgkQBcgs9XrR2kaEswCdEXLwO+ljybEvbto8FvwEAxYo
xjYAnAjAdKw0BrTttZfVVGOEay+0Cz2j
=LrqD
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#178092 — Re: "Invalid arch-independent ELF magic" in grub after SSD migrationy

On Thu, Feb 23, 2017 at 11:25:43AM +0100, tomas@tuxteam.de wrote:
> On Thu, Feb 23, 2017 at 07:53:45AM +0900, Mark Fletcher wrote:
> > On Wed, Feb 22, 2017 at 04:35:16PM +0100, Lucio Crusca wrote:
> > > Il 22/02/2017 15:39, Eero Volotinen ha scritto:
> > > >Try using clonezilla: http://clonezilla.org/
> > > 
> > > I can try, but I'd prefer understanding what I'm doing wrong, if possible.
> > > 
> > > 
> > I am not sure I can explain why this would be necessary (theoretically, 
> > it wouldn't) but you might want to try manually recreating the partition 
> > structure on the SSD and then using dd (or just cp actually) to copy 
> > each partition.
> 
> In the OP's context this doesn't make much sense. From the OP's mail
> 
>   dd if=/dev/sda of=/dev/sdb [other params elided]
> 
> That would copy boot sector, partition table and everything. If
> 
>  (a) the one (or the other) disk isn't broken
>  (b) no one else is concurrently writing to the copied disk
> 
> everything should work. And from the thread up to now, I gather that
> there's at least good evidence against (b).
> 
And yet, oh and yet, it WASN'T working, WAS it?

Hence my suggestion.

Mark

[toc] | [prev] | [next] | [standalone]

#178075

On Wed, 2017-02-22 at 09:18 +0100, Lucio Crusca wrote:
> I booted a live Ubuntu from CD media, checked with fdisk that every
> partition is starting 4K aligned and used the following command to
> copy the disk contents:
> 
> dd if=/dev/sda of=/dev/sdb status=progress bs=4K

Did you unmount all partitions on /dev/sda and /dev/sdb first?
Ubuntu live CDs have a habit of mounting every partition it sees at
startup which will result in a corrupt disk copy. 

The above method is how I clone disks, but I do verify the copy
immediately after with something like:

cmp -n <byte-size-output-by-dd-command> /dev/sba /dev/sdb

-- 
Tixy

[toc] | [prev] | [next] | [standalone]

#178077

Il 22/02/2017 17:40, Tixy ha scritto:
> On Wed, 2017-02-22 at 09:18 +0100, Lucio Crusca wrote:
>> I booted a live Ubuntu from CD media, checked with fdisk that every
>> partition is starting 4K aligned and used the following command to
>> copy the disk contents:
>>
>> dd if=/dev/sda of=/dev/sdb status=progress bs=4K
>
> Did you unmount all partitions on /dev/sda and /dev/sdb first?

Yes I did. But, even if I didn't, I fail to understand how that could break grub.

> Ubuntu live CDs have a habit of mounting every partition it sees at
> startup which will result in a corrupt disk copy.

Just to play it safe, I'm going to make the copy again using sysrescuecd.

>
> The above method is how I clone disks, but I do verify the copy
> immediately after with something like:
>
> cmp -n <byte-size-output-by-dd-command> /dev/sba /dev/sdb

Thanks for the hint, I'll do that too.

[toc] | [prev] | [next] | [standalone]

#178078

On Wed, 2017-02-22 at 18:56 +0100, Lucio Crusca wrote:
> Il 22/02/2017 17:40, Tixy ha scritto:
> > On Wed, 2017-02-22 at 09:18 +0100, Lucio Crusca wrote:
> >> I booted a live Ubuntu from CD media, checked with fdisk that every
> >> partition is starting 4K aligned and used the following command to
> >> copy the disk contents:
> >>
> >> dd if=/dev/sda of=/dev/sdb status=progress bs=4K
> >
> > Did you unmount all partitions on /dev/sda and /dev/sdb first?
> 
> Yes I did. But, even if I didn't, I fail to understand how that could break grub.

If the target disk (your SSD) already had partitions with filesystem and
Ubuntu mounted them, then any activity that modified those filesystem
could be written back to the disk at any time, e.g. to the sectors where
grub was copied to it after it was copied there.

At the very least, Ubuntu would cause writes to the SSD due to things
like superblock updates for mount time and count, and possibly access
timestamps in file inodes. But if it's a GUI desktop live CD, I wouldn't
be surprised if there wasn't background file indexing and thumbnailing
tasks running too, writing who knows what to the filesystem.

-- 
Tixy


If you don't think Ubuntu would write to a file-system unnecessarily,
(which I do, because I'm sure it'll have indexing an thumbnailing tasks
running in the backround)


 you coppied it could cause modifications to be written to the SSD at
any time, say to the sectors where grub got copied to. If you don't
think Ubuntu would cause
 Who knows what background tasks Ubuntu has indexi

then you copying a disk image to the SSD could result in corruption if
Ubuntu caused modifications to the SSD to happen in the same sectors
where Grub was. Say a filesystem superblock was near the start of the
original contents, an the loast mount time or file access times were
written out to that after grub was coppied there  

[toc] | [prev] | [next] | [standalone]

#178079

Tixy wrote:
> At the very least, Ubuntu would cause writes to the SSD due to things
> like superblock updates for mount time and count, and possibly access
> timestamps in file inodes. But if it's a GUI desktop live CD, I wouldn't
> be surprised if there wasn't background file indexing and thumbnailing
> tasks running too, writing who knows what to the filesystem.

I badly hope you are right, for two reasons:

1) the copy this time would work (sysrescuecd)
2) much more important, there would be yet another good reason to call Ubuntu names :)

cmp is running just now, it started a few minutes ago and it will take about 2 hours. No errors reported until now. I'll let you know the results.

[toc] | [prev] | [next] | [standalone]

#178084

Il 22/02/2017 21:40, Lucio Crusca ha scritto:
>
> cmp is running just now, it started a few minutes ago and it will take about 2 hours. No errors reported until now. I'll let you know the results.
>

No errors reported by cmp. Still the system is not bootable, same error as before. What a pity, it wasn't Ubuntu to blame...
  

[toc] | [prev] | [next] | [standalone]

#178087

[Multipart message — attachments visible in raw view] — view raw

On 22/02/17 21:18, Lucio Crusca wrote:
> Here is how I copied the disk contents over the SDD.
> I booted a live Ubuntu from CD media, checked with fdisk that every
> partition is starting 4K aligned and used the following command to copy
> the disk contents:
> 
> dd if=/dev/sda of=/dev/sdb status=progress bs=4K

You checked the partitions (on /dev/sdb) with fdisk, and then did the dd?

I think you just overwrote the partitions you checked.

I don't know if this is related to your problem.

Maybe you'd be better off copying the partitions separately, and then
reinstalling grub.

Richard

[toc] | [prev] | [next] | [standalone]

#178101

> The HDD is a Seagate 250GB 7200rpm, the SDD is a Samsung 250GB EVO 850.
> The total capacity matches exactly.

You mean they really have *exactly* the same number of blocs?

> dd if=/dev/sda of=/dev/sdb status=progress bs=4K

FWIW, after doing that, I'd recommend you look at the partition table,
edit it (ever so slightly) and save the result: GPT partition tables are
duplicated: one copied at the very beginning and one copy at the very
end, so if the drives don't have exactly the same size the secondary
copy will appear corrupted.

Sadly, I don't think that explains your problem,


        Stefan

[toc] | [prev] | [next] | [standalone]

#178104

[Multipart message — attachments visible in raw view] — view raw

On Wed, Feb 22, 2017 at 09:18:26AM +0100, Lucio Crusca wrote:
> dd if=/dev/sda of=/dev/sdb status=progress bs=4K

Why did you decide to do a block-level copy, rather than file-level? Too many
partitions/LVM volumes/etc?  Personally I'd always recommend a file-level copy,
using something like rsync, which means no duplicate UUIDs, you aren't spending
time copying sectors that aren't referenced, the SSD gets fewer write cycles
and it can be interrupted and resumed. Or pvmove in some cases.

-- 
Jonathan Dowland

[toc] | [prev] | [next] | [standalone]

#178108

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Feb 23, 2017 at 02:27:51PM +0000, Jonathan Dowland wrote:
> On Wed, Feb 22, 2017 at 09:18:26AM +0100, Lucio Crusca wrote:
> > dd if=/dev/sda of=/dev/sdb status=progress bs=4K
> 
> Why did you decide to do a block-level copy, rather than file-level?

Not the OP, but there are other reasons to prefer a block-level copy,
among others "same UUID" (I know, I know), so no need to change fstab.

Usually I prefer a file-level copy, though.

Regards
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAliu+n8ACgkQBcgs9XrR2kYNswCfUJ6HRkan7zjLK/fXltCqc0qA
sOAAn32Y7UEFICksx7s/kYHpYQKq4J7g
=qsjO
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#178112

> among others "same UUID" (I know, I know), so no need to change fstab.

Yuck!  I recommend you stay away from UUIDs in your fstab.  Instead name
your partitions.  If you use LVM (which you should do anyway for all
kinds of other reasons) your volumes are already named anyway so there's
nothing special to do, and for those rare cases where you have to use
a "real partition" rather than an LVM volume, then label the
file-system.

That gives you much more readable /etc/fstab entries, and that saves you
from having to worry about which operation preserves UUID and which
doesn't and when do you need to change the UUID and when you don't (and
how).

Of course, you may say that I just traded managing UUIDs against
managing names, but in my experience it's simpler, more upfront, and
intuitive, so I'm never caught off-guard.


        Stefan

[toc] | [prev] | [next] | [standalone]

#178127

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Feb 23, 2017 at 10:45:55AM -0500, Stefan Monnier wrote:
> > among others "same UUID" (I know, I know), so no need to change fstab.
> 
> Yuck!  I recommend you stay away from UUIDs in your fstab.  Instead name
> your partitions.

Agree -- only in half. I think those are different things and are thus
to be used differently.

For "permanently" or "semipermanently" mounted things, label/name
is a good match. For travelling things, where you want to avoid
inadvertent collissions, UUID might be better (you might argue that
in this case the UUID shouldn't be in the fstab in the first place;
but using the UUID to "recognize" the partition is here the right
thing to do).

[...]

> Of course, you may say that I just traded managing UUIDs against
> managing names, but in my experience it's simpler, more upfront, and
> intuitive, so I'm never caught off-guard.

I may, but I won't say :-)

For partitions which don't move much (and that's almost surely the
set in fstab) we are in violent agreement. Still you might want to
have an "errant disk" in the fstab (the proverbial back-up USB
drive which comes and goes): then I would definitely use UUID, to
avoid dumping my backups to the wrong drive. But then, this one
perhaps wouldn't be documented in fstab.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAliwAPEACgkQBcgs9XrR2kZHSACeO/ekKlI9inPsDlt02TavRr+r
WxwAn2XyKu8qsinW65dThSRqGuGbhApU
=n2p1
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#178129

Hi,

whatever merits the various address methods for partitions may have,
the GRUB message "invalid arch-independent ELF magic" is about a program
file and not about a partition.

Pick any source file of this list in a current
git://git.savannah.gnu.org/grub.git clone:

  ./grub-core/loader/i386/bsdXX.c:    return grub_error (GRUB_ERR_BAD_OS, N_("invalid arch-independent ELF magic"));
  ./grub-core/loader/ia64/efi/linux.c:                  N_("invalid arch-independent ELF magic"));
  ./grub-core/loader/multiboot_elfxx.c:    return grub_error(GRUB_ERR_UNKNOWN_OS, N_("invalid arch-independent ELF magic"));
  ./grub-core/kern/dl.c:    return grub_error (GRUB_ERR_BAD_OS, N_("invalid arch-independent ELF magic"));
  ./grub-core/kern/elf.c:    return grub_error (GRUB_ERR_BAD_OS, N_("invalid arch-independent ELF magic"));
  ./grub-core/kern/elf.c:    return grub_error (GRUB_ERR_BAD_OS, N_("invalid arch-independent ELF magic"));
  ./util/grub-module-verifierXX.c:    grub_util_error ("invalid arch-independent ELF magic");

It's always the same gesture when looking for the data described in
  https://en.wikipedia.org/wiki/Executable_and_Linkable_Format#File_header


So why does the reigning GRUB not like the file in the perfect disk copy ?
Maybe because it is not accessing the copied disk at all but rather reads
garbage from somewhere else ?
(The internet has rumors that re-installing GRUB would help. Shrug.)


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#178130

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Feb 24, 2017 at 11:43:00AM +0100, Thomas Schmitt wrote:
> Hi,
> 
> whatever merits the various address methods for partitions may have,
> the GRUB message "invalid arch-independent ELF magic" is about a program
> file and not about a partition.

[...]

Thanks, Thomas. Even-headed as always, and the most insightful contribution
in this thread so-far :)

regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAliwGEEACgkQBcgs9XrR2kY79wCfQnTmXGus6NEwbrySqDUm9mCA
DxQAoII1mS50/swLFMyuz+weaWyVld3V
=w7E2
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web