problem when changing display mode to join display in budgie

[Mina Morcose Farage]

hi

i have an external monitor beside my laptop monitor when i try to change to
extended mode or as called in budgie " Join Display " my external monitor
turn to be crumbled it's like the display has been splitted to small boxes
and overlayed over each other

to reproduce this problem you to make the external  monitor on left and to
be primary and try to apply the mode and to bypass this issu you should to
make to the right i want to report this bug but i am not sure which package
related to this problem

Thank ou
Mina Morcose Farage

Re: ALSA bug? Laptop headphone output depending on speaker channel setting

[Joel Roth]

Brendon Higgins wrote:
> Seasonal greetings, Debian users!
> 
> I was wondering if anyone has pointers for an audio configuration issue. I 
> have 
> Debian Testing running on a Dell laptop (Latitude E6320, audio chipset 
> detected as HDA Intel PCH, 92HD90BXX). The speaker output works fine. When I 
> plug in headphones, the system seems to detect that okay: it mutes the 
> speakers ("Speaker+LO" channel in alsamixer) and unmutes the headphones 
> ("Headphone" channel).
> 
> The problem is that no sound comes out of my headphones.
> 
> I've noticed that I have to also unmute and restore volume of the Speaker+LO 
> channel to hear anything in the headphones (meanwhile, with headphones 
> connected, the laptop speakers are silent as you would expect). The Headphone 
> volume setting doesn't seem to matter at all, although muting that does also 
> cause the headphones to mute.
> 
> It all used to work fine, but probably a couple of years ago it started 
> having 
> this behaviour. I suspect it was a kernel update, or maybe ALSA library - I 
> can't be certain - and put it off hoping the bug might just get fixed...
> 
> Any suggestions? I looked at the hdajackretask app,  but no idea where I 
> would 
> even start there.

Do you have pulseaudio running on your system?

It is a layer above ALSA, and could be related to your
issue.

> Thanks in advance,
> Brendon
> 
> 
> 

-- 
Joel Roth

Re: Debian 10 64bit

[Charlie Gibbs]

On Thu, 24 Dec 2020 10:40:02 +0100  wrote:

> On Wed, Dec 23, 2020 at 07:29:21PM -0600, David Wright wrote:
>
> [...]
>
>> Yes. And that's probably why google searches so often land on Arch
>> wiki pages=E2=80=94I assume that google is still ranking on the basis
>> of links to pages.
>
> Google? What /is/ that google thing people keep talking about?

I found out about it at https://www.duckduckgo.com

> ;-P

Back at ya, good buddy.

> Xmas, happy new and all that

And a happy Hanukkwanzaamas to you too.

--
/~\  Charlie Gibbs  |  Microsoft is a dictatorship.
\ /|  Apple is a cult.
 X   I'm really at ac.dekanfrus |  Linux is anarchy.
/ \  if you read it the right way.  |  Pick your poison.

Re: Discussion about backup passwords for LUKS encrypted filesystems before revising wiki

[David Christensen]

On 2020-12-24 10:06, rhkra...@gmail.com wrote:


On Tuesday, December 22, 2020 07:20:39 PM David Christensen wrote:

Thank you for offering to improve Debian documentation.  :-)


You're welcome, but I wasn't making a general offer to improve documentation,
just to fix something that I thought was misleading.


One fix is still an improvement.  :-)



... I
need to setup a few encrypted partitions for backup of some encrypted data
(currently backed up in only one place, on the same computer).  So I have an
interest in (better) learning how to set up LUKS partitions (without regard to
LVM).  


I have several such "encrypted backup media" drives.  The following are 
from my notes when I prepared one:


1.  Wipe drive:

# dd if=/dev/zero of=/dev/disk/by-id/ata-ST3000DM001-***redacted*** bs=4M

2.  Create GPT partition scheme:

# parted /dev/disk/by-id/ata-ST3000DM001-***redacted*** mklabel gpt

3.  Create one partition using almost all of the available space:

# parted /dev/disk/by-id/ata-ST3000DM001-***redacted*** mkpart primary 
0% 100%


4.  Create a LUKS container:

# cryptsetup luksFormat 
/dev/disk/by-id/ata-ST3000DM001-***redacted***-part1


WARNING!

This will overwrite data on 
/dev/disk/by-id/ata-ST3000DM001-***redacted***-part1 irrevocably.


Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:

5.  Open the LUKS container:

# cryptsetup luksOpen 
/dev/disk/by-id/ata-ST3000DM001-***redacted***-part1 i3000a_crypt

Enter passphrase for /dev/disk/by-id/ata-ST3000DM001-***redacted***-part1:

6.  Create an ext4 filesystem:

# mkfs.ext4 /dev/mapper/i3000a_crypt
mke2fs 1.42.5 (29-Jul-2012)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
183148544 inodes, 732565760 blocks
36628288 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
22357 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 2048, 23887872, 71663616, 78675968,
10240, 214990848, 51200, 550731776, 644972544

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

7.  Create a mount point:

# mkdir /mnt/i3000a

8.  Mount the filesystem:

# mount /dev/mapper/i3000a_crypt /mnt/i3000a



But, I've also been curious about LVM (without much intention of using
it) -- when I started skimming the LVM wiki page and found the stuff on LUKS I
decided that would be worth reading in view of my first interest (LUKS).



Further / farther aside: The secondary interest in LVM was sparked by some
clues in the ongoing thread(s) on debian-user that pointed to (or lead me to)
some gotchas that, if I were to start using LVM I'd want to be very aware of
(for instance, that adding a partition to an LVM wipes out any data on that
partition.


I have used MD and LUKS on Linux in the past.  Now I prefer OpenZFS (on 
FreeBSD).  But, that is a long story.  Learn LUKS and backups on Linux 
first.




As I was reading parts of that wiki page again (again in the LUKS section) I
started to realize that (to me) the more important thing (rather than creating
backup passwords) is creating a backup of the LUKS header.  I guess that is
what you are suggesting.  


Yes.



So, while "Backup passwords" -> "Step" ->
2.1 and "Restore password" -> 1.1 may describe useful system
administration procedures, these subsections have conceptual and
technical issues.


... I don't know
what they are -- I might be interested in learning what they are, but not sure
I'm interested in rewriting the document to reflect them more correctly.



Yeah, I guess I can see that perhaps some of the discussion of LUKS on this
page could / should be moved to a page specifically on LUKS, or as you mention
below, to a wiki page on BackupAndRecovery.  Again, I'm probably not ready to
do that (although to a certain extent I do enjoy writing and spend too much
time doing (or trying) to do it.


Do your homework, ask good questions, read the answers, and implement 
solutions that work for you.  Accept that you will make mistakes, so be 
prepared with good backups.  Eventually, you'll learn what you need to know.



If and when you feel comfortable contributing to the Debian Wiki, etc., 
then please do so.



David

Re: QEMU-KVM VMs sometime freeze when I run them for a couple of days

[Dan Ritter]

buz.hr...@seznam.cz wrote: 
> Hi Debian people ;-),
> 
> After having some issues with Fedora last year I decided to reinstall all my 
> servers to Debian 10. I'm supper happy with Debian except one repeating issue 
> I have with QEMU-KVM hosts that is very difficult to reproduce so I would 
> like to discuss it first before I open a new bug. Could you please discuss it 
> with me? ;-)
> 
> I noticed that when I run VMs for a long period of time (a couple of days) 
> one or multiple VMs quite often stuck. It is not possible to connect the 
> stuck VMs using virt-manager and their serial consoles don't respond.


First question: when they are just a few minutes old, does the
serial console work?


> It is not possible to shut them down ("virsh shutdown vm"). Sometimes the 
> stuck VMs can be powered down ("virsh destroy vm") but in most cases "virsh 
> destroy" doesn't work. In that case the only thing to do is to shut down rest 
> of running VMs (that do respond) and reboot the host.

Second question: when the VMs are a few minutes old, does virsh
shutdown work?

> When I reboot/shutdown the host the reboot/shutdown takes approx. 30min.
> 
> This is how it looks like during the reboot / shutdown:
> ~~~
> [   ***] (1 of 4) A stop job is running for /dev/dm-1 (18min 6s / no limit)

You probably want to change that to 1 minute or so.

> As I mentioned it is very difficult to reproduce it since it takes days to 
> get into that situation. VMs that are more likely to get stuck are VMs that:
> 
> a) have larger virtual disks
> b) more intensive storage use (use more IOPs)
> c) have more vCPUs
> 
> The problem is that VMs with larger disks usually use more IOPs and also have 
> more vCPUs so it is difficult to say what exactly is the issue. Based on my 
> testing I thing that less vCPUs makes it less likely to get stuck but it's 
> difficult to say...
> 
> The only thing I'm confident is that the problem is not HW related - it 
> happened both on my SuperMicro with XEON E5 v2 and on other hardware with 
> Intel i7 7th gen.

Are the VMs set up to match the local hardware definition or be
fully emulated?

And, especially: if they are not using virtio for disk and
network address, try that ASAP.

> Btw. this has never happened on my laptop that has same configuration as the 
> server (+Desktop Env.) but I reboot it multiple time a week so that might be 
> an answer...

Not so much an answer as an explanation why you haven't seen it,
but, sure, that's plausible.

-dsr-

ALSA bug? Laptop headphone output depending on speaker channel setting

[Brendon Higgins]

Seasonal greetings, Debian users!

I was wondering if anyone has pointers for an audio configuration issue. I have 
Debian Testing running on a Dell laptop (Latitude E6320, audio chipset 
detected as HDA Intel PCH, 92HD90BXX). The speaker output works fine. When I 
plug in headphones, the system seems to detect that okay: it mutes the 
speakers ("Speaker+LO" channel in alsamixer) and unmutes the headphones 
("Headphone" channel).

The problem is that no sound comes out of my headphones.

I've noticed that I have to also unmute and restore volume of the Speaker+LO 
channel to hear anything in the headphones (meanwhile, with headphones 
connected, the laptop speakers are silent as you would expect). The Headphone 
volume setting doesn't seem to matter at all, although muting that does also 
cause the headphones to mute.

It all used to work fine, but probably a couple of years ago it started having 
this behaviour. I suspect it was a kernel update, or maybe ALSA library - I 
can't be certain - and put it off hoping the bug might just get fixed...

Any suggestions? I looked at the hdajackretask app,  but no idea where I would 
even start there.

Thanks in advance,
Brendon

QEMU-KVM VMs sometime freeze when I run them for a couple of days

[buz.hrach]

Hi Debian people ;-),

After having some issues with Fedora last year I decided to reinstall all my 
servers to Debian 10. I'm supper happy with Debian except one repeating issue I 
have with QEMU-KVM hosts that is very difficult to reproduce so I would like to 
discuss it first before I open a new bug. Could you please discuss it with me? 
;-)

I noticed that when I run VMs for a long period of time (a couple of days) one 
or multiple VMs quite often stuck. It is not possible to connect the stuck VMs 
using virt-manager and their serial consoles don't respond.

It is not possible to shut them down ("virsh shutdown vm"). Sometimes the stuck 
VMs can be powered down ("virsh destroy vm") but in most cases "virsh destroy" 
doesn't work. In that case the only thing to do is to shut down rest of running 
VMs (that do respond) and reboot the host.

This is a kernel message I get in console that tells me that one or multiple 
VMs are stuck:
~~~
[686811.010084] INFO: task CPU 0/KVM:12193 blocked for more than 120 seconds.
[686811.017040]   Tainted: P   OE 4.19.0-12-amd64 #1 Debian 
4.19.152-1
[686811.024777] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
[686811.033012] INFO: task CPU 1/KVM:12194 blocked for more than 120 seconds.
[686811.039921]   Tainted: P   OE 4.19.0-12-amd64 #1 Debian 
4.19.152-1
[686811.047606] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
[686811.055803] INFO: task worker:5952 blocked for more than 120 seconds.
[686811.062355]   Tainted: P   OE 4.19.0-12-amd64 #1 Debian 
4.19.152-1
[686811.070048] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
[686811.078059] INFO: task worker:7667 blocked for more than 120 seconds.
[686811.084618]   Tainted: P   OE 4.19.0-12-amd64 #1 Debian 
4.19.152-1
[686811.092306] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
[686811.100296] INFO: task worker:4903 blocked for more than 120 seconds.
[686811.106849]   Tainted: P   OE 4.19.0-12-amd64 #1 Debian 
4.19.152-1
[686811.114530] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
[686811.122512] INFO: task worker:4905 blocked for more than 120 seconds.
[686811.129068]   Tainted: P   OE 4.19.0-12-amd64 #1 Debian 
4.19.152-1
[686811.136765] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
[686811.144771] INFO: task worker:4920 blocked for more than 120 seconds.
[686811.151328]   Tainted: P   OE 4.19.0-12-amd64 #1 Debian 
4.19.152-1
[686811.159009] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
[686811.167009] INFO: task worker:7328 blocked for more than 120 seconds.
[686811.173576]   Tainted: P   OE 4.19.0-12-amd64 #1 Debian 
4.19.152-1
[686811.181256] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
[686931.842071] INFO: task CPU 0/KVM:12193 blocked for more than 120 seconds.
[686931.849028]   Tainted: P   OE 4.19.0-12-amd64 #1 Debian 
4.19.152-1
[686931.856764] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
[686931.864997] INFO: task CPU 1/KVM:12194 blocked for more than 120 seconds.
[686931.871908]   Tainted: P   OE 4.19.0-12-amd64 #1 Debian 
4.19.152-1
[686931.879586] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
~~~

When I reboot/shutdown the host the reboot/shutdown takes approx. 30min.

This is how it looks like during the reboot / shutdown:
~~~
...
[1051413.325604] libvirt-guests.sh[10107]: error: Failed to shutdown domain 
de763fd3-043c-4f6f-b7f9-e134907b9f54
[1051413.325964] libvirt-guests.sh[10107]: error: Timed out during operation: 
cannot acquire state change lock (held by monitor=remoteDispatchDomainShutdown 
agent=remoteDispatchDomainShutdown)
...
[1053290.120617] reboot: Power down
~~~

Or systemd waits for LUKS encrypted block storage which doesn't make sense 
since LUKS is used only on SSD with the host OS and VMs run from a different 
SSDs.
~~~
[  OK  ] Stopped target Local File Systems (Pre).
[  OK  ] Stopped Create Static Device Nodes in /dev.
[  OK  ] Stopped Create System Users.
 Stopping Monitoring of LVM_meventd or progress polling...
[  OK  ] Stopped Monitoring of LVM2_ dmeventd or progress polling.
[FAILED] Failed deactivating swap swp.
 Stopping Cryptography Setup for swapluks1...
[  OK  ] Stopped Cryptography Setup for swapluks1.
 Stopping Load/Save Random Seed...
[  OK  ] Removed slice system-systemd\x2dcryptsetup.slice.
[  OK  ] Stopped Load/Save Random Seed.
[  OK  ] Stopped Remount Root and Kernel File Systems.
[  OK  ] Reached target Shutdown.
[   ***] (1 of 4) A stop job is running for /dev/dm-1 (18min 6s / no limit)
~~~
and then
~~~
[  OK  ] Stopped Load/Save Random Seed.
[  OK  ] Stopped Remount Root and Kernel File Systems.
[ 

Re: Discussion about backup passwords for LUKS encrypted filesystems before revising wiki

[rhkramer]

Note: Initially sent to David off list, he asked me to reply to the list.

David,

Thanks for your response!

I'm replying privately intentionally for various reasons -- I may summarize 
some of this on list at some point.

On Tuesday, December 22, 2020 07:20:39 PM David Christensen wrote:
> Thank you for offering to improve Debian documentation.  :-)

You're welcome, but I wasn't making a general offer to improve documentation, 
just to fix something that I thought was misleading.

And, I have a little trouble understanding what you are suggesting.  Keep 
reading.

Aside: Maybe I should explain why I was reading (some of) that wiki page: I 
need to setup a few encrypted partitions for backup of some encrypted data 
(currently backed up in only one place, on the same computer).  So I have an 
interest in (better) learning how to set up LUKS partitions (without regard to 
LVM).  But, I've also been curious about LVM (without much intention of using 
it) -- when I started skimming the LVM wiki page and found the stuff on LUKS I 
decided that would be worth reading in view of my first interest (LUKS).

Further / farther aside: The secondary interest in LVM was sparked by some 
clues in the ongoing thread(s) on debian-user that pointed to (or lead me to) 
some gotchas that, if I were to start using LVM I'd want to be very aware of 
(for instance, that adding a partition to an LVM wipes out any data on that 
partition.

> I agree that the content of "LVM" Debian Wiki page "Encrypted LVM"
> section could use some improvement.
> 
> 
> AIUI backing up aLinux Unified Key Setup (LUKS) header will save a copy
> of the metadata for a LUKS volume, which includes secure hashes of the
> passphrases (and/or keys) used to access the contents (such as a Linux
> Volume Manager (LVM) volume).  

As I was reading parts of that wiki page again (again in the LUKS section) I 
started to realize that (to me) the more important thing (rather than creating 
backup passwords) is creating a backup of the LUKS header.  I guess that is 
what you are suggesting.  (Again, I might, or might not revise the wiki to say 
that, if that is your point.  If that is not your point, I need some 
amplification.)

> So, while "Backup passwords" -> "Step" ->
> 2.1 and "Restore password" -> 1.1 may describe useful system
> administration procedures, these subsections have conceptual and
> technical issues.

Well, except for the one discussed previous to this sentence, I don't know 
what they are -- I might be interested in learning what they are, but not sure 
I'm interested in rewriting the document to reflect them more correctly.

 > The subjects of multiple passphrases and/or keys for encrypted items
> (volumes, filesystems, directories, files, etc.) and disaster
> preparedness/ recovery of encrypted volumes and/or containers are
> related, but different.  Regarding the first subject and LUKS, I would
> expect the first to appear on a wiki page for "LUKS" (which does not
> appear to exist).  

Yeah, I guess I can see that perhaps some of the discussion of LUKS on this 
page could / should be moved to a page specifically on LUKS, or as you mention 
below, to a wiki page on BackupAndRecovery.  Again, I'm probably not ready to 
do that (although to a certain extent I do enjoy writing and spend too much 
time doing (or trying) to do it.

> The latter subject for LUKS could be a useful
> addition to the "BackupAndRecovery" wiki page:
> 
>  https://wiki.debian.org/BackupAndRecovery
> 
> 
> David

Re: transfer speed data

[Michael Stone]

On Wed, Dec 23, 2020 at 05:09:47PM +0100, Nicolas George wrote:

Michael Stone (12020-12-23):

No, network speeds are traditionally measured in bits because networks
transferred data in bits and telcos dealt with bits, and they sold and
billed bits. Computer internals were measured in bytes and words because
they transferred data in bytes and words. Some people do now talk about
network speeds for computers in byte units, but you're really just swapping
one source of confusion for another when you do that. (There's an immense
amount of existing tooling for network-related information that already uses
bits, so everything that decides bytes are better for networking requires
conversion when dealing with most other networking tools even if it
eliminates conversion when dealing with filesystem or memory tools.) There
isn't one "right answer" that magically simplifies communications.


I read this paragraph as the defense of a cargo cult.


You may certainly read it as you wish, nevertheless I'll continue to 
explain why things are measured in different ways in different domains 
without resorting to baseless conspiracy theories. I'm also mostly 
interested in communicating with actual people, so regardless of whether 
you believe you have a superior approach that is more logical than the 
way language is used by other people is irrelevant to me--I find it more 
productive to be as clear as possible within the bounds of common
usage than to insist that everyone else should change. YMMV, have fun 
with your crusade.

Re: transfer speed data

[Michael Stone]

On Wed, Dec 23, 2020 at 07:27:49PM -0600, David Wright wrote:

I thought Michael Stone had already covered that, by suggesting sparse
files (with which I'm not familiar) 


A sparse file is one which has logically allocated empty (zero-filled) 
blocks without allocating physical blocks. You can create one easily 
with something like "truncate -s 1G testfile" and use "ls -l testfile ; 
du testfile" to confirm that it's logically 1G but using 0 disk blocks. 
This is convenient for storing certain data structures with a lot of 
empty space (e.g., /var/log/lastlog). On some ancient unix systems it 
could actually be slower to access sparse files than real files, but 
you're unlikely to run into those anymore and sparse files can be useful 
in certain kinds of testing. You do want to make sure you're not testing 
something that compresses data, as a file full of zeros will skew 
results for that sort of application.


On Thu, Dec 24, 2020 at 11:06:50AM +0200, Andrei POPESCU wrote:

I was rather referring to real use ;)

Speed tests under optimized conditions do have their purpose (e.g. is my
network interface working properly?[1]), but they might be misleading
when the bottleneck for real world transfers is elsewhere (like the
limited storage options on the PINE A64+).


Generally you'd want to test multiple things in isolation to understand 
where the bottlenecks are. I was speaking specifically about the 
encryption algorithms because someone suggested that was the problem 
was. Testing the disk I/O in isolation might be a logical next step, if 
a null-disk and null-network copy performed well. If it didn't perform 
well, then you'd have established an upper bound on what to expect from 
scp. (This would be relevant mainly on very low-power hardware these 
days, and though you're talking about an A64 I don't see where the OP 
said that was what he was using.)

Re: Debian 8 system is not fully functional

[Kenneth Parker]

On Thu, Dec 24, 2020, 8:08 AM Greg Wooledge  wrote:

> On Thu, Dec 24, 2020 at 12:49:30PM +0800, zhang yang wrote:
> > IP_ dynaddr
> > To modify and save the prompt: "IP"_ dynaddr" E212: Can't open file for
> > writing“.
> > So I used Chmod 777 ip_ dynaddr authority, display error: Chmod: changing
> > permissions of 'IP_ dynaddr': Operation not permitted.
> > I use chaddr - i ip_dynaddr command to removes attributes and displays an
> > error: chattr: Inappropriate ioctl for device while reading flags on
> > ip_dynaddr.  How to set dynaddr?
>
> For the benefit of others, the file in question is
>
> /proc/sys/net/ipv4/ip_dynaddr
>
> /proc is not a regular file system.  It's an interface to pieces of the
> kernel.  Some of these pieces can be read by everyone.  Almost none of
> them can be *written* by everyone -- you usually have to be root to
> write to them.
>
> chmod 777 is almost always a *huge* mistake.  If the permissions on a
> file are stopping you from doing someting, there's usually a reason
> for that.  Destroying the permissions on the file is not the right answer.
> Elevating yourself to a higher power level is.
>
> Now, the next thing you'll want to know is that while root can probably
> write to this file, it can't necessary *edit* the file with a text
> editor.  You're expected to use a much lower level of access to open
> the file, write to it, and close it.  Typically that's done with
>
> echo something > /proc/whatever
>
> Of course this redirection means that it's your shell who needs
> privileges to open the file for writing.  If you try it as your
> regular user, you'll encounter the "permission denied" error that
> you already saw.
>
> The expected course of action is for you to do it from a root shell,
> which you obtain by using su or sudo.
>
> $ su
> Password:
> # echo something > /proc/whatever
> # exit
> $
>
> If you're not a fan of su, or if you're one of those people who has
> decided not to have a root password (a bad idea!), then you can get
> a root shell with sudo -s:
>
> $ sudo -s
> # echo something >/proc/whatever
> # exit
> $
>
> (sudo may prompt you for your password if you haven't used sudo in that
> terminal in the last few minutes.)
>
> Some people will try to be clever and do this:
>
> sudo echo something > /proc/whatever
>
> That will not work, for the reasons explained at
> .


+10

That is an Awesome page you have there, Greg!  I have Bookmarked it.

>

You may use one of
> the quoted forms on that page if you prefer.  But the original design
> of the files in /proc was for users with a root shell to perform shell
> redirections.  Not for sudo.
>
> Also, while I'm here talking about su, bear in mind that Debian decided
> to become more like Red Hat and replaced their version of su with the
> one used by Red Hat, and didn't bother configuring it to maintain backward
> compatibility with the previous version.  See
>  for workarounds...
>

Also good.  I was never affected by the change, because I always use "su
-".

Kenneth Parker

>

Re: Debian 8 system is not fully functional

[Greg Wooledge]

On Thu, Dec 24, 2020 at 12:49:30PM +0800, zhang yang wrote:
> IP_ dynaddr
> To modify and save the prompt: "IP"_ dynaddr" E212: Can't open file for
> writing“.
> So I used Chmod 777 ip_ dynaddr authority, display error: Chmod: changing
> permissions of 'IP_ dynaddr': Operation not permitted.
> I use chaddr - i ip_dynaddr command to removes attributes and displays an
> error: chattr: Inappropriate ioctl for device while reading flags on
> ip_dynaddr.  How to set dynaddr?

For the benefit of others, the file in question is

/proc/sys/net/ipv4/ip_dynaddr

/proc is not a regular file system.  It's an interface to pieces of the
kernel.  Some of these pieces can be read by everyone.  Almost none of
them can be *written* by everyone -- you usually have to be root to
write to them.

chmod 777 is almost always a *huge* mistake.  If the permissions on a
file are stopping you from doing someting, there's usually a reason
for that.  Destroying the permissions on the file is not the right answer.
Elevating yourself to a higher power level is.

Now, the next thing you'll want to know is that while root can probably
write to this file, it can't necessary *edit* the file with a text
editor.  You're expected to use a much lower level of access to open
the file, write to it, and close it.  Typically that's done with

echo something > /proc/whatever

Of course this redirection means that it's your shell who needs
privileges to open the file for writing.  If you try it as your
regular user, you'll encounter the "permission denied" error that
you already saw.

The expected course of action is for you to do it from a root shell,
which you obtain by using su or sudo.

$ su
Password: 
# echo something > /proc/whatever
# exit
$ 

If you're not a fan of su, or if you're one of those people who has
decided not to have a root password (a bad idea!), then you can get
a root shell with sudo -s:

$ sudo -s
# echo something >/proc/whatever
# exit
$ 

(sudo may prompt you for your password if you haven't used sudo in that
terminal in the last few minutes.)

Some people will try to be clever and do this:

sudo echo something > /proc/whatever

That will not work, for the reasons explained at
.  You may use one of
the quoted forms on that page if you prefer.  But the original design
of the files in /proc was for users with a root shell to perform shell
redirections.  Not for sudo.

Also, while I'm here talking about su, bear in mind that Debian decided
to become more like Red Hat and replaced their version of su with the
one used by Red Hat, and didn't bother configuring it to maintain backward
compatibility with the previous version.  See
 for workarounds, including
how to configure su to behave sanely.

Re: Debian 10 64bit

[deloptes]

David Wright wrote:

> Yes. And that's probably why google searches so often land on Arch
> wiki pages—I assume that google is still ranking on the basis of
> links to pages.

Links to pages?! Clicks on links and profiling

MX-Linux Patito Feo 19.3

[ellanios82]

Dear List ,

 - jus' sayin' : this morning , had dreadful difficulty starting : 
Desktop Icons all gone :


 Workspaces all gone : the sole workspace unresponsive  : status paralytic


 solved by backup-restore of total /home directory



 phew !! : for me - Big worry !!   :(



 regards

Re: Debian 10 64bit

[tomas]

On Wed, Dec 23, 2020 at 07:29:21PM -0600, David Wright wrote:

[...]

> Yes. And that's probably why google searches so often land on Arch
> wiki pages—I assume that google is still ranking on the basis of
> links to pages.

Google? What /is/ that google thing people keep talking about?

;-P

Xmas, happy new and all that
 - t


signature.asc
Description: Digital signature

Re: transfer speed data

[Andrei POPESCU]

On Mi, 23 dec 20, 19:27:49, David Wright wrote:
> 
> I thought Michael Stone had already covered that, by suggesting sparse
> files (with which I'm not familiar) and /dev/null for conducting his
> encryption tests. I don't think any other posts had covered what's
> *between* the PCs, rather than in them.
> 
> Common sense would dictate against using SD cards etc for testing
> network speeds (unless, say, you were using such files), because you
> obviously want to reduce to a minimum the number of points of weakness
> (ie slowness), testing the speed of just one link in the chain at a time.

I was rather referring to real use ;)

Speed tests under optimized conditions do have their purpose (e.g. is my 
network interface working properly?[1]), but they might be misleading 
when the bottleneck for real world transfers is elsewhere (like the 
limited storage options on the PINE A64+).

[1] Especially for the PINE A64+, which did have some troubles with the 
network interface due to a hardware bug. Fortunately the issue was 
identified and corrected in later batches.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature