from:"Alberto Sentieri"

Re: ajuda

2021-02-28 Thread Alberto Sentieri


Troque a linha que onde está escrito

GRUB_CMDLINE_LINUX_DEFAULT="quiet"

por uma com

GRUB_CMDLINE_LINUX_DEFAULT="nomodeset"

ou

GRUB_CMDLINE_LINUX_DEFAULT="quiet nomodeset"

Depois execute update-grub (como root)


On 2/28/21 3:50 PM, Luis Inocêncio wrote:
E o que tenho que alterar no ficheiro /etc/default/grub, que controla 
o boot?



Em dom., 28 de fev. de 2021 às 05:50, Alberto Sentieri 
<2...@tripolho.com <mailto:2...@tripolho.com>> escreveu:


Ainda sobre a placa Nvidia. Voce tem que alterar o arquivo de nome
/etc/default/grub, que controla o seu boot. Depois disso voce tem
que executar o programa update-grub. Tudo isso como root.

On 2/27/21 5:15 PM, Luis Inocêncio wrote:

Boa Noite.
Antes de mais agradecer a vossa atenção. Deixo abaixo mais
detalhadamente os problemas que tenho, agora que parece que já
consegui instalar (isso após tentar se sucesso com outras
Distros) pela primeira vez o Debian:
1- Tendo uma placa grafica Nvidia (julgo que é por isso) nunca
consigo entrar diretamente pelo Grub, sem antes trocar na lina
relativa ao linux no Grub ‘quiet’ por ‘nomodeset’. A primeira
duvida é essa, como configurar definitivamente isso para não ter
que estar sempre a alterar no Grub? Ou será que quando conseguir
as drives (especificas) do Nvidia isso fica resolvido?
2- Ao tentar entrar como rooter (no terminal) utilizando sudo -s,
apesar de inserir corretamente a senha é me sempre informado que
a senha não é correta e nunca tenho acesso como rooter. Já
alterei a senha e o problema persiste :( ... Isso apesar de
conseguir aceder gestor de pacotes synaptic  utilizando no caso
exatamente a mesma senha que não é aceite no terminal. Isso é
normal? Como resolver isso?
3- Enfim, preciso conseguir entrar como rooter senão não
conseguirei fazer nada como o Debian e será até já 100%
frustrante minha experiencia com o Linux :(
Agradeço antecipadamente a vossa atenção e ajuda

Good evening. First of all thank you for your attention. I leave
below in more detail the problems I have, now that it seems that
I already managed to install (this after trying to be successful
with other Distros) for the first time Debian: 1- Having an
Nvidia graphics card (I think that's why) I can never get
directly through Grub, without first switching to the linux
related to Grub 'quiet' by 'nomodeset'. The first question is
this, how to definitively configure this to not have to be
constantly changing in Grub? Or will it be that when you get the
(specific) Nvidia drives this is resolved? 2- When trying to
enter as a rooter (in the terminal) using sudo -s, despite
correctly entering the password, I am always informed that the
password is not correct and I never have access as a rooter. I
have already changed the password and the problem persists :( ...
That despite being able to access synaptic package manager using
in this case exactly the same password that is not accepted in
the terminal. Is this normal? How to solve this? 3- Anyway, I
need to be able to log in as a rooter otherwise I will not be
able to do anything like Debian and it will be even 100%
frustrating my experience with Linux :( Thank you in advance for
your attention and help

Em sáb., 27 de fev. de 2021 às 19:23, Alberto Sentieri
<2...@tripolho.com <mailto:2...@tripolho.com>> escreveu:

Luis,

Apesar de falar português, eu não entendi sua pergunta
completamente.

Debian tem duas passwords. Uma para root e outra para o
usuário comum.

Para fazer updates você precisa da password para root.

Eu sempre faço isto:

Abro um terminal (procure por terminal).

No terminal entre "su -" (sem as aspas). Este commando vai
pedir pela password do root. Aí você digita:

apt-get update

e depois ...

apt-get upgrade


On 2/27/21 12:05 PM, Luis Inocêncio wrote:

Boa Tarde
Desculpem, sou novo no Debian e tudo é novidade e não sei
onde conseguirei encontrar ajuda para o problema que tenho??
(ou o Debian tem?)
Tenho o Debian instalado no meu computador, e apesar de
ainda só conseguir entrar no ambiente do Debian depois de
aceder via "comando" nomodeset no Grub... :(
Tentando atualizar o Debian por forma a ir colocando-o
operacional/funcional logo na minha primeira tentativa a
aceder ao root (via terminal) esse acesso me é negado (não é
aceite a password que escolhi???)
Entretanto com a mesma password consigo aceder ao gestor de
Pacotes Synaptic - que no entanto não me ajudou (nada)
porque através dele tambem não foi aceite/instalado nenhum
programa do meu interesse.
Podem me ajudar

Re: ajuda

2021-02-27 Thread Alberto Sentieri


Luis,

1) Sobre placa NVidia. Eu também tenho uma placa NVidia. Infelizmente 
esta placa tem especificações não públicas, e os drivers open-source 
nunca funcionaram corretamente para mim. A solução que acabei adotando 
foi instalar os drivers da própria Nvidia. Mesmo assim, algumas vezes 
tenho problemas.


2) Quanto ao comando sudo, o seu usuário tem que ser um membro do grupo 
para poder utilizá-lo. O comando "sudo bash" e o comando "su -" são 
distintos. Para o comando sudo você tem que entrar com a senha do 
usuário corrente. Já para o comando "su -" você tem que entrar com a 
senha do root. Se voce quiser utilizar o comando sudo, você tem que 
tornar o seu uusário um membro do grupo sudoers.


Você poderá descobrir se o seu usuário é membro do grupo sudo através do 
comando:


cat /etc/group|grep sudo

Se a resposta for algo do tipo

sudo:x:27:

Então seu usuário não faz parte do grupo. No entanto, para colocar o seu 
usuário no grupo você tem que ser membro do grupo ou estar logado como root.


Obviamente este comandos tem que ser emitidos de um terminal (terminal 
application).



Boa sorte,

Alberto

On 2/27/21 5:50 PM, Semih Ozlem wrote:

To clarify the situation

(i) You have installed Debian but not the graphics card yet and you 
are having issues with installations because it does not accept the 
password that you set up during the installation. You successfully 
changed either the root or the user or both passwords? And after the 
change the sudo command still did not accept the new password? I have 
no idea that would be the case. Maybe some of the more experienced 
members have an idea.
For installation of NVIDIA 
https://wiki.debian.org/NvidiaGraphicsDrivers 
 is a page you can look 
up ç
(ii) No it is not normal. After you change the password the new one 
should work. Normally passwords are changed by the command "sudo 
passwd username" from command line which asks for new password and if 
a password for root user was set up it would ask for root user's 
password. If these methods for changing the password do not work 
(which I assumed to be the case in my earlier email) then basically 
you would have to reset the password in a configuration file somewhere 
that I forget and would have to look up. But maybe someone on the list 
knows the answer already and upon seeing the message would reply so do 
reply to everyone on the list.
(iii) I believe root is the administrative user which can make changes 
to the system. But problems do occur I think in whatever system one 
works under, but it is my impression that generally people in this 
list are helpful in resolving the issues. I hope your experience 
remains good.
When installing did you create a regular user with a username and 
password Does this password with the created username work

Did you ever set up your root password

Luis Inocêncio mailto:lumarin...@gmail.com>>, 
28 Şub 2021 Paz, 01:15 tarihinde şunu yazdı:


Boa Noite.
Antes de mais agradecer a vossa atenção. Deixo abaixo mais
detalhadamente os problemas que tenho, agora que parece que já
consegui instalar (isso após tentar se sucesso com outras Distros)
pela primeira vez o Debian:
1- Tendo uma placa grafica Nvidia (julgo que é por isso) nunca
consigo entrar diretamente pelo Grub, sem antes trocar na lina
relativa ao linux no Grub ‘quiet’ por ‘nomodeset’. A primeira
duvida é essa, como configurar definitivamente isso para não ter
que estar sempre a alterar no Grub? Ou será que quando conseguir
as drives (especificas) do Nvidia isso fica resolvido?
2- Ao tentar entrar como rooter (no terminal) utilizando sudo -s,
apesar de inserir corretamente a senha é me sempre informado que a
senha não é correta e nunca tenho acesso como rooter. Já alterei a
senha e o problema persiste :( ... Isso apesar de conseguir aceder
gestor de pacotes synaptic  utilizando no caso exatamente a mesma
senha que não é aceite no terminal. Isso é normal? Como resolver isso?
3- Enfim, preciso conseguir entrar como rooter senão não
conseguirei fazer nada como o Debian e será até já 100% frustrante
minha experiencia com o Linux :(
Agradeço antecipadamente a vossa atenção e ajuda

Good evening. First of all thank you for your attention. I leave
below in more detail the problems I have, now that it seems that I
already managed to install (this after trying to be successful
with other Distros) for the first time Debian: 1- Having an Nvidia
graphics card (I think that's why) I can never get directly
through Grub, without first switching to the linux related to Grub
'quiet' by 'nomodeset'. The first question is this, how to
definitively configure this to not have to be constantly changing
in Grub? Or will it be that when you get the (specific) Nvidia
drives this is resolved? 2- When trying to enter as a rooter (in
the terminal) using sudo -s,

Re: Question: SSD speed

2020-10-07 Thread Alberto Sentieri

Just a small correction: it I believe SATA uses 8B/10B protocol, which 
means each byte uses 10 bits on the serial channel.


On 10/7/20 5:56 AM, Jeremy Nicoll wrote:

On Wed, 7 Oct 2020, at 09:39, Hans wrote:

Hi folks,

I have a little question. Smartctl is telling me, that my ssd drive is 6Gb/sec
capable, but the actual speed is only 1,5GB/sec.

If your SATA (presumably) connection from the machine to the SSD is a
6 Gbps one, the maximum data transfer speed in bytes across that
connection would be one eighth of that (as there's 8 bits per byte), so
about 760 MBps.

That's about half of your "1,5GBps".  That makes me wonder if your
SSD uses two SATA channels at once - is that even possible?

Alternatively, do any SSDs compress data before sending it across the
SATA channel?

Re: Debian hangs (PREEMPT RT?)

2020-06-25 Thread Alberto Sentieri

I had a similar problem, but I could ssh into the machine, otherwise I 
would say it was locked. My problem was the video driver (NVIDIA card). 
I fixed it by installing the manufacture driver.


On 6/25/20 3:54 PM, Malte Schmidt wrote:

Dear all,

I'm running Debian 10 with the recent updates using a RT Kernel to run 
a Machine using Linuxcnc. I face the problem that Debian "hangs" i.e. 
becomes completely unresponsive. This includes Keyboard, Mouse and 
also the SysReq + REISUB does no longer work. The system does not 
really "crash" i.e. I keep seeing X. Usually X and keyboard freeze a 
bit before the mouse pointer also stops to move.
I have the feeling that this only occurs when there is a realtime task 
running but I cannot say that for sure.


Not sure if pastebins are appreciated here:
Output of dmesg: https://pastebin.com/zgh6Cw84
Xorg.0.log:https://pastebin.com/eNJCLTWf
/var/log/messages https://pastebin.com/EbJh4qYY

I did spot anything obvious in the logs

This PC was used for a couple of years for Machine control running a 
Realtime Kernel on Debian 7


I'm a bit clueless at this point and would appreciate hints what to 
check for.


Thanks,
Malte

--
Robert Hirsch und Malte Schmidt
Adverrun Drives
Fruehlingstr. 41
90537 Feucht
i...@adverrun.com

Re: Zoom- best practice?

2020-06-09 Thread Alberto Sentieri

This is a long thread. I did not read it all. Did anyone suggest 
http://meet.google.com?

Re: Looking for video card recommendation

2020-05-06 Thread Alberto Sentieri


Thanks. Adding contrib solved the problem.

On 5/5/20 8:24 PM, Alexander V. Makartsev wrote:

On 05.05.2020 20:29, Alberto Sentieri wrote:
Last time I installed it I downloaded the driver from NVIDIA web 
site. I was able to install it and it worked well, but updates 
started bothering me. Maybe I should have tried a Debian repo, but I 
did not and I have no recollection of the reason.


Anyway, I was trying to install it now using debian repos (deb 
http://deb.debian.org/debian/ buster main non-free), as you 
suggested, and I got this. Any suggestion?


# nvidia-detect
Detected NVIDIA GPUs:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF119 
[NVS 310] [10de:107d] (rev a1)


Checking card:  NVIDIA Corporation GF119 [NVS 310] (rev a1)
Your card is only supported up to the 390 legacy drivers series.
It is recommended to install the
    nvidia-legacy-390xx-driver
package.
# apt-get install nvidia-legacy-390xx-driver
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 nvidia-legacy-390xx-driver : PreDepends: nvidia-installer-cleanup 
but it is not installable
  Depends: 
nvidia-legacy-390xx-driver-libs (= 390.116-1) but it is not going to 
be installed or
nvidia-legacy-390xx-driver-libs-nonglvnd (= 390.116-1) but it is not 
going to be installed
  Depends: nvidia-legacy-390xx-driver-bin 
(= 390.116-1) but it is not going to be installed
  Depends: 
xserver-xorg-video-nvidia-legacy-390xx (= 390.116-1) but it is not 
going to be installed
  Depends: 
nvidia-legacy-390xx-vdpau-driver (= 390.116-1) but it is not going to 
be installed
  Depends: 
nvidia-legacy-390xx-alternative (= 390.116-1) but it is not going to 
be installed
  Depends: 
nvidia-legacy-390xx-kernel-dkms (= 390.116-1) but it is not going to 
be installed or

nvidia-legacy-390xx-kernel-390.116
  Depends: nvidia-support but it is not 
installable
  Recommends: 
nvidia-settings-legacy-390xx but it is not installable
  Recommends: libnvidia-legacy-390xx-cfg1 
(= 390.116-1) but it is not going to be installed
  Recommends: nvidia-persistenced but it 
is not installable

E: Unable to correct problems, you have held broken packages.



Package "nvidia-installer-cleanup" is in "contrib" section, so you 
have to add it too. Don't forget to invoke "apt update" after that.



--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀https://www.debian.org
⠈⠳⣄

Re: Looking for video card recommendation

2020-05-05 Thread Alberto Sentieri

Last time I installed it I downloaded the driver from NVIDIA web site. I 
was able to install it and it worked well, but updates started bothering 
me. Maybe I should have tried a Debian repo, but I did not and I have no 
recollection of the reason.


Anyway, I was trying to install it now using debian repos (deb 
http://deb.debian.org/debian/ buster main non-free), as you suggested, 
and I got this. Any suggestion?


# nvidia-detect
Detected NVIDIA GPUs:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF119 [NVS 
310] [10de:107d] (rev a1)


Checking card:  NVIDIA Corporation GF119 [NVS 310] (rev a1)
Your card is only supported up to the 390 legacy drivers series.
It is recommended to install the
    nvidia-legacy-390xx-driver
package.
# apt-get install nvidia-legacy-390xx-driver
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 nvidia-legacy-390xx-driver : PreDepends: nvidia-installer-cleanup but 
it is not installable
  Depends: nvidia-legacy-390xx-driver-libs 
(= 390.116-1) but it is not going to be installed or
nvidia-legacy-390xx-driver-libs-nonglvnd (= 390.116-1) but it is not 
going to be installed
  Depends: nvidia-legacy-390xx-driver-bin 
(= 390.116-1) but it is not going to be installed
  Depends: 
xserver-xorg-video-nvidia-legacy-390xx (= 390.116-1) but it is not going 
to be installed
  Depends: nvidia-legacy-390xx-vdpau-driver 
(= 390.116-1) but it is not going to be installed
  Depends: nvidia-legacy-390xx-alternative 
(= 390.116-1) but it is not going to be installed
  Depends: nvidia-legacy-390xx-kernel-dkms 
(= 390.116-1) but it is not going to be installed or

nvidia-legacy-390xx-kernel-390.116
  Depends: nvidia-support but it is not 
installable
  Recommends: nvidia-settings-legacy-390xx 
but it is not installable
  Recommends: libnvidia-legacy-390xx-cfg1 
(= 390.116-1) but it is not going to be installed
  Recommends: nvidia-persistenced but it is 
not installable

E: Unable to correct problems, you have held broken packages.


On 5/5/20 7:07 AM, Alexander V. Makartsev wrote:

On 03.05.2020 19:51, Alberto Sentieri wrote:
I have a Nvidia NVS310 installed in my Linux computer for a few 
years. It works well with the Nvidia driver, and not so well with the 
Linux nouveau driver. I am looking for a equivalent replacement (a 
cheap one) which works well with a standard non-proprietary Linux 
device driver. By works well I mean does not lock on me.


I do not need fancy graphics, but I need:

- 2 DisplayPort
- support for 2 monitors up to 2560 x 1600
Since you don't want to use proprietary drivers I suggest you to look 
for an AMD video card.
Also 2xDisplayPort is a quite a requirement. At the quick glance your 
options are to select from AMD RX570 video cards or better, which 
counts as "fancy graphics".




If you are curious about the reason to replace it, here it goes:

The Nvidia NVS310 has never worked well with Linux. In the beginning 
(many years ago) I decided to install Nvidia proprietary drivers, but 
every kernel upgrade would require an additional effort to have the 
driver working. That was enough for me to try the standard 
non-proprietary driver again.



What is this "additional effort" you have to perform?
For me, proprietary Nvidia drivers (installed from official Debian 
repos, ofcourse) are working fine, and since they build kernel modules 
using DKMS automatically every driver update or major kernel update, I 
don't have to do anything more than reboot the system, so Xorg server 
would use updated driver. You can make the Xorg server to use updated 
driver even without reboot, but it will require stopping Xorg server, 
reload kernel modules and start it back on, so for me reboot is quicker.


--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀https://www.debian.org
⠈⠳⣄

Re: Looking for video card recommendation

2020-05-04 Thread Alberto Sentieri


Thank you for your answer. I will try the nouveau user list.

I tried the  suggestion below, I mean delete nouveau_dri.so, but the 
system became unstable. I could not login, and the mouse and keyboard 
became very slow. After entering the correct password, the login screen 
would come back as if I hadn't done anything. That message was written 
before buster, and does not seem to work with it.


Thanks

On 5/4/20 8:17 PM, riveravaldez wrote:

On 5/3/20, Alberto Sentieri <2...@tripolho.com> wrote:

Lately, with Debian stretch (and Mate), things got sort of stable with
the nouveau driver, and I was getting one frozen screen every few
months, which was kind of acceptable. A couple of weeks ago I upgrade to
Debian buster (GNOME3) and the nightmare is back: I get a frozen screen
at leas once a day. A simple F11 pressed on Firefox could cause the
freeze, but there other things, which I could not determine, that also
cause the freeze. The freeze is only a graphic freeze, I mean, I can ssh
into the machine from my laptop, stop all services and shut it down, or
restart it. But I could not figure out a way of restarting the video
without a reboot. And every freeze usually means losing something, and
losing many minutes.

I know that eventually the nouveau guys will get it stable again, and I
admire their continuous work, but this time I do not want to wait for them.

Any suggestions?


Hi, have you tried sending this to the nouveau list?

nouv...@lists.freedesktop.org

I had similar symptoms for a long time and found the solution here:

https://www.spinics.net/lists/nouveau/msg01004.html

Maybe worthwhile to give it a try.

Best regards.

Looking for video card recommendation

2020-05-03 Thread Alberto Sentieri

I have a Nvidia NVS310 installed in my Linux computer for a few years. 
It works well with the Nvidia driver, and not so well with the Linux 
nouveau driver. I am looking for a equivalent replacement (a cheap one) 
which works well with a standard non-proprietary Linux device driver. By 
works well I mean does not lock on me.


I do not need fancy graphics, but I need:

- 2 DisplayPort
- support for 2 monitors up to 2560 x 1600

If you are curious about the reason to replace it, here it goes:

The Nvidia NVS310 has never worked well with Linux. In the beginning 
(many years ago) I decided to install Nvidia proprietary drivers, but 
every kernel upgrade would require an additional effort to have the 
driver working. That was enough for me to try the standard 
non-proprietary driver again.


Lately, with Debian stretch (and Mate), things got sort of stable with 
the nouveau driver, and I was getting one frozen screen every few 
months, which was kind of acceptable. A couple of weeks ago I upgrade to 
Debian buster (GNOME3) and the nightmare is back: I get a frozen screen 
at leas once a day. A simple F11 pressed on Firefox could cause the 
freeze, but there other things, which I could not determine, that also 
cause the freeze. The freeze is only a graphic freeze, I mean, I can ssh 
into the machine from my laptop, stop all services and shut it down, or 
restart it. But I could not figure out a way of restarting the video 
without a reboot. And every freeze usually means losing something, and 
losing many minutes.


I know that eventually the nouveau guys will get it stable again, and I 
admire their continuous work, but this time I do not want to wait for them.


Any suggestions?

Here is dmesg in one of the freezes:

[23664.639186] WARNING: CPU: 3 PID: 7223 at 
drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h:172 
init_rdauxr+0xf4/0x130 [nouveau]
[23664.639187] Modules linked in: nfnetlink cfg80211 fuse rfcomm arc4 
md4 sha512_ssse3 sha512_generic nls_utf8 cifs ccm dns_resolver fscache 
8021q garp mrp bridge stp llc vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) 
cmac bnep intel_rapl snd_hda_codec_hdmi btusb btrtl btbcm 
x86_pkg_temp_thermal btintel intel_powerclamp bluetooth nls_ascii 
nls_cp437 coretemp vfat fat kvm_intel jitterentropy_rng kvm 
snd_hda_codec_realtek snd_hda_codec_generic drbg irqbypass 
crct10dif_pclmul ansi_cprng crc32_pclmul snd_hda_intel 
ghash_clmulni_intel joydev ecdh_generic snd_hda_codec intel_cstate 
snd_hda_core efi_pstore snd_hwdep snd_pcm eeepc_wmi asus_wmi snd_timer 
intel_uncore mei_me pcc_cpufreq snd sparse_keymap iTCO_wdt mei 
intel_rapl_perf rfkill efivars wmi_bmof pcspkr soundcore sg 
iTCO_vendor_support evdev firewire_sbp2
[23664.639207]  parport_pc ppdev lp parport efivarfs ip_tables x_tables 
autofs4 ext4 crc16 mbcache jbd2 crc32c_generic fscrypto ecb 
hid_logitech_hidpp hid_logitech_dj hid_generic usbhid hid sr_mod cdrom 
sd_mod nouveau crc32c_intel video i2c_algo_bit mxm_wmi xhci_pci ttm ahci 
xhci_hcd libahci drm_kms_helper ehci_pci aesni_intel ehci_hcd libata 
aes_x86_64 drm crypto_simd usbcore cryptd e1000e glue_helper scsi_mod 
firewire_ohci i2c_i801 firewire_core lpc_ich mfd_core crc_itu_t 
usb_common wmi button
[23664.639224] CPU: 3 PID: 7223 Comm: kworker/u24:1 Tainted: G   
OE 4.19.0-8-amd64 #1 Debian 4.19.98-1+deb10u1
[23664.639225] Hardware name: System manufacturer System Product 
Name/P9X79, BIOS 4502 10/15/2013

[23664.639254] Workqueue: nvkm-disp gf119_disp_super [nouveau]
[23664.639275] RIP: 0010:init_rdauxr+0xf4/0x130 [nouveau]
[23664.639276] Code: e1 48 89 ef ba 09 00 00 00 be 01 00 00 00 e8 e3 9c 
03 00 85 c0 75 27 80 7c 24 0f 01 74 0e 48 c7 c7 10 bf 8e c0 e8 7a b9 b8 
dc <0f> 0b 48 89 ef e8 12 9a 03 00 0f b6 44 24 0e e9 39 ff ff ff 48 89

[23664.639277] RSP: 0018:a53483adfc08 EFLAGS: 00010246
[23664.639279] RAX: 0024 RBX: a53483adfc90 RCX: 

[23664.639280] RDX:  RSI: 9a2bff8d66b8 RDI: 
9a2bff8d66b8
[23664.639281] RBP: 9a2bfb86e800 R08: 0571 R09: 
0007
[23664.639282] R10:  R11: 9e7f46ed R12: 
0102
[23664.639283] R13: 9a2bfbbb3b00 R14: 0020 R15: 
00df
[23664.639284] FS:  () GS:9a2bff8c() 
knlGS:

[23664.639285] CS:  0010 DS:  ES:  CR0: 80050033
[23664.639286] CR2: 7f9acaa452c4 CR3: 000633e0a002 CR4: 
000606e0

[23664.639287] Call Trace:
[23664.639310]  init_auxch+0xf6/0x180 [nouveau]
[23664.639331]  nvbios_exec+0x45/0xd0 [nouveau]
[23664.639359]  nvkm_dp_train_init+0x12e/0x170 [nouveau]
[23664.639386]  nvkm_dp_acquire+0x1a6/0xcb0 [nouveau]
[23664.639390]  ? update_blocked_averages+0x77b/0x950
[23664.639394]  ? __switch_to_asm+0x41/0x70
[23664.639395]  ? __switch_to_asm+0x41/0x70
[23664.639397]  ? syscall_return_via_sysret+0x14/0x83
[23664.639399]  ? __switch_to_asm+0x35/0x70
[23664.639400]  ?

Re: unexpected behavior of cp and mv

2020-04-30 Thread Alberto Sentieri


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959211

On 4/30/20 3:52 PM, The Wanderer wrote:

On 2020-04-30 at 15:27, Alberto Sentieri wrote:


I run tcpdump while running my simple program on both stretch and
buster. On stretch, x2 uses SMB (version 1, I guess) protocol, while
on buster it uses SMB2 (version 2 or 3).

So, the problem can be solved by adding vers=1.0 to mount.cifs
options. Any version from 2.0 and above will incur in the same
utimensat error. I set vers to 1.0 and it worked properly.

Beware: this is a security hole. My understanding (based on experiences
in my workplace) is that the SMBv1 protocol is known to be inherently,
unfixably insecure, to the point that current Windows versions will not
speak it unless explicitly told to in an out-of-the-way and inconvenient
configuration location.

I would not consider forcing the use of SMBv1 to be a satisfactory
resolution, unless you can be 100% sure that nothing malicious will ever
be in a position to mess around here.

Re: unexpected behavior of cp and mv

2020-04-30 Thread Alberto Sentieri

Thanks for the information. I will enter a bug report asking for a fix 
for the last stretch available samba server. Or maybe for cifs-utils on 
buster side.


On 4/30/20 3:52 PM, The Wanderer wrote:

On 2020-04-30 at 15:27, Alberto Sentieri wrote:


I run tcpdump while running my simple program on both stretch and
buster. On stretch, x2 uses SMB (version 1, I guess) protocol, while
on buster it uses SMB2 (version 2 or 3).

So, the problem can be solved by adding vers=1.0 to mount.cifs
options. Any version from 2.0 and above will incur in the same
utimensat error. I set vers to 1.0 and it worked properly.

Beware: this is a security hole. My understanding (based on experiences
in my workplace) is that the SMBv1 protocol is known to be inherently,
unfixably insecure, to the point that current Windows versions will not
speak it unless explicitly told to in an out-of-the-way and inconvenient
configuration location.

I would not consider forcing the use of SMBv1 to be a satisfactory
resolution, unless you can be 100% sure that nothing malicious will ever
be in a position to mess around here.

Re: unexpected behavior of cp and mv

2020-04-30 Thread Alberto Sentieri

I run tcpdump while running my simple program on both stretch and 
buster. On stretch, x2 uses SMB (version 1, I guess) protocol, while on 
buster it uses SMB2 (version 2 or 3).


So, the problem can be solved by adding vers=1.0 to mount.cifs options. 
Any version from 2.0 and above will incur in the same utimensat error. I 
set vers to 1.0 and it worked properly.


While using SMB2, I can also see FILE_INFO/SMB2_FILE_BASIC_INFO on 
buster as a result of utimensat, so something is being sent to the samba 
server.


The question to be answered now is if this is a problem on buster side, 
or or on samba stretch side. The later has all updates.




On 4/30/20 1:32 PM, Thomas Schmitt wrote:

Hi,

Alberto Sentieri wrote:

ls -ls "${NAME}"
Note that the /mnt/u1/rw/receipt is a SMB folder. I got this result:
1024 -rwxr-xr-x 1 u1 u1 10 Apr 30 12:20 /mnt/u1/rw/receipt/test2.txt
[...]
I run the same binary and script on my debian stretch workstation, 
and got

4 -rwxr-xr-x 1 u1 u1 10 Feb  5  2017 /mnt/u1/rw/receipt/test2.txt

It is quite remarkable that the SMB file is reported to use 1024 blocks
for storing 10 bytes.

-

I am still not convinced that SYS_utimensat is to blame.

What do you get if you sleep for 3 seconds before performing it ?

If still the file timestamp changes with that sleep:
What happens if you close the fd without calling utimensat and
re-open the file for applying utimensat only then ?
(What if you let sleep between between close and re-open ?)


Have a nice day :)

Thomas

Re: unexpected behavior of cp and mv

2020-04-30 Thread Alberto Sentieri


1 second, 3 seconds or 10 minutes have the same result.

About the 1024 1K-blocks, if one checks the file size on the samba 
server using the same  command, the return will be:

4 -rwxrw-r--  1 root cifsusers   10 Feb  5  2017 test2.txt

So, it is using only 4Kbytes on the server. I have no idea why smb 
interface always reports 1Mbyte. By the way, I have seen this behavior 
for many years. stat (on the workstation) also reports the same (2048 
512-byte blocks).


I will do the tests you suggested later. I am also thinking about trying 
a flush before utimensat. None of this, however, happens in cp.


It may not be utimensat. Between the kernel and the smb, there is a cifs 
package (the driver) which could be doing it wrong. Both the kernel and 
cifs package are different between the two workstations.


Thanks,

Alberto

On 4/30/20 1:32 PM, Thomas Schmitt wrote:

Hi,

Alberto Sentieri wrote:

ls -ls "${NAME}"
Note that the /mnt/u1/rw/receipt is a SMB folder. I got this result:
1024 -rwxr-xr-x 1 u1 u1 10 Apr 30 12:20 /mnt/u1/rw/receipt/test2.txt
[...]
I run the same binary and script on my debian stretch workstation, and got
4 -rwxr-xr-x 1 u1 u1 10 Feb  5  2017 /mnt/u1/rw/receipt/test2.txt

It is quite remarkable that the SMB file is reported to use 1024 blocks
for storing 10 bytes.

-

I am still not convinced that SYS_utimensat is to blame.

What do you get if you sleep for 3 seconds before performing it ?

If still the file timestamp changes with that sleep:
What happens if you close the fd without calling utimensat and
re-open the file for applying utimensat only then ?
(What if you let sleep between between close and re-open ?)


Have a nice day :)

Thomas

Re: unexpected behavior of cp and mv

2020-04-30 Thread Alberto Sentieri

Apparently there is something wrong with the debian stretch utimensat 
system call, or with its interaction with cifs. It works as expected 
when the destination file is on a ext4 file system, but it does not work 
when the destination file is on a SMB file system.


I wrote a simple C program, which I compiled with .

On my debian buster workstation, I run the program using a script, which is:

#!/bin/bash
NAME='/mnt/u1/rw/receipt/test2.txt'
rm -f "${NAME}"
ls -ls "${NAME}"
/mnt/1g/home/u1/data/cp-pi/x2 "${NAME}"
ls -ls "${NAME}"
sleep 1
ls -ls "${NAME}"

Note that the /mnt/u1/rw/receipt is a SMB folder. I got this result:

$ ./do2.sh
ls: cannot access '/mnt/u1/rw/receipt/test2.txt': No such file or directory
0 -rwxr-xr-x 1 u1 u1 10 Feb  5  2017 /mnt/u1/rw/receipt/test2.txt
1024 -rwxr-xr-x 1 u1 u1 10 Apr 30 12:20 /mnt/u1/rw/receipt/test2.txt

As you can see, the time stamp changes after one second.

This is the C code for x2.

#include 
#include 
#include 
#include 
#include 
#include 
#include 

static char *data = "test data\n";
static struct timespec timestamps [2] = {
    { 1588174263, 908624390 },
    { 1486350336, 481422339 }
};

int main (int argc, char **argv)
{
    int fd;

    if (argc > 1) {
        fd = openat (AT_FDCWD, argv [1], O_WRONLY|O_CREAT, 0666);
        if (fd >= 0) {
            write (fd, data, strlen (data));
            /* do not use glibc utimensat directly, it does not allow 
NULL as a second argument */

            syscall (SYS_utimensat, fd, NULL, timestamps, 0);
            close (fd);
            return 0;
        }
    }
    printf ("something went wrong\n");
    return 0;
}

About my buster workstation:
# cat /proc/version;dpkg -l |grep cifs
Linux version 4.19.0-8-amd64 (debian-ker...@lists.debian.org) (gcc 
version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.98-1+deb10u1 (2020-04-27)

ii cifs-utils 2:6.8-2 amd64 Common Internet File System utilities

I run the same binary and script on my debian stretch workstation, and 
got this:


$ ./do2.sh
ls: cannot access '/mnt/u1/rw/receipt/test2.txt': No such file or directory
0 -rwxr-xr-x 1 u1 u1 10 Feb  5  2017 /mnt/u1/rw/receipt/test2.txt
4 -rwxr-xr-x 1 u1 u1 10 Feb  5  2017 /mnt/u1/rw/receipt/test2.txt

$ cat /proc/version
Linux version 4.9.0-12-amd64 (debian-ker...@lists.debian.org) (gcc 
version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 
4.9.210-1 (2020-01-20)

# dpkg -l |grep cifs
ii  cifs-utils 2:6.7-1 amd64 Common Internet File System utilities

I run the C program above, using the same binary, and got two different 
behaviors.


Can anyone help me with this?

On 4/29/20 5:31 PM, Thomas Schmitt wrote:

Hi,

assumed that the success of "touch" indicates that utimensat(2) works
fine, i would pick the failed fsetxattr(2) as next suspect.

Does this set the timestamps despite failing ?

setfattr -n user.test_name -v test_value /mnt/u1/rw/receipt/u1.crontab

(I expect an "Operation not supported" error as in strace.
If it succeeds against our will, try -n "test_name", without prefix
"user.".)


Alberto Sentieri wrote:

So, the cp behavior on debian stretch and buster seems to be the same.

But the implementation of the system calls is not.



touch does the trick of dup2 and close, before calling utimensat.

Hm. To verify suchtheories you will have to create a C program which
uses the traced system calls and by which you can test variations.

Quite interesting would be to inquire the file timestamps immediately
after utimensat() in order to learn whether it gets into effect at
least for a short time.


Have a nice day :)

Thomas

Re: unexpected behavior of cp and mv

2020-04-30 Thread Alberto Sentieri


Thanks.

By any chance is there a cifs specialist watching this thread?

Apparently the timestamp is initially correct but it changes after a 
while. Does anyone knows why? Is there a worker finishing the file copy, 
which could be creating this effect?


I wrote the following script to repeat my tests:

#!/bin/bash
rm -f /mnt/u1/rw/receipt/u1.crontab
/bin/stat /mnt/u1/rw/receipt/u1.crontab
/bin/cp -pi /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/
ls -ls /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/u1.crontab
/bin/stat /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/u1.crontab
sleep 1
ls -ls /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/u1.crontab
/bin/stat /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/u1.crontab

The result is this:

$ ./do_it.sh
/bin/stat: cannot stat '/mnt/u1/rw/receipt/u1.crontab': No such file or 
directory

4 -rw-r--r-- 1 u1 u1 54 Feb  5  2017 /mnt/1g/home/u1/data/u1.crontab
0 -rwxr-xr-x 1 u1 u1 54 Feb  5  2017 /mnt/u1/rw/receipt/u1.crontab
  File: /mnt/1g/home/u1/data/u1.crontab
  Size: 54        Blocks: 8  IO Block: 4096   regular file
Device: 831h/2097d    Inode: 58721601    Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  u1)   Gid: ( 1000/  u1)
Access: 2020-04-29 11:31:03.908624390 -0400
Modify: 2017-02-05 22:05:36.481422339 -0500
Change: 2017-02-05 22:05:36.581420492 -0500
 Birth: -
  File: /mnt/u1/rw/receipt/u1.crontab
  Size: 54        Blocks: 0  IO Block: 16384  regular file
Device: 2ch/44d    Inode: 75374568    Links: 1
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/  u1)   Gid: ( 1000/  u1)
Access: 2020-04-29 11:31:03.908624300 -0400
Modify: 2017-02-05 22:05:36.481422300 -0500
Change: 2020-04-30 10:04:07.613793700 -0400
 Birth: -
   4 -rw-r--r-- 1 u1 u1 54 Feb  5  2017 /mnt/1g/home/u1/data/u1.crontab
1024 -rwxr-xr-x 1 u1 u1 54 Apr 30 10:04 /mnt/u1/rw/receipt/u1.crontab
  File: /mnt/1g/home/u1/data/u1.crontab
  Size: 54        Blocks: 8  IO Block: 4096   regular file
Device: 831h/2097d    Inode: 58721601    Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  u1)   Gid: ( 1000/  u1)
Access: 2020-04-29 11:31:03.908624390 -0400
Modify: 2017-02-05 22:05:36.481422339 -0500
Change: 2017-02-05 22:05:36.581420492 -0500
 Birth: -
  File: /mnt/u1/rw/receipt/u1.crontab
  Size: 54        Blocks: 2048   IO Block: 16384  regular file
Device: 2ch/44d    Inode: 75374568    Links: 1
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/  u1)   Gid: ( 1000/  u1)
Access: 2020-04-29 11:31:03.908624300 -0400
Modify: 2020-04-30 10:04:07.611931500 -0400
Change: 2020-04-30 10:04:07.611931500 -0400
 Birth: -

On 4/30/20 6:39 AM, Thomas Schmitt wrote:

Hi,

Alberto Sentieri wrote:

I tried setfattr as you suggested with "user" and without "user". Both
failed with "Operation not supported" and none of them changed the
timestamp.

This only leaves the idea to mimick the strace of cp -p in an own
C program to see whether utimensat() has the desired effect and
whether following calls spoil it.
Maybe it is necessary to really create a new file and to write
some realistic amount of data to it in order to set up the conditions
for the problem.

The code of cp.c and copy.c in
   https://sources.debian.org/src/coreutils/8.30-3/src/
looks not overly self-contained. So it might be difficult to get a
debuggable version of cp, if not Debian package development magic can
produce it.


Have a nice day :)

Thomas

Re: unexpected behavior of cp and mv

2020-04-29 Thread Alberto Sentieri

I tried setfattr as you suggested with "user" and without "user". Both 
failed with "Operation not supported" and none of them changed the 
timestamp.


On 4/29/20 5:31 PM, Thomas Schmitt wrote:

Hi,

assumed that the success of "touch" indicates that utimensat(2) works
fine, i would pick the failed fsetxattr(2) as next suspect.

Does this set the timestamps despite failing ?

   setfattr -n user.test_name -v test_value /mnt/u1/rw/receipt/u1.crontab

(I expect an "Operation not supported" error as in strace.
If it succeeds against our will, try -n "test_name", without prefix
"user.".)


Alberto Sentieri wrote:

So, the cp behavior on debian stretch and buster seems to be the same.

But the implementation of the system calls is not.



touch does the trick of dup2 and close, before calling utimensat.

Hm. To verify suchtheories you will have to create a C program which
uses the traced system calls and by which you can test variations.

Quite interesting would be to inquire the file timestamps immediately
after utimensat() in order to learn whether it gets into effect at
least for a short time.


Have a nice day :)

Thomas

Re: unexpected behavior of cp and mv

2020-04-29 Thread Alberto Sentieri


I am using ls -ls to check the data.

As captured from my screen:

$ rm /mnt/u1/rw/receipt/u1.crontab
$ ls -ls /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/u1.crontab
ls: cannot access '/mnt/u1/rw/receipt/u1.crontab': No such file or directory
4 -rw-r--r-- 1 u1 u1 54 Feb  5  2017 /mnt/1g/home/u1/data/u1.crontab
$ cp -pi /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/
$ ls -ls /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/u1.crontab
   4 -rw-r--r-- 1 u1 u1 54 Feb  5  2017 /mnt/1g/home/u1/data/u1.crontab
1024 -rwxr-xr-x 1 u1 u1 54 Apr 30 00:00 /mnt/u1/rw/receipt/u1.crontab

Other messages have more details.

On 4/29/20 9:47 PM, David Wright wrote:

On Wed 29 Apr 2020 at 15:07:52 (-0400), Alberto Sentieri wrote:

When I tried strace with /bin/cp -pi I can see on both commands
something like this:

utimensat(4, NULL, [{tv_sec=1588174263, tv_nsec=908624390} /*
2020-04-29T11:31:03.908624390-0400 */, {tv_sec=1486350336,
tv_nsec=481422339} /* 2017-02-05T22:05:36.481422339-0500 */], 0) = 0

The utimensat is exactly the same for both cp -pi to a ext4 file
system or to a smb filesystem. So, cp seems to be working as expected.
Probably the same is true to /bin/mv.

There's no possibility, is there, that you're reading the file status
time rather than the file modification time? cp -ip/mv will update the
former though not the latter. All three times will be set by touch in
the absence of any options (c and m).

I'm not familiar with cifs/smb protocols and filesystems.


-

Exactly the same behavior for /bin/cp and /bin/mv. I do not have any other cp 
or mv in my path.

$ sha1sum  /bin/cp /bin/mv
220687a082fb9d0dbb48e9a2b1093cbb4e9de55a  /bin/cp
46e71d67df7eb1c41f8f8c9039f401e242cce94a  /bin/mv


On Wed, Apr 29, 2020 at 12:22:41PM -0400, Alberto Sentieri wrote:

cp and mv are not preserving the file timestamps when copying from a ext4
file system to a smb file system.

I am running cp and mv on:
$ lsb_release -a
No LSB modules are available.
Distributor ID:    Debian
Description:    Debian GNU/Linux 10 (buster)
Release:    10
Codename:    buster

SMB is running on:
$ lsb_release -a
No LSB modules are available.
Distributor ID:    Debian
Description:    Debian GNU/Linux 9.12 (stretch)
Release:    9.12
Codename:    stretch

I am using "cp -pi" to copy the files and "mv -i" to move them.

If I run cp or mv on a Debian stretch, time stamps will be correct on the
SMB file system.

Buster gnome3 file manager will copy or move the files without problems, I
mean, they will preserve time stamps.

This started happening since I upgraded my workstation to buster, so the
problem seems to be in buster. I am mounting the file system on buster with
the following line added to fstab, which, by the way, is the same I was
using when my workstation was running stretch:

//192.168.1.2/alberto /mnt/u1/rw cifs
credentials=/root/pass/alberto.pass,uid=alberto,gid=alberto,rw 0 0

Does anyone knows which package is causing this behavior?


First, do you see the same behavior if you use /bin/cp and /bin/mv
instead of simply cp and mv?

Cheers,
David.

Re: unexpected behavior of cp and mv

2020-04-29 Thread Alberto Sentieri

Exactly as shown on my screen,  it shows that rsync, when used with -av, 
works as expected, but cp -pi does not.


$ rm /mnt/u1/rw/receipt/u1.crontab
$ ls -ls /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/u1.crontab
ls: cannot access '/mnt/u1/rw/receipt/u1.crontab': No such file or directory
4 -rw-r--r-- 1 u1 u1 54 Feb  5  2017 /mnt/1g/home/u1/data/u1.crontab
$ cp -pi /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/
$ ls -ls /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/u1.crontab
   4 -rw-r--r-- 1 u1 u1 54 Feb  5  2017 /mnt/1g/home/u1/data/u1.crontab
1024 -rwxr-xr-x 1 u1 u1 54 Apr 30 00:00 /mnt/u1/rw/receipt/u1.crontab
$ rm /mnt/u1/rw/receipt/u1.crontab
$ rsync  /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/
$ ls -ls /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/u1.crontab
   4 -rw-r--r-- 1 u1 u1 54 Feb  5  2017 /mnt/1g/home/u1/data/u1.crontab
1024 -rwxr-xr-x 1 u1 u1 54 Apr 30 00:01 /mnt/u1/rw/receipt/u1.crontab
$ rm /mnt/u1/rw/receipt/u1.crontab
$ ls -ls /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/u1.crontab
ls: cannot access '/mnt/u1/rw/receipt/u1.crontab': No such file or directory
4 -rw-r--r-- 1 u1 u1 54 Feb  5  2017 /mnt/1g/home/u1/data/u1.crontab
$ rsync -av /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/
sending incremental file list
u1.crontab

sent 158 bytes  received 35 bytes  386.00 bytes/sec
total size is 54  speedup is 0.28
$ ls -ls /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/u1.crontab
   4 -rw-r--r-- 1 u1 u1 54 Feb  5  2017 /mnt/1g/home/u1/data/u1.crontab
1024 -rwxr-xr-x 1 u1 u1 54 Feb  5  2017 /mnt/u1/rw/receipt/u1.crontab

On 4/29/20 5:48 PM, songbird wrote:

Alberto Sentieri wrote:

On 4/29/20 4:13 PM, Thomas Schmitt wrote:

Hi,

Alberto Sentieri wrote:

It is clear
there that -p has no effect on that particular case of smb destinations. A
similar problem is happening with mv.

Maybe its not the file copying operation but the subsequent adjustment
of the timestamps.
Did you already try whether you can change timestamps on SMB by e.g.
touch(1) ?

   if touch does work then try using it and the original file
name on the original file system as a reference file.

(see man touch)

   another thing to try would be to see if rsync is also
not doing this correctly.

   sorry, short on time at the moment to dig further but
these two things came immediately to mind.


   songbird

Re: unexpected behavior of cp and mv

2020-04-29 Thread Alberto Sentieri


Just to document what I've seen so far:

These are some straces which may help finding the problem:

1) cp -p  from ext4 to smb, debian buster, which failed:

utimensat(4, NULL, [{tv_sec=1588174263, tv_nsec=908624390} /* 
2020-04-29T11:31:03.908624390-0400 */, {tv_sec=1486350336, 
tv_nsec=481422339} /* 2017-02-05T22:05:36.481422339-0500 */], 0) = 0
fgetxattr(3, "system.posix_acl_access", 0x7ffd302bd820, 132) = -1 
ENODATA (No data available)

fstat(3, {st_mode=S_IFREG|0644, st_size=54, ...}) = 0
fsetxattr(4, "system.posix_acl_access", 
"\2\0\0\0\1\0\6\0\377\377\377\377\4\0\4\0\377\377\377\377 
\0\4\0\377\377\377\377", 28, 0) = -1 EOPNOTSUPP (Operation not supported)

fchmod(4, 0100644)  = 0
close(4)    = 0
close(3)    = 0
munmap(0x7fda0caa2000, 139264)  = 0
lseek(0, 0, SEEK_CUR)   = -1 ESPIPE (Illegal seek)
close(0)    = 0
close(1)    = 0
close(2)    = 0
exit_group(0)   = ?
+++ exited with 0 +++

2) cp -p from ext4 to ext4, debian buster, which worked correctly:

utimensat(4, NULL, [{tv_sec=1588174263, tv_nsec=908624390} /* 
2020-04-29T11:31:03.908624390-0400 */, {tv_sec=1486350336, 
tv_nsec=481422339} /* 2017-02-05T22:05:36.481422339-0500 */], 0) = 0
fgetxattr(3, "system.posix_acl_access", 0x7fffea95d4d0, 132) = -1 
ENODATA (No data available)

fstat(3, {st_mode=S_IFREG|0644, st_size=54, ...}) = 0
fsetxattr(4, "system.posix_acl_access", 
"\2\0\0\0\1\0\6\0\377\377\377\377\4\0\4\0\377\377\377\377 
\0\4\0\377\377\377\377", 28, 0) = 0

close(4)    = 0
close(3)    = 0
munmap(0x7f13495c9000, 139264)  = 0
lseek(0, 0, SEEK_CUR)   = -1 ESPIPE (Illegal seek)
close(0)    = 0
close(1)    = 0
close(2)    = 0
exit_group(0)   = ?

3) touch smb file, debian buster (command touch -t 202001011700 
u1.crontab), which works correctly:


openat(AT_FDCWD, "u1.crontab", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 
0666) = 3

dup2(3, 0)  = 0
close(3)    = 0
utimensat(0, NULL, [{tv_sec=1577916000, tv_nsec=0} /* 
2020-01-01T17:00:00-0500 */, {tv_sec=1577916000, tv_nsec=0} /* 
2020-01-01T17:00:00-0500 */], 0) = 0

close(0)    = 0
close(1)    = 0
close(2)    = 0
exit_group(0)   = ?

4) cp -p from ext4 to smb on debian stretch, which works correctly:

utimensat(4, NULL, [{tv_sec=1588174263, tv_nsec=908624390}, 
{tv_sec=1486350336, tv_nsec=481422339}], 0) = 0
fgetxattr(3, "system.posix_acl_access", 0x7ffdd4465000, 132) = -1 
ENODATA (No data available)

fstat(3, {st_mode=S_IFREG|0644, st_size=54, ...}) = 0
fsetxattr(4, "system.posix_acl_access", 
"\2\0\0\0\1\0\6\0\377\377\377\377\4\0\4\0\377\377\377\377 
\0\4\0\377\377\377\377", 28, 0) = -1 EOPNOTSUPP (Operation not supported)

fchmod(4, 0100644)  = 0
close(4)    = 0
close(3)    = 0
munmap(0x7f8ab2aaf000, 139264)  = 0
lseek(0, 0, SEEK_CUR)   = -1 ESPIPE (Illegal seek)
close(0)    = 0
close(1)    = 0
close(2)    = 0
exit_group(0)   = ?

So, the cp behavior on debian stretch and buster seems to be the same.

touch does the trick of dup2 and close, before calling utimensat.

Alberto

On 4/29/20 4:13 PM, Thomas Schmitt wrote:

Hi,

Alberto Sentieri wrote:

It is clear
there that -p has no effect on that particular case of smb destinations. A
similar problem is happening with mv.

Maybe its not the file copying operation but the subsequent adjustment
of the timestamps.
Did you already try whether you can change timestamps on SMB by e.g.
touch(1) ?


Have a nice day :)

Thomas

Re: unexpected behavior of cp and mv

2020-04-29 Thread Alberto Sentieri

The content file is copied correctly. And touch works as expected on smb 
files. The command below produced the expected results:


touch -t 201901011300  /mnt/u1/rw/receipt/u1.crontab


On 4/29/20 4:13 PM, Thomas Schmitt wrote:

Hi,

Alberto Sentieri wrote:

It is clear
there that -p has no effect on that particular case of smb destinations. A
similar problem is happening with mv.

Maybe its not the file copying operation but the subsequent adjustment
of the timestamps.
Did you already try whether you can change timestamps on SMB by e.g.
touch(1) ?


Have a nice day :)

Thomas

Re: unexpected behavior of cp and mv

2020-04-29 Thread Alberto Sentieri


Charles,

Please read the whole thread, which starts at 
https://lists.debian.org/debian-user/2020/04/msg01361.html. It is clear 
there that -p has no effect on that particular case of smb destinations. 
A similar problem is happening with mv.


I resurrect my stretch workstation and the behavior is different from 
buster, when copying a file with -pi from ext4 to smb.



On 4/29/20 3:16 PM, Charles Curley wrote:

On Wed, 29 Apr 2020 12:22:41 -0400
Alberto Sentieri <2...@tripolho.com> wrote:


cp and mv are not preserving the file timestamps when copying from a
ext4 file system to a smb file system.

What I see is:

* mv does preserve the time of the file, regardless of copying to an
   SMB share or not.

* cp indeed does not preserve the time of the original file, regardless
   of copying to an SMB share or not.

mv simply moves a directory entry, including the inode, from here to
there. cp creates a new directory entry at the destination. So these
results make sense.

To have cp preserve the time (i.e. copy the original file's time to the
copy), use its -p option.

Also, check for aliases that might include options you don't want.

Re: Re: unexpected behavior of cp and mv

2020-04-29 Thread Alberto Sentieri

When I tried strace with /bin/cp -pi I can see on both commands 
something like this:


utimensat(4, NULL, [{tv_sec=1588174263, tv_nsec=908624390} /* 
2020-04-29T11:31:03.908624390-0400 */, {tv_sec=1486350336, 
tv_nsec=481422339} /* 2017-02-05T22:05:36.481422339-0500 */], 0) = 0


The utimensat is exactly the same for both cp -pi to a ext4 file system 
or to a smb filesystem. So, cp seems to be working as expected. Probably 
the same is true to /bin/mv.


-

Exactly the same behavior for /bin/cp and /bin/mv. I do not have any other cp 
or mv in my path.

$ sha1sum  /bin/cp /bin/mv
220687a082fb9d0dbb48e9a2b1093cbb4e9de55a  /bin/cp
46e71d67df7eb1c41f8f8c9039f401e242cce94a  /bin/mv


On Wed, Apr 29, 2020 at 12:22:41PM -0400, Alberto Sentieri wrote:

cp and mv are not preserving the file timestamps when copying from a ext4
file system to a smb file system.

I am running cp and mv on:
$ lsb_release -a
No LSB modules are available.
Distributor ID:    Debian
Description:    Debian GNU/Linux 10 (buster)
Release:    10
Codename:    buster

SMB is running on:
$ lsb_release -a
No LSB modules are available.
Distributor ID:    Debian
Description:    Debian GNU/Linux 9.12 (stretch)
Release:    9.12
Codename:    stretch

I am using "cp -pi" to copy the files and "mv -i" to move them.

If I run cp or mv on a Debian stretch, time stamps will be correct on the
SMB file system.

Buster gnome3 file manager will copy or move the files without problems, I
mean, they will preserve time stamps.

This started happening since I upgraded my workstation to buster, so the
problem seems to be in buster. I am mounting the file system on buster with
the following line added to fstab, which, by the way, is the same I was
using when my workstation was running stretch:

//192.168.1.2/alberto /mnt/u1/rw cifs
credentials=/root/pass/alberto.pass,uid=alberto,gid=alberto,rw 0 0

Does anyone knows which package is causing this behavior?


First, do you see the same behavior if you use /bin/cp and /bin/mv
instead of simply cp and mv?

Regards,

-Roberto

--
Roberto C. Sánchez

Re: Re: unexpected behavior of cp and mv

2020-04-29 Thread Alberto Sentieri


Exactly the same behavior for /bin/cp and /bin/mv. I do not have any other cp 
or mv in my path.

$ sha1sum  /bin/cp /bin/mv
220687a082fb9d0dbb48e9a2b1093cbb4e9de55a  /bin/cp
46e71d67df7eb1c41f8f8c9039f401e242cce94a  /bin/mv


On Wed, Apr 29, 2020 at 12:22:41PM -0400, Alberto Sentieri wrote:

cp and mv are not preserving the file timestamps when copying from a ext4
file system to a smb file system.

I am running cp and mv on:
$ lsb_release -a
No LSB modules are available.
Distributor ID:    Debian
Description:    Debian GNU/Linux 10 (buster)
Release:    10
Codename:    buster

SMB is running on:
$ lsb_release -a
No LSB modules are available.
Distributor ID:    Debian
Description:    Debian GNU/Linux 9.12 (stretch)
Release:    9.12
Codename:    stretch

I am using "cp -pi" to copy the files and "mv -i" to move them.

If I run cp or mv on a Debian stretch, time stamps will be correct on the
SMB file system.

Buster gnome3 file manager will copy or move the files without problems, I
mean, they will preserve time stamps.

This started happening since I upgraded my workstation to buster, so the
problem seems to be in buster. I am mounting the file system on buster with
the following line added to fstab, which, by the way, is the same I was
using when my workstation was running stretch:

//192.168.1.2/alberto /mnt/u1/rw cifs
credentials=/root/pass/alberto.pass,uid=alberto,gid=alberto,rw 0 0

Does anyone knows which package is causing this behavior?


First, do you see the same behavior if you use /bin/cp and /bin/mv
instead of simply cp and mv?

Regards,

-Roberto

--
Roberto C. Sánchez

unexpected behavior of cp and mv

2020-04-29 Thread Alberto Sentieri

cp and mv are not preserving the file timestamps when copying from a 
ext4 file system to a smb file system.


I am running cp and mv on:
$ lsb_release -a
No LSB modules are available.
Distributor ID:    Debian
Description:    Debian GNU/Linux 10 (buster)
Release:    10
Codename:    buster

SMB is running on:
$ lsb_release -a
No LSB modules are available.
Distributor ID:    Debian
Description:    Debian GNU/Linux 9.12 (stretch)
Release:    9.12
Codename:    stretch

I am using "cp -pi" to copy the files and "mv -i" to move them.

If I run cp or mv on a Debian stretch, time stamps will be correct on 
the SMB file system.


Buster gnome3 file manager will copy or move the files without problems, 
I mean, they will preserve time stamps.


This started happening since I upgraded my workstation to buster, so the 
problem seems to be in buster. I am mounting the file system on buster 
with the following line added to fstab, which, by the way, is the same I 
was using when my workstation was running stretch:


//192.168.1.2/alberto /mnt/u1/rw cifs 
credentials=/root/pass/alberto.pass,uid=alberto,gid=alberto,rw 0 0


Does anyone knows which package is causing this behavior?

Alberto

Re: ajuda

Re: ajuda

Re: Question: SSD speed

Re: Debian hangs (PREEMPT RT?)

Re: Zoom- best practice?

Re: Looking for video card recommendation

Re: Looking for video card recommendation

Re: Looking for video card recommendation

Looking for video card recommendation

Re: unexpected behavior of cp and mv

Re: unexpected behavior of cp and mv

Re: unexpected behavior of cp and mv

Re: unexpected behavior of cp and mv

Re: unexpected behavior of cp and mv

Re: unexpected behavior of cp and mv

Re: unexpected behavior of cp and mv

Re: unexpected behavior of cp and mv

Re: unexpected behavior of cp and mv

Re: unexpected behavior of cp and mv

Re: unexpected behavior of cp and mv

Re: unexpected behavior of cp and mv

Re: Re: unexpected behavior of cp and mv

Re: Re: unexpected behavior of cp and mv

unexpected behavior of cp and mv

24 matches

Site Navigation

Mail list logo

Footer information