Joe composed on 2023-11-28 15:02 (UTC-):
> the BIOS resets
> DefaultBoot to the Windows drive and I then need a rescue OS to get back
> to grub.
If this is accurate, your BIOS is broken. It's standard procedure for a PC BIOS,
even since before UEFI in PCs became commonplace, to provide a BBS
On Tue, 28 Nov 2023 07:31:09 -0500
Dan Purgert wrote:
> On Nov 27, 2023, Daniel Rodriguez wrote:
> >
> > Context: I have Debian 11 in a HDD and Windows 11 in a SSD.
> > Initially, the first running disk was my SSD.
> > Event: when I switched to HDD and Debian booted, this applied an
> > update an
On Nov 27, 2023, Daniel Rodriguez wrote:
>
> Context: I have Debian 11 in a HDD and Windows 11 in a SSD. Initially, the
> first running disk was my SSD.
> Event: when I switched to HDD and Debian booted, this applied an
> update and restarted as usual. Later it entered the BIOS setting on
> its own
Hello team,
I would like to report unexpected behaviors in Debian 11 that it may
require to look into, I don't have the knowledge for now to get a clear
idea about what could happen, and this could be useful to make it visible
to keep in mind.
Context: I have Debian 11 in a HDD and Windows 11 in
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 u
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
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
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 t
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 id
On Thu 30 Apr 2020 at 12:46:26 (-0400), Alberto Sentieri wrote:
> 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 destin
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 1
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, whi
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
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 des
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 faile
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/hom
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
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=48142233
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 subse
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" er
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=48142233
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
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 times
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
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.
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 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 a
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
> Descript
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
On 9/21/2016 7:30 AM, Richard Owlett wrote:
On 9/21/2016 7:06 AM, David wrote:
On 21 September 2016 at 21:59, Richard Owlett
wrote:
I'm learning the shell.
Which shell?
That may be an an even better question than meets the eye.
I have two use cases:
1. the immediate one being whatever
Gregg writes:
> imadev:~$ csh
> % echo "$0"
> No file for $0.
Well, that tells you that you are running something weird and
nonstandard such as csh. But if you are running csh you already knew
that.
If
echo $0
doesn't produce satisfactory results run
ps
and examine the output
On Wed, Sep 21, 2016 at 08:18:36AM -0500, John Hasler wrote:
> To find out what shell you are running type
>
> echo $0
imadev:~$ csh
% echo "$0"
No file for $0.
The world's a much bigger place than just the Bourne family of shells,
unfortunately.
ps -p $$ # works in csh too
Richard writes:
> When in an arbitrary terminal of an arbitrary Desktop Environment, how
> would I determine which shell is in use?
To find out what shell is the login shell type
echo $SHELL
To find out what shell you are running type
echo $0
To run the Korn shell type
ksh
To kill the shell
On Wed, Sep 21, 2016 at 07:30:50AM -0500, Richard Owlett wrote:
> 1. the immediate one being whatever shell MATE terminal uses.
Unless it's completely diverging from Unix standards, it should launch
your user account's shell as defined either by the $SHELL environment
variable, or by your entry
On 9/21/2016 7:06 AM, David wrote:
On 21 September 2016 at 21:59, Richard Owlett wrote:
I'm learning the shell.
Which shell?
That may be an an even better question than meets the eye.
I have two use cases:
1. the immediate one being whatever shell MATE terminal uses.
Sub-question: W
On Wed, 21 Sep 2016 07:18:50 -0500
Richard Owlett wrote:
Hello Richard,
>Is this a systemd thing?
No, it's a bash thing. If you're not using bash (IDK what Mate's
terminal is based on) then it won't exist. Look for something like
equivalent to see what you've got, if anything.
--
Regards
Hello,
Not a bug, but a feature since the first C shell release in 1978 [1],
which was copied to pretty much every shell created since (Korn
shell/ksh, Bourne again shell/bash, Z shell/zsh, …). The reason behind
it is that – since Unix predates most graphical user interfaces, and
most of the time
On 9/21/2016 7:04 AM, humbert.olivie...@free.fr wrote:
De: "Richard Owlett"
Workaround?
rm ~/.bash_history
HTH
It didn't :<
No such file seems to exist in any directory.
Is this a systemd thing?
On 21 September 2016 at 21:59, Richard Owlett wrote:
> I'm learning the shell.
Which shell?
Try 'man whatever.shell.you.are.using' and read what it says about "history".
In bash for example, you can set HISTFILESIZE to zero.
De: "Richard Owlett"
> Workaround?
rm ~/.bash_history
HTH
I'm learning the shell.
I experiment with test cases in "MATE Terminal"
The "up arrow" key is useful to recall previous command for editing.
I hadn't expected it when I found all instances of "MATE
Terminal" share same history.
*HOWEVER* I found that history remains after a "power off",
"boot"
41 matches
Mail list logo
