Nur noch bis MORGEN statt 249,00€ jetzt nur für 47,00€

[Newsletter]

25% Rabatt auf ALLE BODYWORK360 Programme 

+++ NUR NOCH BIS MORGEN +++ 

Hey,
Ich hoffe du genießt dein Wochenende :)

Bis morgen Abend hast du noch die Möglichkeit Dir 25% Rabatt auf alle 
BODYWORK360 Programme zu sichern. 

Nur jetzt statt 249,00€ nur für 47,00€

Die Auswahl ist groß! Suche dir aus unseren verschiedenen BODYWORK360 
Programmen, das für Dich am besten geeignetste Programm heraus.

Klicke HIER und erfahre mehr http://bit.ly/2roJkas

Heute möchte ich dir zeigen, was mit unserem Fettreduzierungs- und 
Definitionsprogramm möglich ist.  http://bit.ly/2roJkas

Das sind Anna und Erik. Die beiden haben erst vor kurzem das Programm beendet 
und sind mehr als zufrieden mit ihren Ergebnissen.
Aber sieh selbst:

Innerhalb von 12 Wochen haben die beiden es geschafft ihren Körperfettanteil 
deutlich zu senken UND dabei sogar noch stärker zu werden. 

Respekt dafür!
Hier gibt es noch mehr Transformationen http://bit.ly/2roJkas

Wenn auch Du durchstarten willst, egal ob mit Fettverbrennung, oder 
Muskelaufbau, mit dem Kauf der BODYWORK360 Programmen bist du deinem Ziel schon 
einen entscheidenden Schritt näher gekommen.

Klicke HIER und erfahre alles über die Angebote http://bit.ly/2roJkas


Falls der Fall bei dir eintritt und du keine bilder sehen kannst schau sie dir 
bitte online an

Und nun wünsche ich dir noch ein schönes Wochenende :)

Dein Karl

P.S: Nur noch bis MORGEN hast du die Chance dir 25% Rabatt zu sichern.
Es wird also allerhöchste Zeit dein Angebot hier sicher  http://bit.ly/2roJkas

Re: switching flavors

[Davor Balder]

Yes - and based on some work I did earlier in the week if you keep the
things simple I would say your upgrade should be uneventful.

I  changed the repo to unstable

Then I did:

apt-get update

apt-get upgrade

That was it.


Cheers


D

On 04/06/17 13:11, Gary Dale wrote:
> On 03/06/17 08:59 PM, Frank M wrote:
>> I am running Debian Stretch, and like to change to Sid.
>>
>> Can I just change my sources.list to unstable and upgrade?
>>
>> I have run Sid before and am prepared to deal with some breakage
>
> Yes, although I'd do a dist-upgrade (or full-upgrade if using aptitude).
>
> Based on some earlier problems with Stretch and the discussions around
> it, I'm not sure that sid is necessarily less stable. Apparently they
> dump stuff into Stretch without anyone actually checking to see that
> it can work with other Stretch libraries.
>

Re: switching flavors

[Gary Dale]

On 03/06/17 08:59 PM, Frank M wrote:

I am running Debian Stretch, and like to change to Sid.

Can I just change my sources.list to unstable and upgrade?

I have run Sid before and am prepared to deal with some breakage


Yes, although I'd do a dist-upgrade (or full-upgrade if using aptitude).

Based on some earlier problems with Stretch and the discussions around 
it, I'm not sure that sid is necessarily less stable. Apparently they 
dump stuff into Stretch without anyone actually checking to see that it 
can work with other Stretch libraries.

switching flavors

[Frank M]

I am running Debian Stretch, and like to change to Sid.

Can I just change my sources.list to unstable and upgrade?

I have run Sid before and am prepared to deal with some breakage.

Re: drive names and UUIDs, was Re: Intresting dd fsck grub uuid fstab action

[Joel Rees]

On Sun, Jun 4, 2017 at 12:59 AM, Pascal Hambourg  wrote:
> Le 03/06/2017 à 17:48, Gene Heskett a écrit :
>>
>>
>> I don't believe that will work.  dd runs on the raw device, not to an
>> artificially created "partition".
>
>
> dd runs on any type of device, including partitions.
>

But it copies the raw data.

In the context of this discussion, it makes absolutely no sense to
have it twiddling any of the data it copies, much less any of the data
that refers to what is being copied.

(Sorry about the misfire, Pascal.)

-- 
Joel Rees

One of these days I'll get someone to pay me
to design a language that combines the best of Forth and C.
Then I'll be able to leap wide instruction sets with a single #ifdef,
run faster than a speeding infinite loop with a #define,
and stop all integer size bugs with a bare cast.

More of my delusions:
http://reiisi.blogspot.com/2017/05/do-not-pay-modern-danegeld-ransomware.html
http://reiisi.blogspot.jp/p/novels-i-am-writing.html

Re: drive names and UUIDs, was Re: Intresting dd fsck grub uuid fstab action

[Joel Rees]

(Google or something is screwing up the threading. My apologies if I
mess it up further.)

On Sun, Jun 4, 2017 at 7:30 AM, Fungi4All  wrote:
>
>> From: deb...@lionunicorn.co.uk
>>
>>> Ι was waiting to see if anyone else found something like this significant
>> and willing to contribute some wisdom
>> No wisdom here, I'm afraid.
>
> just evolution of the unix-dna

It would definitely be evolution. And it would be something that should be
relegated to an explicitly specified option (maybe like character
encoding stuff), if at all.

And it would be orders of magnitude more complex than what dd now
does. That's part of the reason we have (g)parted and other similar
tools. (And, if you are using LVM, LVM has its own tools.)

>>[...]
>>> Also, I believe that when dd is used to copy something from disk to disk
>>> it should provide an option of whether to
>>> produce a new uuid or retain the original (backup, not a concurrent
>>> system).
>
>> Here you're asking for the impossible. dd is blind to what it's
>> copying at that level. It can fiddle with something it calls "records"
>> (which stinks of IBM FB↔VB conversion) and that's about it.
>
>
> I actually like dd the more I learn about it but what I was suggesting was
> to have
> an option to change the uuid to a new random one after it is done copying.

If at all, an option, but it really is out of dd's scope. dd is not parted.

> I understand (think) that dd does not even care about the format of the fs
> it copies
> or that of what it copies to, just blocks of space, where to start and where
> to finish.

Very true.

> So if a 10gb NTFS partition is copied to a 20gb EXT4 partition, the target
> will be an
> ntfs 20gb partition.

No, the target will, depending on what you specify, be a 10gb file in
the ext4 partition or a 10gb NTFS partition (overwriting the ext4 file
system completely) and a 10gb gap of unused disk space that the MBR
says goes with the partition which is formatted as a 10gb NTFS
partition, but the NTFS partition really doesn't know anything about
(unless you tell it about it afterwards by expanding the partition
using NTFS tools.)

IIUC.

>  So I suspect it does formatting in there too,

dd is not parted, nor is it an NTFS partition editor.

> otherwise the
> partition would have been left half ntfs half ext4.

The MBR partition is left half used by the NTFS file system and half
unused. The unused part may have some useless bits of ext4 left
behind, but it has nothing like a file system in it.

> The kernel I assume as soon as dd is done picks up the new set of uuids and
> updates the table.  So if dd does not do it it leaves the system in a mesh.

Not that I am aware. Not unless you tell the kernel to do so.

>[...]


-- 
Joel Rees

One of these days I'll get someone to pay me
to design a language that combines the best of Forth and C.
Then I'll be able to leap wide instruction sets with a single #ifdef,
run faster than a speeding infinite loop with a #define,
and stop all integer size bugs with a bare cast.

More of my delusions:
http://reiisi.blogspot.com/2017/05/do-not-pay-modern-danegeld-ransomware.html
http://reiisi.blogspot.jp/p/novels-i-am-writing.html

Re: Proper sources list from Jessie > Stretch

[Ric Moore]

On 06/02/2017 10:41 AM, Fungi4All wrote:

Sorry for the top-post but I think it is appropriate


It is not ever appropriate, no matter what you think. Ric


--
My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
http://linuxcounter.net/user/44256.html

Re: HP CP1215 - CUPS not printing from Stretch to Jessie server.

[Gary Dale]

The Printing section on the wiki deals with "Double Filtering". It might
help.



Where is the wiki?

Re: HP CP1215 - CUPS not printing from Stretch to Jessie server.

[Gary Dale]

On 03/06/17 02:39 PM, Gary Dale wrote:

On 03/06/17 02:21 PM, Brian wrote:

On Sat 03 Jun 2017 at 14:00:59 -0400, Gary Dale wrote:


On 03/06/17 05:10 AM, Brian wrote:

On Fri 02 Jun 2017 at 16:38:42 -0400, Gary Dale wrote:

I have an HP Color Laserjet CP1215 printer attached to a Jessie 
server via
USB. I'm trying to print to it from Stretch workstation. This has 
been
failing for a long time now. It's not a new problem. I've tried 
removing the

printer and re-finding it many times without success.
We presume the re-finding is done via the CUPS web interface or 
something

similar. Is cups-browsed running on the client?

  systemctl status cups-browsed

Yes, I used the web interface to find the printer.

On the following pages you would be best advised to choose "raw" as the
PPD and have all the filtering on the server.


And yes cups-browsed is
running on the workstation.

cups-browsed is not a cause of your problem but if you let it do its
job it would set up a raw queue for you.

You're right, but I've had this setup for a long time and it was never 
a problem before. It seems to have started with Stretch.


Anyway, thanks!



After much gnashing of teeth (actually disassembling my Samsung C410 to 
remove two sheets of paper wrapped around the fuser), I'm still confused 
about something. When I set up my Samsung C410 through the CUPS web 
interface, on the server I use the Samsung C410 driver and the usb 
connection. On the client I use the discovered printer but again need to 
use the Samsung C410 driver which now shows up as Remote printer: 
Samsung C410 Series (color).


When I set up the HP Color LaserJet CP1215, on the server I use the HP 
Color LaserJet CP1215 Foomatic driver and the usb connection. However on 
the client when I use the discovered printer and the CP1215 driver, it 
doesn't work. I need to use raw printing.


I'm sorry but this doesn't make any sense to me. If I understand things 
correctly, CUPS knows that the printer is remote and is being handled by 
a CUPS server but can't figure out which machine should do the 
rendering. Instead it leaves it up to the driver to add the smarts to 
figure out who should do it.


I've got several printers attached to my server, including 2 Samsungs, 1 
Epson and the CP1215. Only the CP1215 seems to believe that it is a 
local raw printer on my client. And again, this only seems to be a 
problem since I moved to Stretch. I think this qualifies as a bug.

Re: drive names and UUIDs, was Re: Intresting dd fsck grub uuid fstab action

[Fungi4All]

From: deb...@lionunicorn.co.uk

> Ι was waiting to see if anyone else found something like this significant and 
> willing to contribute some wisdom
No wisdom here, I'm afraid.

just evolution of the unix-dna

> I suspect the experiment would be simple.
> Let's say we make a new partition on a disk with a debian installed system 
> and use dd to clone that system in
> the new partition (I have no idea whether doing this in the same disk or a 
> second one makes a difference),
> Let's say that dd copies uuid to the new partition so we have two partitions 
> with the same uuid in the same system.
> Intentionally we make the mistake and log in to the original system and 
> update-grub with the conflict.

AIUI there's a race condition here, perhaps even several. The correct
MBR should be read as normal by the BIOS, but grub then searches
by UUID for the kernel/ramdisk, and the kernel searches by UUID for
the root filesystem, and we don't know how it chooses between them.

I think this bit of info gets one level deeper to source of problems.

Do they (a) take the UUID being searched for and look at each disk/
partition's UUID for a match, or (b) read all the available UUIDs into
a table (overwriting any duplicates by the new entry) and then take
the UUID being searched for and look it up in the table? These
strategies give opposite results.

I suspect at some point, when 2 matching uuids come up for different
disks or parts of the same disk, the partition is left out as unmountable.
In my case it would mix and match the partitions of one system with
some from its clone. How do I know this? I had labeled the partitions
as their sda/sdb numbers and the system booted with 5 partitions
showing me the mix match as unmounted and when I'd attempt to mount
them it would say no no.

> Then relogin and create new uuids for the clone, edit ftstab and check 
> original, then update-grub.
> Will it boot having the first root or the clone root? Then look at grub.cfg 
> of the original to see if the uuids for each
> entry are matching or there is a mismatch.
> I went through the grub manual and didn't come up with an answer. It smells 
> like a tiny bug or room for improvement.

I think you'd have to study both grub and the kernel's code to
find an answer, and their developers would say "Just don't do it,
it's not defined, it may change tomorrow".

if time=23:59 do yesterday :)

> Also, I believe that when dd is used to copy something from disk to disk it 
> should provide an option of whether to
> produce a new uuid or retain the original (backup, not a concurrent system).

Here you're asking for the impossible. dd is blind to what it's
copying at that level. It can fiddle with something it calls "records"
(which stinks of IBM FB↔VB conversion) and that's about it.

I actually like dd the more I learn about it but what I was suggesting was to 
have
an option to change the uuid to a new random one after it is done copying.
I understand (think) that dd does not even care about the format of the fs it 
copies
or that of what it copies to, just blocks of space, where to start and where to 
finish.
So if a 10gb NTFS partition is copied to a 20gb EXT4 partition, the target will 
be an
ntfs 20gb partition. So I suspect it does formatting in there too, otherwise the
partition would have been left half ntfs half ext4.
The kernel I assume as soon as dd is done picks up the new set of uuids and
updates the table. So if dd does not do it it leaves the system in a mesh.

For copying filesystems around, there are commands for doing that.
Years ago I used cpio -vdamp but I've seen better commands (cp -a ?)
in threads here more recently. These have the advantage that you
prepare the empty filesystem the way you want it before you copy
into it.

I thought that dd is more accurate and quicker with the exception of little
data in a huge partition, where it copies a huge amount of empty space.

Cheers,
David.

cheers back

Re: Install Debian 8.8.0/XFCE on32 bit system

[Felix Miata]

David Wright composed on 2017-06-01 18:55 (UTC-0500):

> When I managed to persuade the Computing Service to issue me with
> several disks at the same time (very infrequently), I would make
> sure I created partitions with slightly different (usually by one
> cylinder, a historical concept!) absolute and relative sizes so that
> I could distinguish them in circumstances where size was the only
> parameter visible.

Most of my / partitions are 4800M, 5600M or 7200M, to facilitate interchange
with minimal need to do any re-partitioning. I have bunches of multiboot test
systems, and do a lot of cloning. There's no way I could keep track of what I
have without a written record of what lives where. Luckily, the only partitioner
ever used here[1] creates logs with tables that inventory each disk wonderfully.
(Old) example: http://fm.no-ip.com/Tmp/Dfsee/fi965d03.txt

[1] http://www.dfsee.com/
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: drive names and UUIDs, was Re: Intresting dd fsck grub uuid fstab action

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Jun 03, 2017 at 05:59:06PM +0200, Pascal Hambourg wrote:
> Le 03/06/2017 à 17:48, Gene Heskett a écrit :
> >
> >I don't believe that will work.  dd runs on the raw device, not to an
> >artificially created "partition".
> 
> dd runs on any type of device, including partitions.

Exactly. Or to nit the pick a tad more: dd copies a raw byte stream:
that can be a device, a partition, a chunk thereof or even a file.
Whatever the OS can represent as a byte stream.

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

iEYEARECAAYFAlkzC0wACgkQBcgs9XrR2kYuPQCaAn0s5QjN7FgsIxsmm+B7H4vx
hpwAn33UTBG8fyWPPmE1hFtXZ6D4FKYb
=q5IS
-END PGP SIGNATURE-

Re: HP CP1215 - CUPS not printing from Stretch to Jessie server.

[Gary Dale]

On 03/06/17 02:21 PM, Brian wrote:

On Sat 03 Jun 2017 at 14:00:59 -0400, Gary Dale wrote:


On 03/06/17 05:10 AM, Brian wrote:

On Fri 02 Jun 2017 at 16:38:42 -0400, Gary Dale wrote:


I have an HP Color Laserjet CP1215 printer attached to a Jessie server via
USB. I'm trying to print to it from Stretch workstation. This has been
failing for a long time now. It's not a new problem. I've tried removing the
printer and re-finding it many times without success.

We presume the re-finding is done via the CUPS web interface or something
similar. Is cups-browsed running on the client?

  systemctl status cups-browsed

Yes, I used the web interface to find the printer.

On the following pages you would be best advised to choose "raw" as the
PPD and have all the filtering on the server.


And yes cups-browsed is
running on the workstation.

cups-browsed is not a cause of your problem but if you let it do its
job it would set up a raw queue for you.

You're right, but I've had this setup for a long time and it was never a 
problem before. It seems to have started with Stretch.


Anyway, thanks!

Re: HP CP1215 - CUPS not printing from Stretch to Jessie server.

[Brian]

On Sat 03 Jun 2017 at 14:00:59 -0400, Gary Dale wrote:

> On 03/06/17 05:10 AM, Brian wrote:
> >On Fri 02 Jun 2017 at 16:38:42 -0400, Gary Dale wrote:
> >
> >>I have an HP Color Laserjet CP1215 printer attached to a Jessie server via
> >>USB. I'm trying to print to it from Stretch workstation. This has been
> >>failing for a long time now. It's not a new problem. I've tried removing the
> >>printer and re-finding it many times without success.
> >We presume the re-finding is done via the CUPS web interface or something
> >similar. Is cups-browsed running on the client?
> >
> >  systemctl status cups-browsed
> 
> Yes, I used the web interface to find the printer.

On the following pages you would be best advised to choose "raw" as the
PPD and have all the filtering on the server.

>And yes cups-browsed is
> running on the workstation.

cups-browsed is not a cause of your problem but if you let it do its
job it would set up a raw queue for you.

-- 
Brian.

Re: HP CP1215 - CUPS not printing from Stretch to Jessie server.

[Gary Dale]

On 03/06/17 05:10 AM, Brian wrote:

On Fri 02 Jun 2017 at 16:38:42 -0400, Gary Dale wrote:


I have an HP Color Laserjet CP1215 printer attached to a Jessie server via
USB. I'm trying to print to it from Stretch workstation. This has been
failing for a long time now. It's not a new problem. I've tried removing the
printer and re-finding it many times without success.

We presume the re-finding is done via the CUPS web interface or something
similar. Is cups-browsed running on the client?

  systemctl status cups-browsed


Yes, I used the web interface to find the printer. And yes cups-browsed 
is running on the workstation.




I'm using the HP Color LaserJet CP1215 Foomatic/foo2hp (recommended) driver
on both the server and my workstation. However when I try printing anything
from the workstation, it fails with a "Filter failed" message. The message
appears on the CUPS Jobs page on both the workstation and server.

I can print directly from the server (e.g. test page using the CUPS Printers
page or lp from the command line) but not from my workstation.

I can print to another printer (Samsung C410) attached to the server, also
by USB, using the same protocol (dnssd:) and it works. The major difference
is that the it's using the Samsung C410 Series (color) driver.

The cups error log on the server isn't helpful. The first message that it
shows for a failing job is:

E [02/Jun/2017:14:17:27 -0400] [Job 2241] Job stopped due to filter errors;
please consult the error_log file for details.

Unfortunately, the code that reports the terminating state of the job
does not have the name of the process that failed, which gets logged
separately.


Further down it shows these interesting messages:

D [02/Jun/2017:14:17:27 -0400] [Job 2241] Printing system options:
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option
'job-uuid=urn:uuid:33ae3777-92ed-3ade-5cc3-a52464b726bc'
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option
job-uuid=urn:uuid:33ae3777-92ed-3ade-5cc3-a52464b726bc.
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option
'job-originating-host-name=192.168.1.24'
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option
job-originating-host-name=192.168.1.24.
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option
'time-at-creation=1496427439'
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option
time-at-creation=1496427439.
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option
'time-at-processing=1496427439'
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option
time-at-processing=1496427439.
D [02/Jun/2017:14:17:27 -0400] [Job 2241] CM Color Calibration Mode in CUPS:
Off
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Options from the PPD file:
D [02/Jun/2017:14:17:27 -0400] [Job 2241]

D [02/Jun/2017:14:17:27 -0400] [Job 2241] File: /var/spool/cups/d02241-001
D [02/Jun/2017:14:17:27 -0400] [Job 2241]

D [02/Jun/2017:14:17:27 -0400] [Job 2241] Cannot process
"/var/spool/cups/d02241-001": Unknown filetype.

The server has been sent a file by the client which cannot be MIME typed.


D [02/Jun/2017:14:17:27 -0400] [Job 2241] Process is dying with "Could not
print file /var/spool/cups/d02241-001
D [02/Jun/2017:14:17:27 -0400] [Job 2241] ", exit stat 2

Any ideas?

The Printing section on the wiki deals with "Double Filtering". It might
help.

Re: drive names and UUIDs, was Re: Intresting dd fsck grub uuid fstab action

[Pascal Hambourg]

Le 03/06/2017 à 18:04, David Wright a écrit :


AIUI there's a race condition here, perhaps even several. The correct
MBR should be read as normal by the BIOS, but grub then searches
by UUID for the kernel/ramdisk, and the kernel searches by UUID for
the root filesystem, and  we don't know how it chooses between them.


Note that the kernel does not know anything about filesystem UUIDs 
(stored in filesystem metadata). It only knows about partition UUIDs 
(stored in partition tables). The part that uses UUIDs to locate the 
root filesystem is the initrd/initramfs userland scripts, with the help 
of libblkid/udev.



Do they (a) take the UUID being searched for and look at each disk/
partition's UUID for a match, or (b) read all the available UUIDs into
a table (overwriting any duplicates by the new entry) and then take
the UUID being searched for and look it up in the table? These
strategies give opposite results.


I think GRUB does the former and libblkid/udev does the latter.

Re: drive names and UUIDs, was Re: Intresting dd fsck grub uuid fstab action

[David Wright]

On Sat 03 Jun 2017 at 11:02:54 (-0400), Fungi4All wrote:

> Ι was waiting to see if anyone else found something like this significant and 
> willing to contribute some wisdom

No wisdom here, I'm afraid.

> I suspect the experiment would be simple.
> Let's say we make a new partition on a disk with a debian installed system 
> and use dd to clone that system in
> the new partition (I have no idea whether doing this in the same disk or a 
> second one makes a difference),
> Let's say that dd copies uuid to the new partition so we have two partitions 
> with the same uuid in the same system.
> Intentionally we make the mistake and log in to the original system and 
> update-grub with the conflict.

AIUI there's a race condition here, perhaps even several. The correct
MBR should be read as normal by the BIOS, but grub then searches
by UUID for the kernel/ramdisk, and the kernel searches by UUID for
the root filesystem, and  we don't know how it chooses between them.

Do they (a) take the UUID being searched for and look at each disk/
partition's UUID for a match, or (b) read all the available UUIDs into
a table (overwriting any duplicates by the new entry) and then take
the UUID being searched for and look it up in the table? These
strategies give opposite results.

> Then relogin and create new uuids for the clone, edit ftstab and check 
> original, then update-grub.
> Will it boot having the first root or the clone root? Then look at grub.cfg 
> of the original to see if the uuids for each
> entry are matching or there is a mismatch.
> I went through the grub manual and didn't come up with an answer. It smells 
> like a tiny bug or room for improvement.

I think you'd have to study both grub and the kernel's code to
find an answer, and their developers would say "Just don't do it,
it's not defined, it may change tomorrow".

> Also, I believe that when dd is used to copy something from disk to disk it 
> should provide an option of whether to
> produce a new uuid or retain the original (backup, not a concurrent system).

Here you're asking for the impossible. dd is blind to what it's
copying at that level. It can fiddle with something it calls "records"
(which stinks of IBM FB↔VB conversion) and that's about it.

For copying filesystems around, there are commands for doing that.
Years ago I used cpio -vdamp but I've seen better commands (cp -a ?)
in threads here more recently. These have the advantage that you
prepare the empty filesystem the way you want it before you copy
into it.

Cheers,
David.

Re: drive names and UUIDs, was Re: Intresting dd fsck grub uuid fstab action

[Pascal Hambourg]

Le 03/06/2017 à 17:48, Gene Heskett a écrit :


I don't believe that will work.  dd runs on the raw device, not to an
artificially created "partition".


dd runs on any type of device, including partitions.

Re: drive names and UUIDs, was Re: Intresting dd fsck grub uuid fstab action

[Gene Heskett]

On Saturday 03 June 2017 11:02:54 Fungi4All wrote:

>  Original Message 
> From: deb...@lionunicorn.co.uk
> To: debian-user@lists.debian.org
>
> On Thu 01 Jun 2017 at 12:24:28 (-0400), Fungi4All wrote:
> > Why don't just skip all this that we are in perfect agreement with
> > and go to the juicy part. After all uuids are unique and fstab are
> > all correct, updating-grub would mix match uuids in writing its
> > grub.cfg
> > Two uuids on the same entry! Over and over again till I edited
> > it out to the correct ones and it all worked. Why does everyone
> > choses to skip on this issue and keeps explaining me over and over
> > what I have well understood by now?
>
> Well, we don't have a lot of evidence. But we do have a tiny bit:
>
> Ι was waiting to see if anyone else found something like this
> significant and willing to contribute some wisdom I suspect the
> experiment would be simple.
> Let's say we make a new partition on a disk with a debian installed
> system and use dd to clone that system in the new partition (I have no
> idea whether doing this in the same disk or a second one makes a
> difference),

I don't believe that will work.  dd runs on the raw device, not to an 
artificially created "partition".

rsync OTOH, can run on a partition to partition basis.  And that should 
give you different blkid's.

> Let's say that dd copies uuid to the new partition so we 
> have two partitions with the same uuid in the same system.
> Intentionally we make the mistake and log in to the original system
> and update-grub with the conflict. Then relogin and create new uuids
> for the clone, edit ftstab and check original, then update-grub. Will
> it boot having the first root or the clone root? Then look at grub.cfg
> of the original to see if the uuids for each entry are matching or
> there is a mismatch.
> I went through the grub manual and didn't come up with an answer. It
> smells like a tiny bug or room for improvement. Also, I believe that
> when dd is used to copy something from disk to disk it should provide
> an option of whether to produce a new uuid or retain the original
> (backup, not a concurrent system).
>
> if [ x$feature_platform_search_hint = xy ]; then
> search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos3
> --hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3
> --hint='hd0,msdos3' UUID on sda3 XXX else
> search --no-floppy --fs-uuid --set=root UUID on sda3 YYY
> fi


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: drive names and UUIDs, was Re: Intresting dd fsck grub uuid fstab action

[Fungi4All]

 Original Message 
From: deb...@lionunicorn.co.uk
To: debian-user@lists.debian.org

On Thu 01 Jun 2017 at 12:24:28 (-0400), Fungi4All wrote:

> Why don't just skip all this that we are in perfect agreement with and go to 
> the juicy part.
> After all uuids are unique and fstab are all correct, updating-grub would mix 
> match uuids in writing
> its grub.cfg
> Two uuids on the same entry! Over and over again till I edited it out to 
> the correct ones and it all worked.
> Why does everyone choses to skip on this issue and keeps explaining me over 
> and over
> what I have well understood by now?

Well, we don't have a lot of evidence. But we do have a tiny bit:

Ι was waiting to see if anyone else found something like this significant and 
willing to contribute some wisdom
I suspect the experiment would be simple.
Let's say we make a new partition on a disk with a debian installed system and 
use dd to clone that system in
the new partition (I have no idea whether doing this in the same disk or a 
second one makes a difference),
Let's say that dd copies uuid to the new partition so we have two partitions 
with the same uuid in the same system.
Intentionally we make the mistake and log in to the original system and 
update-grub with the conflict.
Then relogin and create new uuids for the clone, edit ftstab and check 
original, then update-grub.
Will it boot having the first root or the clone root? Then look at grub.cfg of 
the original to see if the uuids for each
entry are matching or there is a mismatch.
I went through the grub manual and didn't come up with an answer. It smells 
like a tiny bug or room for improvement.
Also, I believe that when dd is used to copy something from disk to disk it 
should provide an option of whether to
produce a new uuid or retain the original (backup, not a concurrent system).

if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos3 
--hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3 --hint='hd0,msdos3' UUID on 
sda3 XXX
else
search --no-floppy --fs-uuid --set=root UUID on sda3 YYY
fi

Re: Trying to understand man page for dd

[Curt]

On 2017-06-01, Ulf Volmer  wrote:
> On 05/28/2017 02:05 PM, JPlews wrote:
>
 $ dd if=/dev/zero of=/dev/null& pid=$!
 $ kill -USR1 $pid; sleep 1; kill $pid
>
>> have a look at status=progress
>
> This option does not exist in debian stable.

Would 'pv' help?

 dd if=/dev/zero | pv | of=/dev/null

Apparently if you know the approximate 'size' it will give you will an
ETA.

 dd if=/dev/sdb | pv -s 2G | dd of=DriveCopy1.dd bs=4096

It can also be used directly as in the man page example

 pv file | nc -w 1 somewhere.com 3000

In this latter case it evaluates the file size directly.


> best regards
> Ulf
>
>


-- 
"It might be a vision--of a shell, of a wheelbarrow, of a fairy kingdom on the
far side of the hedge; or it might be the glory of speed; no one knew." --Mrs.
Ramsay, speculating on why her little daughter might be dashing about, in "To
the Lighthouse," by Virginia Woolf.

Re: HP CP1215 - CUPS not printing from Stretch to Jessie server.

[Brian]

On Fri 02 Jun 2017 at 16:38:42 -0400, Gary Dale wrote:

> I have an HP Color Laserjet CP1215 printer attached to a Jessie server via
> USB. I'm trying to print to it from Stretch workstation. This has been
> failing for a long time now. It's not a new problem. I've tried removing the
> printer and re-finding it many times without success.

We presume the re-finding is done via the CUPS web interface or something
similar. Is cups-browsed running on the client?

 systemctl status cups-browsed

> I'm using the HP Color LaserJet CP1215 Foomatic/foo2hp (recommended) driver
> on both the server and my workstation. However when I try printing anything
> from the workstation, it fails with a "Filter failed" message. The message
> appears on the CUPS Jobs page on both the workstation and server.
> 
> I can print directly from the server (e.g. test page using the CUPS Printers
> page or lp from the command line) but not from my workstation.
> 
> I can print to another printer (Samsung C410) attached to the server, also
> by USB, using the same protocol (dnssd:) and it works. The major difference
> is that the it's using the Samsung C410 Series (color) driver.
> 
> The cups error log on the server isn't helpful. The first message that it
> shows for a failing job is:
> 
> E [02/Jun/2017:14:17:27 -0400] [Job 2241] Job stopped due to filter errors;
> please consult the error_log file for details.

Unfortunately, the code that reports the terminating state of the job
does not have the name of the process that failed, which gets logged
separately.

> Further down it shows these interesting messages:
> 
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Printing system options:
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option
> 'job-uuid=urn:uuid:33ae3777-92ed-3ade-5cc3-a52464b726bc'
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option
> job-uuid=urn:uuid:33ae3777-92ed-3ade-5cc3-a52464b726bc.
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option
> 'job-originating-host-name=192.168.1.24'
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option
> job-originating-host-name=192.168.1.24.
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option
> 'time-at-creation=1496427439'
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option
> time-at-creation=1496427439.
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option
> 'time-at-processing=1496427439'
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option
> time-at-processing=1496427439.
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] CM Color Calibration Mode in CUPS:
> Off
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Options from the PPD file:
> D [02/Jun/2017:14:17:27 -0400] [Job 2241]
> 
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] File: /var/spool/cups/d02241-001
> D [02/Jun/2017:14:17:27 -0400] [Job 2241]
> 
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Cannot process
> "/var/spool/cups/d02241-001": Unknown filetype.

The server has been sent a file by the client which cannot be MIME typed.

> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Process is dying with "Could not
> print file /var/spool/cups/d02241-001
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] ", exit stat 2
> 
> Any ideas?

The Printing section on the wiki deals with "Double Filtering". It might
help.

-- 
Brian.

Re: HP CP1215 - CUPS not printing from Stretch to Jessie server.

[Brian]

On Sat 03 Jun 2017 at 07:53:06 +, Curt wrote:

> On 2017-06-03, Gary Dale  wrote:
> >>
> >>
> >> Any ideas?
> >>
> > BTW: the same thing happens when I use the hpcups driver.
> >
> 
> I may be all wet but have you attempted setting the client queue to raw?
> 
> Perhaps this could be tested beforehand with 'lpr -l ' (on the
> client machine, of course).

A good idea. With some slight adjustment to the command printing should
take place:

 lpr -P  -l 

 can only be omitted if it is the default destination.

Alternatively (if lpr is not on the machine):

 lp -d  -o raw 

-- 
Brian.

Re: HP CP1215 - CUPS not printing from Stretch to Jessie server.

[Curt]

On 2017-06-03, Gary Dale  wrote:
>>
>>
>> Any ideas?
>>
> BTW: the same thing happens when I use the hpcups driver.
>

I may be all wet but have you attempted setting the client queue to raw?

Perhaps this could be tested beforehand with 'lpr -l ' (on the
client machine, of course).

Sorry if I wasted your time.


-- 
"It might be a vision--of a shell, of a wheelbarrow, of a fairy kingdom on the
far side of the hedge; or it might be the glory of speed; no one knew." --Mrs.
Ramsay, speculating on why her little daughter might be dashing about, in "To
the Lighthouse," by Virginia Woolf.

Re: How to delay resume after suspend to get disks ready, using kernel command line switch?

[deloptes]

Ram Ramesh wrote:

> Problem:
> 
> I am having a problem with ubuntu 14.04 resume from suspend. I suspect a
> race condition in boot process. I have a mpt2sas (LSISAS2008:
> FWVersion(20.00.07.00)) host adapter to which several of my disks are
> attached. On occasions, there is a delay before these devices become
> available. However, kernel tries to assemble RAID6 that includes these
> disks before they become available. As a result the array gets assembled
> in a degraded mode.
> 
> My question:
> 
> I like to tell kernel to delay resume until LSI card finishes its card
> identifying devices. Can I use resumedelay/rootdelay switches in
> grub.cfg to accomplish this? If so, which one I should use?
> 
> Ramesh

I also have mpt2sas and it is slow in disk initialization but I never use
suspend/resume. I only use shutdown/reboot. I use rootdelay=15.