Re: enumerating with Grub*

[David Wright]

On Fri 08 Jul 2016 at 01:44:28 (-0400), Felix Miata wrote:
> David Wright composed on 2016-07-08 00:04 (UTC-0500):
> 
> >What I'm trying to find out is why you wrote "Grub2 *inexplicably*
> >counts partitions starting with 1" (my emphasis) when everything
> >I've ever seen counts partitions from 1 (with the notable exception
> >of old Grub). I think they've been counted from 1 since their invention.
> 
> The inexplicable part is a consequence of never having seen anything
> explaining *why* the change that breaks backward compatibility with
> itself and the compendium of archived help discussion was made, nor
> why made only for partition enumeration, not disk enumeration, thus
> mixing two counting methods within single configuration strings.
> 
> >However, I've fallen behind in disk technology, still using PATA
> >disks except for caddies. Hence my question about newfangled devices.
> >Do any of those expect you to count their partitions from other than 1?
> >I'm just flailing around for a reason why old Grub might have done what
> >it did, because you haven't yet given one.
> 
> I wasn't trying to explain why it did what it did, only what it did.

Fair enough. You and I see things from a very different perspective.
You want to see the whys of Grub2's scheme, I want those of old Grub.
You see breaking backwards compatibility as inexplicable. I see that
as less important than the major design flaw (IMHO) in old Grub of
counting partitions in a unique (noone has come up with a counter-
example) manner.

The argument of mixing counting methods (disks from 0, partitions
from 1) is a red herring. Counting this way is firmly established. Why
do partitions count from 1? Well, it might be because the designers
realised that '0' could be used as an indication of the whole
disk. There's no such concept when enumerating disks. /sbin/lilo -A
uses 0 in just this way: it deactivates all partitions.

But as for design flaws, I see that choice of partitions counted from
0 in old Grub in much the same way as, say, Guido's choice of integer
division (3 / 2 yields 1) in Python versions before 3: an unfortunate
choice. The backwards compatibility broken by that change alone in
py2→py3 makes enumeration changes in Grub seem trivial to get
frustrated by. The person who started this subthread seemed to have
difficulty with the numbers 0 and 1 anyway.

Cheers,
David.

Automounted with udisks volumes could not be opend in Nautilus normal user (uid=1000)

[Evgenii Frolov]

Dear all,

I've started experiencing a problem with automounted volumes and 
volumes, mounted via Nautilus. I use debian jessie with gnome 3.14. And 
the problem is:


1) I plug in a usb storage device and it is mounted with udisks at 
/media/$USER/$LABEL

OR I use udisksctl mount -b /dev/sdXY
Both of these actions mount th sdXY partition to the /media/$USER/$LABEL.

2) I open Nautilus and click at the mounted device label.

3) I get the error message "This location could not be displayed. \n You 
do not have the permissions necessary to view the contents of “$LABEL”." 
And the directory is not opened. Moreover,

$ ls /media/$USER/$LABEL gives
ls: cannot access /media/$USER/$LABEL: Permission denied

I experience this kind of behavior on a pretty recent debian-gnome 
install. And not only on plugged usb-sticks (any FS: fat, ntfs, ext4), 
but also on my main sda there is additional ext4 partition I do not 
mount via fstab. This partition has the same error message after it not 
being mounted is clicked in nautilus and hence mounted with udisks.


I didn't tweak polkit, udev rules or udisks... The usb-stick I plug in 
works on my secondaty debian installation on the same laptop. By "works" 
I mean it is automounted when plugged in and opens when clicked in 
Nautilus (on the contrary to my Jessie intallation).

Finally, fstab does not include any of described "problem-media".

I have absolutely no idea, what could have caused such a malfunctioning.
Any help required!

Sincerely,
Evgenii

Re: Automounted with udisks volumes could not be opend in Nautilus normal user (uid=1000)

[Michael Biebl]

Am 08.07.2016 um 17:20 schrieb Evgenii Frolov:
> Dear all,
> 
> I've started experiencing a problem with automounted volumes and
> volumes, mounted via Nautilus. I use debian jessie with gnome 3.14. And
> the problem is:
> 
> 1) I plug in a usb storage device and it is mounted with udisks at
> /media/$USER/$LABEL
> OR I use udisksctl mount -b /dev/sdXY
> Both of these actions mount th sdXY partition to the /media/$USER/$LABEL.
> 
> 2) I open Nautilus and click at the mounted device label.
> 
> 3) I get the error message "This location could not be displayed. \n You
> do not have the permissions necessary to view the contents of “$LABEL”."
> And the directory is not opened. Moreover,
> $ ls /media/$USER/$LABEL gives
> ls: cannot access /media/$USER/$LABEL: Permission denied

Does /media/$USER have the wrong permissions?
Is it owned by $USER?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Automounted with udisks volumes could not be opend in Nautilus normal user (uid=1000)

[Evgenii Frolov]

Dear Michael,

/media/$USER is root:root drwxr-x---

and /media/$USER/$LABEL is $USER:$USER drwx--

Is it as intended?
And, if not, how could it be changed without my "help"?

Sincerely,
Evgenii

PS my first list-request...

On 07/08/2016 06:26 PM, Michael Biebl wrote:

Am 08.07.2016 um 17:20 schrieb Evgenii Frolov:

Dear all,

I've started experiencing a problem with automounted volumes and
volumes, mounted via Nautilus. I use debian jessie with gnome 3.14. And
the problem is:

1) I plug in a usb storage device and it is mounted with udisks at
/media/$USER/$LABEL
OR I use udisksctl mount -b /dev/sdXY
Both of these actions mount th sdXY partition to the /media/$USER/$LABEL.

2) I open Nautilus and click at the mounted device label.

3) I get the error message "This location could not be displayed. \n You
do not have the permissions necessary to view the contents of “$LABEL”."
And the directory is not opened. Moreover,
$ ls /media/$USER/$LABEL gives
ls: cannot access /media/$USER/$LABEL: Permission denied

Does /media/$USER have the wrong permissions?
Is it owned by $USER?

Re: Automounted with udisks volumes could not be opend in Nautilus normal user (uid=1000)

[Cindy-Sue Causey]

On 7/8/16, Evgenii Frolov  wrote:
> Dear Michael,
>
> /media/$USER is root:root drwxr-x---
>
> and /media/$USER/$LABEL is $USER:$USER drwx--
>
> Is it as intended?
> And, if not, how could it be changed without my "help"?

While you're waiting for feedback from others, I ran mine for
comparison. For both /media/$USER and /media/$USER/$LABEL, I get:

drwxr-x---+ root root

That's on a super basic debootstrap'ed in Sid Unstable setup where
I've never altered permissions going that route.

Your one there is obviously missing that one execute permission that
I'm *a-suming* is helping cause the problem. That's as much as I can
gather from it. Pretty much about all my memory has ever retained
about permissions is don't give out any more access permissions than
is absolutely necessary to perform ordinary, daily computing. It's
safer for your system that way. :)

Good luck solving your issue.

Cindy :)

-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with duct tape *

Re: Automounted with udisks volumes could not be opend in Nautilus normal user (uid=1000)

[Evgenii Frolov]

Dear Cindy-Sue Causey,

Indeed, I have the same permissions as you've mentioned on my sid 
(upgraded from Jessie-gnome) installation too.

As I understand, it is not the best idea to change this by hand, isn't it?
And what could possibly be a reason for this problem to occur?

Thank you for the assumption!
Sincerely,
Evgenii

On 07/08/2016 07:01 PM, Cindy-Sue Causey wrote:

On 7/8/16, Evgenii Frolov  wrote:

Dear Michael,

/media/$USER is root:root drwxr-x---

and /media/$USER/$LABEL is $USER:$USER drwx--

Is it as intended?
And, if not, how could it be changed without my "help"?

While you're waiting for feedback from others, I ran mine for
comparison. For both /media/$USER and /media/$USER/$LABEL, I get:

drwxr-x---+ root root

That's on a super basic debootstrap'ed in Sid Unstable setup where
I've never altered permissions going that route.

Your one there is obviously missing that one execute permission that
I'm *a-suming* is helping cause the problem. That's as much as I can
gather from it. Pretty much about all my memory has ever retained
about permissions is don't give out any more access permissions than
is absolutely necessary to perform ordinary, daily computing. It's
safer for your system that way. :)

Good luck solving your issue.

Cindy :)

Re: Automounted with udisks volumes could not be opend in Nautilus normal user (uid=1000)

[Michael Biebl]

Am 08.07.2016 um 17:32 schrieb Evgenii Frolov:
> Dear Michael,
> 
> /media/$USER is root:root drwxr-x---
> 
> and /media/$USER/$LABEL is $USER:$USER drwx--
> 
> Is it as intended?

No, /media/$USER hould be owned by $USER

> And, if not, how could it be changed without my "help"?

chown $USER:$USER /media/$USER should fix it.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Automounted with udisks volumes could not be opend in Nautilus normal user (uid=1000)

[David Wright]

On Fri 08 Jul 2016 at 12:01:13 (-0400), Cindy-Sue Causey wrote:
> On 7/8/16, Evgenii Frolov  wrote:
> > Dear Michael,
> >
> > /media/$USER is root:root drwxr-x---
> >
> > and /media/$USER/$LABEL is $USER:$USER drwx--
> >
> > Is it as intended?
> > And, if not, how could it be changed without my "help"?
> 
> While you're waiting for feedback from others, I ran mine for
> comparison. For both /media/$USER and /media/$USER/$LABEL, I get:
> 
> drwxr-x---+ root root

^ I spy a plus sign here. Perhaps ACL involvement.

> That's on a super basic debootstrap'ed in Sid Unstable setup where
> I've never altered permissions going that route.
> 
> Your one there is obviously missing that one execute permission that
> I'm *a-suming* is helping cause the problem. That's as much as I can
> gather from it. Pretty much about all my memory has ever retained
> about permissions is don't give out any more access permissions than
> is absolutely necessary to perform ordinary, daily computing. It's
> safer for your system that way. :)

Cheers,
David.

Docker in Debian Jessie

[Daniel Bareiro]

Hi all!

I am trying to install Docker Engine 1.11 on Debian GNU/Linux Jessie
(8.5). From what I read in the documentation [1], Debian Jessie is a
supported distribution. However, I am having some problems installing:

--
# aptitude install docker-engine
The following NEW packages will be installed:
  aufs-tools{a} cgroupfs-mount{a} docker-engine libnih-dbus1{a}
libnih1{a} mountall{a} plymouth{a}
0 packages upgraded, 7 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/14.8 MB of archives. After unpacking 74.1 MB will be used.
Do you want to continue? [Y/n/?] Y
Selecting previously unselected package plymouth.
(Reading database ... 177196 files and directories currently installed.)
Preparing to unpack .../plymouth_0.9.0-9_amd64.deb ...
Unpacking plymouth (0.9.0-9) ...
Selecting previously unselected package libnih1.
Preparing to unpack .../libnih1_1.0.3-4.3_amd64.deb ...
Unpacking libnih1 (1.0.3-4.3) ...
Selecting previously unselected package libnih-dbus1.
Preparing to unpack .../libnih-dbus1_1.0.3-4.3_amd64.deb ...
Unpacking libnih-dbus1 (1.0.3-4.3) ...
Selecting previously unselected package mountall.
Preparing to unpack .../mountall_2.54_amd64.deb ...
Unpacking mountall (2.54) ...
Selecting previously unselected package aufs-tools.
Preparing to unpack .../aufs-tools_1%3a3.2+20130722-1.1_amd64.deb ...
Unpacking aufs-tools (1:3.2+20130722-1.1) ...
Selecting previously unselected package cgroupfs-mount.
Preparing to unpack .../cgroupfs-mount_1.1_all.deb ...
Unpacking cgroupfs-mount (1.1) ...
Selecting previously unselected package docker-engine.
Preparing to unpack .../docker-engine_1.11.2-0~jessie_amd64.deb ...
Unpacking docker-engine (1.11.2-0~jessie) ...
Processing triggers for man-db (2.7.0.2-5) ...
Processing triggers for systemd (215-17+deb8u4) ...
Processing triggers for dbus (1.8.20-0+deb8u1) ...
Setting up plymouth (0.9.0-9) ...
update-initramfs: deferring update (trigger activated)
update-rc.d: warning: start and stop actions are no longer supported;
falling back to defaults
update-rc.d: warning: start and stop actions are no longer supported;
falling back to defaults
Setting up libnih1 (1.0.3-4.3) ...
Setting up libnih-dbus1 (1.0.3-4.3) ...
Setting up mountall (2.54) ...
Setting up aufs-tools (1:3.2+20130722-1.1) ...
Setting up cgroupfs-mount (1.1) ...
Setting up docker-engine (1.11.2-0~jessie) ...
Job for docker.service failed. See 'systemctl status docker.service' and
'journalctl -xn' for details.
invoke-rc.d: initscript docker, action "start" failed.
dpkg: error processing package docker-engine (--configure):
 subprocess installed post-installation script returned error exit status 1
Processing triggers for initramfs-tools (0.120+deb8u2) ...
update-initramfs: Generating /boot/initrd.img-3.16.0-4-amd64
Processing triggers for libc-bin (2.19-18+deb8u4) ...
Processing triggers for systemd (215-17+deb8u4) ...
Errors were encountered while processing:
 docker-engine
E: Sub-process /usr/bin/dpkg returned an error code (1)
Failed to perform requested operation on package.  Trying to recover:
Setting up docker-engine (1.11.2-0~jessie) ...
Job for docker.service failed. See 'systemctl status docker.service' and
'journalctl -xn' for details.
invoke-rc.d: initscript docker, action "start" failed.
dpkg: error processing package docker-engine (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 docker-engine
--

Checking the syslog, I think this is because the version of Debian
Jessie for Systemd does not support the "Delegate" option used in the
Unit that brings the package.

--
Jul  8 13:33:08 orion systemd[1]:
[/lib/systemd/system/docker.service:19] Unknown lvalue 'Delegate' in
section 'Service'
Jul  8 13:33:08 orion systemd[1]:
[/lib/systemd/system/docker.service:19] Unknown lvalue 'Delegate' in
section 'Service'
Jul  8 13:33:08 orion docker[20716]:
time="2016-07-08T13:33:08.607373846-03:00" level=info msg="New
containerd process, pid: 20721\n"
Jul  8 13:33:09 orion docker[20716]:
time="2016-07-08T13:33:09.614783897-03:00" level=info msg="[graphdriver]
using prior storage driver \"aufs\""
Jul  8 13:33:09 orion docker[20716]:
time="2016-07-08T13:33:09.654605062-03:00" level=info msg="Graph
migration to content-addressability took 0.00 seconds"
Jul  8 13:33:09 orion docker[20716]:
time="2016-07-08T13:33:09.663921318-03:00" level=info msg="Firewalld
running: false"
Jul  8 13:33:09 orion docker[20716]:
time="2016-07-08T13:33:09.755517105-03:00" level=fatal msg="Error
starting daemon: Error initializing network controller: Error creating
default \"bridge\" network: failed to parse pool request for address
space \"LocalDefault\" pool \"\" subpool \"\": could not find an
available predefined network"
Jul  8 13:33:

Re: Docker in Debian Jessie

[Daniel Bareiro]

On 08/07/16 14:45, Daniel Bareiro wrote:

> Hi all!
> 
> I am trying to install Docker Engine 1.11 on Debian GNU/Linux Jessie
> (8.5). From what I read in the documentation [1], Debian Jessie is a
> supported distribution. However, I am having some problems installing:
> 
> (...)

Sorry. I forgot to put the link of the documentation.

[1] https://docs.docker.com/v1.11/engine/installation/linux/debian/


Kind regards,
Daniel



signature.asc
Description: OpenPGP digital signature

KRDC interprets Period as Delete

[Kent West]

Debian unstable
kernel = 4.6.0-1-amd64 #1 SMP Debian 4.6.2-1 (2016-06-15) x86_64 GNU/Linux
KDE Frameworks 5.23.0
QT 5.6.1

Whenever I use KRDC to remote to a Macintosh (El Capitan), and open a
Terminal window on the Mac, and edit a file with nano, a press of the
period key on my local keyboard results in a deletion (not backspace) of
the current character.

nano directly at the El Capitan Mac does not do this.
This problem does not seem to exhibit on other Mac apps, not even at the
command line in Terminal, but only in nano in the Terminal.

I don't know if this is a bug in nano, in Terminal, in El Capitan, in KDRC,
in Debian 

Not sure where to go from here, and may just have to settle for
work-arounds, but if anyone has any suggestions, I'm open to hearing them.

Thanks!


-- 
Kent West<")))><
Westing Peacefully - http://kentwest.blogspot.com

Re: reasons to ditch LILO before upgrading to jessie?

[Brian]

On Thu 07 Jul 2016 at 23:34:11 -0400, Gary Dale wrote:

> On 07/07/16 05:12 PM, Brian wrote:
> >On Thu 07 Jul 2016 at 15:18:05 -0400, Gary Dale wrote:
> >
> >>On 07/07/16 02:55 PM, David Wright wrote:
> >>>On Thu 07 Jul 2016 at 14:39:51 (-0400), Gary Dale wrote:
> The big selling feature of Grub over Lilo was that it didn't need to
> updated each time you changed something. That fell by the wayside
> with Grub 2. Now the big selling feature is that it works with more
> than just Linux.
> >>>I guess I don't know what you mean by "update".
> >>>If I change the contents of grub.cfg, the effect is immediate:
> >>>the changes will be seen at the next boot. I don't do anything more.
> >>However the second line of grub.cfg says "DO NOT EDIT THIS FILE". If you do
> >>edit it, the changes will be overwritten the next time a debian upgrade
> >>automatically regenerates it. The only method for preserving your changes is
> >>to update the grub templates then run update-grub.
> >No it's not. dpkg-divert. That's sufficient to search the list archives
> >for something which has been mentioned a few times but has passed you by.
> 
> A lot of trouble for something that can be avoided if you just edit the
> correct files in the first place.

Let's see. You write your own grub.cfg or edit the existing one. You
want to preserve your file from being changed so you use a *one line
command* to ensure that. But this one line command is a lot of trouble.
A one line command is onerous?

It is much easier to edit the unspecified "correct files" to stop any
changes to grub.cfg at a Debian upgrade which attempts to regenerate
it? One lives and learns.

Re: Docker in Debian Jessie

[Gilles Mocellin]

Le 08/07/2016 à 19:48, Daniel Bareiro a écrit :

On 08/07/16 14:45, Daniel Bareiro wrote:


Hi all!

I am trying to install Docker Engine 1.11 on Debian GNU/Linux Jessie
(8.5). From what I read in the documentation [1], Debian Jessie is a
supported distribution. However, I am having some problems installing:

(...)

Hello,

Docker tries to use aufs as storage (for /var/lib/docker).
aufs is not in the Debian kernel.

The easiest way I find was to configure Docker to use overalyfs instead.

Here comes the second problem : systemd.

With sysvinit, you simply hav to put a launch option in 
/etc/default/docker :

DOCKER_OPTS="-s overlay"

With systemd, you have to overrid the service configuration, and if you 
want to use /etc/default/docker, here's how to do it :


Create /etc/systemd/system/docker.service.d/overlayfs.conf with that 
content :

[Service]
EnvironmentFile=-/etc/default/docker
ExecStart=
ExecStart=/usr/bin/docker daemon -H fd:// $DOCKER_OPTS

Re: Docker in Debian Jessie

[Daniel Bareiro]

On 08/07/16 15:15, Gilles Mocellin wrote:

>>> I am trying to install Docker Engine 1.11 on Debian GNU/Linux Jessie
>>> (8.5). From what I read in the documentation [1], Debian Jessie is a
>>> supported distribution. However, I am having some problems installing:
>>>
>>> (...)

> Hello,

Hello, Gilles. Thanks for your reply.

> Docker tries to use aufs as storage (for /var/lib/docker).
> aufs is not in the Debian kernel.
> 
> The easiest way I find was to configure Docker to use overalyfs instead.
> 
> Here comes the second problem : systemd.
> 
> With sysvinit, you simply hav to put a launch option in
> /etc/default/docker :
> DOCKER_OPTS="-s overlay"
> 
> With systemd, you have to overrid the service configuration, and if you
> want to use /etc/default/docker, here's how to do it :
> 
> Create /etc/systemd/system/docker.service.d/overlayfs.conf with that
> content :
> [Service]
> EnvironmentFile=-/etc/default/docker
> ExecStart=
> ExecStart=/usr/bin/docker daemon -H fd:// $DOCKER_OPTS

I tried to add DOCKER_OPTS in /etc/default/docker. Then I changed the
Init file based on your suggestion:

---
# cat /etc/default/docker | grep DOCKER_OPTS
# Use DOCKER_OPTS to modify the daemon startup options.
#DOCKER_OPTS="--dns 8.8.8.8 --dns 8.8.4.4"
DOCKER_OPTS="-s overlay"
---
# cat /lib/systemd/system/docker.service
[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network.target docker.socket
Requires=docker.socket

[Service]
Type=notify
# the default is not to use systemd for cgroups because the delegate
issues still
# exists and systemd currently does not support the cgroup feature set
required
# for containers run by docker

 DGB - 20160708 
EnvironmentFile=-/etc/default/docker
#ExecStart=/usr/bin/docker daemon -H fd://
ExecStart=/usr/bin/docker daemon -H fd:// $DOCKER_OPTS
 DGB - 20160708 

MountFlags=slave
LimitNOFILE=1048576
LimitNPROC=1048576
LimitCORE=infinity
TimeoutStartSec=0
# set delegate yes so that systemd does not reset the cgroups of docker
containers
Delegate=yes

[Install]
WantedBy=multi-user.target
---

But it seems that the file system is not recognized:

---
Jul  8 15:41:12 orion docker[4838]:
time="2016-07-08T15:41:12.933967003-03:00" level=info msg="New
containerd process, pid: 4844\n"
Jul  8 15:41:13 orion docker[4838]:
time="2016-07-08T15:41:13.938943525-03:00" level=error msg="'overlay'
not found as a supported filesystem on this host. Please ensure kernel
is new enough and has overlay support loaded."
Jul  8 15:41:13 orion docker[4838]:
time="2016-07-08T15:41:13.939091971-03:00" level=fatal msg="Error
starting daemon: error initializing graphdriver: driver not supported"
Jul  8 15:41:13 orion systemd[1]: docker.service: main process exited,
code=exited, status=1/FAILURE
Jul  8 15:41:13 orion docker[4838]: time="2016-07-08T15:41:13-03:00"
level=info msg="stopping containerd after receiving terminated"
Jul  8 15:41:13 orion systemd[1]: Failed to start Docker Application
Container Engine.
Jul  8 15:41:13 orion systemd[1]: Unit docker.service entered failed state.
---

Kind regards,
Daniel



signature.asc
Description: OpenPGP digital signature

Re: KRDC interprets Period as Delete

[Kent West]

On Fri, Jul 8, 2016 at 1:01 PM, Kent West  wrote:

> Debian unstable
> kernel = 4.6.0-1-amd64 #1 SMP Debian 4.6.2-1 (2016-06-15) x86_64 GNU/Linux
> KDE Frameworks 5.23.0
> QT 5.6.1
>
> Whenever I use KRDC to remote to a Macintosh (El Capitan), and open a
> Terminal window on the Mac, and edit a file with nano, a press of the
> period key on my local keyboard results in a deletion (not backspace) of
> the current character.
>
> nano directly at the El Capitan Mac does not do this.
> This problem does not seem to exhibit on other Mac apps, not even at the
> command line in Terminal, but only in nano in the Terminal.
>
> I don't know if this is a bug in nano, in Terminal, in El Capitan, in
> KDRC, in Debian 
>
> Not sure where to go from here, and may just have to settle for
> work-arounds, but if anyone has any suggestions, I'm open to hearing them.
>
> Thanks!
>
>
I just realized that the numeric keypad on my Debian box has a period and a
delete function on the same key. Apparently nano/Terminal/El Capitan/KRDC
is confusing my two period keys as that delete key, maybe?


-- 
Kent West<")))><
Westing Peacefully - http://kentwest.blogspot.com

Re: Docker in Debian Jessie

[Daniel Bareiro]

Hello, Gilles.

>> Docker tries to use aufs as storage (for /var/lib/docker).
>> aufs is not in the Debian kernel.
>>
>> The easiest way I find was to configure Docker to use overalyfs instead.
>>
>> Here comes the second problem : systemd.
>>
>> With sysvinit, you simply hav to put a launch option in
>> /etc/default/docker :
>> DOCKER_OPTS="-s overlay"
>>
>> With systemd, you have to overrid the service configuration, and if you
>> want to use /etc/default/docker, here's how to do it :
>>
>> Create /etc/systemd/system/docker.service.d/overlayfs.conf with that
>> content :
>> [Service]
>> EnvironmentFile=-/etc/default/docker
>> ExecStart=
>> ExecStart=/usr/bin/docker daemon -H fd:// $DOCKER_OPTS

> I tried to add DOCKER_OPTS in /etc/default/docker. Then I changed the
> Init file based on your suggestion:
> 
> ---
> # cat /etc/default/docker | grep DOCKER_OPTS
> # Use DOCKER_OPTS to modify the daemon startup options.
> #DOCKER_OPTS="--dns 8.8.8.8 --dns 8.8.4.4"
> DOCKER_OPTS="-s overlay"
> ---
> # cat /lib/systemd/system/docker.service
> [Unit]
> Description=Docker Application Container Engine
> Documentation=https://docs.docker.com
> After=network.target docker.socket
> Requires=docker.socket
> 
> [Service]
> Type=notify
> # the default is not to use systemd for cgroups because the delegate
> issues still
> # exists and systemd currently does not support the cgroup feature set
> required
> # for containers run by docker
> 
>  DGB - 20160708 
> EnvironmentFile=-/etc/default/docker
> #ExecStart=/usr/bin/docker daemon -H fd://
> ExecStart=/usr/bin/docker daemon -H fd:// $DOCKER_OPTS
>  DGB - 20160708 
> 
> MountFlags=slave
> LimitNOFILE=1048576
> LimitNPROC=1048576
> LimitCORE=infinity
> TimeoutStartSec=0
> # set delegate yes so that systemd does not reset the cgroups of docker
> containers
> Delegate=yes
> 
> [Install]
> WantedBy=multi-user.target
> ---
> 
> But it seems that the file system is not recognized:
> 
> ---
> Jul  8 15:41:12 orion docker[4838]:
> time="2016-07-08T15:41:12.933967003-03:00" level=info msg="New
> containerd process, pid: 4844\n"
> Jul  8 15:41:13 orion docker[4838]:
> time="2016-07-08T15:41:13.938943525-03:00" level=error msg="'overlay'
> not found as a supported filesystem on this host. Please ensure kernel
> is new enough and has overlay support loaded."
> Jul  8 15:41:13 orion docker[4838]:
> time="2016-07-08T15:41:13.939091971-03:00" level=fatal msg="Error
> starting daemon: error initializing graphdriver: driver not supported"
> Jul  8 15:41:13 orion systemd[1]: docker.service: main process exited,
> code=exited, status=1/FAILURE
> Jul  8 15:41:13 orion docker[4838]: time="2016-07-08T15:41:13-03:00"
> level=info msg="stopping containerd after receiving terminated"
> Jul  8 15:41:13 orion systemd[1]: Failed to start Docker Application
> Container Engine.
> Jul  8 15:41:13 orion systemd[1]: Unit docker.service entered failed state.
> ---

From what I've read here [1], it seems that this filesystem was
introduced with Linux 3.18. And I'm using here 3.16:

# uname -a
Linux orion 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08)
x86_64 GNU/Linux

Are you using the kernel of Backports?


Kind regards,
Daniel

[1] https://docs.docker.com/engine/userguide/storagedriver/overlayfs-driver/



signature.asc
Description: OpenPGP digital signature

Re: reasons to ditch LILO before upgrading to jessie?

[Gary Dale]

On 08/07/16 02:19 PM, Brian wrote:

On Thu 07 Jul 2016 at 23:34:11 -0400, Gary Dale wrote:


On 07/07/16 05:12 PM, Brian wrote:

On Thu 07 Jul 2016 at 15:18:05 -0400, Gary Dale wrote:


On 07/07/16 02:55 PM, David Wright wrote:

On Thu 07 Jul 2016 at 14:39:51 (-0400), Gary Dale wrote:

The big selling feature of Grub over Lilo was that it didn't need to
updated each time you changed something. That fell by the wayside
with Grub 2. Now the big selling feature is that it works with more
than just Linux.

I guess I don't know what you mean by "update".
If I change the contents of grub.cfg, the effect is immediate:
the changes will be seen at the next boot. I don't do anything more.

However the second line of grub.cfg says "DO NOT EDIT THIS FILE". If you do
edit it, the changes will be overwritten the next time a debian upgrade
automatically regenerates it. The only method for preserving your changes is
to update the grub templates then run update-grub.

No it's not. dpkg-divert. That's sufficient to search the list archives
for something which has been mentioned a few times but has passed you by.

A lot of trouble for something that can be avoided if you just edit the
correct files in the first place.

Let's see. You write your own grub.cfg or edit the existing one. You
want to preserve your file from being changed so you use a *one line
command* to ensure that. But this one line command is a lot of trouble.
A one line command is onerous?

It is much easier to edit the unspecified "correct files" to stop any
changes to grub.cfg at a Debian upgrade which attempts to regenerate
it? One lives and learns.

Let's see then. You can edit a grub template file or grub.cfg. You make 
the same change either way but the grub template file won't get 
clobbered so there is no need to run dpkg-divert.


Moreover, you don't need to update a system manual to note that you are 
diverting a package. You just need to note that a single file is not the 
package maintainers default - something you have to do either way.

Re: KRDC interprets Period as Delete

[Kent West]

On Fri, Jul 8, 2016 at 2:06 PM, Kent West  wrote:

> On Fri, Jul 8, 2016 at 1:01 PM, Kent West  wrote:
>
>>
>>
>> Whenever I use KRDC to remote to a Macintosh (El Capitan), and open a
>> Terminal window on the Mac, and edit a file with nano, a press of the
>> period key on my local keyboard results in a deletion (not backspace) of
>> the current character.
>>
>
> I just realized that the numeric keypad on my Debian box has a period and
> a delete function on the same key. Apparently nano/Terminal/El Capitan/KRDC
> is confusing my two period keys as that delete key, maybe?
>
>
I could find no combination (using Shift, or Ctrl, or NumLock, or
ScrollLock, etc) that would turn either key into a period key.



-- 
Kent West<")))><
Westing Peacefully - http://kentwest.blogspot.com

Re: reasons to ditch LILO before upgrading to jessie?

[David Wright]

On Fri 08 Jul 2016 at 19:19:00 (+0100), Brian wrote:
> On Thu 07 Jul 2016 at 23:34:11 -0400, Gary Dale wrote:
> > On 07/07/16 05:12 PM, Brian wrote:
> > >On Thu 07 Jul 2016 at 15:18:05 -0400, Gary Dale wrote:
> > >>On 07/07/16 02:55 PM, David Wright wrote:
> > >>>On Thu 07 Jul 2016 at 14:39:51 (-0400), Gary Dale wrote:
> > The big selling feature of Grub over Lilo was that it didn't need to
> > updated each time you changed something. That fell by the wayside
> > with Grub 2. Now the big selling feature is that it works with more
> > than just Linux.
> > >>>I guess I don't know what you mean by "update".
> > >>>If I change the contents of grub.cfg, the effect is immediate:
> > >>>the changes will be seen at the next boot. I don't do anything more.
> > >>However the second line of grub.cfg says "DO NOT EDIT THIS FILE". If you 
> > >>do
> > >>edit it, the changes will be overwritten the next time a debian upgrade
> > >>automatically regenerates it. The only method for preserving your changes 
> > >>is
> > >>to update the grub templates then run update-grub.
> > >No it's not. dpkg-divert. That's sufficient to search the list archives
> > >for something which has been mentioned a few times but has passed you by.
> > 
> > A lot of trouble for something that can be avoided if you just edit the
> > correct files in the first place.
> 
> Let's see. You write your own grub.cfg or edit the existing one. You
> want to preserve your file from being changed so you use a *one line
> command* to ensure that. But this one line command is a lot of trouble.
> A one line command is onerous?
> 
> It is much easier to edit the unspecified "correct files" to stop any
> changes to grub.cfg at a Debian upgrade which attempts to regenerate
> it? One lives and learns.

I *think* I've worked out what this rant is all about: the replacement
of /boot/grub/menu.lst in old Grub by /boot/grub/grub.cfg in Grub2.
So under the old system, you generated or wrote menu.lst and then you
could edit it to your heart's content. Under the new system, grub.cfg
is always (re)built from a set of scripts and some preference data in
/etc/default/grub, unless you've protected it with your one-line
command. In case of the latter, it behaves just like menu.lst did:
if you edit it, the effect is immediate (and unlike lilo).

Somebody else then chimed in about how the partition numbering scheme
has been screwed (more like corrected IMHO) which meant people were
scratching their heads over "Is it (hd1,0) or (hd0,1)" when the world
has moved on to using UUID/LABELs instead if worrying about whether
the kernel happened to discover their disks in the right order.

Cheers,
David.

debian wifi install

[Jude DaShiell]

Install was successful this time since I now have rt2870.bin available for 
debian to install and use.  Unfortunately, the installer did not save the 
network configuration it figured out and used to my new system.  Has 
anyone got a good url describing what to do with iwconfig and other 
utilities to get a ralink 2870 adapter running post-install?




--

Re: reasons to ditch LILO before upgrading to jessie?

[Brian]

On Fri 08 Jul 2016 at 15:08:21 -0400, Gary Dale wrote:

> On 08/07/16 02:19 PM, Brian wrote:
> >On Thu 07 Jul 2016 at 23:34:11 -0400, Gary Dale wrote:
> >
> >>On 07/07/16 05:12 PM, Brian wrote:
> >>>On Thu 07 Jul 2016 at 15:18:05 -0400, Gary Dale wrote:
> >>>
> On 07/07/16 02:55 PM, David Wright wrote:
> >On Thu 07 Jul 2016 at 14:39:51 (-0400), Gary Dale wrote:
> >>The big selling feature of Grub over Lilo was that it didn't need to
> >>updated each time you changed something. That fell by the wayside
> >>with Grub 2. Now the big selling feature is that it works with more
> >>than just Linux.
> >I guess I don't know what you mean by "update".
> >If I change the contents of grub.cfg, the effect is immediate:
> >the changes will be seen at the next boot. I don't do anything more.
> However the second line of grub.cfg says "DO NOT EDIT THIS FILE". If you 
> do
> edit it, the changes will be overwritten the next time a debian upgrade
> automatically regenerates it. The only method for preserving your changes 
> is
> to update the grub templates then run update-grub.
> >>>No it's not. dpkg-divert. That's sufficient to search the list archives
> >>>for something which has been mentioned a few times but has passed you by.
> >>A lot of trouble for something that can be avoided if you just edit the
> >>correct files in the first place.
> >Let's see. You write your own grub.cfg or edit the existing one. You
> >want to preserve your file from being changed so you use a *one line
> >command* to ensure that. But this one line command is a lot of trouble.
> >A one line command is onerous?
> >
> >It is much easier to edit the unspecified "correct files" to stop any
> >changes to grub.cfg at a Debian upgrade which attempts to regenerate
> >it? One lives and learns.
> >
> Let's see then. You can edit a grub template file or grub.cfg. You make the

No. You edit or devise a grub,cfg. GRUB template files are not involved.
They are irrelevant. You can ignore them because you are doing you own
thing. You have decided what *you* want, not what /etc/grub.d wants to
give you.

If you have some way of easily adjusting files in /etc/grub.d to the
needs of a user I wish you would say.

> same change either way but the grub template file won't get clobbered so
> there is no need to run dpkg-divert.

It's not the same change. ("grub template file". What is that? There
isn't one as far as I can see).

> Moreover, you don't need to update a system manual to note that you are
> diverting a package. You just need to note that a single file is not the
> package maintainers default - something you have to do either way.

Diverting is a Debian thing. The GRUB manual would never mention it.

Re: reasons to ditch LILO before upgrading to jessie?

[Brian]

On Fri 08 Jul 2016 at 14:23:01 -0500, David Wright wrote:

> On Fri 08 Jul 2016 at 19:19:00 (+0100), Brian wrote:
> > On Thu 07 Jul 2016 at 23:34:11 -0400, Gary Dale wrote:
> > > On 07/07/16 05:12 PM, Brian wrote:
> > > >On Thu 07 Jul 2016 at 15:18:05 -0400, Gary Dale wrote:
> > > >>On 07/07/16 02:55 PM, David Wright wrote:
> > > >>>On Thu 07 Jul 2016 at 14:39:51 (-0400), Gary Dale wrote:
> > > The big selling feature of Grub over Lilo was that it didn't need to
> > > updated each time you changed something. That fell by the wayside
> > > with Grub 2. Now the big selling feature is that it works with more
> > > than just Linux.
> > > >>>I guess I don't know what you mean by "update".
> > > >>>If I change the contents of grub.cfg, the effect is immediate:
> > > >>>the changes will be seen at the next boot. I don't do anything more.
> > > >>However the second line of grub.cfg says "DO NOT EDIT THIS FILE". If 
> > > >>you do
> > > >>edit it, the changes will be overwritten the next time a debian upgrade
> > > >>automatically regenerates it. The only method for preserving your 
> > > >>changes is
> > > >>to update the grub templates then run update-grub.
> > > >No it's not. dpkg-divert. That's sufficient to search the list archives
> > > >for something which has been mentioned a few times but has passed you by.
> > > 
> > > A lot of trouble for something that can be avoided if you just edit the
> > > correct files in the first place.
> > 
> > Let's see. You write your own grub.cfg or edit the existing one. You
> > want to preserve your file from being changed so you use a *one line
> > command* to ensure that. But this one line command is a lot of trouble.
> > A one line command is onerous?
> > 
> > It is much easier to edit the unspecified "correct files" to stop any
> > changes to grub.cfg at a Debian upgrade which attempts to regenerate
> > it? One lives and learns.
> 
> I *think* I've worked out what this rant is all about: the replacement
> of /boot/grub/menu.lst in old Grub by /boot/grub/grub.cfg in Grub2.

Was that a rant? If so, It has nothing whatsoever to do with GRUB
legacy.

If you want GRUB to do what you want you write your own grub,cfg.

Stop moaning. Do it or file file a bug, Then stop moaning and do it.

Re: reasons to ditch LILO before upgrading to jessie?

[David Wright]

On Fri 08 Jul 2016 at 21:16:00 (+0100), Brian wrote:
> On Fri 08 Jul 2016 at 14:23:01 -0500, David Wright wrote:
> > On Fri 08 Jul 2016 at 19:19:00 (+0100), Brian wrote:
> > > On Thu 07 Jul 2016 at 23:34:11 -0400, Gary Dale wrote:
> > > > On 07/07/16 05:12 PM, Brian wrote:
> > > > >On Thu 07 Jul 2016 at 15:18:05 -0400, Gary Dale wrote:
> > > > >>On 07/07/16 02:55 PM, David Wright wrote:
> > > > >>>On Thu 07 Jul 2016 at 14:39:51 (-0400), Gary Dale wrote:
> > > > The big selling feature of Grub over Lilo was that it didn't need to
> > > > updated each time you changed something. That fell by the wayside
> > > > with Grub 2. Now the big selling feature is that it works with more
> > > > than just Linux.
> > > > >>>I guess I don't know what you mean by "update".
> > > > >>>If I change the contents of grub.cfg, the effect is immediate:
> > > > >>>the changes will be seen at the next boot. I don't do anything more.
> > > > >>However the second line of grub.cfg says "DO NOT EDIT THIS FILE". If 
> > > > >>you do
> > > > >>edit it, the changes will be overwritten the next time a debian 
> > > > >>upgrade
> > > > >>automatically regenerates it. The only method for preserving your 
> > > > >>changes is
> > > > >>to update the grub templates then run update-grub.
> > > > >No it's not. dpkg-divert. That's sufficient to search the list archives
> > > > >for something which has been mentioned a few times but has passed you 
> > > > >by.
> > > > 
> > > > A lot of trouble for something that can be avoided if you just edit the
> > > > correct files in the first place.
> > > 
> > > Let's see. You write your own grub.cfg or edit the existing one. You
> > > want to preserve your file from being changed so you use a *one line
> > > command* to ensure that. But this one line command is a lot of trouble.
> > > A one line command is onerous?
> > > 
> > > It is much easier to edit the unspecified "correct files" to stop any
> > > changes to grub.cfg at a Debian upgrade which attempts to regenerate
> > > it? One lives and learns.
> > 
> > I *think* I've worked out what this rant is all about: the replacement
> > of /boot/grub/menu.lst in old Grub by /boot/grub/grub.cfg in Grub2.
> 
> Was that a rant? If so, It has nothing whatsoever to do with GRUB
> legacy.

I was referring to the threads which started Thu, 7 Jul 2016 14:39:51 -0400
as quoted above. In them, I have argued against the view that something
"fell by the wayside" in Grub2 wrt the legacy version. Sorry if you
thought that I was accusing yourself of ranting.

> If you want GRUB to do what you want you write your own grub,cfg.

I do; unconventionally, but it suits me.

> Stop moaning. Do it or file file a bug, Then stop moaning and do it.

I'm the person without a complaint about Grub2, not the one moaning.

Cheers,
David.

Re: reasons to ditch LILO before upgrading to jessie?

[Gary Dale]

On 08/07/16 03:51 PM, Brian wrote:

On Fri 08 Jul 2016 at 15:08:21 -0400, Gary Dale wrote:


On 08/07/16 02:19 PM, Brian wrote:

On Thu 07 Jul 2016 at 23:34:11 -0400, Gary Dale wrote:


On 07/07/16 05:12 PM, Brian wrote:

On Thu 07 Jul 2016 at 15:18:05 -0400, Gary Dale wrote:


On 07/07/16 02:55 PM, David Wright wrote:

On Thu 07 Jul 2016 at 14:39:51 (-0400), Gary Dale wrote:

The big selling feature of Grub over Lilo was that it didn't need to
updated each time you changed something. That fell by the wayside
with Grub 2. Now the big selling feature is that it works with more
than just Linux.

I guess I don't know what you mean by "update".
If I change the contents of grub.cfg, the effect is immediate:
the changes will be seen at the next boot. I don't do anything more.

However the second line of grub.cfg says "DO NOT EDIT THIS FILE". If you do
edit it, the changes will be overwritten the next time a debian upgrade
automatically regenerates it. The only method for preserving your changes is
to update the grub templates then run update-grub.

No it's not. dpkg-divert. That's sufficient to search the list archives
for something which has been mentioned a few times but has passed you by.

A lot of trouble for something that can be avoided if you just edit the
correct files in the first place.

Let's see. You write your own grub.cfg or edit the existing one. You
want to preserve your file from being changed so you use a *one line
command* to ensure that. But this one line command is a lot of trouble.
A one line command is onerous?

It is much easier to edit the unspecified "correct files" to stop any
changes to grub.cfg at a Debian upgrade which attempts to regenerate
it? One lives and learns.


Let's see then. You can edit a grub template file or grub.cfg. You make the

No. You edit or devise a grub,cfg. GRUB template files are not involved.
They are irrelevant. You can ignore them because you are doing you own
thing. You have decided what *you* want, not what /etc/grub.d wants to
give you.

If you have some way of easily adjusting files in /etc/grub.d to the
needs of a user I wish you would say.
So that's the problem. You never took the time to RTFM. See 
https://help.ubuntu.com/community/Grub2/Setup#File_Structure



same change either way but the grub template file won't get clobbered so
there is no need to run dpkg-divert.

It's not the same change. ("grub template file". What is that? There
isn't one as far as I can see).
Again, RTFM. There are lots of files for you to tinker with in 
/etc/grub.d. You can even add your own and it's guaranteed not be 
tampered with by any updates.





Moreover, you don't need to update a system manual to note that you are
diverting a package. You just need to note that a single file is not the
package maintainers default - something you have to do either way.

Diverting is a Debian thing. The GRUB manual would never mention it.

No, but you do have to document each system that you are running. If you 
are doing anything that is not standard, it has to be recorded so that 
the next person (or you 3 months later) will know that you've done it.


I gather from your comment that you aren't doing this. That's asking for 
trouble, especially if you are running custom configurations and 
protecting them with diversions. Complexity added onto complexity 
without documentation is a good recipe for disaster.

Re: reasons to ditch LILO before upgrading to jessie?

[Brian]

On Fri 08 Jul 2016 at 16:57:30 -0500, David Wright wrote:

> On Fri 08 Jul 2016 at 21:16:00 (+0100), Brian wrote:
> 
> > Stop moaning. Do it or file file a bug, Then stop moaning and do it.
> 
> I'm the person without a complaint about Grub2, not the one moaning.

Apologies. I was intending to talk in general but it looks as though
my remark was directed solely at you. That wasn't my intent but I can
see how it looks that way.

Time to avoid controversy and try to stick to technical points. :)

Re: reasons to ditch LILO before upgrading to jessie?

[Brian]

On Fri 08 Jul 2016 at 18:13:01 -0400, Gary Dale wrote:

> >>On 08/07/16 02:19 PM, Brian wrote:
> >
> >If you have some way of easily adjusting files in /etc/grub.d to the
> >needs of a user I wish you would say.
> So that's the problem. You never took the time to RTFM. See
> https://help.ubuntu.com/community/Grub2/Setup#File_Structure

That page, no matter how informative it may be, is not the manual. My
comment was intended to elicit some specific technical advice on how to
adjust an /etc/grub.d file(s) to perform a particular task. Something
like the topic in

  https://lists.debian.org/debian-user/2016/07/msg00278.html

Using labels in a hand written grub.cfg is a snap. Stopping it being
overwritten is another snap. Perhaps altering file X in grub.d is just
as easy and unstressful.

Maybe one day I will read 'pinfo grub'. :)

> >>same change either way but the grub template file won't get clobbered so
> >>there is no need to run dpkg-divert.
> >It's not the same change. ("grub template file". What is that? There
> >isn't one as far as I can see).
> Again, RTFM. There are lots of files for you to tinker with in /etc/grub.d.
> You can even add your own and it's guaranteed not be tampered with by any
> updates.

So there are. Users should stay away from them (40_custom excepted)
unless they know what they are doing.

> >>Moreover, you don't need to update a system manual to note that you are
> >>diverting a package. You just need to note that a single file is not the
> >>package maintainers default - something you have to do either way.
> >Diverting is a Debian thing. The GRUB manual would never mention it.
> >
> No, but you do have to document each system that you are running. If you are
> doing anything that is not standard, it has to be recorded so that the next
> person (or you 3 months later) will know that you've done it.
> 
> I gather from your comment that you aren't doing this. That's asking for
> trouble, especially if you are running custom configurations and protecting
> them with diversions. Complexity added onto complexity without documentation
> is a good recipe for disaster.

I cannot argue with that.

Re: Debian support for samsung chromebook

[Byung-Hee HWANG (황병희)]

On 2016년 7월 7일 오전 11시 46분 11초 GMT+09:00, Jacob Adams  wrote:
>(Please CC me as I am not subscribed)
>
>I have an old samsung arm chromebook that I would like to try and
>install Debian on. The wiki has a page on it
>(https://wiki.debian.org/InstallingDebianOn/Samsung/ARMChromebook ) but
>the process it uses requires copying the chromeos kernel and only
>installs to a usb or sdcard. According to the linux-exynos wiki
>(http://linux-exynos.org/wiki/ARM_Chromebook/Mainline_Linux_kernel )
>there is now mainline support for this device in Linux and a  defconfig
>for it  (exynos).
>
>I would like to install to the internal ssd with a default kernel so
>that it still get updates. It this possible or will I have to build my
>own kernel?

My chromebook(Codename: Alex) is now charging. According to my three days test, 
Crouton is enough to use. That is easy to install. 

Otherewise you should go to chromium project (chrome os discuss forum[1]). In 
there, you could talk to Jedi developers about custom build for {linux and 
chrom os}.

Try to Crouton, in first;

Sincerely,

[1] chromium-os-disc...@chromium.org

-- 
^고맙습니다 감사합니다_^))//

off topic Question of the day..

[Gene Heskett]

Greetings all;

I bought, about a month ago, a big Brother MFC, proclaimed that it could 
do 11x17 prints when single sheet fed from the slot in the rear.

Its a Brother MFC-J6920DW.
So having a rockhopper output file that has been exported as a pdf by 
inkscape, I ordered up a ream of 11x17 28lb paper from wallies.

But I'll be switched if I can find a setting anyplace that will make it 
use a sheet of it fed thru the rear slot/door.

Anybody here got the magic incantation to keep it from shrinking the 
image to unusability on the paper in the two front trays?

Thanks.

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: reasons to ditch LILO before upgrading to jessie?

[Gary Dale]

On 08/07/16 07:06 PM, Brian wrote:

On Fri 08 Jul 2016 at 18:13:01 -0400, Gary Dale wrote:


On 08/07/16 02:19 PM, Brian wrote:

If you have some way of easily adjusting files in /etc/grub.d to the
needs of a user I wish you would say.

So that's the problem. You never took the time to RTFM. See
https://help.ubuntu.com/community/Grub2/Setup#File_Structure

That page, no matter how informative it may be, is not the manual. My
comment was intended to elicit some specific technical advice on how to
adjust an /etc/grub.d file(s) to perform a particular task. Something
like the topic in

   https://lists.debian.org/debian-user/2016/07/msg00278.html

Using labels in a hand written grub.cfg is a snap. Stopping it being
overwritten is another snap. Perhaps altering file X in grub.d is just
as easy and unstressful.

Maybe one day I will read 'pinfo grub'. :)
True enough, but it shows how much good information there is out there. 
As for altering the correct files, it is just as easy and unstressful.





same change either way but the grub template file won't get clobbered so
there is no need to run dpkg-divert.

It's not the same change. ("grub template file". What is that? There
isn't one as far as I can see).

Again, RTFM. There are lots of files for you to tinker with in /etc/grub.d.
You can even add your own and it's guaranteed not be tampered with by any
updates.

So there are. Users should stay away from them (40_custom excepted)
unless they know what they are doing.

Same is true for altering any file.




Moreover, you don't need to update a system manual to note that you are
diverting a package. You just need to note that a single file is not the
package maintainers default - something you have to do either way.

Diverting is a Debian thing. The GRUB manual would never mention it.


No, but you do have to document each system that you are running. If you are
doing anything that is not standard, it has to be recorded so that the next
person (or you 3 months later) will know that you've done it.

I gather from your comment that you aren't doing this. That's asking for
trouble, especially if you are running custom configurations and protecting
them with diversions. Complexity added onto complexity without documentation
is a good recipe for disaster.

I cannot argue with that.

Re: off topic Question of the day..

[Gene Heskett]

On Friday 08 July 2016 21:35:30 Gene Heskett wrote:

> Greetings all;
>
> I bought, about a month ago, a big Brother MFC, proclaimed that it
> could do 11x17 prints when single sheet fed from the slot in the rear.
>
> Its a Brother MFC-J6920DW.
> So having a rockhopper output file that has been exported as a pdf by
> inkscape, I ordered up a ream of 11x17 28lb paper from wallies.
>
> But I'll be switched if I can find a setting anyplace that will make
> it use a sheet of it fed thru the rear slot/door.
>
> Anybody here got the magic incantation to keep it from shrinking the
> image to unusability on the paper in the two front trays?
>
> Thanks.
>
> Cheers, Gene Heskett

Call in the St. Bernards, I found it. With the pdf loaded into evince I 
was able to set "current page" in its printer dialog, then it called the 
system gizmo, and on the 2nd tab was a paper selection pulldown that had 
the 11x17 selection available. And darned if it didn't work!  Biggest 
problem was getting the paper started straight enough.  Very poor and 
downright flimsy guidance hardware for the rear big sheet/odd size input 
port.

Job done and now I know how. ;-)


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: off topic Question of the day..

[Jörg-Volker Peetz]

With cups-client all printer specific options can be listed with

  lpoptions -l

To select a specific printer add '-p '. See 'man lpoptions' or
http://localhost:631/help .

Regards,
jvp.