Re: [SOLVED] potential bug? - was Re: Problem with cryptsetup-initramfs

[Michel Verdier]

On 2024-07-29, Thomas Schmitt wrote:

>   https://www.debian.org/Bugs/Reporting
>   "Sending the bug report via e-mail"
>   (about 30 lines down the page)
>   "An Example Bug Report"
>   (another 30 lines down the page)

Still the first and recommended way is to use the package reportbug which
do all you describe.

Re: [SOLVED] potential bug? - was Re: Problem with cryptsetup-initramfs

[Thomas Schmitt]

Hi,

Ian Molton wrote:
> Perhaps someone can help me with the bug tracker?

If i have to submit a bug, then i use the e-mail way.
See:

  https://www.debian.org/Bugs/Reporting
  "Sending the bug report via e-mail"
  (about 30 lines down the page)
  "An Example Bug Report"
  (another 30 lines down the page)

The first three lines of the example are real mail headers for your
mail client.  The others lines are mail body text.


In particular i'd do for submitting a bug about xorriso:

- Compose a mail for sub...@bugs.debian.org

- Begin the mail body text by

Package: xorriso

  Maybe after having searched the package name by
  apt-file search ...program.name...

- Next comes the package version header with the version string

Version: 1.5.4-4

  The internet proposes a tangible command line for this:

dpkg -s xorriso | grep '^Version'

- After an empty line comes the bug description text.

  A checklist for information to be included is at
https://www.debian.org/Bugs/Reporting
  under
"Please include in your report:"
  Usually you can provide only a part of this list. Just leave out
  what would stop you from submitting the bug report.

- Read what you wrote and check whether it would be understandable
  for somebody who does not know more about your situation than you
  wrote in the mail body.
  (You may of course assume that the reader is an expert with the
   package in question.)

- Send the mail (as said, to sub...@bugs.debian.org)

- Wait for the acknowledgement mail which will tell you the bug number.

  Since i am upstream of xorriso i never submitted a Debian bug for it.
  Here is the acknowledgement for one of my earliest bug reports:

Date: Fri, 07 Aug 2015 13:03:05 +
From: Debian Bug Tracking System 
Reply-To: 794...@bugs.debian.org
To: Thomas Schmitt 
Subject: Bug#794868: Acknowledgement (dvd+rw-tools: Burn failure of
 growisofs on DVD-R[W] with write type DAO)

- Subscribe to your new bug report (which is behaving like a little
  mailing list).
  Send a mail with arbitrary subject and body text to the bug number's
  subscribe address

794868-subscr...@bugs.debian.org

  Or go to the bug report page
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794868
  and click the "subscribe" link about 10 lines down from the page top.

- If you get replies, send answers to the bug report's own mail address:

794...@bugs.debian.org

  It might be a good idea to Cc: the mail address from where the answer
  came. Just in case it is not subscribed to the bug report.



Have a nice day :)

Thomas

Re: [SOLVED] potential bug? - was Re: Problem with cryptsetup-initramfs

[Michel Verdier]

On 2024-07-28, Ian Molton wrote:

> Perhaps someone can help me with the bug tracker?

Install the package reportbug. It's as easy as writing a mail.

Problem WiFi

[Ian Molton]

I have had some luck with problem WiFi on laptops by setting the acpi_osi 
type to one of various windows types on the kernel command line.


You can add it in /etc/default/grub

Remember to run update-grub after editing it.

Problem WiFi

[Riccardo]

Hello, I have a HP Compaq Presario CQ 60 notebook from 2009, I have this
WiFi problem with any GNU/Linux distro: I have to leave the WiFi always
active, if I turn it off it doesn't turn on anymore, to restart it I have
to restart the notebook.

I currently use Debian Bookworm 12 but in my opinion the problem comes from
the Kernel (6.1.0-23-amd64).

The WiFi card is a Qualcomm Atheros AR242x / AR542x Wireless Network
Adapter (PCI-Express) (rev 01).

Thanks for your attention.

Best regards.

Richard - Turin (Italy)

Re: [SOLVED] potential bug? - was Re: Problem with cryptsetup-initramfs

[Ian Molton]

Hi,

Thanks for your reply,

I'm afraid I've always found the bug tracker a very inaccessible thing. 
Despite having a decent amount of technical knowledge,  I find it 
daunting, and a jarring thing to cope with mentally.


This is why i come to the mailing lists to seek help, but as you note, 
devs do not seem to inhabit/monitor this place, and i would not like this 
bug to be overlooked.


Perhaps someone can help me with the bug tracker?

Long ago, i was part of the LFS community,  which was always a place 
where devs were excellent at interacting with users.


I attended debconf 11, but found it hard to make connections there.

Much of my experience of using / contributing to FOSS projects was in the 
period from 2000-2008, and (to my eyes) it is shocking how, in general, 
FOSS project communities have split into hierarchical Dev/user systems.


I dont think this is a good sign of the times, and to my mind it is 
evidence of a corporate sickness that threatens to destroy FOSS community 
that would have been Microsoft's wet dream back then, and something which 
used to be strongly resisted, not encouraged.


Users are one of the pillars of FOSS. without them, projects wither and 
die, whilst the corporate world subsumes them...


Maybe its just one persons opinion though.  I hope not!

Re: [SOLVED] potential bug? - was Re: Problem with cryptsetup-initramfs

[Jonathan Dowland]

On Fri Jul 26, 2024 at 10:47 AM BST, Nicolas George wrote:
> Now maybe you fix your MUA configuration to not omit “Re: ”.

What would that achieve?

-- 
Please do not CC me for listmail.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Re: [SOLVED] potential bug? - was Re: Problem with cryptsetup-initramfs

[Jonathan Dowland]

I'm glad you've solved your issue. I read your original (very detailed)
mail and I had nothing to contribute with respect to a fix; but I was
interested to follow it, as I rely upon remote decryption of the root
filesystem myself.

>From what you write, I think you are correct that some component
(perhaps cryptroot-initramfs) should be enhanced to handle this
scenario better. I'm not sure of exactly what change would be required,
nor where that change should be made.

There are very few Debian developers monitoring this list. For there to
be any chance at all of this enhancement being made, someone will need
to spend the time to write up a summary and submit it as a bug against
the cryptroot-initramfs package. (perhaps the cryptroot-initramfs
maintainers decide the bug better belongs to another component: bugs can
be re-assigned after filing with ease).

>From there, with luck and a following wind, it may get resolved.


Good luck,

-- 
Please do not CC me for listmail.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Re: [SOLVED] potential bug? - was Re: Problem with cryptsetup-initramfs

[Andy Smith]

Hi,

On Fri, Jul 26, 2024 at 10:35:03AM +0100, Ian Molton wrote:
> Should this be reported somewhere else? Any devs reading this?

Yes, if you think there is a bug it should be reported in
bugs.debian.org. The "reportbug" program may help.

This mailing list is mostly for user support by other users, not for
reporting bugs or getting the attention of package maintainers.
Filing a bug report would have more chance of getting the attention
of the package maintainer.

Thanks,
Andy

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

Re: [SOLVED] potential bug? - was Re: Problem with cryptsetup-initramfs

[Ian Molton]

Really helpful. Thanks for that.

Really makes one feel part of the community.

Re: [SOLVED] potential bug? - was Re: Problem with cryptsetup-initramfs

[Nicolas George]

Ian Molton (12024-07-26):
> Now what?

Now maybe you fix your MUA configuration to not omit “Re: ”.

Regards,

-- 
  Nicolas George

[SOLVED] potential bug? - was Re: Problem with cryptsetup-initramfs

[Ian Molton]

Now what?

Should this be reported somewhere else? Any devs reading this?

[SOLVED] potential bug? - was Re: Problem with cryptsetup-initramfs

[Ian Molton]

Hi all,


I have solved the boot issue. I got physical access to the machine, and 
connected a monitor and keyboard to it.


As usual, it booted the initramfs, and started dropbear, but this time, 
I entered the disk key on the keyboard.


The machine attempted to boot, but failed, dropping back to the 
initramfs prompt - however, crucially, the video console logged a useful 
error - the rootfs could not be mounted (despite mounting just fine, 
without errors, in read write mode, over the ssh connection previously).


I ran a fsck in the initramfs environment, and rebooted it.

The machine booted and I again unlocked it via the (keyboard) console.

This resulted in a clean boot with no untoward errors.

I shut it down, and rebooted, and now it boots successfully even if I 
unlock it via the ssh connection.


I feel like this is a bug in cryptroot-initramfs - surely it would be 
critically important for the aforementioned filesystem error to have 
been logged to the ssh console, rather than it silently failing to boot? 
afterall - it DOES log the errors to the video console.


Or have I been daft and somehow misconfigured it? I don't think I 
deviated from the standard configuration.


Is there a simple way to have errors logged to the console AND to the 
ssh session? Have I been thick?


Thanks,

-Ian


On 24/07/2024 00:14, Ian Molton wrote:

Hi all,

I'm having problems with one of my machines. it's a Pine RockPro64.

Debian bookworm has been running very stably on it for some time. I 
rebooted it a couple of weeks ago for maintainance, having applied 
updates, after 108 days up. I have an encrypted LVM volume, containing 
root, swap, and data LVs, with /boot on a MMC card, and I use 
cryptsetup-initramfs to allow me to log in and unlock the volume at 
boot time, via ssh.


I rebooted it this morning, due to a crash, and it didn't come back up.

I can still connect to dropbear (running in the initramfs context), 
and the MoTD (as always) prompts me to run cryptroot-unlock, which 
appears to do its job (ie. the LVM volume is unlocked / decrypted), 
however it does not proceed to switch root (and drop the ssh 
connection), as it used to, with complete reliability.


At first, I suspected a problem with the rootfs, however this appears 
not to be the issue - the volume is present at the expected location, 
and can be manually mounted.


Executing the following allows me to enter a chroot on the rootfs:

mount -text4 /dev/vg0/root /root
mount --bind /dev /root/dev
mount --bind /proc /root/proc
mount --bind /sys /root/sys
chroot /root /bin/bash --login

and following this I can run:

mount /boot

which correctly mounts the MMC card containing the /boot partition in 
the chrooted environment.


Inspecting /boot, everything appears to be in order. I have issued 
update-initramfs a few times, even completely removing the existing 
initramfs and recreating it.  I have also inspected the initramfs 
built by update-initramfs, and can see nothing out of the ordinary. 
crypttab is copied from the host, and the UUID matches that displayed 
by lsblk -f - which is not surprising given that executing 
cryptroot-unlock does, in fact, decrypt the volume.


Once chrooted, I can see that /sbin/init is a symlink to 
/lib/systemd/systemd, which exists and is executable, but obviously 
cannot be executed as anything other than PID 1. Attempting to execute 
it results in it complaining of a missing argument, or, if one is 
provided, an error that it is ignoring the request due to running in a 
chroot.


The kernel command line (cat /proc/cmdline) contains a correct root= 
entry, which points at /dev/mapper/vg0-root


I'm stumped - I cannot see why the initramfs environment fails to 
mount the rootfs and execute init.


I have run an additional apt update / upgrade / dist-upgrade, whilst 
under chroot, in the hope that it will magically fix everything, but 
to no avail.


I was using a custom dtb that enabled PCIe x4 on the board, but have 
removed that and reverted to the debian-supplied .dtb file just in case.


Any ideas? I have several machines using this configuration, both 
arm64 and amd64, and I'm now a little uneasy about rebooting any of 
them, in case there has been a breaking change somewhere which they, 
too, are likely to fall afoul of.


Any thoughts? I've never really had to debug the init process (ie. 
PID1) and am not sure how to proceed.


Thanks,

-Ian

Re: Problem with cryptsetup-initramfs

[Michel Verdier]

On 2024-07-24, Ian Molton wrote:

> I'm stumped - I cannot see why the initramfs environment fails to mount the
> rootfs and execute init.

You could run with kernel parameter "debug=vc" if you have a console. Else
with "debug" you get logs in /run/initramfs.
Also initramfs uses busybox (if you installed it). Some busybox commands
are slightly different from normal ones. Although I don't see differences
for cryptsetup.

Problem with cryptsetup-initramfs

[Ian Molton]

Hi all,

I'm having problems with one of my machines. it's a Pine RockPro64.

Debian bookworm has been running very stably on it for some time. I 
rebooted it a couple of weeks ago for maintainance, having applied 
updates, after 108 days up. I have an encrypted LVM volume, containing 
root, swap, and data LVs, with /boot on a MMC card, and I use 
cryptsetup-initramfs to allow me to log in and unlock the volume at boot 
time, via ssh.


I rebooted it this morning, due to a crash, and it didn't come back up.

I can still connect to dropbear (running in the initramfs context), and 
the MoTD (as always) prompts me to run cryptroot-unlock, which appears 
to do its job (ie. the LVM volume is unlocked / decrypted), however it 
does not proceed to switch root (and drop the ssh connection), as it 
used to, with complete reliability.


At first, I suspected a problem with the rootfs, however this appears 
not to be the issue - the volume is present at the expected location, 
and can be manually mounted.


Executing the following allows me to enter a chroot on the rootfs:

mount -text4 /dev/vg0/root /root
mount --bind /dev /root/dev
mount --bind /proc /root/proc
mount --bind /sys /root/sys
chroot /root /bin/bash --login

and following this I can run:

mount /boot

which correctly mounts the MMC card containing the /boot partition in 
the chrooted environment.


Inspecting /boot, everything appears to be in order. I have issued 
update-initramfs a few times, even completely removing the existing 
initramfs and recreating it.  I have also inspected the initramfs built 
by update-initramfs, and can see nothing out of the ordinary. crypttab 
is copied from the host, and the UUID matches that displayed by lsblk -f 
- which is not surprising given that executing cryptroot-unlock does, in 
fact, decrypt the volume.


Once chrooted, I can see that /sbin/init is a symlink to 
/lib/systemd/systemd, which exists and is executable, but obviously 
cannot be executed as anything other than PID 1. Attempting to execute 
it results in it complaining of a missing argument, or, if one is 
provided, an error that it is ignoring the request due to running in a 
chroot.


The kernel command line (cat /proc/cmdline) contains a correct root= 
entry, which points at /dev/mapper/vg0-root


I'm stumped - I cannot see why the initramfs environment fails to mount 
the rootfs and execute init.


I have run an additional apt update / upgrade / dist-upgrade, whilst 
under chroot, in the hope that it will magically fix everything, but to 
no avail.


I was using a custom dtb that enabled PCIe x4 on the board, but have 
removed that and reverted to the debian-supplied .dtb file just in case.


Any ideas? I have several machines using this configuration, both arm64 
and amd64, and I'm now a little uneasy about rebooting any of them, in 
case there has been a breaking change somewhere which they, too, are 
likely to fall afoul of.


Any thoughts? I've never really had to debug the init process (ie. PID1) 
and am not sure how to proceed.


Thanks,

-Ian

Re: Kali Linux problem and support question [WAS Re: w4sp-lab]

[Nicholas Geovanis]

On Wed, Jul 17, 2024, 3:10 PM Bret Busby  wrote:

> On 18/7/24 01:43, Andrew M.A. Cater wrote:
> > On Wed, Jul 17, 2024 at 05:52:47PM +0200, Aleix Piulachs wrote:
> >> installing w4sp-lab in Kali-linux-2024.2-installer-everything-amd64.iso
> >> gives me an error when I press w4sp_webapp.py in python module error:
> >> import w4sp and error in module: from w4sp_app import * and I cannot
> change
> >> the w4sp or * how do I do it?
> >
> > Hi Aleix,
> >
> > Please go and read the FAQ that I post almost every month on this list.
> >
> > Kali is _derived_ from Debian and isn't Debian. As such, I'd respectfully
> > suggest that you go and find Kali support elsewhere.
> >
> > Thanks for reading, with every good wish as ever
> >
> > Andrew Cater
> > (amaca...@debian.org)
> >
>
> This exists;
>
> https://www.kali.org/community/
>
> Users of Kali Linux, should peruse that web page.
>
>  From that web page, unfortunately, Kali Linux, like Linux Mint, and
> some of the BSD variants, does not provide an officially supported users
> mailing list, like Debian Linux provides this one, and Ubuntu Linux,
> with its users mailing list.
>

Are you intentionally ignoring the Kali Linux support forum which is hosted
at that same website? And if you want a gateway'd email list and web-based
forum working together, as some sites do (Canonical used to...), wouldn't
the best move be to ask that very same forum about their collective
thoughts?

So, it is up to a user of software that does not have an officially
> supported users' mailing list, to create and administer a users' mailing
> list, like for some other Linux distributions and Thunderbird and
> Firefox, as has happened at groups.io  (https://groups.io -> "Find or
> Create a Group").
>
> And, remember the proverb; "Every journey of a thousand leagues, starts
> with the first step".
>
> ..
> Bret Busby
> Armadale
> West Australia
> (UTC+0800)
> ..
>
>

Re: Kali Linux problem and support question [WAS Re: w4sp-lab]

[Bret Busby]

On 18/7/24 01:43, Andrew M.A. Cater wrote:

On Wed, Jul 17, 2024 at 05:52:47PM +0200, Aleix Piulachs wrote:

installing w4sp-lab in Kali-linux-2024.2-installer-everything-amd64.iso
gives me an error when I press w4sp_webapp.py in python module error:
import w4sp and error in module: from w4sp_app import * and I cannot change
the w4sp or * how do I do it?


Hi Aleix,

Please go and read the FAQ that I post almost every month on this list.

Kali is _derived_ from Debian and isn't Debian. As such, I'd respectfully
suggest that you go and find Kali support elsewhere.

Thanks for reading, with every good wish as ever

Andrew Cater
(amaca...@debian.org)



This exists;

https://www.kali.org/community/

Users of Kali Linux, should peruse that web page.

From that web page, unfortunately, Kali Linux, like Linux Mint, and 
some of the BSD variants, does not provide an officially supported users 
mailing list, like Debian Linux provides this one, and Ubuntu Linux, 
with its users mailing list.


So, it is up to a user of software that does not have an officially 
supported users' mailing list, to create and administer a users' mailing 
list, like for some other Linux distributions and Thunderbird and 
Firefox, as has happened at groups.io  (https://groups.io -> "Find or 
Create a Group").


And, remember the proverb; "Every journey of a thousand leagues, starts 
with the first step".


..
Bret Busby
Armadale
West Australia
(UTC+0800)
..

Kali Linux problem and support question [WAS Re: w4sp-lab]

[Andrew M.A. Cater]

On Wed, Jul 17, 2024 at 05:52:47PM +0200, Aleix Piulachs wrote:
> installing w4sp-lab in Kali-linux-2024.2-installer-everything-amd64.iso
> gives me an error when I press w4sp_webapp.py in python module error:
> import w4sp and error in module: from w4sp_app import * and I cannot change
> the w4sp or * how do I do it?

Hi Aleix,

Please go and read the FAQ that I post almost every month on this list.

Kali is _derived_ from Debian and isn't Debian. As such, I'd respectfully
suggest that you go and find Kali support elsewhere.

Thanks for reading, with every good wish as ever

Andrew Cater
(amaca...@debian.org)

Re: Problem with conda

[Stephen P. Molnar]

On 07/14/2024 08:57 AM, Stephen P. Molnar wrote:



On 07/14/2024 07:15 AM, Stephen P. Molnar wrote:



On 07/14/2024 01:28 AM, Brad Rogers wrote:

On Sat, 13 Jul 2024 15:31:59 -0400
"Stephen P. Molnar"  wrote:

Hello Stephen,


I downloaded a new copy of Miniconda3-latest-Linux-x89_64.s

You say nothing about where you got this from but, assuming it's
https://docs.anaconda.com/miniconda/
your problem may well be that what you downloaded requires Python3.12.4
but Bookworm only has Python3.11.2


Thank you for you response.

I just installed Miniconda3-py310_24.5.0.0-linuus-x86_63.sh and got 
the same result.


Well, I solved the problem (sort of). I installed 
Anaconda3-2023.07-2-Linux-x86_64.sh. This allows the installation of 
new python apps. I can also run some of the apps that I installed 
before Miniconda3 stopped working.


I would still to be able to use Miniconda3.


Now I am really confused!

Earlier today I discovered that, if as soon as I opened a terminal. i 
entered bash the terminal changed from 'comp@AbNormal:-$- bash' to 
'(base)� comp@AbNormal:-$- ' and the color of the prompt changed from 
black to green.


Conda commands work and all of my applications in the conda environment 
work as they should.


--
Stephen P. Molnar, Ph.D.
https://insilicochemistry.net
(614)312-7528 (c)
Skype:  smolnar1

Re: Problem with conda

[Stephen P. Molnar]

On 07/14/2024 07:15 AM, Stephen P. Molnar wrote:



On 07/14/2024 01:28 AM, Brad Rogers wrote:

On Sat, 13 Jul 2024 15:31:59 -0400
"Stephen P. Molnar"  wrote:

Hello Stephen,


I downloaded a new copy of Miniconda3-latest-Linux-x89_64.s

You say nothing about where you got this from but, assuming it's
https://docs.anaconda.com/miniconda/
your problem may well be that what you downloaded requires Python3.12.4
but Bookworm only has Python3.11.2


Thank you for you response.

I just installed Miniconda3-py310_24.5.0.0-linuus-x86_63.sh and got 
the same result.


Well, I solved the problem (sort of). I installed 
Anaconda3-2023.07-2-Linux-x86_64.sh. This allows the installation of new 
python apps. I can also run some of the apps that I installed before 
Miniconda3 stopped working.


I would still to be able to use Miniconda3.

--
Stephen P. Molnar, Ph.D.
https://insilicochemistry.net
(614)312-7528 (c)
Skype:  smolnar1

Re: Problem with conda

[Stephen P. Molnar]

On 07/14/2024 01:28 AM, Brad Rogers wrote:

On Sat, 13 Jul 2024 15:31:59 -0400
"Stephen P. Molnar"  wrote:

Hello Stephen,


I downloaded a new copy of Miniconda3-latest-Linux-x89_64.s

You say nothing about where you got this from but, assuming it's
https://docs.anaconda.com/miniconda/
your problem may well be that what you downloaded requires Python3.12.4
but Bookworm only has Python3.11.2


Thank you for you response.

I just installed Miniconda3-py310_24.5.0.0-linuus-x86_63.sh and got the 
same result.


--
Stephen P. Molnar, Ph.D.
https://insilicochemistry.net
(614)312-7528 (c)
Skype:  smolnar1

Re: Problem with conda

[Brad Rogers]

On Sat, 13 Jul 2024 15:31:59 -0400
"Stephen P. Molnar"  wrote:

Hello Stephen,

>I downloaded a new copy of Miniconda3-latest-Linux-x89_64.s

You say nothing about where you got this from but, assuming it's
https://docs.anaconda.com/miniconda/
your problem may well be that what you downloaded requires Python3.12.4
but Bookworm only has Python3.11.2

-- 
 Regards  _   "Valid sig separator is {dash}{dash}{space}"
 / )  "The blindingly obvious is never immediately apparent"
/ _)rad   "Is it only me that has a working delete key?"
Age of destruction, age of oblivion
Neuromancer - Billy Idol


pgpuhAMmXEncv.pgp
Description: OpenPGP digital signature

Problem with conda

[Stephen P. Molnar]

I am running Bookworm with the bash shell and use  a conda environment 
for some of my Molecular Modeling software. For some reason I can no 
longer activate my conda apps.


I downloaded a new copy of Miniconda3-latest-Linux-x89_64.sh. The 
sha256sum agreed


I deleted the Miniconda3 and .conda directories and installed the new 
download  in /home/comp/Miniconda3 without any warnings or errors and 
accepted automatically initializing of the bash shell.


.Bashrc was amended with:

# >>> conda initialize >>>
# !! Contents within this block are managed by 'conda init' !!
__conda_setup="$('/home/comp/Miniconda3/bin/conda' 'shell.bash' 'hook' 
2> /dev/null)"

if [ $? -eq 0 ]; then
    eval "$__conda_setup"
else
    if [ -f "/home/comp/Miniconda3/etc/profile.d/conda.sh" ]; then
    . "/home/comp/Miniconda3/etc/profile.d/conda.sh"
    else
    export PATH="/home/comp/Miniconda3/bin:$PATH"
    fi
fi
unset __conda_setup
# <<< conda initialize <<<

The 'conda list' command did return a list (see attached)

However when I opened a new terminal it still had  the 
'comp@Abanormal:~$ ' prompt and an attempted to activate an app:


comp@Abanormal:~$ conda activate

I got:

CondaError: Run 'conda init' before 'conda activate'

conda init bash and conda activate in a new terminal seemed to enter a loop.

I am really lost at this point. I've installed Miniconda a number of 
times without any problems.


I would be appreciate of some pointers towards solving this problem.

Thanks in advance

--
Stephen P. Molnar, Ph.D.
https://insilicochemistry.net
(614)312-7528 (c)
Skype:  smolnar1

# packages in environment at /home/comp/Miniconda3:
#
# NameVersion   Build  Channel
_libgcc_mutex 0.1main  
_openmp_mutex 5.1   1_gnu  
anaconda-anon-usage   0.4.4   py312hfc0e8ea_100  
archspec  0.2.3  pyhd3eb1b0_0  
boltons   23.0.0  py312h06a4308_0  
brotli-python 1.0.9   py312h6a678d5_8  
bzip2 1.0.8h5eee18b_6  
c-ares1.19.1   h5eee18b_0  
ca-certificates   2024.3.11h06a4308_0  
certifi   2024.6.2py312h06a4308_0  
cffi  1.16.0  py312h5eee18b_1  
charset-normalizer2.0.4  pyhd3eb1b0_0  
conda 24.5.0  py312h06a4308_0  
conda-content-trust   0.2.0   py312h06a4308_1  
conda-libmamba-solver 24.1.0 pyhd3eb1b0_0  
conda-package-handling2.3.0   py312h06a4308_0  
conda-package-streaming   0.10.0  py312h06a4308_0  
cryptography  42.0.5  py312hdda0065_1  
distro1.9.0   py312h06a4308_0  
expat 2.6.2h6a678d5_0  
fmt   9.1.0hdb19cb5_1  
frozendict2.4.2   py312h06a4308_0  
icu   73.1 h6a678d5_0  
idna  3.7 py312h06a4308_0  
jsonpatch 1.33py312h06a4308_1  
jsonpointer   2.1pyhd3eb1b0_0  
krb5  1.20.1   h143b758_1  
ld_impl_linux-64  2.38 h1181459_1  
libarchive3.6.2h6ac8c49_3  
libcurl   8.7.1h251f7ec_0  
libedit   3.1.20230828 h5eee18b_0  
libev 4.33 h7f8727e_1  
libffi3.4.4h6a678d5_1  
libgcc-ng 11.2.0   h1234567_1  
libgomp   11.2.0   h1234567_1  
libmamba  1.5.8hfe524e5_2  
libmambapy1.5.8   py312h2dafd23_2  
libnghttp21.57.0   h2d74bed_0  
libsolv   0.7.24   he621ea3_1  
libssh2   1.11.0   h251f7ec_0  
libstdcxx-ng  11.2.0   h1234567_1  
libuuid   1.41.5   h5eee18b_0  
libxml2   2.10.4   hfdd30dd_2  
lz4-c 1.9.4h6a678d5_1  
menuinst  2.1.1   py312h06a4308_0  
ncurses   6.4  h6a678d5_0  
openssl   3.0.14   h5eee18b_0  
packaging 23.2py312h06a4308_0  
pcre2 10.42hebb0a14_1  
pip   24.0py312h06a4308_0  
platformdirs  3.10.0  py312h06a4308_0  
pluggy1.0.0   py312h06a4308_1  
pybind11-abi  5hd3eb1b0_0  
p

Re: Strange Problem

[Stephen P. Molnar]

Thank you for the guidance, I really appreciate it.


On 06/29/2024 03:34 PM, David Christensen wrote:

On 6/29/24 10:01, Stephen P. Molnar wrote:



On 06/29/2024 12:28 PM, Darac Marjal wrote:


On 29/06/2024 15:13, Stephen P. Molnar wrote:
I have just restated by Xfce4 user on my Bookworm system and find 
that I can no longer resize some of the apps on the desktop and the 
icons in the upper right corner of the tool bar are missing.


Often, this is an indication that the window manager isn't running. 
For XFCE4, the window manager is called "xfwm4". Try pressing 
"Alt+F2" to bring up the launch dialog, enter "xfwm4" at the prompt 
and press enter.



This is only om my user directory, the root directory is still normal.

Don't run X sessions (read: don't run XFCE) as root.


I have not the faintest idea as to what might be going on and would 
greatly appreciate assistance.


Thanks in advance.


Well, the problem is back. I logged out and back in, and there it was!

I tried "Alt+F2" then "xfwm4" (without the quotes, of course) and got 
nothing.



Please power off your computer.  Then power on your computer. Then 
document every command or value you enter into the computer and every 
response by the computer.  If and when the computer does something 
other than what you expect, document what the computer did and what 
you expected it to do.  Research the proper terminology and use it.  
Then power off, power on, follow your document, and see if the issues 
are repeatable.  Then post your document.



David



--
Stephen P. Molnar, Ph.D.
https://insilicochemistry.net
(614)312-7528 (c)
Skype:  smolnar1

Re: Strange Problem

[David Christensen]

On 6/29/24 10:01, Stephen P. Molnar wrote:



On 06/29/2024 12:28 PM, Darac Marjal wrote:


On 29/06/2024 15:13, Stephen P. Molnar wrote:
I have just restated by Xfce4 user on my Bookworm system and find 
that I can no longer resize some of the apps on the desktop and the 
icons in the upper right corner of the tool bar are missing.


Often, this is an indication that the window manager isn't running. 
For XFCE4, the window manager is called "xfwm4". Try pressing "Alt+F2" 
to bring up the launch dialog, enter "xfwm4" at the prompt and press 
enter.



This is only om my user directory, the root directory is still normal.

Don't run X sessions (read: don't run XFCE) as root.


I have not the faintest idea as to what might be going on and would 
greatly appreciate assistance.


Thanks in advance.


Well, the problem is back. I logged out and back in, and there it was!

I tried "Alt+F2" then "xfwm4" (without the quotes, of course) and got 
nothing.



Please power off your computer.  Then power on your computer.  Then 
document every command or value you enter into the computer and every 
response by the computer.  If and when the computer does something other 
than what you expect, document what the computer did and what you 
expected it to do.  Research the proper terminology and use it.  Then 
power off, power on, follow your document, and see if the issues are 
repeatable.  Then post your document.



David

Re: Strange Problem

[Stephen P. Molnar]

On 06/29/2024 12:28 PM, Darac Marjal wrote:


On 29/06/2024 15:13, Stephen P. Molnar wrote:
I have just restated by Xfce4 user on my Bookworm system and find 
that I can no longer resize some of the apps on the desktop and the 
icons in the upper right corner of the tool bar are missing.


Often, this is an indication that the window manager isn't running. 
For XFCE4, the window manager is called "xfwm4". Try pressing "Alt+F2" 
to bring up the launch dialog, enter "xfwm4" at the prompt and press 
enter.



This is only om my user directory, the root directory is still normal.

Don't run X sessions (read: don't run XFCE) as root.


I have not the faintest idea as to what might be going on and would 
greatly appreciate assistance.


Thanks in advance.


Well, the problem is back. I logged out and back in, and there it was!

I tried "Alt+F2" then "xfwm4" (without the quotes, of course) and got 
nothing.


--
Stephen P. Molnar, Ph.D.
https://insilicochemistry.net
(614)312-7528 (c)
Skype:  smolnar1

Re: Strange Problem

[Darac Marjal]

On 29/06/2024 15:13, Stephen P. Molnar wrote:
I have just restated by Xfce4 user on my Bookworm system and find that 
I can no longer resize some of the apps on the desktop and the icons 
in the upper right corner of the tool bar are missing.


Often, this is an indication that the window manager isn't running. For 
XFCE4, the window manager is called "xfwm4". Try pressing "Alt+F2" to 
bring up the launch dialog, enter "xfwm4" at the prompt and press enter.



This is only om my user directory, the root directory is still normal.

Don't run X sessions (read: don't run XFCE) as root.


I have not the faintest idea as to what might be going on and would 
greatly appreciate assistance.


Thanks in advance.



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Strange Problem

[Stephen P. Molnar]

On 06/29/2024 10:13 AM, Stephen P. Molnar wrote:
I have just restated by Xfce4 user on my Bookworm system and find that 
I can no longer resize some of the apps on the desktop and the icons 
in the upper right corner of the tool bar are missing. This is only om 
my user directory, the root directory is still normal.


I have not the faintest idea as to what might be going on and would 
greatly appreciate assistance.


Thanks in advance.


I don't know what I did, but the problem seems  to be gone.

--
Stephen P. Molnar, Ph.D.
https://insilicochemistry.net
(614)312-7528 (c)
Skype:  smolnar1

Strange Problem

[Stephen P. Molnar]

I have just restated by Xfce4 user on my Bookworm system and find that I 
can no longer resize some of the apps on the desktop and the icons in 
the upper right corner of the tool bar are missing. This is only om my 
user directory, the root directory is still normal.


I have not the faintest idea as to what might be going on and would 
greatly appreciate assistance.


Thanks in advance.

--
Stephen P. Molnar, Ph.D.
https://insilicochemistry.net
(614)312-7528 (c)
Skype:  smolnar1

Re: Bookworm: IBM DSD3300 iSCSI connection problem [solved]

[Greg]

On 6/17/24 11:04, Timothy M Butterworth wrote:



On Sun, Jun 16, 2024 at 3:41 PM Greg <mailto:p...@sojka.co>> wrote:


Hi there,

I'm trying to mount iscsi share exported from old IBM DS3300.
Unfortunately I get the following error:

ping timeout of 5 secs expired, recv timeout 5, last rx
4405941922,<http://voice.google.com/calls?a=nc,%2B14405941922> last
ping 4405943173, now 440598


DS3300 is in "Optimal" state.

Thanks in advance for any help

More info from dmesg:

[444198.925420] scsi 10:0:0:31: Attached scsi generic sg7 type 0
[444209.025722]  connection12:0: ping timeout of 5 secs expired, recv
timeout 5, last rx
4405941922,<http://voice.google.com/calls?a=nc,%2B14405941922> last
ping 4405943173,<http://voice.google.com/calls?a=nc,%2B14405943173>
now 440598<http://voice.google.com/calls?a=nc,%2B1440598>
[444209.025765]  connection12:0: detected conn error (1022)
[444211.083687] sd 10:0:0:0: Power-on or device reset occurred
[444221.313734]  connection12:0: ping timeout of 5 secs expired, recv
timeout 5, last rx 4405944962, last ping 4405946240, now 4405947520
[444221.313780]  connection12:0: detected conn error (1022)
[444223.373262] sd 10:0:0:0: Power-on or device reset occurred
[444233.601772]  connection12:0: ping timeout of 5 secs expired, recv
timeout 5, last rx 4405948034, last ping 4405949312, now 4405950592
[444233.601814]  connection12:0: detected conn error (1022)


According to these errors a ping test is failing. Can you ping and 
traceroute to the DS3300 from the client? It looks like you have a 
connectivity problem. If you recently setup a firewall then you need to 
open ICMP echo-request and echo-reply.


Thanks for the tip. The problem is definitely related to firewall.

Regards
Greg

Re: Bookworm: IBM DSD3300 iSCSI connection problem

[Timothy M Butterworth]

On Sun, Jun 16, 2024 at 3:41 PM Greg  wrote:

> Hi there,
>
> I'm trying to mount iscsi share exported from old IBM DS3300.
> Unfortunately I get the following error:
>
> ping timeout of 5 secs expired, recv timeout 5, last rx 4405941922,
> <http://voice.google.com/calls?a=nc,%2B14405941922> last
> ping 4405943173, now 440598
>


> DS3300 is in "Optimal" state.
>
> Thanks in advance for any help
>
> More info from dmesg:
>
> [444198.925420] scsi 10:0:0:31: Attached scsi generic sg7 type 0
> [444209.025722]  connection12:0: ping timeout of 5 secs expired, recv
> timeout 5, last rx 4405941922,
> <http://voice.google.com/calls?a=nc,%2B14405941922> last ping 4405943173,
> <http://voice.google.com/calls?a=nc,%2B14405943173> now 440598
> <http://voice.google.com/calls?a=nc,%2B1440598>
> [444209.025765]  connection12:0: detected conn error (1022)
> [444211.083687] sd 10:0:0:0: Power-on or device reset occurred
> [444221.313734]  connection12:0: ping timeout of 5 secs expired, recv
> timeout 5, last rx 4405944962, last ping 4405946240, now 4405947520
> [444221.313780]  connection12:0: detected conn error (1022)
> [444223.373262] sd 10:0:0:0: Power-on or device reset occurred
> [444233.601772]  connection12:0: ping timeout of 5 secs expired, recv
> timeout 5, last rx 4405948034, last ping 4405949312, now 4405950592
> [444233.601814]  connection12:0: detected conn error (1022)
>

According to these errors a ping test is failing. Can you ping and
traceroute to the DS3300 from the client? It looks like you have a
connectivity problem. If you recently setup a firewall then you need to
open ICMP echo-request and echo-reply.


> and so on...
> On DS3300 error log I see:
>
> Date/Time: 6/16/24 9:27:04 PM
> Sequence number: 621
> Event type: 180D
> Description: Session terminated unexpectedly
> Event specific codes: 0/0/0
> Event category: Internal
> Component type: iSCSI Initiator
> Component location: iqn.1993-08.org.debian:01:bc2c2e478b92
> Logged by: Controller in slot A
>
> Raw data:
> 4d 45 4c 48 03 00 00 00 6d 02 00 00 00 00 00 00
> 0d 18 49 02 88 3c 6f 66 00 00 00 00 00 00 00 00
> 00 00 00 00 04 00 00 00 19 00 00 00 19 00 00 00
> 26 00 00 00 69 71 6e 2e 31 39 39 33 2d 30 38 2e
> 6f 72 67 2e 64 65 62 69 61 6e 3a 30 31 3a 62 63
> 32 63 32 65 34 37 38 62 39 32 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 01 00 00 00 00 00 00 00 00 00 00 00
>
>  From DS3300 service console:
>
> 06/16/24-19:26:55 (GMT) (IOSched): NOTE:  DDB Changed on port 0
> mbox[0-5] 8014 0001 0038 0021 f 
> 06/16/24-19:26:55 (GMT) (IOSched): NOTE:  QLUtmConnection: Calling UTM
> with initiator ID 0x38 Request 0x2
> 06/16/24-19:26:55 (GMT) (IOSched): NOTE:  CloseConnectionNotification:
> Free connection object for InitiatorId 0x38   pPortal
> 06/16/24-19:26:55 (GMT) (IOSched): NOTE:  QLUpdateInitiatorData: [38]
> Not connected - prev 25
> 06/16/24-19:26:57 (GMT) (IOSched): NOTE:  DDB Changed on port 0
> mbox[0-5] 8014 0001 0039 0023  
> 06/16/24-19:26:57 (GMT) (IOSched): NOTE:  QLUtmConnection: Calling UTM
> with initiator ID 0x39 Request 0x1
> 06/16/24-19:26:57 (GMT) (IOSched): NOTE:  QLUpdateInitiatorData: [39]
> Connected - prev 21
> 06/16/24-19:26:57 (GMT) (IOSched): WARN:  LoginPduContinue:
> ClosingSession (all conns) to allow new login. pSession = 1C25240
> 06/16/24-19:26:57 (GMT) (IOSched): NOTE:  CloseSession:
> Session:0x1c25248, Tsih:0x1d1dbf4  pSessionItn:0x40e872c.
> 06/16/24-19:26:57 (GMT) (IOSched): NOTE:  InstantiateSession:
> 06/16/24-19:26:57 (GMT) (IOSched): NOTE:Session:0x0x1c25248
> 06/16/24-19:26:57 (GMT) (IOSched): NOTE:Initiator
> Name:iqn.1993-08.org.debian:01:bc2c2e478b92
> 06/16/24-19:26:57 (GMT) (IOSched): NOTE:Target
> Name:iqn.1992-01.com.lsi:1535.600a0b8000496dab666d0069
> 06/16/24-19:26:57 (GMT) (IOSched): NOTE:Target Obj:0x0x2fabd1c
> 06/16/24-19:26:57 (GMT) (IOSched): NOTE:  InstantiateSession:
> SES_TYPE_NORMAL, SES_STATE_ACTIVE, SES_TRAN_IN_LOGIN.
> 06/16/24-19:26:57 (GMT) (IOSched): WARN:  AddConnectionToSession: Add
> new connection to this session,
>  Type:2 HostCID:0 TSIH:48 ConnCnt:1 MaxConns:1 MaxConnNeg:0
> pSession:0x1c25248
> 06/16/24-19:26:57 (GMT) (IOSched): NOTE:  LoginPduContinue:
> SES_STATE_LOGGED_IN - normal
> 06/16/24-19:26:57 (GMT) (IOSched): NOTE:
> Initiator = iqn.1993-08.org.debian:01:bc2c2e478b92
> 06/16/24-19:26:57 (GMT) (IOSched): NOTE:
> Target = iqn.1992-01.com.lsi:1535.600a0b8000496dab0009
> 06/16/24-19:26:57 (GMT) (IOSched): NOTE:   CID:
> , SSID: 3dafefe
> 06/16/24-19:26:57 (GMT) (IOSched): NOTE:  LoginPduContinue: eitItn
> allocated 

Bookworm: IBM DSD3300 iSCSI connection problem

[Greg]

Hi there,

I'm trying to mount iscsi share exported from old IBM DS3300. 
Unfortunately I get the following error:


ping timeout of 5 secs expired, recv timeout 5, last rx 4405941922, last 
ping 4405943173, now 440598


DS3300 is in "Optimal" state.

Thanks in advance for any help

More info from dmesg:

[444198.925420] scsi 10:0:0:31: Attached scsi generic sg7 type 0
[444209.025722]  connection12:0: ping timeout of 5 secs expired, recv 
timeout 5, last rx 4405941922, last ping 4405943173, now 440598

[444209.025765]  connection12:0: detected conn error (1022)
[444211.083687] sd 10:0:0:0: Power-on or device reset occurred
[444221.313734]  connection12:0: ping timeout of 5 secs expired, recv 
timeout 5, last rx 4405944962, last ping 4405946240, now 4405947520

[444221.313780]  connection12:0: detected conn error (1022)
[444223.373262] sd 10:0:0:0: Power-on or device reset occurred
[444233.601772]  connection12:0: ping timeout of 5 secs expired, recv 
timeout 5, last rx 4405948034, last ping 4405949312, now 4405950592

[444233.601814]  connection12:0: detected conn error (1022)

and so on...
On DS3300 error log I see:

Date/Time: 6/16/24 9:27:04 PM
Sequence number: 621
Event type: 180D
Description: Session terminated unexpectedly
Event specific codes: 0/0/0
Event category: Internal
Component type: iSCSI Initiator
Component location: iqn.1993-08.org.debian:01:bc2c2e478b92
Logged by: Controller in slot A

Raw data:
4d 45 4c 48 03 00 00 00 6d 02 00 00 00 00 00 00
0d 18 49 02 88 3c 6f 66 00 00 00 00 00 00 00 00
00 00 00 00 04 00 00 00 19 00 00 00 19 00 00 00
26 00 00 00 69 71 6e 2e 31 39 39 33 2d 30 38 2e
6f 72 67 2e 64 65 62 69 61 6e 3a 30 31 3a 62 63
32 63 32 65 34 37 38 62 39 32 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01 00 00 00 00 00 00 00 00 00 00 00

From DS3300 service console:

06/16/24-19:26:55 (GMT) (IOSched): NOTE:  DDB Changed on port 0 
mbox[0-5] 8014 0001 0038 0021 f 
06/16/24-19:26:55 (GMT) (IOSched): NOTE:  QLUtmConnection: Calling UTM 
with initiator ID 0x38 Request 0x2
06/16/24-19:26:55 (GMT) (IOSched): NOTE:  CloseConnectionNotification: 
Free connection object for InitiatorId 0x38   pPortal
06/16/24-19:26:55 (GMT) (IOSched): NOTE:  QLUpdateInitiatorData: [38] 
Not connected - prev 25
06/16/24-19:26:57 (GMT) (IOSched): NOTE:  DDB Changed on port 0 
mbox[0-5] 8014 0001 0039 0023  
06/16/24-19:26:57 (GMT) (IOSched): NOTE:  QLUtmConnection: Calling UTM 
with initiator ID 0x39 Request 0x1
06/16/24-19:26:57 (GMT) (IOSched): NOTE:  QLUpdateInitiatorData: [39] 
Connected - prev 21
06/16/24-19:26:57 (GMT) (IOSched): WARN:  LoginPduContinue: 
ClosingSession (all conns) to allow new login. pSession = 1C25240
06/16/24-19:26:57 (GMT) (IOSched): NOTE:  CloseSession: 
Session:0x1c25248, Tsih:0x1d1dbf4  pSessionItn:0x40e872c.

06/16/24-19:26:57 (GMT) (IOSched): NOTE:  InstantiateSession:
06/16/24-19:26:57 (GMT) (IOSched): NOTE:Session:0x0x1c25248
06/16/24-19:26:57 (GMT) (IOSched): NOTE:Initiator 
Name:iqn.1993-08.org.debian:01:bc2c2e478b92
06/16/24-19:26:57 (GMT) (IOSched): NOTE:Target 
Name:iqn.1992-01.com.lsi:1535.600a0b8000496dab666d0069

06/16/24-19:26:57 (GMT) (IOSched): NOTE:Target Obj:0x0x2fabd1c
06/16/24-19:26:57 (GMT) (IOSched): NOTE:  InstantiateSession: 
SES_TYPE_NORMAL, SES_STATE_ACTIVE, SES_TRAN_IN_LOGIN.
06/16/24-19:26:57 (GMT) (IOSched): WARN:  AddConnectionToSession: Add 
new connection to this session,
Type:2 HostCID:0 TSIH:48 ConnCnt:1 MaxConns:1 MaxConnNeg:0 
pSession:0x1c25248
06/16/24-19:26:57 (GMT) (IOSched): NOTE:  LoginPduContinue: 
SES_STATE_LOGGED_IN - normal
06/16/24-19:26:57 (GMT) (IOSched): NOTE: 
Initiator = iqn.1993-08.org.debian:01:bc2c2e478b92
06/16/24-19:26:57 (GMT) (IOSched): NOTE: 
Target = iqn.1992-01.com.lsi:1535.600a0b8000496dab0009
06/16/24-19:26:57 (GMT) (IOSched): NOTE:   CID: 
, SSID: 3dafefe
06/16/24-19:26:57 (GMT) (IOSched): NOTE:  LoginPduContinue: eitItn 
allocated was 0x40e872c for initiator [39] Session:0x01c20
06/16/24-19:26:57 (GMT) (IOSched): WARN:  DdbSetParms:Session:0x1c25248 
Conn:0x3dafed8 sNegotiated.MaxRecvDataSegmentLength 0
06/16/24-19:26:57 (GMT) (setAliasAltTask): NOTE:  snrAliasAltTask: 
IconSendInfeasibleException Error
06/16/24-19:26:57 (GMT) (IOSched): NOTE:  DDB Changed on port 0 
mbox[0-5] 8014 0001 0039 0025  
06/16/24-19:26:57 (GMT) (IOSched): NOTE:  QLUpdateInitiatorData: [39] 
Logged In.

Re: Quickemu Problem

[Florent Rougon]

Le 19/05/2024, Timothy M Butterworth  a écrit:

> sudo sync && sh -c "/usr/bin/echo 1 > /proc/sys/vm/drop_caches"

--w--- 1 root root 0 19 mai   13:11 /proc/sys/vm/drop_caches

The redirection won't work unless the person is already root—there was a
thread about this here just a few days ago. :-)

Regards

-- 
Florent

Re: Quickemu Problem

[Timothy M Butterworth]

On Sat, May 18, 2024 at 5:53 PM Stephen P. Molnar 
wrote:

> I have just installed installed Quickemu v-6.1.4.
>
>  quickget windows 11 ran as it should without any errors or warnings.
>  However:
>  (base) comp@Abanormal:~/VM$ quickemu --vm windows-10.conf
>  ~/VM ~/VM
>  Quickemu 4.9.4 using /usr/bin/qemu-system-x86_64 v7.2.9
>   - Host: Debian GNU/Linux 12 (bookworm) running Linux 6.1
> (Abanormal)
>   - CPU:  AMD FX(tm)-8320 Eight-Core Processor
>   - CPU VM:   1 Socket(s), 2 Core(s), 2 Thread(s), 4G RAM
>  ERROR! You have insufficient RAM to run windows in a VM
>  (base) comp@Abanormal:~/VM$
>
> I am somewhat confused as:
>
>  (base) comp@Abanormal:~$ free -ght
> totalusedfree  shared
> buff/cache   available
>  Mem:   7.7Gi   2.3Gi   225Mi 34Mi
> 5.4Gi   5.3Gi
>  Swap:  975Mi50Mi   925Mi
>   Total: 8.6Gi   2.4Gi   1.1Gi
>

All your RAM is being used as buffer/cache. Run the following command to
free up ram:

sudo sync && sh -c "/usr/bin/echo 1 > /proc/sys/vm/drop_caches"


> The strange thing is that I have installed Windows 10 using QEMU/KVM
> virt-manager without any RAM problems at all.
>
> Some guidance would be appreciated.
>
> Thanks in advance.
>
> --
> Stephen P. Molnar, Ph.D.
> https://insilicochemistry.net
> (614)312-7528 (c)
> Skype:  smolnar1
>
>

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

Re: Quickemu Problem with amount of RAM

[Geert Stappers]

On Sat, May 18, 2024 at 11:56:06AM -0400, Stephen P. Molnar wrote:
> I have just installed installed Quickemu v-6.1.4.
> 
>     quickget windows 11 ran as it should without any errors or warnings.
>     However:
>         (base) comp@Abanormal:~/VM$ quickemu --vm windows-10.conf
>     ~/VM ~/VM
>     Quickemu 4.9.4 using /usr/bin/qemu-system-x86_64 v7.2.9
>  - Host: Debian GNU/Linux 12 (bookworm) running Linux 6.1 (Abanormal)
>  - CPU:  AMD FX(tm)-8320 Eight-Core Processor
>  - CPU VM:   1 Socket(s), 2 Core(s), 2 Thread(s), 4G RAM
>     ERROR! You have insufficient RAM to run windows in a VM
>     (base) comp@Abanormal:~/VM$
> 
> I am somewhat confused as:
> 
>     (base) comp@Abanormal:~$ free -ght
>        total    used free    shared  buff/cache   available
>         Mem:   7.7Gi   2.3Gi    225Mi  34Mi   5.4Gi   5.3Gi
>         Swap:  975Mi    50Mi    925Mi
>     Total: 8.6Gi   2.4Gi    1.1Gi
> 
> The strange thing is that I have installed Windows 10 using QEMU/KVM
> virt-manager without any RAM problems at all.

I say: "without any **noted** RAM problems at all"
 

> Some guidance would be appreciated.

My guess is: 4Gb in the guest, requires much more 4Gb on the host.

 
> Thanks in advance.

Thank the mailinglist by sharing how you got beyond the hurdle.


Groeten
Geert Stappers
-- 
Silence is hard to parse

Quickemu Problem

[Stephen P. Molnar]

I have just installed installed Quickemu v-6.1.4.

    quickget windows 11 ran as it should without any errors or warnings.
    However:
        (base) comp@Abanormal:~/VM$ quickemu --vm windows-10.conf
    ~/VM ~/VM
    Quickemu 4.9.4 using /usr/bin/qemu-system-x86_64 v7.2.9
 - Host: Debian GNU/Linux 12 (bookworm) running Linux 6.1 
(Abanormal)

 - CPU:  AMD FX(tm)-8320 Eight-Core Processor
 - CPU VM:   1 Socket(s), 2 Core(s), 2 Thread(s), 4G RAM
    ERROR! You have insufficient RAM to run windows in a VM
    (base) comp@Abanormal:~/VM$

I am somewhat confused as:

    (base) comp@Abanormal:~$ free -ght
       total    used    free  shared 
buff/cache   available
        Mem:   7.7Gi   2.3Gi   225Mi 34Mi   
5.4Gi   5.3Gi

        Swap:  975Mi    50Mi   925Mi
 Total: 8.6Gi   2.4Gi   1.1Gi

The strange thing is that I have installed Windows 10 using QEMU/KVM 
virt-manager without any RAM problems at all.


Some guidance would be appreciated.

Thanks in advance.

--
Stephen P. Molnar, Ph.D.
https://insilicochemistry.net
(614)312-7528 (c)
Skype:  smolnar1

Re: Kvm Bridge Network Problem

[Geert Stappers]

On Tue, May 07, 2024 at 02:17:05AM +0100, Gareth Evans wrote:
> On Tue 07/05/2024 at 01:51, Gareth Evans wrote:
> 
> I did miss a step.  
> 
> > Start VM, check DHCP address assigned
> 
> should be
> 
> > Edit the VM NIC settings and choose your routed network connection from the 
> > "Network Source" dropdown. Apply changes.
> 
> > Start VM, check DHCP address assigned
> 
> I actually deleted other vibrX devices and networks before starting, but I 
> don't think that matters.
> 
> G

For the sake of the archive: Place _all_ steps in one email.
Preferable in reply to the original posting.
 

Groeten
Geert Stappers
-- 
Silence is hard to parse

Re: Kvm Bridge Network Problem

[Gareth Evans]

On Tue 07/05/2024 at 01:51, Gareth Evans  wrote:

I did miss a step.  

> Start VM, check DHCP address assigned

should be

> Edit the VM NIC settings and choose your routed network connection from the 
> "Network Source" dropdown. Apply changes.

> Start VM, check DHCP address assigned

I actually deleted other vibrX devices and networks before starting, but I 
don't think that matters.

G

Re: Kvm Bridge Network Problem

[Gareth Evans]

On host:

$ ip a|grep wl
3: wlp1s0:  mtu 1500 qdisc noqueue state UP 
group default qlen 1000
inet 192.168.1.100/24 ...

Using:

virt-manager > Edit > Connection Details > Virtual Networks > Add network 

Mode: Routed
Network: 192.168.200.0/24
Accept default DHCP range
Forward to: physical device
Device: wlp1s0 [this is my physical wifi card]

Then:

$ sudo sysctl -w net.ipv4.ip_forward=1

Then check:

$ ip link

6: virbr0:  mtu 1500 qdisc noqueue state UP 
mode DEFAULT group default qlen 1000
link/ether 52:54:00:54:ed:48 brd ff:ff:ff:ff:ff:ff
7: vnet0:  mtu 1500 qdisc noqueue master 
virbr0 state UNKNOWN mode DEFAULT group default qlen 1000
link/ether fe:54:00:9b:a7:8e brd ff:ff:ff:ff:ff:ff

Start VM, check DHCP address assigned

On VM guest:

$ ip a|grep enp
2: enp1s0:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
inet 192.168.200.151/24 ...

At this point (with firewalls temporarily off) I was able to ssh to and from 
host and VM guest using their respective IP addresses.

After adding a static route on my wireless router:

192.168.200.0/24 via 192.168.1.100  (to paraphrase the web form)

I installed apache2 on the VM guest and was able to access

http://192.168.200.151

from my phone over wifi, and websites on the host from the VM guest.

Firewalld actived on host with ssh and https services allowed - ssh and web 
browsing worked as before.

No nf/iptables jiggery-pokery, but static route on router required.

Perhaps not the most efficient solution, but I try to avoid too many firewall 
rules because they make my head spin :)

Don't think I've omitted any steps.

Does that help?

Best wishes,
Gareth

Re: Kvm Bridge Network Problem

[Gareth Evans]

On Sun 05/05/2024 at 07:53, Gareth Evans  wrote:

> That might suggest NAT is still operative for the VM.

Ah, I hadn't seen Geert's reply, which I think is closer to the mark :)

This gives a routing-based approach:

https://www.linux-kvm.org/page/Networking

This creates an isolated network between host and guest, which without routing 
presumably is additional to the default network, and the (Ubuntu-based) netplan 
stuff needs substituting with /e/n/i adjustments:

https://www.nodinrogers.com/post/2022-01-06-enabling-kvm-host-to-vm-communcation/

All of which I have yet to test but have been meaning to look into this again.

HTH

Re: Kvm Bridge Network Problem

[Gareth Evans]

On Sat 04/05/2024 at 21:26, Stephen P. Molnar  wrote:
> ... 
> I have managed to follow the 
> instructions in:
>
> https://www.cyberciti.biz/faq/how-to-add-network-bridge-with-nmcli-networkmanager-on-linux/
>  
> ...
> I was able to use the LAN 
> printer and the 40" TV , but could not access the Host.

Hi Stephen,

That might suggest NAT is still operative for the VM.

Did you do the "optional" part of the tutorial in your link too, re KVM network 
config?

What is the output of

# nmcli con show

# nmcli device

# virsh net-list --all

# virsh net-dumpxml yourNetworkName

I don't have a network cable to hand to test this at the moment (wifi NIC 
bridging is complex if possible with KVM [1] and apples and oranges and all 
that) but will do later if your problem is not solved.

I think the presence of enp2s0 in /e/n/i (which your attachment seems to be) 
prevents NM from managing it, but if I'm wrong about that, could it be getting 
an address (static or otherwise) from NM?

Gareth

[1] https://hacktivate.it/posts/kvm-bridge-wireless/

Re: Kvm Bridge Network Problem, VM accessing the host

[Geert Stappers]

On Sat, May 04, 2024 at 04:26:07PM -0400, Stephen P. Molnar wrote:
> I am running Bookworm on my main platform. After quite a bit of googling and
> many errors and much head scratching I have managed to follow the
> instructions in:
> 
> https://www.cyberciti.biz/faq/how-to-add-network-bridge-with-nmcli-networkmanager-on-linux/
> .
> 
> I have currently implicated this on a Windows 10 client. However, there
> still remains a problem. After the first restart of the Windows client the
> internet was accessible. However, a problem arose after I successfully
> installed br0 (copy attached). I was able to use the LAN printer and the 40"
> TV , but could not access the Host.

Ah, the VM guest can not access the host.
(I changed 'Subject: Re: Kvm Bridge Network Problem'
into 'Subject: Re: Kvm Bridge Network Problem, VM accessing the host')

 
> I'm sure that I have missed something, but I don't know what.

Network switches only forward packets.

 
> Guidance to a solution to the problem would be appreciated.

I have been where O.P. is, the challenge^Wproblem is real.
 

> # This file describes the network interfaces available on your system
> # and how to activate them. For more information, see interfaces(5).
> 
> source /etc/network/interfaces.d/*
> 
> # The loopback network interface
> auto lo
> iface lo inet loopback
> 
> # Specify that the physical interface that should be connected to the bridge
> # should be configured manually, to avoid conflicts with NetworkManager
> iface enp2s0 inet manual
> 
> #Primary network interface with bridge
> auto br0
> iface br0 inet static
> address 162.237.98.238
> broadcast 162.237.98.255
> netmask 255.255.255.0
> gateway 162.237.98.1
> bridge_ports enp2s0
> bridge_stp off
> bridge_waitport 0
> bridge fd 0


That brigde configuration looks good, even might be good.

The thing is that host and VM are at the same interface of the network
switch. And network switches only forward packets. It is a "physical
law" in computer networking. Hopefully brings this email thread
the jargon name of the "problem".


If direct connection between host and the VM guest is important,
then add such connection and take the costs it brings.


Groeten
Geert Stappers
-- 
Silence is hard to parse

Kvm Bridge Network Problem

[Stephen P. Molnar]

I am running Bookworm on my main platform. After quite a bit of googling 
and many errors and much head scratching I have managed to follow the 
instructions in:


https://www.cyberciti.biz/faq/how-to-add-network-bridge-with-nmcli-networkmanager-on-linux/ 
.


I have currently implicated this on a Windows 10 client. However, there 
still remains a problem. After the first restart of the Windows client 
the internet was accessible. However, a problem arose after I 
successfully installed br0 (copy attached). I was able to use the LAN 
printer and the 40" TV , but could not access the Host.


I'm sure that I have missed something, but I don't know what.

Guidance to a solution to the problem would be appreciated.

Thanks in advance,

--
Stephen P. Molnar, Ph.D.
https://insilicochemistry.net
(614)312-7528 (c)
Skype:  smolnar1

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# Specify that the physical interface that should be connected to the bridge
# should be configured manually, to avoid conflicts with NetworkManager
iface enp2s0 inet manual

#Primary network interface with bridge
auto br0
iface br0 inet static
address 162.237.98.238
broadcast 162.237.98.255
netmask 255.255.255.0
gateway 162.237.98.1
bridge_ports enp2s0
bridge_stp off
bridge_waitport 0
bridge fd 0

Re: QEMU/KVM virt-manager Problem

[Gareth Evans]

On Thu 02/05/2024 at 20:14, Gareth Evans  wrote:
> On Thu 02/05/2024 at 19:57, Stephen P. Molnar  wrote:
>> On 05/02/2024 12:54 PM, Gareth Evans wrote:
>>>
>>>
>>>> On 2 May 2024, at 17:47, Gareth Evans  wrote:
>>>>
>>>> 
>>>>
>>>>> On 2 May 2024, at 15:43, Stephen P. Molnar  
>>>>> wrote:
>>>>>
>>>>> I am running Bookworm and have implemented QEMU/KVM virt-manager. 
>>>>> When I install a client I have been using virt-manager --> View 
>>>>> -->Scale Display --> Always. However, now the 'Always ', the only 
>>>>> option available is the default 'Only when Fullscreen'.
>>>>
>>>> Is Bookworm the VM client too?  With GUI?  Does this happen for all 
>>>> clients, just one, or one type?
>>>>
>>>> Off the top of my head, I think the scale always option may disappear 
>>>> if the guest display doesn't support it - I seem to recall VirtualBox 
>>>> Guest Additions being required for this functionality for some guests 
>>>> in VirtualBox (which I acknowledge you are not using, I'm just 
>>>> saying...) so I don't think it's "straightforward" functionality
>>>
>>> What video protocol are you using?
>>>
>>> spice-vdagent is mentioned here a few comments down
>>>
>>> https://forum.manjaro.org/t/virt-manager-scale-display-not-working/138275/3
>> I am using the procedure in 
>> https://getlabsdone.com/install-windows-10-on-ubuntu-kvm/
>>
>> I am most interested in installing Windows 10, as there computation 
>> chemistry windows apps that I want to use on Bookworm. However, the same 
>> problem is resent for Linux clients that I've installed.
>
> In 
>
> virt-manager > Edit > Preferences > [console tab]
>
> I see options for
>
> Graphical console scaling [ Never / Fullscreen only / Always]
> Resize guest with window [System default / Off / On]
>
> This looks like it might just set defaults for options accessible from 
> the VM view menu, but perhaps worth experimenting with?
>
> The only Linux VM I have in virt-manager used the spice display manager 
> by default.
>
> If you are using spice too, this
>
> https://stackoverflow.com/questions/41990600/virt-manager-guest-resize-not-working
>
> suggests spice-guest-tools is required for Windows clients, with link 
> to download page
>
> Does any of that help?
>
> Best wishes
> Gareth

Just noticed the link you provided includes a ref to spice-guest-tools.

With an Alpine client (and no "tools") I get less than optimal scaling from 
virt-manager - some black space at the horizontal edges, but there is a scaling 
of sorts going on, just not entirely using the available window space.

Are you using the stock version of virt-manager?

$ apt policy virt-manager
virt-manager:
  Installed: 1:4.1.0-2

Re: QEMU/KVM virt-manager Problem

[Gareth Evans]

On Thu 02/05/2024 at 19:57, Stephen P. Molnar  wrote:
> On 05/02/2024 12:54 PM, Gareth Evans wrote:
>>
>>
>>> On 2 May 2024, at 17:47, Gareth Evans  wrote:
>>>
>>> 
>>>
>>>> On 2 May 2024, at 15:43, Stephen P. Molnar  
>>>> wrote:
>>>>
>>>> I am running Bookworm and have implemented QEMU/KVM virt-manager. 
>>>> When I install a client I have been using virt-manager --> View 
>>>> -->Scale Display --> Always. However, now the 'Always ', the only 
>>>> option available is the default 'Only when Fullscreen'.
>>>
>>> Is Bookworm the VM client too?  With GUI?  Does this happen for all 
>>> clients, just one, or one type?
>>>
>>> Off the top of my head, I think the scale always option may disappear 
>>> if the guest display doesn't support it - I seem to recall VirtualBox 
>>> Guest Additions being required for this functionality for some guests 
>>> in VirtualBox (which I acknowledge you are not using, I'm just 
>>> saying...) so I don't think it's "straightforward" functionality
>>
>> What video protocol are you using?
>>
>> spice-vdagent is mentioned here a few comments down
>>
>> https://forum.manjaro.org/t/virt-manager-scale-display-not-working/138275/3
> I am using the procedure in 
> https://getlabsdone.com/install-windows-10-on-ubuntu-kvm/
>
> I am most interested in installing Windows 10, as there computation 
> chemistry windows apps that I want to use on Bookworm. However, the same 
> problem is resent for Linux clients that I've installed.

In 

virt-manager > Edit > Preferences > [console tab]

I see options for

Graphical console scaling [ Never / Fullscreen only / Always]
Resize guest with window [System default / Off / On]

This looks like it might just set defaults for options accessible from the VM 
view menu, but perhaps worth experimenting with?

The only Linux VM I have in virt-manager used the spice display manager by 
default.

If you are using spice too, this

https://stackoverflow.com/questions/41990600/virt-manager-guest-resize-not-working

suggests spice-guest-tools is required for Windows clients, with link to 
download page

Does any of that help?

Best wishes
Gareth

Re: QEMU/KVM virt-manager Problem

[Stephen P. Molnar]

On 05/02/2024 12:54 PM, Gareth Evans wrote:




On 2 May 2024, at 17:47, Gareth Evans  wrote:



On 2 May 2024, at 15:43, Stephen P. Molnar  
wrote:


I am running Bookworm and have implemented QEMU/KVM virt-manager. 
When I install a client I have been using virt-manager --> View 
-->Scale Display --> Always. However, now the 'Always ', the only 
option available is the default 'Only when Fullscreen'.


Is Bookworm the VM client too?  With GUI?  Does this happen for all 
clients, just one, or one type?


Off the top of my head, I think the scale always option may disappear 
if the guest display doesn't support it - I seem to recall VirtualBox 
Guest Additions being required for this functionality for some guests 
in VirtualBox (which I acknowledge you are not using, I'm just 
saying...) so I don't think it's "straightforward" functionality


What video protocol are you using?

spice-vdagent is mentioned here a few comments down

https://forum.manjaro.org/t/virt-manager-scale-display-not-working/138275/3
I am using the procedure in 
https://getlabsdone.com/install-windows-10-on-ubuntu-kvm/


I am most interested in installing Windows 10, as there computation 
chemistry windows apps that I want to use on Bookworm. However, the same 
problem is resent for Linux clients that I've installed.


--
Stephen P. Molnar, Ph.D.
https://insilicochemistry.net
(614)312-7528 (c)
Skype:  smolnar1

Re: QEMU/KVM virt-manager Problem

[Gareth Evans]

> On 2 May 2024, at 17:47, Gareth Evans  wrote:
> 
> 
> 
>> On 2 May 2024, at 15:43, Stephen P. Molnar  wrote:
>> 
>> I am running Bookworm and have implemented QEMU/KVM virt-manager. When I 
>> install a client I have been using virt-manager --> View -->Scale Display 
>> --> Always. However, now the 'Always ', the only option available is the 
>> default 'Only when Fullscreen'.
> 
> Is Bookworm the VM client too?  With GUI?  Does this happen for all clients, 
> just one, or one type?
> 
> Off the top of my head, I think the scale always option may disappear if the 
> guest display doesn't support it - I seem to recall VirtualBox Guest 
> Additions being required for this functionality for some guests in VirtualBox 
> (which I acknowledge you are not using, I'm just saying...) so I don't think 
> it's "straightforward" functionality

What video protocol are you using?

spice-vdagent is mentioned here a few comments down

https://forum.manjaro.org/t/virt-manager-scale-display-not-working/138275/3

Re: QEMU/KVM virt-manager Problem

[Gareth Evans]

> On 2 May 2024, at 15:43, Stephen P. Molnar  wrote:
> 
> I am running Bookworm and have implemented QEMU/KVM virt-manager. When I 
> install a client I have been using virt-manager --> View -->Scale Display --> 
> Always. However, now the 'Always ', the only option available is the default 
> 'Only when Fullscreen'.

Is Bookworm the VM client too?  With GUI?  Does this happen for all clients, 
just one, or one type?

Off the top of my head, I think the scale always option may disappear if the 
guest display doesn't support it - I seem to recall VirtualBox Guest Additions 
being required for this functionality for some guests in VirtualBox (which I 
acknowledge you are not using, I'm just saying...) so I don't think it's 
"straightforward" functionality

Re: QEMU/KVM virt-manager Problem

[Curt]

On 2024-05-02, Stephen P. Molnar  wrote:
> I am running Bookworm and have implemented QEMU/KVM virt-manager. When I 
> install a client I have been using virt-manager --> View -->Scale 
> Display --> Always. However, now the 'Always ', the only option 
> available is the default 'Only when Fullscreen'.
>
> Now this in not exactly a major problem, but it makes me wonder what 
> else might be going wrong?
>
> I would appreciate some guidance in this matter.
>
> Thanks in advance.
>

>
> Thanks in advance.


https://askubuntu.com/questions/43861/how-do-i-unmaximize-full-screen-view-in-virt-manager


A variety of answers to the fullscreeen conundrum, some of which are rather
recent if you scroll downward sufficiently.

QEMU/KVM virt-manager Problem

[Stephen P. Molnar]

I am running Bookworm and have implemented QEMU/KVM virt-manager. When I 
install a client I have been using virt-manager --> View -->Scale 
Display --> Always. However, now the 'Always ', the only option 
available is the default 'Only when Fullscreen'.


Now this in not exactly a major problem, but it makes me wonder what 
else might be going wrong?


I would appreciate some guidance in this matter.

Thanks in advance.

--
Stephen P. Molnar, Ph.D.
https://insilicochemistry.net
(614)312-7528 (c)
Skype:  smolnar1

Gnome problem occured, system can't recover on testing

[Richard]

Hi,
after a reboot I'm now greeted by a white screen saying

Oh no! Something has gone wrong A problem has occurred and the system can't
recover. Please contact a system administrator.

I can still switch to a different tty, but I can't really tell what the
issue is. The output of journalctl -b --priority 3 is:

kernel: cros_ec_lpcs cros_ec_lpcs.0: EC ID not detected
bluetoothd[894]: profiles/sap/server.c:sap_server_register() Sap driver
initialization failed.
bluetoothd[894]: sap-server: Operation not permitted (1)
bluetoothd[894]: Failed to load LTKs for hci0: Invalid Parameters (0x0d)
systemd[1]: Failed to start firewalld.service - firewalld - dynamic
firewall daemon.
csc_vpnagent[961]: Function: startParser File:
../../vpn/Common/Xml/CVCSaxParser.cpp Line: 171 Invoked Function:
xmlCreateFileParserCtxt Return Code: -33554427 (0xFE05) Description:
GLOBAL_ERROR_NULL_POINTER
csc_vpnagent[961]: Function: LoadSettingsFromXmlFile File:
../../vpn/PhoneHome/PhoneHomeAgent.cpp Line: 626 Invoked Function:
XmlParser::parseFile Return Code: -33554423 (0xFE09) Description:
GLOBAL_ERROR_UNEXPECTED
gnome-session-binary[1447]: Unrecoverable failure in required component
org.gnome.Shell.desktop
kernel: ucsi_acpi USBC000:00: ucsi_handle_connector_change:
GET_CONNECTOR_STATUS failed (-5)
gnome-session-binary[1618]: Unrecoverable failure in required component
org.gnome.Shell.desktop
gnome-session-binary[1618]: Unrecoverable failure in required component
org.gnome.SettingsDaemon.UsbProtection.desktop
kernel: ucsi_acpi USBC000:00: ucsi_handle_connector_change:
GET_CONNECTOR_STATUS failed (-110)
login[2018]: PAM unable to dlopen(pam_lastlog.so):
/usr/lib/security/pam_lastlog.so: cannot open shared object file: No such
file or directory
PAM adding faulty module: pam_lastlog.so

Now, the first line can just be ignored, that's typical. The things that
concern me the most are the last two lines. It already has been reported as
a bug and seems to be in the works, but I haven't seen any inidcation that
this should cause a complete failure. The other reasons I've found for the
Gnome related error message was either trouble with Nvidia - but I don't
have any installed - or outdated firmware. So I've just made double shure
to really have the latest firmware by copying over the 04/2024 archive from
kernel.org with rsync -rc, yet no change (I'm running on a Ryzen 7040, so
the AMD firmware available in the Debian repos is way too old, no matter
which branch).

So what's going on?

Best
Richard

Re: Internet Access Problem

[Max Nikulin]

On 11/04/2024 20:53, Stephen P. Molnar wrote:
I am running Bullseye and attempting to use QEMU/KVM virt-manager, on 
the computers on my LAN rather than Oracle VM VirtualBox.

[...]

However, when I pinged yahoo.com. I got the result:

Reply from 169.234.75.136: Destination host unreachable.


If the VM for some reason is configured with "user" network instead of 
vibr0 then it is expected:


https://wiki.qemu.org/Documentation/Networking

Note - if you are using the (default) SLiRP user networking, then ping
(ICMP) will not work, though TCP and UDP will. Don't try to use ping to
test your QEMU network configuration!


Regular user running VM does not have enough privileges to send ICMP 
packets.

Re: problem with live usb booting

[Eddie]

On 4/11/24 10:14, Greg Wooledge wrote:

On Thu, Apr 11, 2024 at 01:30:46PM +, sarath wrote:

dear debian

I have created live usb with debian-live-12.5.0-amd64-standard.iso using tool 
Ventoy-1.0.95. When tried to booting it is ended with command line options. 
please help me to the next step


It's not clear to me what you mean.  Was there an *error* message?  If so,
what does it say?

If you simply mean "I expected a graphical interface, and instead I got
a text console login prompt", that's because you used the -standard image
which has a minimalist set of packages, equivalent to what you would get
if you installed Debian normally, and un-selected the desktop environment
option, and only left "Standard" selected.

If you want a graphical interface, you'll need a different image.



I agree with Greg - I use Ventoy/debian-live-12.2.0-amd64-xfce.iso and 
it works just fine in the xfce graphical interface. Use the desktop you 
prefer as part of the debian live iso for a graphical install.

Re: problem with live usb booting

[Greg Wooledge]

On Thu, Apr 11, 2024 at 01:30:46PM +, sarath wrote:
> dear debian
> 
> I have created live usb with debian-live-12.5.0-amd64-standard.iso using tool 
> Ventoy-1.0.95. When tried to booting it is ended with command line options. 
> please help me to the next step

It's not clear to me what you mean.  Was there an *error* message?  If so,
what does it say?

If you simply mean "I expected a graphical interface, and instead I got
a text console login prompt", that's because you used the -standard image
which has a minimalist set of packages, equivalent to what you would get
if you installed Debian normally, and un-selected the desktop environment
option, and only left "Standard" selected.

If you want a graphical interface, you'll need a different image.

Re: Internet Access Problem

[Marco Moock]

Am 11.04.2024 um 09:53:30 Uhr schrieb Stephen P. Molnar:

> I followed the How To (HowTo.txt, attached) without any warning or
> error messages. However, when I pinged yahoo.com. I got the result:
> 
> Reply from 169.234.75.136: Destination host unreachable.

You have to specify how your network is being attached to the VM. I
recommend a network bridge to your NIC, so the virtual PC is a normal
client in your network.

-- 
Gruß
Marco

Send unsolicited bulk mail to 1712822010mu...@cartoonies.org

Internet Access Problem

[Stephen P. Molnar]

I am running Bullseye and attempting to use QEMU/KVM virt-manager, on 
the computers on my LAN rather than Oracle VM VirtualBox.


I particularly would like to be able to run Windows 10 as there in one 
application that I need for my molecular modeling research that is not 
available for Linux.


I followed the How To (HowTo.txt, attached) without any warning or error 
messages. However, when I pinged yahoo.com. I got the result:


Reply from 169.234.75.136: Destination host unreachable.

It is my understanding the internet should be reachable from Windows 10 
from the default connection.


The default virt-manger xml file and the host i pa results are also 
attached.


I would appreciate any sort of insight as to what might have gone wrong.

Thanks in advance.

--
Stephen P. Molnar, Ph.D.
https://insilicochemistry.net
(614)312-7528 (c)
Skype:  smolnar1



  default
  8230a394-6e17-4ef9-8841-5b4a13812a38
  

  

  
  
  
  

  

  

How To Install Windows 10 on Ubuntu
KVM?
By: Saifudheen Sidheeq


Published: August 23, 2020 - Last updated: November 4, 2023


https://getlabsdone.com/install-windows-10-on-ubuntu-kvm/
 (base) comp@AbNormal:~$ ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: enp2s0:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
link/ether bc:ee:7b:5e:83:36 brd ff:ff:ff:ff:ff:ff
inet 162.237.98.238/22 brd 162.237.99.255 scope global dynamic 
noprefixroute enp2s0
   valid_lft 547sec preferred_lft 547sec
inet6 2600:1700:4280:3690::3f7/128 scope global dynamic noprefixroute
   valid_lft 2583846sec preferred_lft 596646sec
inet6 2600:1700:4280:3690:beee:7bff:fe5e:8336/64 scope global dynamic 
mngtmpaddr noprefixroute
   valid_lft 3414sec preferred_lft 3414sec
inet6 fe80::beee:7bff:fe5e:8336/64 scope link noprefixroute
   valid_lft forever preferred_lft forever
3: virbr0:  mtu 1500 qdisc noqueue state 
DOWN group default qlen 1000
link/ether 52:54:00:c4:59:37 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
   valid_lft forever preferred_lft forever
4: virbr1:  mtu 1500 qdisc noqueue state 
DOWN group default qlen 1000
link/ether 52:54:00:68:bf:76 brd ff:ff:ff:ff:ff:ff
inet 192.168.100.1/24 brd 192.168.100.255 scope global virbr1
   valid_lft forever preferred_lft forever
(base) comp@AbNormal:~$

problem with live usb booting

[sarath]

dear debian

I have created live usb with debian-live-12.5.0-amd64-standard.iso using tool 
Ventoy-1.0.95. When tried to booting it is ended with command line options. 
please help me to the next step

thanks regards
Sarathdc

Sent with [Proton Mail](https://proton.me/) secure email.

problem with installer (testing)

[Angelo Mose Pozzi]

The newly released debian installer (daily build) for testing do not show

the LVM logical volumes and fail when asked for LVM configuration.

The problem is quite new because a installer build im mid February

worked fine.

So who do I have to file the bug to?

Regards

Angelo Pozzi

Re: strange time problem with bullseye

[Roy J. Tellason, Sr.]

On Thursday 07 March 2024 02:44:42 pm Greg Wooledge wrote:
> On Thu, Mar 07, 2024 at 02:33:05PM -0500, Roy J. Tellason, Sr. wrote:
> > On Thursday 07 March 2024 09:02:44 am Teemu Likonen wrote:
> > > systemctl status systemd-timesyncd.service
> > 
> > This got me some interesting results:
> > 
> > ● systemd-timesyncd.service - Network Time Synchronization
> >Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; 
> > vendor preset: enabled)
> >   Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
> >└─disable-with-time-daemon.conf
> >Active: inactive (dead)
> > Condition: start condition failed at Wed 2024-02-14 16:17:31 EST; 3 weeks 0 
> > days ago
> >└─ ConditionFileIsExecutable=!/usr/sbin/VBoxService was not met
> >  Docs: man:systemd-timesyncd.service(8)
> > 
> > Hmm.
> 
> Are you running that on a virtualbox client, or a virtualbox host?

That was on the host.  The client is running an older version of Slackware.
 
> In any case, you might find it interesting to read the unit file in
> question ("systemctl cat systemd-timesyncd.service").  It looks like
> you've got one of the slightly older kind, where the service is always
> installed, but is prevented from running if any of several different
> programs is found.
 
Yes,  I'm running older software here.  I did that and see those listed near 
the end of it.  The system does seem to do okay with keeping the right time,  
though,  for the most part.  The only rough spot was the RTC was way off,  but 
that's now been fixed... 


-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

Re: strange time problem with bullseye/buster

[Max Nikulin]

On 08/03/2024 07:17, gene heskett wrote:

I have NDI how to extract chrony's logs from journalctl.


- man journalctl,
- docs listed on the systemd web site.

Re: strange time problem with bullseye/buster

[gene heskett]

On 3/7/24 21:30, David Wright wrote:

On Thu 07 Mar 2024 at 19:17:02 (-0500), gene heskett wrote:

On 3/7/24 12:19, David Wright wrote:

On Thu 07 Mar 2024 at 11:29:47 (-0500), gene heskett wrote:

On 3/7/24 10:59, Greg Wooledge wrote:



You should be able to verify that the systemd-timesyncd package is
removed.




In some older versions of Debian, systemd-timesyncd was part of the
systemd package, and was always installed, even if you installed ntp
or chrony.  In these versions, the systemd unit file for timesync
had checks for the existence of the binaries belonging to ntp, chrony
and openntpd, and would prevent timesync from running if any of those
was found.

I don't remember which version did which thing.

And of course, if you are not actually running Debian, then all bets are
off.  You're on your own with Armbian, Raspbian, etc.


and because the printer is arm stuff, its old armbian buster vintage.
mks@mkspi:/etc/init.d$ sudo apt purge systemd-timesyncd
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package 'systemd-timesyncd' is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
mks@mkspi:/etc/init.d$
yet timedatectl is still there and shows:
mks@mkspi:/etc/init.d$ timedatectl
 Local time: Thu 2024-03-07 11:15:53 EST
 Universal time: Thu 2024-03-07 16:15:53 UTC
   RTC time: Thu 2024-03-07 11:04:39
  Time zone: America/New_York (EST, -0500)
System clock synchronized: no
NTP service: inactive
RTC in local TZ: no
mks@mkspi:/etc/init.d$
And the local time shown above is correct to the second.


Debian's buster's systemd (241) has timesyncd built-in, so you may
find that   ls -l /lib/systemd/systemd-timesyncd still finds it.

The output from timedatectl is worrying. I would monitor chrony and
check its logs to see if it it's doing anything. After all, you had
ntpsec running until a "moment" ago, so you'd hardly expect the clock
to be wrong by now.


At the instant I removed ntpsec and minute later whem I re-installed
chrony, the time on that printer was around 20 hours stale. By about a
minute after chrony started, which the install did, time was
synchronized.

And still is. Somehow, it resurrected the customized
/etc/chrony/chrony.conf which pointed it at this machines ntpsec
server. So I didn't have to re-invent that wheel. It just Worked.
Memory in the u-sd card? IDK.

I have NDI how to extract chrony's logs from journalctl.


You could run these commands as an ordinary user instead:

   $ chronyc sources
   $ chronyc sourcestats
   $ chronyc tracking

which will give you an idea of what it is doing.

Cheers,
David.

.

mks@mkspi:/etc/init.d$ chronyc tracking
Reference ID: C0A84703 (coyote.coyote.den)
Stratum : 4
Ref time (UTC)  : Fri Mar 08 03:23:48 2024
System time : 0.06175 seconds slow of NTP time
Last offset : -0.05491 seconds
RMS offset  : 0.07778 seconds
Frequency   : 6.590 ppm slow
Residual freq   : -0.002 ppm
Skew: 0.036 ppm
Root delay  : 0.034696314 seconds
Root dispersion : 0.054448538 seconds
Update interval : 64.5 seconds
Leap status : Normal

Looks good to me. ;o)>

Thanks David. Take care & stay well.

Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: strange time problem with bullseye/buster

[David Wright]

On Thu 07 Mar 2024 at 19:17:02 (-0500), gene heskett wrote:
> On 3/7/24 12:19, David Wright wrote:
> > On Thu 07 Mar 2024 at 11:29:47 (-0500), gene heskett wrote:
> > > On 3/7/24 10:59, Greg Wooledge wrote:
> > 
> > > > You should be able to verify that the systemd-timesyncd package is
> > > > removed.
> > > > 
> > > 
> > > > In some older versions of Debian, systemd-timesyncd was part of the
> > > > systemd package, and was always installed, even if you installed ntp
> > > > or chrony.  In these versions, the systemd unit file for timesync
> > > > had checks for the existence of the binaries belonging to ntp, chrony
> > > > and openntpd, and would prevent timesync from running if any of those
> > > > was found.
> > > > 
> > > > I don't remember which version did which thing.
> > > > 
> > > > And of course, if you are not actually running Debian, then all bets are
> > > > off.  You're on your own with Armbian, Raspbian, etc.
> > > > 
> > > and because the printer is arm stuff, its old armbian buster vintage.
> > > mks@mkspi:/etc/init.d$ sudo apt purge systemd-timesyncd
> > > Reading package lists... Done
> > > Building dependency tree
> > > Reading state information... Done
> > > Package 'systemd-timesyncd' is not installed, so not removed
> > > 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
> > > mks@mkspi:/etc/init.d$
> > > yet timedatectl is still there and shows:
> > > mks@mkspi:/etc/init.d$ timedatectl
> > > Local time: Thu 2024-03-07 11:15:53 EST
> > > Universal time: Thu 2024-03-07 16:15:53 UTC
> > >   RTC time: Thu 2024-03-07 11:04:39
> > >  Time zone: America/New_York (EST, -0500)
> > > System clock synchronized: no
> > >NTP service: inactive
> > >RTC in local TZ: no
> > > mks@mkspi:/etc/init.d$
> > > And the local time shown above is correct to the second.
> > 
> > Debian's buster's systemd (241) has timesyncd built-in, so you may
> > find that   ls -l /lib/systemd/systemd-timesyncd still finds it.
> > 
> > The output from timedatectl is worrying. I would monitor chrony and
> > check its logs to see if it it's doing anything. After all, you had
> > ntpsec running until a "moment" ago, so you'd hardly expect the clock
> > to be wrong by now.
> 
> At the instant I removed ntpsec and minute later whem I re-installed
> chrony, the time on that printer was around 20 hours stale. By about a
> minute after chrony started, which the install did, time was
> synchronized.
> 
> And still is. Somehow, it resurrected the customized
> /etc/chrony/chrony.conf which pointed it at this machines ntpsec
> server. So I didn't have to re-invent that wheel. It just Worked.
> Memory in the u-sd card? IDK.
> 
> I have NDI how to extract chrony's logs from journalctl.

You could run these commands as an ordinary user instead:

  $ chronyc sources
  $ chronyc sourcestats
  $ chronyc tracking

which will give you an idea of what it is doing.

Cheers,
David.

Re: strange time problem with bullseye

[gene heskett]

On 3/7/24 14:16, Roy J. Tellason, Sr. wrote:

On Wednesday 06 March 2024 12:42:12 pm Greg Wooledge wrote:

How do I get the RTC to agree with the right time?


"hwclock -w" to copy the system clock to the hardware clock (RTC).  This
should also be done during shutdown, but it doesn't hurt to do it now.


True, but needs a sudo in front if it in my case on that armbian buster 
machine.
  
That seemed to do what I needed.


I don't ordinarily shut this machine down for the most part.  Every once in a while all 
of my swap partition gets filled up,  and then there's this continuous hard drive 
activity that I'm assuming is what they mean by "thrashing". The only option at 
that point is to get its attention with the power switch.  And then I need to go through 
a whole routing with bringing up what I had going,  including re-starting virtualbox and 
the stuff that runs in it,  etc.  If I'm lucky then I can get back the windows I had 
going before,  sometimes I'm not so lucky.  A system monitor I run on desktop 4 always 
comes up,  but on the wrong desktop and I have to move it.

The "eat all available memory" culprit seems to be firefox.  I just need to 
look at that system monitor every once in a while and when things start getting excessive 
shut firefox down and restart it.  Then I don't have the problem...

I'm not sure if I have ntp or something else running here.  (Looking...)  I 
don't see it in my process list.




Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: strange time problem with bullseye/buster

[gene heskett]

On 3/7/24 12:19, David Wright wrote:

On Thu 07 Mar 2024 at 11:29:47 (-0500), gene heskett wrote:

On 3/7/24 10:59, Greg Wooledge wrote:



You should be able to verify that the systemd-timesyncd package is
removed.




In some older versions of Debian, systemd-timesyncd was part of the
systemd package, and was always installed, even if you installed ntp
or chrony.  In these versions, the systemd unit file for timesync
had checks for the existence of the binaries belonging to ntp, chrony
and openntpd, and would prevent timesync from running if any of those
was found.

I don't remember which version did which thing.

And of course, if you are not actually running Debian, then all bets are
off.  You're on your own with Armbian, Raspbian, etc.


and because the printer is arm stuff, its old armbian buster vintage.
mks@mkspi:/etc/init.d$ sudo apt purge systemd-timesyncd
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package 'systemd-timesyncd' is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
mks@mkspi:/etc/init.d$
yet timedatectl is still there and shows:
mks@mkspi:/etc/init.d$ timedatectl
Local time: Thu 2024-03-07 11:15:53 EST
Universal time: Thu 2024-03-07 16:15:53 UTC
  RTC time: Thu 2024-03-07 11:04:39
 Time zone: America/New_York (EST, -0500)
System clock synchronized: no
   NTP service: inactive
   RTC in local TZ: no
mks@mkspi:/etc/init.d$
And the local time shown above is correct to the second.


Debian's buster's systemd (241) has timesyncd built-in, so you may
find that   ls -l /lib/systemd/systemd-timesyncd still finds it.

The output from timedatectl is worrying. I would monitor chrony and
check its logs to see if it it's doing anything. After all, you had
ntpsec running until a "moment" ago, so you'd hardly expect the clock
to be wrong by now.


At the instant I removed ntpsec and minute later whem I re-installed 
chrony, the time on that printer was around 20 hours stale. By about a 
minute after chrony started, which the install did, time was synchronized.


And still is. Somehow, it resurrected the customized
/etc/chrony/chrony.conf which pointed it at this machines ntpsec server. 
So I didn't have to re-invent that wheel. It just Worked. Memory in the 
u-sd card? IDK.


I have NDI how to extract chrony's logs from journalctl.


I tried installing chrony in 2017 (jessie), and it appeared unable
to slew the clock five seconds in two days of interrupted running.

Cheers,
David.


Thank you David, take care & stay well.

Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: strange time problem with bullseye

[Greg Wooledge]

On Thu, Mar 07, 2024 at 02:33:05PM -0500, Roy J. Tellason, Sr. wrote:
> On Thursday 07 March 2024 09:02:44 am Teemu Likonen wrote:
> > systemctl status systemd-timesyncd.service
> 
> This got me some interesting results:
> 
> ● systemd-timesyncd.service - Network Time Synchronization
>Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; 
> vendor preset: enabled)
>   Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
>└─disable-with-time-daemon.conf
>Active: inactive (dead)
> Condition: start condition failed at Wed 2024-02-14 16:17:31 EST; 3 weeks 0 
> days ago
>└─ ConditionFileIsExecutable=!/usr/sbin/VBoxService was not met
>  Docs: man:systemd-timesyncd.service(8)
> 
> Hmm.

Are you running that on a virtualbox client, or a virtualbox host?

In any case, you might find it interesting to read the unit file in
question ("systemctl cat systemd-timesyncd.service").  It looks like
you've got one of the slightly older kind, where the service is always
installed, but is prevented from running if any of several different
programs is found.

Re: strange time problem with bullseye

[Dan Ritter]

Roy J. Tellason, Sr. wrote: 
> I don't ordinarily shut this machine down for the most part.  Every once in a 
> while all of my swap partition gets filled up,  and then there's this 
> continuous hard drive activity that I'm assuming is what they mean by 
> "thrashing". The only option at that point is to get its attention with the 
> power switch.  And then I need to go through a whole routing with bringing up 
> what I had going,  including re-starting virtualbox and the stuff that runs 
> in it,  etc.  If I'm lucky then I can get back the windows I had going 
> before,  sometimes I'm not so lucky.  A system monitor I run on desktop 4 
> always comes up,  but on the wrong desktop and I have to move it.
> 
> The "eat all available memory" culprit seems to be firefox.  I just need to 
> look at that system monitor every once in a while and when things start 
> getting excessive shut firefox down and restart it.  Then I don't have the 
> problem...

There's a kernel feature called the OOM-killer (out of memory)
which is supposed to detect when you are running out of memory
and select a process to kill.

Did you turn it off? It would be a setting in /etc/sysctl.conf
or /etc/sysctl.d/*

If not, perhaps you have an excessive amount of slow swap for it to be happy?

 
> I'm not sure if I have ntp or something else running here.  (Looking...)  I 
> don't see it in my process list.

Other likely candidates are systemd-timesync and chrony.

-dsr-

Re: strange time problem with bullseye

[Roy J. Tellason, Sr.]

On Thursday 07 March 2024 09:02:44 am Teemu Likonen wrote:
> systemctl status systemd-timesyncd.service

This got me some interesting results:

● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; 
vendor preset: enabled)
  Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
   └─disable-with-time-daemon.conf
   Active: inactive (dead)
Condition: start condition failed at Wed 2024-02-14 16:17:31 EST; 3 weeks 0 
days ago
   └─ ConditionFileIsExecutable=!/usr/sbin/VBoxService was not met
 Docs: man:systemd-timesyncd.service(8)

Hmm.

-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

Re: strange time problem with bullseye

[Roy J. Tellason, Sr.]

On Wednesday 06 March 2024 12:42:12 pm Greg Wooledge wrote:
> > How do I get the RTC to agree with the right time?
> 
> "hwclock -w" to copy the system clock to the hardware clock (RTC).  This
> should also be done during shutdown, but it doesn't hurt to do it now.
 
That seemed to do what I needed.

I don't ordinarily shut this machine down for the most part.  Every once in a 
while all of my swap partition gets filled up,  and then there's this 
continuous hard drive activity that I'm assuming is what they mean by 
"thrashing". The only option at that point is to get its attention with the 
power switch.  And then I need to go through a whole routing with bringing up 
what I had going,  including re-starting virtualbox and the stuff that runs in 
it,  etc.  If I'm lucky then I can get back the windows I had going before,  
sometimes I'm not so lucky.  A system monitor I run on desktop 4 always comes 
up,  but on the wrong desktop and I have to move it.

The "eat all available memory" culprit seems to be firefox.  I just need to 
look at that system monitor every once in a while and when things start getting 
excessive shut firefox down and restart it.  Then I don't have the problem...

I'm not sure if I have ntp or something else running here.  (Looking...)  I 
don't see it in my process list.


-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

Re: strange time problem with bullseye/buster

[David Wright]

On Thu 07 Mar 2024 at 11:29:47 (-0500), gene heskett wrote:
> On 3/7/24 10:59, Greg Wooledge wrote:

> > You should be able to verify that the systemd-timesyncd package is
> > removed.
> > 
> 
> > In some older versions of Debian, systemd-timesyncd was part of the
> > systemd package, and was always installed, even if you installed ntp
> > or chrony.  In these versions, the systemd unit file for timesync
> > had checks for the existence of the binaries belonging to ntp, chrony
> > and openntpd, and would prevent timesync from running if any of those
> > was found.
> > 
> > I don't remember which version did which thing.
> > 
> > And of course, if you are not actually running Debian, then all bets are
> > off.  You're on your own with Armbian, Raspbian, etc.
> > 
> and because the printer is arm stuff, its old armbian buster vintage.
> mks@mkspi:/etc/init.d$ sudo apt purge systemd-timesyncd
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Package 'systemd-timesyncd' is not installed, so not removed
> 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
> mks@mkspi:/etc/init.d$
> yet timedatectl is still there and shows:
> mks@mkspi:/etc/init.d$ timedatectl
>Local time: Thu 2024-03-07 11:15:53 EST
>Universal time: Thu 2024-03-07 16:15:53 UTC
>  RTC time: Thu 2024-03-07 11:04:39
> Time zone: America/New_York (EST, -0500)
> System clock synchronized: no
>   NTP service: inactive
>   RTC in local TZ: no
> mks@mkspi:/etc/init.d$
> And the local time shown above is correct to the second.

Debian's buster's systemd (241) has timesyncd built-in, so you may
find that   ls -l /lib/systemd/systemd-timesyncd still finds it.

The output from timedatectl is worrying. I would monitor chrony and
check its logs to see if it it's doing anything. After all, you had
ntpsec running until a "moment" ago, so you'd hardly expect the clock
to be wrong by now.

I tried installing chrony in 2017 (jessie), and it appeared unable
to slew the clock five seconds in two days of interrupted running.

Cheers,
David.

Re: strange time problem with bullseye

[gene heskett]

On 3/7/24 11:18, Jeffrey Walton wrote:

On Thu, Mar 7, 2024 at 8:44 AM  wrote:


On Thu, Mar 07, 2024 at 08:31:16AM -0500, gene heskett wrote:

[...]
Now, how do I assure timedatectl stays stopped on a reboot? [...]

I'll have to leave this to others more fluent in systemd-ish.


Mask the systemd-timesyncd service. Masking is the service a permanent effect.


it appears its not installed. It can't be found to purge it. That would 
explain why it didn't work.


If you just stop or disable the service, then the service will either
be started on the next reboot, or it can be manually started. Since
you want to permanently disable the service, you have to mask it.

Jeff
.

Thanks Jeff.
Take care & stay well.

Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: strange time problem with bullseye

[gene heskett]

On 3/7/24 10:59, Greg Wooledge wrote:

On Thu, Mar 07, 2024 at 08:31:16AM -0500, gene heskett wrote:

So I purged ntpsec and re-installed chrony which I had done once before with
no luck but this time timedatectl was stopped and it worked!

Now, how do I assure timedatectl stays stopped on a reboot?


Which version of Debian is this?  I'm guessing it's fairly recent,
because ntpsec is fairly recent.

In the most recent version or two, systemd-timesyncd is a separate
package, and it cannot coexist with chrony (they both provide the
"time-daemon" virtual package).  So, if this is Debian 12 (maybe 11
also, dunno about older), then when you installed either ntpsec or
chrony, it should have removed the systemd-timesyncd package.

You should be able to verify that the systemd-timesyncd package is
removed.




In some older versions of Debian, systemd-timesyncd was part of the
systemd package, and was always installed, even if you installed ntp
or chrony.  In these versions, the systemd unit file for timesync
had checks for the existence of the binaries belonging to ntp, chrony
and openntpd, and would prevent timesync from running if any of those
was found.

I don't remember which version did which thing.

And of course, if you are not actually running Debian, then all bets are
off.  You're on your own with Armbian, Raspbian, etc.

.

and because the printer is arm stuff, its old armbian buster vintage.
mks@mkspi:/etc/init.d$ sudo apt purge systemd-timesyncd
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package 'systemd-timesyncd' is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
mks@mkspi:/etc/init.d$
yet timedatectl is still there and shows:
mks@mkspi:/etc/init.d$ timedatectl
   Local time: Thu 2024-03-07 11:15:53 EST
   Universal time: Thu 2024-03-07 16:15:53 UTC
 RTC time: Thu 2024-03-07 11:04:39
Time zone: America/New_York (EST, -0500)
System clock synchronized: no
  NTP service: inactive
  RTC in local TZ: no
mks@mkspi:/etc/init.d$
And the local time shown above is correct to the second.

Thanks Greg, take care & stay well.

Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: strange time problem with bullseye

[Jeffrey Walton]

On Thu, Mar 7, 2024 at 8:44 AM  wrote:
>
> On Thu, Mar 07, 2024 at 08:31:16AM -0500, gene heskett wrote:
>
> [...]
> Now, how do I assure timedatectl stays stopped on a reboot? [...]
>
> I'll have to leave this to others more fluent in systemd-ish.

Mask the systemd-timesyncd service. Masking is the service a permanent effect.

If you just stop or disable the service, then the service will either
be started on the next reboot, or it can be manually started. Since
you want to permanently disable the service, you have to mask it.

Jeff

Re: strange time problem with bullseye

[Greg Wooledge]

On Thu, Mar 07, 2024 at 08:31:16AM -0500, gene heskett wrote:
> So I purged ntpsec and re-installed chrony which I had done once before with
> no luck but this time timedatectl was stopped and it worked!
> 
> Now, how do I assure timedatectl stays stopped on a reboot?

Which version of Debian is this?  I'm guessing it's fairly recent,
because ntpsec is fairly recent.

In the most recent version or two, systemd-timesyncd is a separate
package, and it cannot coexist with chrony (they both provide the
"time-daemon" virtual package).  So, if this is Debian 12 (maybe 11
also, dunno about older), then when you installed either ntpsec or
chrony, it should have removed the systemd-timesyncd package.

You should be able to verify that the systemd-timesyncd package is
removed.

In some older versions of Debian, systemd-timesyncd was part of the
systemd package, and was always installed, even if you installed ntp
or chrony.  In these versions, the systemd unit file for timesync
had checks for the existence of the binaries belonging to ntp, chrony
and openntpd, and would prevent timesync from running if any of those
was found.

I don't remember which version did which thing.

And of course, if you are not actually running Debian, then all bets are
off.  You're on your own with Armbian, Raspbian, etc.

Re: strange time problem with bullseye

[Teemu Likonen]

* 2024-03-07 08:31:16-0500, gene heskett wrote:

> So I purged ntpsec and re-installed chrony which I had done once before 
> with no luck but this time timedatectl was stopped and it worked!
>
> Now, how do I assure timedatectl stays stopped on a reboot? systemd's
> docs are positively opaque about that even if they do go on for
> megabytes.

"timedatectl" is a command for configuring and showing various time
settings. You probably mean: how to stop Systemd's NTP service. See "man
timedatectl" or "timedatectl -h". Look for subcommand "set-ntp".

sudo timedatectl set-ntp false

See the current state with just "timedatectl" command. What happens
behind the surface is enabling/disabling service
systemd-timesyncd.service. You can check its status:

systemctl status systemd-timesyncd.service

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462


signature.asc
Description: PGP signature

Re: strange time problem with bullseye

[tomas]

On Thu, Mar 07, 2024 at 08:31:16AM -0500, gene heskett wrote:

[...]

> So I purged ntpsec and re-installed chrony which I had done once before with
> no luck but this time timedatectl was stopped and it worked!

great :-)

> Now, how do I assure timedatectl stays stopped on a reboot? [...]

I'll have to leave this to others more fluent in systemd-ish.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: strange time problem with bullseye

[gene heskett]

On 3/7/24 00:22, to...@tuxteam.de wrote:

On Wed, Mar 06, 2024 at 08:06:15PM -0600, John Hasler wrote:

Look at the chronyd settime command and the chrony.conf makestep
directive.  These are intended for your situation.


This from man(8) ntpd:

  -g, --panicgate
Allow the first adjustment to be Big.  This option may appear an
unlimited number of times.

Normally, ntpd exits with a message to the system log if the off‐
set exceeds the panic threshold, which is 1000 s by default. This
option allows the time to be set to any value without restric‐
tion; however, this can happen only once. If the threshold is ex‐
ceeded after that, ntpd will exit with a message to the system
log. This option can be used with the -q and -x options.  See the
tinker configuration file directive for other options.

  -G, --force-step-once
Step any initial offset correction..
[...]

Cheers


So I purged ntpsec and re-installed chrony which I had done once before 
with no luck but this time timedatectl was stopped and it worked!


Now, how do I assure timedatectl stays stopped on a reboot? systemd's 
docs are positively opaque about that even if they do go on for 
megabytes. Surprisingly the chrony.conf setting to use my own server 
setup on this machine making me a level 2 ntp server, magically re-appeared.


Seems like it should have a disable option to match the enable but 
playing 50 monkeys didn't find it.


Thanks take care & stay well Tomas.

Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: strange time problem with bullseye

[tomas]

On Wed, Mar 06, 2024 at 09:36:56PM -0500, Greg Wooledge wrote:
> On Wed, Mar 06, 2024 at 08:33:37PM -0500, gene heskett wrote:
> > no place in the ntpsec docs, nor the chrony docs
> > does it show the ability to slam the current time into the SW clock on these
> > arm systems at bootup's first access time.
> 
> Traditionally, this was done by the ntpdate command, which was in the
> ntpdate package.

[...]

>-g, --panicgate

[...]

Heh. Great minds read alike :-)

But thanks for the historical background, which I didn't know.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: strange time problem with bullseye

[tomas]

On Wed, Mar 06, 2024 at 08:06:15PM -0600, John Hasler wrote:
> Look at the chronyd settime command and the chrony.conf makestep
> directive.  These are intended for your situation.

This from man(8) ntpd:

 -g, --panicgate
   Allow the first adjustment to be Big.  This option may appear an
   unlimited number of times.

   Normally, ntpd exits with a message to the system log if the off‐
   set exceeds the panic threshold, which is 1000 s by default. This
   option allows the time to be set to any value without restric‐
   tion; however, this can happen only once. If the threshold is ex‐
   ceeded after that, ntpd will exit with a message to the system
   log. This option can be used with the -q and -x options.  See the
   tinker configuration file directive for other options.

 -G, --force-step-once
   Step any initial offset correction..
   [...]

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: strange time problem with bullseye

[Greg Wooledge]

On Wed, Mar 06, 2024 at 08:33:37PM -0500, gene heskett wrote:
> no place in the ntpsec docs, nor the chrony docs
> does it show the ability to slam the current time into the SW clock on these
> arm systems at bootup's first access time.

Traditionally, this was done by the ntpdate command, which was in the
ntpdate package.

On older Debian releases, you would install both of these (ntp and
ntpdate); ntpdate would run first, slamming the clock, and then ntp
would run second, to keep the clock in sync.

A few releases ago, ntpdate was deprecated, and its slamming functionality
was absorbed into the ntp package, as long as ntp is started with the -g
option.

   -g, --panicgate
   Allow the first adjustment to be big. This option may appear an
   unlimited number of times.

   Normally, ntpd exits with a message to the system log if the offset
   exceeds the panic threshold, which is 1000 s by default. This
   option allows the time to be set to any value without restriction;
   however, this can happen only once. If the threshold is exceeded
   after that, ntpd will exit with a message to the system log. This
   option can be used with the -q and -x options. See the tinker
   configuration file directive for other options.

With ntpsec replacing ntp in Debian 12, the same options apply.  By default,
Debian runs ntpsec with the -g option, to allow the clock to be slammed
at boot time.

hobbit:~$ ps -ef | grep ntpd
ntpsec   854   1  0 Feb17 ?00:01:17 /usr/sbin/ntpd -p 
/run/ntpd.pid -c /etc/ntpsec/ntp.conf -g -N -u ntpsec:ntpsec
greg  3947371138  0 21:34 pts/000:00:00 grep ntpd

Your claims that "no place in the ntpsec docs ... show the ability to
slam the current time" are simply false.

Re: strange time problem with bullseye

[John Hasler]

Look at the chronyd settime command and the chrony.conf makestep
directive.  These are intended for your situation.
-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA

Re: strange time problem with bullseye

[gene heskett]

On 3/6/24 18:02, Greg Wooledge wrote:

On Wed, Mar 06, 2024 at 05:56:29PM -0500, gene heskett wrote:

On 3/6/24 12:42, Greg Wooledge wrote:

On Wed, Mar 06, 2024 at 12:31:46PM -0500, Roy J. Tellason, Sr. wrote:

  sudo timedatectl set-ntp true


But *don't* do that if you're using some other NTP program instead of
systemd-timesyncd.



Are you saying that both chrony and ntpsec, which are fully ntp
client/server ack the docs are worthless to timedatectl?


I'm saying "don't turn on systemd's NTP thing if you're using a different
NTP thing".

Roy's instructions failed to take into account that many of us are
already using a different NTP implementation, besides systemd's.


I can turn either off, but no place in the ntpsec docs, nor the chrony 
docs does it show the ability to slam the current time into the SW clock 
on these arm systems at bootup's first access time.  And the normal 
correction is maybe a second an hour so it its been turned off for a 
week, its another week out of time when turned back on. The whole thing 
never considered the no hwclock situation that exists in 99% of the arm 
world. I was hoping timedatectl had that ability but I see it says you 
must be synched first. The rpis's can do it, whats the secret recipe?


Thank Greg, take care & stay well.
Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: strange time problem with bullseye

[Greg Wooledge]

On Wed, Mar 06, 2024 at 05:56:29PM -0500, gene heskett wrote:
> On 3/6/24 12:42, Greg Wooledge wrote:
> > On Wed, Mar 06, 2024 at 12:31:46PM -0500, Roy J. Tellason, Sr. wrote:
> > >  sudo timedatectl set-ntp true
> > 
> > But *don't* do that if you're using some other NTP program instead of
> > systemd-timesyncd.

> Are you saying that both chrony and ntpsec, which are fully ntp
> client/server ack the docs are worthless to timedatectl?

I'm saying "don't turn on systemd's NTP thing if you're using a different
NTP thing".

Roy's instructions failed to take into account that many of us are
already using a different NTP implementation, besides systemd's.

Re: strange time problem with bullseye

[gene heskett]

On 3/6/24 12:42, Greg Wooledge wrote:

On Wed, Mar 06, 2024 at 12:31:46PM -0500, Roy J. Tellason, Sr. wrote:

Mine shows:

   Local time: Wed 2024-03-06 12:09:44 EST
   Universal time: Wed 2024-03-06 17:09:44 UTC
 RTC time: Wed 2024-03-06 17:20:53
Time zone: America/New_York (EST, -0500)
  Network time on: yes
NTP synchronized: no
  RTC in local TZ: no

How do I get the RTC to agree with the right time?


"hwclock -w" to copy the system clock to the hardware clock (RTC).  This
should also be done during shutdown, but it doesn't hurt to do it now.


On Wed, Mar 06, 2024 at 07:36:11PM +0200, Teemu Likonen wrote:

To get operating system's clock have accurate time it needs to be
synchronized with network time servers via network time protocol (NTP).
Systemd has that feature. Turn in on with

 sudo timedatectl set-ntp true


But *don't* do that if you're using some other NTP program instead of
systemd-timesyncd.  Unfortunately, timedatectl does not know about other
NTP programs, and won't report which one you're using.  You'll have
to find that out yourself


Are you saying that both chrony and ntpsec, which are fully ntp 
client/server ack the docs are worthless to timedatectl?


I have a quite good 3d printer, but its running armbian buster, its out 
of synch by days despite ntpsec running and I can see it access my own 
level 2 server but the timedate never synchronizes. I need to know how 
to setup timedatectl to slam the ntp time into the system clock on first 
access at bootup. That would fix a lot of bogus times reported by 
fluidd, the printers web based gui front end.


Thanks Greg. Take care & stay well.

Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: strange time problem with bullseye

[hlyg]

On 3/6/24 13:37, Teemu Likonen wrote:

It seems that you have solved the problem but here is another hint.
"timedatectl" is a good high-level tool for querying and adjusting time
settings. Without command-line arguments it prints a lot of useful info:

 $ timedatectl
Local time: ke 2024-03-06 07:33:00 EET
Universal time: ke 2024-03-06 05:33:00 UTC
  RTC time: ke 2024-03-06 05:33:00
 Time zone: Europe/Helsinki (EET, +0200)
 System clock synchronized: yes
   NTP service: active
   RTC in local TZ: no

See "timedatectl -h" or manual page for more info.



Thank Likonen, timedatectl is useful, ntp isn't installed

System clock synchronized: no NTP service: n/a RTC in local TZ: no

perhaps it's because i didn't install a set of standard tools during 
deb11 installation

Re: strange time problem with bullseye

[David Wright]

On Wed 06 Mar 2024 at 07:07:36 (-0500), Greg Wooledge wrote:
> On Wed, Mar 06, 2024 at 07:37:09AM +0200, Teemu Likonen wrote:
> > It seems that you have solved the problem but here is another hint.
> > "timedatectl" is a good high-level tool for querying and adjusting time
> > settings. Without command-line arguments it prints a lot of useful info:
> > 
> > $ timedatectl
> >Local time: ke 2024-03-06 07:33:00 EET
> >Universal time: ke 2024-03-06 05:33:00 UTC
> >  RTC time: ke 2024-03-06 05:33:00
> > Time zone: Europe/Helsinki (EET, +0200)
> > System clock synchronized: yes
> >   NTP service: active
> >   RTC in local TZ: no
> > 
> > See "timedatectl -h" or manual page for more info.
> 
> This is a great hint, but be warned that it doesn't quite know about
> NTP services other than systemd-timesyncd.  If you're running ntpsec,
> for example, it'll simply say:
> 
> System clock synchronized: yes
>   NTP service: n/a

Note also that it only shows the system's time zone, and not
necessarily that of the user running it:

$ timedatectl ; echo ; date
   Local time: Wed 2024-03-06 19:18:58 UTC
   Universal time: Wed 2024-03-06 19:18:58 UTC
 RTC time: Wed 2024-03-06 19:18:58
Time zone: Etc/UTC (UTC, +)
System clock synchronized: yes
  NTP service: active
  RTC in local TZ: no

Wed Mar  6 13:18:58 CST 2024
$ 

Cheers,
David.

Re: strange time problem with bullseye

[Jeffrey Walton]

On Wed, Mar 6, 2024 at 7:08 AM Greg Wooledge  wrote:
>
> On Wed, Mar 06, 2024 at 07:37:09AM +0200, Teemu Likonen wrote:
> > It seems that you have solved the problem but here is another hint.
> > "timedatectl" is a good high-level tool for querying and adjusting time
> > settings. Without command-line arguments it prints a lot of useful info:
> >
> > $ timedatectl
> >Local time: ke 2024-03-06 07:33:00 EET
> >Universal time: ke 2024-03-06 05:33:00 UTC
> >  RTC time: ke 2024-03-06 05:33:00
> > Time zone: Europe/Helsinki (EET, +0200)
> > System clock synchronized: yes
> >   NTP service: active
> >   RTC in local TZ: no
> >
> > See "timedatectl -h" or manual page for more info.
>
> This is a great hint, but be warned that it doesn't quite know about
> NTP services other than systemd-timesyncd.  If you're running ntpsec,
> for example, it'll simply say:
>
> System clock synchronized: yes
>   NTP service: n/a

This may help in the future:
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065567>.

Jeff

Re: strange time problem with bullseye

[Jeffrey Walton]

On Wed, Mar 6, 2024 at 12:13 PM Roy J. Tellason, Sr.  wrote:
>
> On Wednesday 06 March 2024 12:37:09 am Teemu Likonen wrote:
> > * 2024-03-06 02:47:06+0800, hlyg wrote:
> >
> > > my newly-installed deb11 for amd64 shows wrong time,  it lags behind
> > > correct time by 8 hours though difference between universal and local
> > > is ok.
> >
> > It seems that you have solved the problem but here is another hint.
> > "timedatectl" is a good high-level tool for querying and adjusting time
> > settings. Without command-line arguments it prints a lot of useful info:
> >
> > $ timedatectl
> >Local time: ke 2024-03-06 07:33:00 EET
> >Universal time: ke 2024-03-06 05:33:00 UTC
> >  RTC time: ke 2024-03-06 05:33:00
> > Time zone: Europe/Helsinki (EET, +0200)
> > System clock synchronized: yes
> >   NTP service: active
> >   RTC in local TZ: no
> >
> > See "timedatectl -h" or manual page for more info.
> >
>
> Mine shows:
>
>   Local time: Wed 2024-03-06 12:09:44 EST
>   Universal time: Wed 2024-03-06 17:09:44 UTC
> RTC time: Wed 2024-03-06 17:20:53
>Time zone: America/New_York (EST, -0500)
>  Network time on: yes
> NTP synchronized: no
>  RTC in local TZ: no
>
> How do I get the RTC to agree with the right time?  I don't reboot this 
> often,  but when I do the time displayed on the onscreen clock is typically 
> off by several minutes.

Install ntp, ntpsec or systemd-timesyncd. Once installed and time is
sync'd, run 'sudo hwclock -w'.

Also see <https://wiki.debian.org/DateTime#Installing_NTP> and
<https://manpages.debian.org/bookworm/util-linux-extra/hwclock.8.en.html>.

Jeff

Re: strange time problem with bullseye

[Greg Wooledge]

On Wed, Mar 06, 2024 at 12:31:46PM -0500, Roy J. Tellason, Sr. wrote:
> Mine shows:
> 
>   Local time: Wed 2024-03-06 12:09:44 EST
>   Universal time: Wed 2024-03-06 17:09:44 UTC
> RTC time: Wed 2024-03-06 17:20:53
>Time zone: America/New_York (EST, -0500)
>  Network time on: yes
> NTP synchronized: no
>  RTC in local TZ: no
> 
> How do I get the RTC to agree with the right time?

"hwclock -w" to copy the system clock to the hardware clock (RTC).  This
should also be done during shutdown, but it doesn't hurt to do it now.


On Wed, Mar 06, 2024 at 07:36:11PM +0200, Teemu Likonen wrote:
> To get operating system's clock have accurate time it needs to be
> synchronized with network time servers via network time protocol (NTP).
> Systemd has that feature. Turn in on with
> 
> sudo timedatectl set-ntp true

But *don't* do that if you're using some other NTP program instead of
systemd-timesyncd.  Unfortunately, timedatectl does not know about other
NTP programs, and won't report which one you're using.  You'll have
to find that out yourself.

Re: strange time problem with bullseye

[Teemu Likonen]

* 2024-03-06 12:31:46-0500, Roy J. Tellason, Sr. wrote:

>   Local time: Wed 2024-03-06 12:09:44 EST
>   Universal time: Wed 2024-03-06 17:09:44 UTC
> RTC time: Wed 2024-03-06 17:20:53
>Time zone: America/New_York (EST, -0500)
>  Network time on: yes
> NTP synchronized: no
>  RTC in local TZ: no
>
> How do I get the RTC to agree with the right time? I don't reboot this
> often, but when I do the time displayed on the onscreen clock is
> typically off by several minutes.

RTC is the clock on computer's motherboard. It has battery and it can
keep time when the computer is off. That's its purpose. When computer is
shut down the operating system saves its time to RTC. When computer is
booted operating system reads RTC time and sets operating system's
clock. The time is not accurate but at very least it's something instead
of random time. When operating system is running RTC does not matter
anymore.

To get operating system's clock have accurate time it needs to be
synchronized with network time servers via network time protocol (NTP).
Systemd has that feature. Turn in on with

sudo timedatectl set-ntp true

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462


signature.asc
Description: PGP signature

Re: strange time problem with bullseye

[Roy J. Tellason, Sr.]

On Wednesday 06 March 2024 12:37:09 am Teemu Likonen wrote:
> * 2024-03-06 02:47:06+0800, hlyg wrote:
> 
> > my newly-installed deb11 for amd64 shows wrong time,  it lags behind
> > correct time by 8 hours though difference between universal and local
> > is ok.
> 
> It seems that you have solved the problem but here is another hint.
> "timedatectl" is a good high-level tool for querying and adjusting time
> settings. Without command-line arguments it prints a lot of useful info:
> 
> $ timedatectl
>Local time: ke 2024-03-06 07:33:00 EET
>Universal time: ke 2024-03-06 05:33:00 UTC
>  RTC time: ke 2024-03-06 05:33:00
> Time zone: Europe/Helsinki (EET, +0200)
> System clock synchronized: yes
>   NTP service: active
>   RTC in local TZ: no
> 
> See "timedatectl -h" or manual page for more info.
> 

Mine shows:

  Local time: Wed 2024-03-06 12:09:44 EST
  Universal time: Wed 2024-03-06 17:09:44 UTC
RTC time: Wed 2024-03-06 17:20:53
   Time zone: America/New_York (EST, -0500)
 Network time on: yes
NTP synchronized: no
 RTC in local TZ: no

How do I get the RTC to agree with the right time?  I don't reboot this often,  
but when I do the time displayed on the onscreen clock is typically off by 
several minutes.

-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

Re: 404 Not Found Error Problem

[Stephen P. Molnar]

On 03/06/2024 09:09 AM, Greg Wooledge wrote:

On Wed, Mar 06, 2024 at 08:21:11AM -0500, Stephen P. Molnar wrote:

Not Found

The requested URL was not found on this server.
Apache/2.4.57 (Debian) Server at abnormal.att.net Port 80

I've installed WebMO a number of times and have not encountered this
particular problem before.

Are you "abnormal.att.net"?  Or at least pretending to be that host
in your error messages?

Or is your web browser going to that host, when you expected it to go
to localhost or something?

When I went to abnormal.att.net there was an index.html in /var/www/html 
that opened with the message that the installation was correct and that 
the index.hml should be removed.


After I deleted the file WebMO opened!

Problem solved.

Many thanks for your reply.

--
Stephen P. Molnar, Ph.D.
https://insilicochemistry.net
(614)312-7528 (c)
Skype:  smolnar1

Re: 404 Not Found Error Problem

[Greg Wooledge]

On Wed, Mar 06, 2024 at 08:21:11AM -0500, Stephen P. Molnar wrote:
> Not Found
> 
> The requested URL was not found on this server.
> Apache/2.4.57 (Debian) Server at abnormal.att.net Port 80
> 
> I've installed WebMO a number of times and have not encountered this
> particular problem before.

Are you "abnormal.att.net"?  Or at least pretending to be that host
in your error messages?

Or is your web browser going to that host, when you expected it to go
to localhost or something?

Re: 404 Not Found Error Problem

[Marco Moock]

Am 06.03.2024 schrieb "Stephen P. Molnar" :

> The requested URL was not found on this server.
> Apache/2.4.57 (Debian) Server at abnormal.att.net Port 80

Check the apache config.
What is the Webroot?

Is the file you are looking for available in the webroot?

404 Not Found Error Problem

[Stephen P. Molnar]

I am running a new installation of Bookworm and have encountered a 404 
Not Found error problem with WebMO (https://www.webmo.net):


Not Found

The requested URL was not found on this server.
Apache/2.4.57 (Debian) Server at abnormal.att.net Port 80

I've installed WebMO a number of times and have not encountered this 
particular problem before. There are complete installation instruction 
on the web page The installation process did not generate any warning or 
error messages. In fact a diagnose.html file is generated (attached) and 
shows no problems.


--
Stephen P. Molnar, Ph.D.
https://insilicochemistry.net
(614)312-7528 (c)
Skype:  smolnar1

<<< text/html; charset=UTF-8; name="diagnose.html": Unrecognized >>>

Re: strange time problem with bullseye

[Greg Wooledge]

On Wed, Mar 06, 2024 at 07:37:09AM +0200, Teemu Likonen wrote:
> It seems that you have solved the problem but here is another hint.
> "timedatectl" is a good high-level tool for querying and adjusting time
> settings. Without command-line arguments it prints a lot of useful info:
> 
> $ timedatectl
>Local time: ke 2024-03-06 07:33:00 EET
>Universal time: ke 2024-03-06 05:33:00 UTC
>  RTC time: ke 2024-03-06 05:33:00
> Time zone: Europe/Helsinki (EET, +0200)
> System clock synchronized: yes
>   NTP service: active
>   RTC in local TZ: no
> 
> See "timedatectl -h" or manual page for more info.

This is a great hint, but be warned that it doesn't quite know about
NTP services other than systemd-timesyncd.  If you're running ntpsec,
for example, it'll simply say:

System clock synchronized: yes
  NTP service: n/a

Re: strange time problem with bullseye

[Teemu Likonen]

* 2024-03-06 02:47:06+0800, hlyg wrote:

> my newly-installed deb11 for amd64 shows wrong time,  it lags behind
> correct time by 8 hours though difference between universal and local
> is ok.

It seems that you have solved the problem but here is another hint.
"timedatectl" is a good high-level tool for querying and adjusting time
settings. Without command-line arguments it prints a lot of useful info:

$ timedatectl
   Local time: ke 2024-03-06 07:33:00 EET
   Universal time: ke 2024-03-06 05:33:00 UTC
 RTC time: ke 2024-03-06 05:33:00
Time zone: Europe/Helsinki (EET, +0200)
System clock synchronized: yes
  NTP service: active
  RTC in local TZ: no

See "timedatectl -h" or manual page for more info.

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462


signature.asc
Description: PGP signature

Re: strange time problem with bullseye

[Jeffrey Walton]

On Tue, Mar 5, 2024 at 7:07 PM hlyg  wrote:
>
>  [...]
>
> Windows shall not cause problem, i rarely use Windows
>
> i don't know if ntp is running, what's default configuration by deb11
> amd64 installer?

If you are dual booting Linux and Windows, then see
<https://wiki.debian.org/DateTime#Windows_Dual_Boot_Strategy>.

Jeff

Re: strange time problem with bullseye

[hlyg]

Thank Greg Wooledge! it's solved with your help

i reboot to enter bios, it use UTC

then i change 3rd line of /etc/adjtime to UTC,  reboot to take effect, 
time is shown correctly now


i am timezone 0800, 8 hours ahead of GMT

both /etc/localtime points to same place

Re: strange time problem with bullseye

[Greg Wooledge]

On Tue, Mar 05, 2024 at 08:28:49PM +0800, hlyg wrote:
> Thank Greg Wooledge!
> 
> zhou@debian:~$ date
> Wed 06 Mar 2024 04:07:02 AM CST
> zhou@debian:~$ date -u
> Tue 05 Mar 2024 08:07:07 PM UTC
> 
> above is from deb11 for i386, it's correct

OK, and your time zone is 20 hours ahead of UTC, it appears.

> zhou@debian:~$ date
> Tue 05 Mar 2024 08:13:23 PM CST
> zhou@debian:~$ date -u
> Tue 05 Mar 2024 12:13:27 PM UTC
> 
> above is from deb11 for amd64, it's wrong, utc lag behind by 4 hours

Now this is odd-looking.  In this instance, your time zone is 4 hours
*behind* UTC instead of 20 hours ahead.  Which makes it off by exactly
one whole day.

Also, it *looks* like your i386 instance wrote UTC to the system clock,
and then your amd64 instance read that as local time.  You can see that
the 8:07:07 PM from the first instance is quite close to the 8:13:23 PM
from the second.

> Windows shall not cause problem, i rarely use Windows

The question isn't how often you use it, but whether you booted it in
between the two instances above.  Probably not, I suppose.

> i don't know if ntp is running, what's default configuration by deb11 amd64
> installer?

There is no "default".  Or rather, there are lots of defaults.  It's not
useful to ask about defaults.  Ask about what you have.

These are the packages that provide time-daemon on Debian 11:

systemd-timesyncd
openntpd
ntp
chrony

If one of those is installed and running, it should set your clock from
Internet sources (assuming it's configured reasonably, and you have
Internet access).

But more importantly, you need to check whether your Debian instances are
using local time or UTC for the real time clock, because it *looks* like
the i386 one is using UTC and the amd64 is not.

Check your /etc/adjtime files.

I'm also extremely curious why two different systems report "CST" with
two wildly different offsets from UTC.  What does
"ls -ld /etc/localtime" give on your systems?  Are they both the same?

Re: strange time problem with bullseye

[hlyg]

On 3/5/24 20:28, hlyg wrote:

Thank Greg Wooledge!

zhou@debian:~$ date
Wed 06 Mar 2024 04:07:02 AM CST
zhou@debian:~$ date -u
Tue 05 Mar 2024 08:07:07 PM UTC

above is from deb11 for i386, it's correct

zhou@debian:~$ date
Tue 05 Mar 2024 08:13:23 PM CST
zhou@debian:~$ date -u
Tue 05 Mar 2024 12:13:27 PM UTC

above is from deb11 for amd64, it's wrong, utc lag behind by 4 hours



Correction: utc is faster than correct by 4 hours

difference in minutes and seconds shall be neglected, because i run them 
in deb11 for i386, then reboot to amd64 and run them after a few minutes


these days i run only deb11 for i386 and amd64 on this machine, other OS 
shall not cause problem