Re: Circumventing keyboard problem on Lenovo R64

[Richard Owlett]

On 09/12/2024 08:35 AM, Richard Owlett wrote:

On 09/12/2024 07:13 AM, Stefan Monnier wrote:

i Ricard,


It has a keyboard failure - the "h" key is intermittent and my primary
account is "Richard" ;/


[ I presume you know tat tis kind of failure can often (sadly not
   always) be fixed by cleaning.  ]


I have other symptoms that hint that there's a temperature problem with 
key decoding.


It's evidently a hard failure.
Left it off overnight and its there.
The local community college has a computer repair service as training 
aid for one of their degree programs.

Will see if they can handle.







I have no problem logging in as root.

Two primary questions:
1. is there someway that I can use a USB connected keyboard
    as workaround while root?


I can't tink of any reason wy tat wouldn't "just work".
ave you tried?


Now I have. It works ;}




2. is there some way to switch from "root" to "Richard" without
    having to type to the pop-up that shows when using
    System->Logout... ?


Probably, and tat probably depends on wat you mean by "switc" and on te
kind of "display manager" you're using (many of tem give you a list of
users from wic you can select by clicking).
You can also (as root) cange your user's name to remove tat pesky
`` letter.



Relevant man page to have 'root' edit a user's login name?

TIA





 Stefan

Re: Circumventing keyboard problem on Lenovo R64

[Hans]

Hi Richard,

exchanging the keyboard yourself might be not a great thing. If it is not an 
apple computer, where you have to strip the whole computer, most keyboards are 
very simple to echange. 

There are often some videos on youtube, which show, how to do it. 

On most, there are 1 - 3 screws to loosen, then (but not always), some clamps 
to press aside, and you can lift up the whole keyboard. 

On my Lenovo T520 (and I suppose most Lenovos are made like mine), you have to 
loosen 2 screws on the bottom, then push the whole keyboard into the mousepad 
direction, and then lift it up. Easy to do.

If done, you can loosen the flat cable as usual and exchage the keyboard.

It is just a hint, if you want to save money. The keyboards are all about 30 - 
50 € (about 40 $) and the exchange by a commercial should not cost much. It is 
done within 10 minutes (maybe a few dollars more)

Hope this helps!

Best

Hans

Re: Circumventing keyboard problem on Lenovo R64

[Richard Owlett]

On 09/13/2024 03:56 AM, Hans wrote:

Hi Richard,

exchanging the keyboard yourself might be not a great thing. If it is not an
apple computer, where you have to strip the whole computer, most keyboards are
very simple to echange.[snip]


ROFL
The keyboard is not the only problem.
I was an electronics tech back in the 60's and have serviced early color 
TVs (CTC2 anyone?), isotope ratio mass spectrometers, control room 
equipment for nuclear power plant, etc etc ;}

You learn things in over a half century ;}!

As I said elsewhere:

Don't have tools nor dexterity ;/
However the local community college has a computer repair service as
training aid for one of their degree programs.
Having been a tech, there's things I want done that could be valuable
background for a new graduate.


Also they have convenient access to parts.

Re: Disk drive zero-fill benchmarks for various synchronization methods and block sizes

[Anssi Saari]

David Wright  writes:

> On Tue 10 Sep 2024 at 11:56:25 (+0300), Anssi Saari wrote:

>> Why do you think that? Which part of the fsync manpage explicitly covers
>> fsync's effect on device files? Share share, it's fair.

>  “fsync() transfers ("flushes") all modified in-core data of (i.e.,
>   modified buffer cache pages for) the file referred to by the file
>   descriptor fd to the disk device (or other permanent storage device)
>   so that all changed information can be retrieved even after the
>   system crashed or was rebooted. This includes writing through or
>   flushing a disk cache if present. The call blocks until the device
>   reports that the transfer has completed. It also flushes metadata
>   information associated with the file (see stat(2)).”

You just parroted a man page I had already read. Why did you think
that'd be helpful? I asked the questions because the man page didn't
answer my questions. As you are apparemntly unable I found for example
https://unix.stackexchange.com/questions/473854/block-device-cache-v-s-a-filesystem
and so arrived to the conclusion that the final close(2) call on a block
device already flushes all buffers before returning. So the answer to
the question "is running sync needed after dd to block device" is
no. Someone else posted that too on this list recently, in another
thread.

Re: Circumventing keyboard problem on Lenovo R64

[George at Clug]

On Friday, 13-09-2024 at 20:17 Richard Owlett wrote:
> On 09/13/2024 03:56 AM, Hans wrote:
> > Hi Richard,
> > 
> > exchanging the keyboard yourself might be not a great thing. If it is not an
> > apple computer, where you have to strip the whole computer, most keyboards 
> > are
> > very simple to echange.[snip]
> 
> ROFL
> The keyboard is not the only problem.
> I was an electronics tech back in the 60's and have serviced early color 
> TVs (CTC2 anyone?), isotope ratio mass spectrometers, control room 
> equipment for nuclear power plant, etc etc ;}
> You learn things in over a half century ;}!
> 
> As I said elsewhere:
> > Don't have tools nor dexterity ;/
> > However the local community college has a computer repair service as
> > training aid for one of their degree programs.
> > Having been a tech, there's things I want done that could be valuable
> > background for a new graduate.
> 
> Also they have convenient access to parts.

Richard, please let us know how you go with your laptop.

My son's first laptop's keyboard has a number of keys that seem worn out, 
making logging in problematic without an external USB keyboard.  

Tried cleaning but that did not help, cannot guarantee I did a great job, 
though.

Works great if we plug in a USB keyboard and mouse. Just not as convenient. 

Speaking about Keyboard issues, I have some desktops that I cannot get to bios 
unless I use a PS/2 keyboard (i.e. they bios does not recognise USB), so I keep 
a few PS/2 keyboards in the cupboard for when I want to do bios changes. (I 
hope this makes someone smile)

You may have already reported the answer to my question, but "does a USB 
keyboard allow you to log in as yourself and as root?"

Like you I once worked with Colour TVs as it was being introduced, much later 
than you did... 
For historical amusement, in Australia:
https://www.nfsa.gov.au/collection/curated/colour-tv-australia
The colour TV revolution hit Australia 40 years ago, on 1 March 1975

Australia was a bit slow at jumping into Colour TV technology. Hopefully we are 
a bit faster these days on getting into new technology.

George.



> 
> 
> 
> 
> 
> 

scp in crontab problem

[Marcus Park]

Hi list,

I have put the private key into my debian VPS (in ~/.ssh/ dir).

When I scp a file from this VPS to another one by hand without password, 
it works.


But when I put this scp into crontab, it seems not work. The scp in 
crontab via private key didn't run as I expect, nothing was copied to peer.


Can you help?

Thank you.
Marcus

Re: scp in crontab problem

[basti]

On 13.09.24 14:24, Marcus Park wrote:

Hi list,

I have put the private key into my debian VPS (in ~/.ssh/ dir).

When I scp a file from this VPS to another one by hand without password, 
it works.


But when I put this scp into crontab, it seems not work. The scp in 
crontab via private key didn't run as I expect, nothing was copied to peer.


Can you help?

Thank you.
Marcus



Cron doesn't know anything about your environment variables.
You can set PATH or HOME or use absolute paths.

/usr/bin/scp -i /home/userYX/.ssh/myKEY r...@example.com ...

Best regards,

Re: scp in crontab problem

[Greg Wooledge]

On Fri, Sep 13, 2024 at 20:24:51 +0800, Marcus Park wrote:
> I have put the private key into my debian VPS (in ~/.ssh/ dir).

Does this private key have a passphrase?

> When I scp a file from this VPS to another one by hand without password, it
> works.
> 
> But when I put this scp into crontab, it seems not work. The scp in crontab
> via private key didn't run as I expect, nothing was copied to peer.

First question: what did the output say?  Any output from the cron job
should have been mailed to you.  If you don't have a mail reader set up
on this machine, try "less /var/mail/$LOGNAME" or something.  If you
don't have local mail delivery set up, fix that.

Second question: if the key has a passphrase, are you using an ssh-agent
to invoke it normally?  The cron job won't have access to your ssh-agent,
not without a bunch of additional setup.

For automated jobs, you usually need the private key to NOT have a
passphrase.  And yes, this is a large security concern.  You'll have
to balance your security needs against your application needs.

Re: Circumventing keyboard problem on Lenovo R64

[Richard Owlett]

On 09/13/2024 07:03 AM, George at Clug wrote:



On Friday, 13-09-2024 at 20:17 Richard Owlett wrote:

On 09/13/2024 03:56 AM, Hans wrote:

Hi Richard,

exchanging the keyboard yourself might be not a great thing. If it is not an
apple computer, where you have to strip the whole computer, most keyboards are
very simple to echange.[snip]


ROFL
The keyboard is not the only problem.
I was an electronics tech back in the 60's and have serviced early color
TVs (CTC2 anyone?), isotope ratio mass spectrometers, control room
equipment for nuclear power plant, etc etc ;}
You learn things in over a half century ;}!

As I said elsewhere:

Don't have tools nor dexterity ;/
However the local community college has a computer repair service as
training aid for one of their degree programs.
Having been a tech, there's things I want done that could be valuable
background for a new graduate.


Also they have convenient access to parts.


Richard, please let us know how you go with your laptop.


May be a while. "Round TUIT" is MIA.



My son's first laptop's keyboard has a number of keys that seem worn out, 
making logging in problematic without an external USB keyboard.

Tried cleaning but that did not help, cannot guarantee I did a great job, 
though.

Works great if we plug in a USB keyboard and mouse. Just not as convenient.


In my case it may be more convenient. The USB is long enough to have 
better keyboard placement.




Speaking about Keyboard issues, I have some desktops that I cannot get to bios 
unless I use a PS/2 keyboard (i.e. they bios does not recognise USB), so I keep 
a few PS/2 keyboards in the cupboard for when I want to do bios changes. (I 
hope this makes someone smile)

You may have already reported the answer to my question, but "does a USB keyboard 
allow you to log in as yourself and as root?"


Yes.



Like you I once worked with Colour TVs as it was being introduced, much later 
than you did...
For historical amusement, in Australia:
https://www.nfsa.gov.au/collection/curated/colour-tv-australia
The colour TV revolution hit Australia 40 years ago, on 1 March 1975


The CTC2 has a special place in memories. I was a young tech for RCA 
Service in mid-60's. Our shop tech quit doing in-home calls. I got most 
of his customers. One was worried about a wet-behind-ears kid working on 
his set (2nd or 3rd year production). Relaxed when he found out my set 
was older than his ;}


Australia was a bit slow at jumping into Colour TV technology. Hopefully we are 
a bit faster these days on getting into new technology.

George.

Re: scp in crontab problem

[Charles Curley]

On Fri, 13 Sep 2024 20:24:51 +0800
Marcus Park  wrote:

> Hi list,
> 
> I have put the private key into my debian VPS (in ~/.ssh/ dir).

The private key of what?

And to ~/.ssh/ on which computer. you are talking about transferring a
file from one computer to another; which one?

And why the private key? Usually one transfers the public key from
one's own computer to another, and one keeps the private key, well,
private.

> 
> When I scp a file from this VPS to another one by hand without
> password, it works.
> 
> But when I put this scp into crontab, it seems not work. The scp in 
> crontab via private key didn't run as I expect, nothing was copied to
> peer.

Don't tell us what you did, show us. Copy exactly the line(s) from your
crontab file and paste it into your email.

Did you get an email from cron? If so, show us that.

> 
> Can you help?

Not without better information.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[fixed]Re: startx returns "Xf86EnableIO: failed to enable I/O ports 0000-03ff"

[Pierre Willaime]

Le 11/09/2024 à 17:55, Max Nikulin a écrit :


grep -r system.conf /usr/share/dbus-1/
/usr/share/dbus-1/system.conf:  ignore_missing="yes">/etc/dbus-1/system.conf


I do not have this file as well. I suggest Pierre to compare config 
files of live and installed environments.


I recommend to read

and the similar document for bullseye. My guess is that the 
non-free-firmware repository may be missed on this machine and it may 
have impact on issues with Xorg.


I had two extra files in /etc/dbus-1

#  ls -l /etc/dbus-1/
total 8
lrwxrwxrwx 1 root root   30  3 avril  2021 session.conf -> 
/usr/share/dbus-1/session.conf
drwxr-xr-x 2 root root 4096 16 sept.  2023 session.d
lrwxrwxrwx 1 root root   29  3 avril  2021 system.conf -> 
/usr/share/dbus-1/system.conf
drwxr-xr-x 2 root root 4096  1 sept. 18:04 system.d

# grep -r system.conf /usr/share/dbus-1/
/usr/share/dbus-1/system.conf:  /etc/dbus-1/system.conf

I deleted them

# rm /etc/dbus-1/session.conf /etc/dbus-1/system.conf

And X server is starting 

Thank you all.

I guess upgrading directly from debian 9 to debian 12 prevented a script to 
remove these files.


I do not think it was related to non-free-firmware repository (Here is my 
sources.list below)

deb http://deb.debian.org/debian bookworm main contrib non-free 
non-free-firmware
deb-src http://deb.debian.org/debian bookworm main contrib non-free 
non-free-firmware

deb http://deb.debian.org/debian-security/ bookworm-security main contrib 
non-free non-free-firmware
deb-src http://deb.debian.org/debian-security/ bookworm-security main contrib 
non-free non-free-firmware

deb http://deb.debian.org/debian bookworm-updates main contrib non-free 
non-free-firmware
deb-src http://deb.debian.org/debian bookworm-updates main contrib non-free 
non-free-firmware

deb http://deb.debian.org/debian bookworm-backports main contrib non-free 
non-free-firmware
deb-src http://deb.debian.org/debian bookworm-backports main contrib non-free 
non-free-firmware

Re: [fixed]Re: startx returns "Xf86EnableIO: failed to enable I/O ports 0000-03ff"

[Max Nikulin]

On 13/09/2024 21:09, Pierre Willaime wrote:
I do not think it was related to non-free-firmware repository (Here is 
my sources.list below)


deb http://deb.debian.org/debian bookworm main contrib non-free 
non-free-firmware


It seems repositories are properly configured. In general however "apt 
policy" (with no package names) is a more reliable way to inspect actual 
configuration.


In bookworm, i915 firmware is in firmware-misc-nonfree, later the 
package has been split into several parts. If everything is working fine 
then it should be installed. update-initramfs, e.g. during installing of 
kernel update, warns if some firmware files are missed. drivers may warn 
concerning firmware issues during boot as well.

Re: OT: Spectacles

[Peter Ehlert]

my personal experience:

On 9/10/24 05:37, debian-u...@howorth.org.uk wrote:

Larry Martell  wrote:

What are these driving glasses? I can no longer drive at night and
would love to know about them.

As well as uncorrected visual faults, such as short-sightedness or
astigmatism, another reason for not being able to drive at night is
cataracts. If so the [only] solution is to have them removed. Either
way, please visit an optician and trust what they say rather than
random people on the Internet.

I have worn glasses since I was about 13 years old. Now I am 74.
near-sighted and astigmatism

I was darn happy to be able to see super close, especially when I get a 
sliver or thorn.


just take to glasses off, and dig it out. go on with my day.

night vision became a challenge, especially while driving.

about a year ago I went to get new glasses, the optometrist said 
"cataracts" you should see a ophthalmologist.
he made a big deal about the cataracts, and I felt he was just being a 
salesman.

I just got new lenses

So, in a nutshell, my Cataracts had the effect of looking through a 
dirty windshield with dirty glasses.

the new glasses were barely compensating, not good.

July 4, 2024... I went back and had the cataract in my left eye worked on.
WOW! after a few days I was seeing better then I could remember ever.

one week later I had the cataract in my right eye corrected.
that eye took longer to heal, but it is super.

NOW: I must use reading glasses for close stuff, like a thorn. Computer 
screen I can manage, cellphone too, but much better with readers. Dime 
store readers suffice, but the professional built are better, they 
correct for the astigmatism also.

Night driving, no problem at all.

I see more stars at night than I ever could.
Bonus: colors. apparently I had lost some color vision... now I see more 
tones. sweet!


= don't hesitate to get checked out. Ask around for references.

Re: Disk drive zero-fill benchmarks for various synchronization methods and block sizes

[tomas]

On Fri, Sep 13, 2024 at 03:00:14PM +0300, Anssi Saari wrote:
> David Wright  writes:
> 
> > On Tue 10 Sep 2024 at 11:56:25 (+0300), Anssi Saari wrote:
> 
> >> Why do you think that? Which part of the fsync manpage explicitly covers
> >> fsync's effect on device files? Share share, it's fair.
> 
> >  “fsync() transfers ("flushes") all modified in-core data of (i.e.,
> >   modified buffer cache pages for) the file referred to by the file
> >   descriptor fd to the disk device (or other permanent storage device)
> >   so that all changed information can be retrieved even after the
> >   system crashed or was rebooted. This includes writing through or
> >   flushing a disk cache if present. The call blocks until the device
> >   reports that the transfer has completed. It also flushes metadata
> >   information associated with the file (see stat(2)).”
> 
> You just parroted a man page I had already read. Why did you think
> that'd be helpful? I asked the questions because the man page didn't
> answer my questions.  As you are apparemntly unable [...]

Please, Anssi. You can do better than that.

> [...] I found for example
> https://unix.stackexchange.com/questions/473854/block-device-cache-v-s-a-filesystem
> and so arrived to the conclusion that the final close(2) call on a block
> device already flushes all buffers before returning. So the answer to
> the question "is running sync needed after dd to block device" is
> no. Someone else posted that too on this list recently, in another
> thread.

So I did an (admittedly very rough) experiment, and this seems to confirm the
above:

  tomas@caliban:~$ time sudo dd if=/dev/zero of=/dev/sdb bs=1M ; time sync
  dd: error writing '/dev/sdb': No space left on device
  15268+0 records in
  15267+0 records out
  16008609792 bytes (16 GB, 15 GiB) copied, 3614.25 s, 4.4 MB/s
  
  real60m14.260s
  user0m0.005s
  sys 0m0.007s
  
  real0m0.077s
  user0m0.002s
  sys 0m0.000s

I interpret that this way: after 16G of dd (the stick is 16G) there isn't
a significant amount of buffers lying around waiting to be flushed to the
stick (it's a slow USB, as suggested by the 60m the dd took, so if there
were a lot of buffers, we'd see more than .077 sec for the sync).

The box has plenty of RAM (16G) for what it's doing (14G free), so there
is no particular memory pressure which would favour quick flushing of
buffers.

So yes, it seems when the dd is done, it's done.

Cheers
-- 
t 


signature.asc
Description: PGP signature

Re: Disk drive zero-fill benchmarks for various synchronization methods and block sizes

[Jeffrey Walton]

On Fri, Sep 13, 2024 at 8:00 AM Anssi Saari
 wrote:
>
> David Wright  writes:
>
> > On Tue 10 Sep 2024 at 11:56:25 (+0300), Anssi Saari wrote:
>
> >> Why do you think that? Which part of the fsync manpage explicitly covers
> >> fsync's effect on device files? Share share, it's fair.
>
> >  “fsync() transfers ("flushes") all modified in-core data of (i.e.,
> >   modified buffer cache pages for) the file referred to by the file
> >   descriptor fd to the disk device (or other permanent storage device)
> >   so that all changed information can be retrieved even after the
> >   system crashed or was rebooted. This includes writing through or
> >   flushing a disk cache if present. The call blocks until the device
> >   reports that the transfer has completed. It also flushes metadata
> >   information associated with the file (see stat(2)).”

> You just parroted a man page I had already read. Why did you think
> that'd be helpful? I asked the questions because the man page didn't
> answer my questions. As you are apparemntly unable I found for example
> https://unix.stackexchange.com/questions/473854/block-device-cache-v-s-a-filesystem
> and so arrived to the conclusion that the final close(2) call on a block
> device already flushes all buffers before returning. So the answer to
> the question "is running sync needed after dd to block device" is
> no. Someone else posted that too on this list recently, in another
> thread.

To add a datapoint...

My daily driver workstation is really fast with lots of RAM. It has
3.4 GHz cpu and 64 GB of RAM. I also set swappiness to a low value to
avoid spilling out of RAM.

I use a lot of SBC's/dev boards for testing. They usually use a
SDcard. The SDcard is really slow. The card can only provide 10 MB/s
or 30 MB/s write speeds. Some cards I use are so cheap they are even
slower.

If I dd an image from the workstation to the SDcard, it happens in
under a second. dd exits, and closes its file descriptors. Something
is obviously wrong since the image is 1 or 2 GB, and the SDcard write
speed is 10 MB/s or 30 MB/s.

The file system cache is still holding the writes. If I remove the
SDcard and try to use it, the image is corrupt. When I say "remove", I
mean pop the card out of the card reader since the write has
supposedly finished.

What I found is, I have to manually call sync to ensure the image is
written from cache to the SDcard. When I call `dd if=... of=/dev/sdd
&& sync`, the command takes 30 seconds or so to complete. The time is
spent in sync, not dd.

Based on my experience with lots of RAM and slow media, you have to
call sync to get the cache manager to write back to the disk.

Jeff

Re: Disk drive zero-fill benchmarks for various synchronization methods and block sizes

[Rick Thomas]

On Fri, Sep 13, 2024, at 5:00 AM, Anssi Saari wrote:
...
> So the answer to
> the question "is running sync needed after dd to block device" is
> no. Someone else posted that too on this list recently, in another
> thread.

On the other hand, it may not be necessary, but it doesn't do any harm.  If it 
is really unnecessary, it will probably cost only a fraction of a second to do. 
 And if it is actually necessary, you should do it, no matter how long it takes.

Rick

unwanted crontab message

[Marcus Park]

Hi list,

When I run 'crontab -e' the screen shows some errors like,

$ crontab -e
Error detected while processing /usr/share/vim/vim82/filetype.vim:
line   10:
E319: Sorry, the command is not available in this version: let 
did_load_filetypes = 1

line   13:
E319: Sorry, the command is not available in this version: let 
s:cpo_save = &cpo

line   47:
E319: Sorry, the command is not available in this version: func! 
s:StarSetf(ft)

line   51:
E319: Sorry, the command is not available in this version: endfunc
line 2440:
E319: Sorry, the command is not available in this version: func! 
TestFiletypeFuncs(testlist)

line 2441:
E319: Sorry, the command is not available in this version:   let output = ''
line 2442:
E319: Sorry, the command is not available in this version:   for f in 
a:testlist

... (and many other lines)

how to fix up it?

Thanks.

Re: unwanted crontab message

[Greg Wooledge]

On Sat, Sep 14, 2024 at 05:44:42 +0800, Marcus Park wrote:
> Hi list,
> 
> When I run 'crontab -e' the screen shows some errors like,
> 
> $ crontab -e
> Error detected while processing /usr/share/vim/vim82/filetype.vim:
> line   10:
> E319: Sorry, the command is not available in this version: let
> did_load_filetypes = 1

What version of Debian is this?

What version of the vim package (or any similarly named package) are
you running?

Did you do anything *noteworthy* with this system, such as attempting
an upgrade from one version of Debian to another, having it fail, and
leaving it half done?

For the record, Debian 12 has vim 9.0.x and a /usr/share/vim/vim90/
directory.  According to ... oh,
that web page is not responding for me.  Sorry, I can't check what
version(s) of Debian might have had vim 8.2.

Anyway, it sounds like you have vim 8.2 config files, but you're running
an *older* version of vim which can't read those configs.  Either that,
or the /usr/share/vim/vim82/filetype.vim file is corrupted.  If it's
a corrupted file, you could purge and reinstall the vim package(s).

Re: unwanted crontab message

[Andy Smith]

Hi,

On Sat, Sep 14, 2024 at 05:44:42AM +0800, Marcus Park wrote:
> When I run 'crontab -e' the screen shows some errors like,
> 
> $ crontab -e
> Error detected while processing /usr/share/vim/vim82/filetype.vim:

I'm pretty sure that these errors will be coming from the editor
binary that is set in your VISUAL or EDITOR environment variables,
or failing thatm whatever /usr/bin/editor points at.

man crontab

The  -e option is used to edit the current crontab using the
editor specified by the VISUAL or EDITOR environ‐ ment
variables.  After you exit from the editor, the modified crontab
will  be  installed  automatically.   If neither of the
environment variables is defined, then the default editor
/usr/bin/editor is used.

> how to fix up it?

Set EDITOR or VISUAL to an editor that works.

export EDITOR=nano

or whatever you prefer.

As to why whatever it is set as right now is doing that, first work
out where it is getting the setting from, so echo $EDITOR and echo
$VISUAL. If neither of those are set then ls -la /usr/bin/editor.

I'll guess that you have vim-tiny or some other very minimal vi
clone installed but still somehow have vim-runtime installed and
it's trying to use that while not being able to parse it.

So either use a different editor or fix that editor or remove
vim-runtime, I suppose.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: unwanted crontab message

[Marcus Park]

Andy Smith :

As to why whatever it is set as right now is doing that, first work
out where it is getting the setting from, so echo $EDITOR and echo
$VISUAL. If neither of those are set then ls -la /usr/bin/editor.



Thanks Andy.

either $EDITOR or $VISUAL in my system is empty.

And /usr/bin/editor points to nano.

Then I run this command,

$ sudo update-alternatives --config editor
There are 4 choices for the alternative editor (providing /usr/bin/editor).

  SelectionPathPriority   Status

* 0/bin/nano40auto mode
  1/bin/ed -100   manual mode
  2/bin/nano40manual mode
  3/usr/bin/vim.basic   30manual mode
  4/usr/bin/vim.tiny15manual mode

Press  to keep the current choice[*], or type selection number: 3
update-alternatives: using /usr/bin/vim.basic to provide /usr/bin/editor 
(editor) in manual mode




to choose vim.basic as default editor.

In my system both vim.basic and vim are the same stuff,

$ vim --version
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Aug 27 2024 05:34:22)
Included patches: 1-16, 647, 17-579, 1969, 580-647, 678, 648-1848, 4975, 
5016, 5023, 5072, 2068, 1849-1854, 1857, 1855-1857, 1331, 1858, 
1858-1859, 1873, 1860-1969, 1992, 1970-1992, 2010, 1993-2068, 2106, 
2069-2106, 2108, 2107-2109, 2109-3995, 4563, 4646, 4774, 4895, 4899, 
4901, 4919, 213, 1840, 1846-1847, 2110-2112, 2121

...


$ vim.basic --version
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Aug 27 2024 05:34:22)
Included patches: 1-16, 647, 17-579, 1969, 580-647, 678, 648-1848, 4975, 
5016, 5023, 5072, 2068, 1849-1854, 1857, 1855-1857, 1331, 1858, 
1858-1859, 1873, 1860-1969, 1992, 1970-1992, 2010, 1993-2068, 2106, 
2069-2106, 2108, 2107-2109, 2109-3995, 4563, 4646, 4774, 4895, 4899, 
4901, 4919, 213, 1840, 1846-1847, 2110-2112, 2121

...


Then I logged out and re-login the system, run 'crontab -e', the error 
still shows. Maybe I got bad luck today. :(


Regards.

Re: scp in crontab problem

[Marcus Park]

basti:

/usr/bin/scp -i /home/userYX/.ssh/myKEY r...@example.com ...



updated: it's really due to environment issue, after I add the '-i' path 
to scp, jobs run well now.


Thanks basti.

Re: unwanted crontab message

[Andy Smith]

Hi,

On Sat, Sep 14, 2024 at 06:12:02AM +0800, Marcus Park wrote:
> either $EDITOR or $VISUAL in my system is empty.
> 
> And /usr/bin/editor points to nano.

Well, I do not really understand what is going on then as you are
definitely running an editor that looks at vim config files, and
nano won't do that.

I assume you are looking at the environment of the same user that is
executing "crontab -e"?

When the editor from "crontab -e" is running, you could go into
another terminal and look at all your processes to see which actual
binary is being called. IIRC, vim when invoked as vi, acts in vi
compat mode and that may be why it can't parse its own system
config. Although still it is a mystery to me why you do not get
nano.

I just ran crontab -e as a fresh user and it actually invoked
/usr/bin/sensible-editor and asked me which editor I wanted to use
(now and in future). So perhaps the man page for crontab is out of
date. It seems that sensible-editor records this choice in
~/.selected_editor. Is this what got called for you? If so,
apparently running "select-editor" will change the choice.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: unwanted crontab message

[Will Mengarini]

You are getting Vim error messages from a version of Vim that does
not support scripting (probably vim.tiny).  That version is probably
installed on your system ALONG WITH a version that does support
scripting, but cron does not have the scripting version of Vim on PATH.
(Typically, your $HOME & root PATHs are more elaborate than the one to
which cron defaults.)  The solution is to set PATH in your crontab.

* Marcus Park  [24-09/14=Sat 06:12 +0800]:
>
> Andy Smith :
>> As to why whatever it is set as right now is doing that, first work
>> out where it is getting the setting from, so echo $EDITOR and echo
>> $VISUAL. If neither of those are set then ls -la /usr/bin/editor.
>
> Thanks Andy.
>
> either $EDITOR or $VISUAL in my system is empty.
>
> And /usr/bin/editor points to nano.
>
> Then I run this command,
>
> $ sudo update-alternatives --config editor
> There are 4 choices for the alternative editor (providing /usr/bin/editor).
>
>   SelectionPathPriority   Status
> 
> * 0/bin/nano40auto mode
>   1/bin/ed -100   manual mode
>   2/bin/nano40manual mode
>   3/usr/bin/vim.basic   30manual mode
>   4/usr/bin/vim.tiny15manual mode
>
> Press  to keep the current choice[*], or type selection number: 3
> update-alternatives: using /usr/bin/vim.basic to provide /usr/bin/editor
> (editor) in manual mode
>
>
>
> to choose vim.basic as default editor.
>
> In my system both vim.basic and vim are the same stuff,
>
> $ vim --version
> VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Aug 27 2024 05:34:22)
> Included patches: 1-16, 647, 17-579, 1969, 580-647, 678, 648-1848, 4975,
> 5016, 5023, 5072, 2068, 1849-1854, 1857, 1855-1857, 1331, 1858, 1858-1859,
> 1873, 1860-1969, 1992, 1970-1992, 2010, 1993-2068, 2106, 2069-2106, 2108,
> 2107-2109, 2109-3995, 4563, 4646, 4774, 4895, 4899, 4901, 4919, 213, 1840,
> 1846-1847, 2110-2112, 2121
> ...
>
>
> $ vim.basic --version
> VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Aug 27 2024 05:34:22)
> Included patches: 1-16, 647, 17-579, 1969, 580-647, 678, 648-1848, 4975,
> 5016, 5023, 5072, 2068, 1849-1854, 1857, 1855-1857, 1331, 1858, 1858-1859,
> 1873, 1860-1969, 1992, 1970-1992, 2010, 1993-2068, 2106, 2069-2106, 2108,
> 2107-2109, 2109-3995, 4563, 4646, 4774, 4895, 4899, 4901, 4919, 213, 1840,
> 1846-1847, 2110-2112, 2121
> ...
>
>
> Then I logged out and re-login the system, run 'crontab -e', the error still
> shows. Maybe I got bad luck today. :(
>
> Regards.

Re: unwanted crontab message

[Will Mengarini]

Or ... disambiguate which Vim crontab -e is using, so it's not vim.tiny.

* Will Mengarini  [24-09/13=Fri 15:47 -0700]:
> You are getting Vim error messages from a version of Vim that does
> not support scripting (probably vim.tiny).  That version is probably
> installed on your system ALONG WITH a version that does support
> scripting, but cron does not have the scripting version of Vim on PATH.
> (Typically, your $HOME & root PATHs are more elaborate than the one to
> which cron defaults.)  The solution is to set PATH in your crontab.
>
> * Marcus Park  [24-09/14=Sat 06:12 +0800]:
> >
> > Andy Smith :
> >> As to why whatever it is set as right now is doing that, first work
> >> out where it is getting the setting from, so echo $EDITOR and echo
> >> $VISUAL. If neither of those are set then ls -la /usr/bin/editor.
> >
> > Thanks Andy.
> >
> > either $EDITOR or $VISUAL in my system is empty.
> >
> > And /usr/bin/editor points to nano.
> >
> > Then I run this command,
> >
> > $ sudo update-alternatives --config editor
> > There are 4 choices for the alternative editor (providing /usr/bin/editor).
> >
> >   SelectionPathPriority   Status
> > 
> > * 0/bin/nano40auto mode
> >   1/bin/ed -100   manual mode
> >   2/bin/nano40manual mode
> >   3/usr/bin/vim.basic   30manual mode
> >   4/usr/bin/vim.tiny15manual mode
> >
> > Press  to keep the current choice[*], or type selection number: 3
> > update-alternatives: using /usr/bin/vim.basic to provide /usr/bin/editor
> > (editor) in manual mode
> >
> >
> >
> > to choose vim.basic as default editor.
> >
> > In my system both vim.basic and vim are the same stuff,
> >
> > $ vim --version
> > VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Aug 27 2024 05:34:22)
> > Included patches: 1-16, 647, 17-579, 1969, 580-647, 678, 648-1848, 4975,
> > 5016, 5023, 5072, 2068, 1849-1854, 1857, 1855-1857, 1331, 1858, 1858-1859,
> > 1873, 1860-1969, 1992, 1970-1992, 2010, 1993-2068, 2106, 2069-2106, 2108,
> > 2107-2109, 2109-3995, 4563, 4646, 4774, 4895, 4899, 4901, 4919, 213, 1840,
> > 1846-1847, 2110-2112, 2121
> > ...
> >
> >
> > $ vim.basic --version
> > VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Aug 27 2024 05:34:22)
> > Included patches: 1-16, 647, 17-579, 1969, 580-647, 678, 648-1848, 4975,
> > 5016, 5023, 5072, 2068, 1849-1854, 1857, 1855-1857, 1331, 1858, 1858-1859,
> > 1873, 1860-1969, 1992, 1970-1992, 2010, 1993-2068, 2106, 2069-2106, 2108,
> > 2107-2109, 2109-3995, 4563, 4646, 4774, 4895, 4899, 4901, 4919, 213, 1840,
> > 1846-1847, 2110-2112, 2121
> > ...
> >
> >
> > Then I logged out and re-login the system, run 'crontab -e', the error still
> > shows. Maybe I got bad luck today. :(
> >
> > Regards.

Re: Disk drive zero-fill benchmarks for various synchronization methods and block sizes

[David Christensen]

On 9/13/24 12:06, Jeffrey Walton wrote:

To add a datapoint...

My daily driver workstation is really fast with lots of RAM. It has 
3.4 GHz cpu and 64 GB of RAM. I also set swappiness to a low value

to avoid spilling out of RAM.

I use a lot of SBC's/dev boards for testing. They usually use a 
SDcard. The SDcard is really slow. The card can only provide 10 MB/s 
or 30 MB/s write speeds. Some cards I use are so cheap they are even 
slower.


If I dd an image from the workstation to the SDcard, it happens in 
under a second. dd exits, and closes its file descriptors. Something 
is obviously wrong since the image is 1 or 2 GB, and the SDcard write

speed is 10 MB/s or 30 MB/s.

The file system cache is still holding the writes. If I remove the 
SDcard and try to use it, the image is corrupt. When I say "remove",
 I mean pop the card out of the card reader since the write has 
supposedly finished.


What I found is, I have to manually call sync to ensure the image is 
written from cache to the SDcard. When I call `dd if=... of=/dev/sdd 
&& sync`, the command takes 30 seconds or so to complete. The time is

spent in sync, not dd.

Based on my experience with lots of RAM and slow media, you have to 
call sync to get the cache manager to write back to the disk.



That makes me think there is a bug in the secure digital card firmware,
the Linux secure digital card device driver, and/or the Linux file
system driver (?).


Have you seen a dd(1) invocation work correctly on a SD card without any
synchronization options and/or trailing sync(1)?


On 9/13/24 13:57, Rick Thomas wrote:

On the other hand, [running sync after dd] may not be necessary, but
it doesn't do any harm. If it is really unnecessary, it will probably
cost only a fraction of a second to do.  And if it is actually
necessary, you should do it, no matter how long it takes.



+1


David

old kernel appears more stable than latest

[hlyg]

i have installed latest 12.7, after running about 10 hours, it doesn't 
respond to my keyboard pressing, power LED on front panel of pc case 
become red, i have to reboot


i run journalctl, i am not sure if msg below are related to my problem

Sep 13 18:06:54 debian kernel: INFO: task RTW_CMD_THREAD:561 blocked for 
more than 604 seconds.
Sep 13 18:06:54 debian kernel:   Tainted: G C 6.1.0-25-amd64 
#1 Debian 6.1.106-3
Sep 13 18:06:54 debian kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Sep 13 18:06:54 debian kernel: task:RTW_CMD_THREAD  state:D stack:0 
pid:561   ppid:2  flags:0x4000

Sep 13 18:06:54 debian kernel: Call Trace:
Sep 13 18:06:54 debian kernel:  
Sep 13 18:06:54 debian kernel:  __schedule+0x34d/0x9e0
Sep 13 18:06:54 debian kernel:  schedule+0x5a/0xd0
Sep 13 18:06:54 debian kernel:  schedule_timeout+0x118/0x150
Sep 13 18:06:54 debian kernel:  wait_for_completion+0x86/0x160
Sep 13 18:06:54 debian kernel:  ? 
rtw_setassocsta_cmdrsp_callback+0x80/0x80 [r8188eu]

Sep 13 18:06:54 debian kernel:  rtw_cmd_thread+0x3f/0x180 [r8188eu]
Sep 13 18:06:54 debian kernel:  kthread+0xda/0x100
Sep 13 18:06:54 debian kernel:  ? kthread_complete_and_exit+0x20/0x20
Sep 13 18:06:54 debian kernel:  ret_from_fork+0x22/0x30
Sep 13 18:06:54 debian kernel:  

12.5 which use vmlinuz-6.1.0-18-amd64 appears more stable
12.7 use vmlinuz-6.1.0-25-amd64

Re: unwanted crontab message

[Greg Wooledge]

On Fri, Sep 13, 2024 at 22:46:09 +, Andy Smith wrote:
> I just ran crontab -e as a fresh user and it actually invoked
> /usr/bin/sensible-editor and asked me which editor I wanted to use
> (now and in future). So perhaps the man page for crontab is out of
> date.

Agreed.

hobbit:~$ strings /usr/bin/crontab | grep usr/bin/
/usr/bin/sensible-editor

The man page is simply wrong, I think.

[SUMMARY] Re: UEFI multiboot

[Max Nikulin]

Avoid setting non-standard GRUB_DISTRIBUTOR in /etc/default/grub if you 
use Debian 12 bookworm with enabled Secure Boot and signed grub image 
from Debian. Alternatively install grub-2.12 from backports.



On 23/08/2024 11:39, Felix Miata wrote:

I don't know what vexing secure boot might introduce, but without it,
GRUB_DISTRIBUTOR= was used by grub-install in Trixie here to produce
results I expected:


There is significant difference in patches for grub-2.12 in trixie and 
for 2.06 in bookworm. In the case of Secure Boot, grub-install copies 
signed grubx64.efi instead of generation of an image specific to the 
machine.


On 30/08/2024 23:09, Max Nikulin wrote:
I have tried some variants of full shim+grub signed configurations on 

[...]
grubx64.efi (v2.06) from Debian bookworm has no problem with reading 
grub.cfg placed in the same directory and directory name does not matter.


grubx64.efi (v2.06) from Ubuntu 20.04 focal reads config file strictly 
from EFI/ubuntu/grub.cfg.


If there is EFI/debian/grub.cfg then it has higher priority than the 
file from the directory from where grubx64.efi is loaded. Loading config 
file from a custom directory looks like an unintentional behavior.


I have not figured out what specific patch causes the difference. A lot 
of lines are changed. I do not think it is a security measure.


The difference of grub-2.06 behavior between Ubuntu and Debian are 
caused by build script, not by patches. It is a result of an attempt to 
fix issues with Unicode characters. Relevant changes:


grub2 (2.06-14) experimental; urgency=medium

* Bundle unicode.pf2 in a squashfs memdisk attached to the signed EFI binary

 -- Julian Andres Klode   Mon, 19 Jun 2023 17:26:49 +0200

grub2 (2.06-6) unstable; urgency=medium

* Include fonts in the memdisk build for EFI images.
  Closes: #1024395, #1025352, #1024447

 -- Steve McIntyre <93...@debian.org>  Sun, 04 Dec 2022 20:42:23 +

Bookworm currently have 2.06-13 and in 2.06-14 config should be loaded 
strictly from EFI/debian/grub.cfg.


The script written for booting from CD or a similar media

accidentally got bundled into regular images

Since 2.06-14 a dedicated squashfs image has been provided for fonts, so 
the config search script is not a part of prebuilt images.



Perhaps something is broken in attempts to improve booting from network.


I wrote "broken" describing Ubuntu-20.4 behavior where custom 
GRUB_DISTRIBUTOR may cause failure to boot. I consider 2.06 broken in 
Debian now. However patches making it possible in 2.12 are really 
related to network


A one setting fw_path and


They have not been included into the upstream repository. Debian 
changelog entry is


* Port UEFI based network stack to 2.12 (LP: #2039081)


A couple of problems that I have noticed in bookworm:

1. When /usr/lib/shim/BOOTX64.CSV is installed, bootloader id in it is 
not adjusted. As a result if additional removable path EFI/BOOT is used 
then there is a chance that fbx64.efi will create "debian" boot entry, 
not the name specified in GRUB_DISTRIBUTOR


2. It is not apparent that after modifying GRUB_DISTRIBUTOR it is 
necessary to create the directory with matched name in /boot/efi/EFI. 
Otherwise "dpkg-reconfigure grub-efi-amd64" does not run grub-install. I 
would prefer to have an explicit setting instead of relying on presence 
of a directory.


3. EFI/debian/grub.cfg has highest priority, so if bookworm is installed 
in parallel with another Debian then neither must have 
GRUB_DISTRIBUTOR=debian. Moreover grub.cfg likely may be found on some 
other disk (e.g. a USB pendrive) having .disk/info. The version from 
backports should help.


I believed fixed .cfg path is a UEFI 
limitation or at best an inherent grub limitation.


I have realized that shim can not work if it can not load grub from the 
same directory. Perhaps it really happens in some cases.



in Special environment variables

15.1.4 cmdpath
The location from which core.img was loaded as an absolute directory
name (see File name syntax). This is set by GRUB at startup based on
information returned by platform firmware. Not every platform provides
this information and some may return only device without path name.


For EFI platform the required function is implemented (for many other 
platforms it is not), however there are enough code paths when it may 
return without providing a usable value.


At first glance shim really loads files using relative paths while grub 
tries to obtain absolute path. Perhaps some EFI-specific trick may be 
added to grub code to make it mo

Re: [SUMMARY] UEFI multiboot

[Felix Miata]

Max Nikulin composed on 2024-09-14 10:59 (UTC+0700):

> So multiple loaders from the same vendor is tricky in the case of UEFI 
> SecureBoot. Behavior of grub may vary across Linux distributions.

Thus, consider to KISS. Pick one installation's bootloader to depend on. Install
no others.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

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

Felix Miata