You are not logged in.
Hello:
No too bad!;
No ...
Not at all.
10. Devuan
If you are still a fan of the old sysvinit, then Devuan might ...
These dicks are mixing potatoes with oranges, with a marked tendency to patronise to boot.
"... still a fan of the old sysvinit ... "
Really? 8^°
Why not say it like it really is:
"If, like a great many Linux users out there, you are not fan of systemd then Devuan will ..."
Best,
A.
Hello:
Old time favourite Memtest86+ has just released version 7.0.
https://www.theregister.com/2024/01/11/ … _released/
Version 7.0 has gained the ability to interrogate the integrated memory controller in Intel Core PCs (first to 14th generations) to find live memory timing information, as well as some preliminary support for obtaining error correction code (ECC) info on some models of AMD Ryzen.
Best,
A.
Hello HB:
... examine the DNS entry for topoi.pooq.com from outside ...
I guess it is this:
~$ nslookup -type=A topoi.pooq.com
Non-authoritative answer:
Name: topoi.pooq.com
Address: 69.165.131.134~$ nslookup -type=MX topoi.pooq.com
Non-authoritative answer:
topoi.pooq.com mail exchanger = 4 b.mx.pooq.com.
topoi.pooq.com mail exchanger = 2 w.mx.pooq.com.~$ nslookup -type=NS topoi.pooq.com
Non-authoritative answer:
*** Can't find topoi.pooq.com: No answer
Authoritative answers can be found from:
pooq.com
origin = b.ns.pooq.com
mail addr = hostmaster.pooq.com
serial = 1703367291
refresh = 16384
retry = 2048
expire = 1048576
minimum = 2560If you need something other than that, let me know.
Best,
A.
Hello HB:
... look into the SMTP configuration of the laptop I pressed into service ...
... trouble sending to gmail as well ...
Ah ...
Config trouble.
Sorry to have bothered ...
No bother at all.
... will provide a success message when I finally do succeed.
Please do.
I'm sure we'll learn something new.
... yet to receive a bounce notice ...
... post again when I receive it.
I have still not received anything.
Probably by tomorrow, when 24hrs. have passed. (?)
Edit:
Seems posts crossed paths ...
... landed in moderation and I deleted it as you instructed ...
At least it did arrive so something else is broken ...
Best,
A.
Hello HB:
... list software examine the DNS information of the sender ...
... capable of *sending* me the usual stream ...
... my DNS information better for sending me a message ...
... does it check for an incoming message ...
Just a guess ...
Could it be that the dyne.org system/software checks the sender's credentials ie: registered, etc. and if not rejects the message?
To be able to reject it, it has to be able to reply to the sender's email address which is why you are getting the error message.
I have sent a test message from an email account that is not registered at dng[at]lists.dyne.org.
That was roughtly 30' ago and it has not yet appeared on the list of 'newest messages'.
That is something that usually happens within one or two minutes if I send a message from the usual email address.
I have yet to receive a bounce notice from the that other email provider.
I will post again when I receive it.
Best,
A.
Hello:
xarchiver is very fast, very lean and still works.
Seems I have made some progress ...
See this bug report against PCManFM from long ago, aparently overlooked:
https://bugs.debian.org/cgi-bin/bugrepo … bug=932461
ie: File -> Compress would not work in PCManFM 1.3.1-1
So I followed the workaround instructions and edited /usr/share/libfm/archivers.list:
[xarchiver]
# create=xarchiver --add-to %F # create command is wrong
create=xarchiver --compress %F
extract=xarchiver --extract %F
extract_to=xarchiver --extract-to %d %FNow compress works and I can choose from a boatload of file types.
Talk about options. 8^°
But still no joy with Action -> Enter password, which remains greyed out.
Cannot find any information on that.
Maybe I would have to see if there is a PCManFM backport for beowulf?
Best,
A.
Hello:
What's wrong with 7z
I have not looked at it, but I was looking for a front end to the applications I have installed.
Thanks for your input.
Best,
A.
Hello:
... was about to ask you the same ...
Ahh ...
I had a look but found more or less the same.
Not at all convinced for the same reason.
ie: bloat
xarchiver is very fast, very lean and still works.
Not many abandoned applications can say the same.
eg: WiCD
I then came across ib/xarchiver:
Seems it is a ... continuation of the Xfce master branch.
But not a fork? Rather confusing, at least for me.
https://www.linuxlinks.com/xarchiver-fr … ing-tools/
https://github.com/ib/xarchiver#readme
There is no .deb package so has to be compiled, something 'ordinary' Dev1ers such as I will have to get used to soon enough.
I'd appreciate it if you could have a look and let me know what you think.
Thanks in advance.
Best,
A.
Hello:
... any evidence that xarchiver can do anything with encryption?
Yes.
What I meant was encryption or password.
Sorry if I expressed myself incorrectly.
https://xarchiver.sourceforge.net/doc/ch04s02.html
For the time being, I made a *.pdf in Acrobat 7 (XPSP3 VM) with a strong password.
Edit:
It would seem that xarchiver is (and has been) definitely abandoned for the longest while.
There are open bugs from 2008 and then there is this:
https://sourceforge.net/p/xarchiver/bugs/97/#e700
Thank you for your email but Xarchiver is definitely abandoned as there are
better archivers out there.
Giuseppe Torelli is the author.
https://xarchiver.sourceforge.net/
Any suggestions for a small footprint front end like xarchiver?
Thanks in advance.
Best,
A.
Hello:
I am attempting to use xarchiver 0.5.4.14 to create an encrypted / password protected file containing a QR image but the application has no option for doing that, no matter what file extension I chose.
From what I can see, all dependencies are met.
I'd appreciate any pointers.
Thanks in advance.
Best,
A.
Hello:
Just got this in my inbox.
Things 'X11' continue to roll along steadily. 8^)
Best,
A.
----
Announce: xterm-389 - 2024/01/01
Files:
https://invisible-island.net/archives/x … rm-389.tgz
https://invisible-island.net/archives/x … 89.tgz.asc
https://invisible-island.net/archives/x … 9.patch.gz
https://invisible-island.net/archives/x … tch.gz.asc
https://invisible-island.net/archives/x … rm-389.tgz
https://invisible-island.net/archives/x … 89.tgz.asc
Patch #389 - 2024/01/01
* interchange variables in subparameter parsing, fixing a bug where
subparameters after the first parameter could be misidentified
(patch by Adam Saponara).
* correct popping of icon/window titles in a case where only one was
pushed from patch #385 changes.
* add XTQMODKEYS response in DECRQSS, as alternative for vim.
* correct DECCIR encoded information on character set size, handle a
VT525 quirk, and add DECST8C (Windows Terminal #14984).
* improve DECRQCRA (prompted by discussion with James Holderness,
Windows Terminal #14974).
* add part of VT525 color controls:
+ DECAC, to update default foreground/background, respond to
DECRQSS
+ DECATC, to respond with DECRQSS
* prevent Unicode non-characters from being printed (prompted by
patch by Grady Martin).
* modify send_SGR() to avoid modifying colors 16 to 255 in printed
output (patch by Grady Martin).
* minor cleanup of miscellaneous error-codes with ERROR_MISC.
* remove legacy CSI 53 for locator status, corrected in patch #294.
* modify DECRQUPSS and DECAUPSS feature to support VT5xx character
sets (report by Thomas Wolff).
* improve configure script:
+ reduce configure-check compiler warnings (prompted by Florian
Weimer, Redhat #2251945)
+ improve usage messages in configure script to make it clearer
when an option value is optional.
* improve EWMH handling (report/analysis by Edward Rosten)
+ reset _NET_WM_STATE_HIDDEN flag from _NET_WM_STATE before
mapping the window to deiconify.
+ cache X properties to reduce latency (adapted from patch by
Edward Rosten).
----
Hello:
.. fully admit his days are indeed numbered ...
It is an undeniable trait of humanity the failure to acknowledge that the days of each one of us are indeed numbered.
Eons go by and it remains the same, unchanged.
Literature of all kinds, from all ages, civilizations and beliefs attest to that.
So worry not and enjoy+thank life for the wonderful gift you have been bestowed.
Merry [fill in] and a Happy [fill in] for you and your father.
Best,
A.
Hello:
... 100yr-old father computing for another year
Great!
Good for you. 8^D
But ...
Why just another year?
... beowulf and evolution mail client version 3.30.5
And?
I use Devuan Beowulf on a backported kernel on a Sun U24 box from 2007 (Intel Q9550/8Gb).
~$ uname -a
Linux devuan 5.10.0-0.deb10.16-amd64 #1 SMP Debian 5.10.127-2~bpo10+1 (2022-07-28) x86_64 GNU/Linux
~$ Both the box and I run perfectly well, for the time being.
I have no need for Daedalus or one of those newfangled webmail clients (wft invented that crap, MS?).
I have used Pegasus Mail (POP3/SMTP) for the last 25+ years and don't plan to stop using it.
... hates any/all change ...
I can very easily relate to that.
And I still have 30 to go till I reach 100.
... thoughts?
My thoughts, YMMV:
I lost my father when he turned 82 back in 2010, would have turned 95 next June.
Your still having yours at 100 and using a computer is a luxury life is very generously gifting you with.
Learn to appreciate it
Bottom line?
Do not fuck around with a 100 year old chap's OS or email client.
Just do proper maintenance, help him out when needed and otherwise leave him and his box to their doings.
Best,
A.
Hello:
I have no intention of bringing such a controversial (and OT) subject to the forum.
So I will limit my comment to this and nothing more:
The laws of the market work.
Surely you jest ... 8^°
Or are totally unaware of what the 'market' and its supposed 'laws' have done to/with the world's economy since the early 80's.
A.
Hello:
I suggest you install xrestop to see exactly what is going on and maybe find the source of the issue.
https://www.freedesktop.org/wiki/Software/xrestop/
That said, do you by chance have conky running?
If so, it could be causing a memory leak.
Check here.
Best,
A.
Hello:
... would be the ultimate identity death of Debian ...
If you look carefully and from (just a bit) further away, you will come to realise that such a thing has already started.
Just what do you think systemd and all the Linux friendly moves from the Redmond camp actually amount to?
And just who do you think are bankrolling all of it?
Redmond and their time proven "Embrace, extend, and extinguish" (EEE) never ceased.
It has always been there, laying dormant and now has set the stage to rear its ugly head again.
Meanwhile, the rest of Linuxland is furiously defending choice without coming to terms with the fact that a dead OS has no use for choice.
Yes, I know ...
But it is that time of the year, is it not?
Of course and as always, YMMV.
Best,
A.
Hello:
News from The Register:
--------------------------------------------------------------------------------------------
Debian preps ground to drop 32-bit x86 as separate edition
Bad news for several downstream distros, but good news for NetBSD
By Liam Proven Tue 19 Dec 2023 // 16:30 UTC
--------------------------------------------------------------------------------------------
https://www.theregister.com/2023/12/19/ … op_x86_32/
After a recent meetup in Cambridge, Debian developers are discussing how to start gradually dropping 32-bit x86 support.
---
The news is in a section titled "A future for the i386 architecture":
Insofar as they still do, we anticipate that the kernel, d-i and images teams will cease to support i386 in the near future.
Best,
A.
... delete ChatGPT messages?
Ab - so - lu - te - ly
Rather dissapointing to see such a question asked here at Dev1.
But here we are.
A.
Hello:
Just got this in my inbox.
Good to see that things 'X11' are rolling along steadily.
Best,
A.
========================================================================
X.Org Security Advisory: December 13, 2023
Issues in X.Org X server prior to 21.1.10 and Xwayland prior to 23.2.3
========================================================================
Multiple issues have been found in the X server and Xwayland implementations
published by X.Org for which we are releasing security fixes for in
xorg-server-21.1.10 and xwayland-23.2.3.
1) CVE-2023-6377 can be triggered by forcing a logical device change on a device
with buttons which will result in an out-of-bounds memory write.
2) CVE-2023-6478 can be triggered by sending a specially crafted
request RRChangeProviderProperty or RRChangeOutputProperty. This will trigger
an integer overflow and lead to disclosure of information.
------------------------------------------------------------------------------------------------------------------------------
1) CVE-2023-6377: X.Org server: Out-of-bounds memory write in XKB button actions
Introduced in: xorg-server-1.6.0 (2009)
Fixed in: xorg-server-21.1.10 and xwayland-23.2.3
Fix: https://gitlab.freedesktop.org/xorg/xse … 4f93810afd
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
A device has XKB button actions for each button on the device. When a logical
device switch happens (e.g. moving from a touchpad to a mouse), the server
re-calculates the information available on the respective master device
(typically the Virtual Core Pointer). This re-calculation only allocated enough
memory for a single XKB action rather instead of enough for the newly active
physical device's number of button. As a result, querying or changing the XKB
button actions results in out-of-bounds memory reads and writes.
This may lead to local privilege escalation if the server is run as root or
remote code execution (e.g. x11 over ssh).
xorg-server-21.1.10 and xwayland-23.2.3 have been patched to fix this issue.
2) CVE-2023-6478: X.Org server: Out-of-bounds memory read in RRChangeOutputProperty and RRChangeProviderProperty
Introduced in: xorg-server-1.4.0 (2007) and xorg-server-1.13.0 (2012), respectively
Fixed in: xorg-server-21.1.10 and xwayland-23.2.3
Fix: https://gitlab.freedesktop.org/xorg/xse … fff81ad632
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
This fixes an OOB read and the resulting information disclosure.
Length calculation for the request was clipped to a 32-bit integer. With
the correct stuff->nUnits value the expected request size was
truncated, passing the REQUEST_FIXED_SIZE check.
The server then proceeded with reading at least stuff->nUnits bytes
(depending on stuff->format) from the request and stuffing whatever it
finds into the property. In the process it would also allocate at least
stuff->nUnits bytes, i.e. 4GB.
See also CVE-2022-46344 where this issue was fixed for other requests.
xorg-server-21.1.10 and xwayland-23.2.3 have been patched to fix this issue.
------------------------------------------------------------------------------------------------------------------------------
Hello:
News from The Register:
---
Systemd 255 is here with improved UKI support
This is release 0b11111111 (0xFF) – what could possibly go wrong?
By Liam Proven - Fri 8 Dec 2023 // 11:43 UTC
---
---
https://www.theregister.com/2023/12/08/ … 5_is_here/
---
The 255th version of systemd is here, banishing support for split and unmerged /usr directories but enriching its UKI boot support.
... this release requires* distributions to have completed the /usr merge process.
* emphasis by article's author
Best,
A.
Hello:
News from The Register:
---
Wayland takes the wheel as Red Hat bids farewell to X.org
Firefox 121, freshly in beta test, will default to the protocol too
By Liam Proven - Wed 29 Nov 2023 // 15:28 UTC
---
https://www.theregister.com/2023/11/29/ … pping_x11/
---
Reads rather foreboding, but the hack is rather fond of systemd based distributions, so I really don't know how impartial his opinion is.
Best,
A.
Hello:
... anyone here give me some idea as to what could be causing this?
ie: what all this means.
Hmm ....
Maybe with some additional information?
For the sake of clarity/brevity I will skip the long story:
1.
Discovered the problem and rolled back to a VM snapshot from 30 days
ago, the oldest one I have.
Concurrently, rolled back to VBox (7.0.6) along with its
GuestAdditions 7.0.6.
I thought that it would rule out (?) a VBox update or some corruption
in the XPSP3 VM as everything happened way after that date.
At least I did not notice it as I do not use the XP VM often.
Problem did *not* go away.
2.
Removed VBox 7.0.6 / GuestAdditions 7.0.6, reinstalled the latest
available (7.0.12) along with GuestAdditions and the Extension Pack
which was missing.
Problem did *not* go away.
3.
Went back to the last snapshot and tried to fix things by mucking
around the XPSP3 installation but only managed to screw it up even
more.
The net result being that it is now on a 'black screen select how to
boot' and 'blue screen with whatever' loop.
4.
I attempted to add a new XP VM using three or four of the
downloadable XP isos I found on the web and was able to install one
of them as a VM.
Problem did *not* go away and shutdown does not work.
Not even shutting down X via ctrl+backspace.
Have to reboot my box.
TL;DR
The problem exists whether I use VirtualBox 7.06 or 7.0.12, with a
recovered version of the VM or the latest one.
Installing a new XPSP3 VM, whether in VirtualBox 7.0.6 or 7.0.12,
complete with GA+EP does not solve the problem.
In all cases, disconnecting the host from the web (cable and all)
does not solve the problem so phoning home does not seem to be a
posible cause.
This is (part of) what I get in a rolling dmesg screen:
------------[ cut here ]------------
--- snip ---
WARNING: CPU: 0 PID: 16511 at arch/x86/kernel/fpu/core.c:129
kernel_fpu_begin_mask+0xc9/0xe0
--- snip ---
Call Trace:
[ +0.000031] SUPR0FpuBegin+0x13/0x20 [vboxdrv]
[ +0.000006] ? up+0x12/0x50
[ +0.000014] ? VBoxHost_RTThreadCtxHookEnable+0x32/0x40 [vboxdrv]
[ +0.000012] ? supdrvIOCtl+0xc5e/0x3650 [vboxdrv]
[ +0.000013] ? rtR0MemAllocEx+0x57/0xd0 [vboxdrv]
[ +0.000012] ? supdrvIOCtlFast+0x58/0xb0 [vboxdrv]
[ +0.000011] ? VBoxDrvLinuxIOCtl_7_0_12+0x57/0x230 [vboxdrv]
[ +0.000003] ? __x64_sys_ioctl+0x84/0xc0
[ +0.000004] ? do_syscall_64+0x33/0x80
[ +0.000003] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ +0.000002] ---[ end trace 2d76295c57757cc8 ]---The warning is always the same.
ie:
at arch/x86/kernel/fpu/core.c:129 kernel_fpu_begin_mask+0xc9/0xe0
The call trace starts with the same line.
ie:
SUPR0FpuBegin+0x13/0x20 [vboxdrv]
And it is all about the same module:
ie:
? VBoxHost_RTThreadCtxHookEnable+0x32/0x40 [vboxdrv]
? VBoxHost_RTThreadCtxHookEnable+0x32/0x40 [vboxdrv]
? supdrvIOCtlFast+0x58/0xb0 [vboxdrv]
? VBoxDrvLinuxIOCtl_7_0_12+0x57/0x230 [vboxdrv]~$ lsmod | grep vbox
vboxnetadp 28672 0
vboxnetflt 32768 1
vboxdrv 589824 4 vboxnetadp,vboxnetflt # <- this one
~$ One of the important packages updated lately was linux-kbuild.
ie: 5.10.179-5~deb10u1 to 5.10.197-1~deb10u1
I understand that it is closely related to module handling by the kernel.
If anyone has a clue as to what the trace in dmesg indicates, I'm
all ears.
Thanks in advance.
Best.
A.
Hello:
After some problems with my XPSP3 VM crashing, I am now getting this printout every time I start the VM.
All this runs under VirtualBox Version 7.0.12 r159484 from the VirtualBox repository.
This happens (no surprise) with XPSP3, stopping and restarting a Chimaera headless VM does not have this problem, so it would seem to be limited to the Windows VM.
commands
~$ vboxmanage list vms
"groucho xp" {e2bdf021-b1a1-49b8-8ec9-3d4a5d194751}
"madmax chimaera" {9a65cf7c-2559-40de-a17e-8d1ab90871e6}
~$
~$ vboxmanage controlvm "madmax chimaera" poweroff
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
~$
~$ vboxmanage startvm "madmax chimaera" --type headless
Waiting for VM "madmax chimaera" to power on...
VM "madmax chimaera" has been successfully started.
~$ dmesg rolling printout
--- snip ---
[ +0.000002] ---[ end trace 1be0adc72d562557 ]---
[Nov24 14:49] device eth0 left promiscuous mode
[ +0.031478] vboxnetflt: 454 out of 45463 packets were not sent (directed to host)
[ +20.695654] vboxdrv: 000000001ad1bd93 VMMR0.r0
[ +0.123945] vboxdrv: 00000000d078db46 VBoxDDR0.r0
[ +0.040694] VBoxNetFlt: attached to 'eth0' / 00:14:4f:4a:a2:81
[ +0.041263] device eth0 entered promiscuous modeThis is the dmesg rolling printout when I start the XPSP3 VM:
[Nov24 14:40] ------------[ cut here ]------------
[ +0.000012] WARNING: CPU: 0 PID: 24553 at arch/x86/kernel/fpu/core.c:129 kernel_fpu_begin_mask+0xc9/0xe0
[ +0.000001] Modules linked in: nls_ascii nls_cp437 vfat fat uas usb_storage usblp fuse vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) autofs4 binfmt_misc nfsd auth_rpcgss nfs_acl nfs lockd grace nfs_ssc fscache sunrpc drivetemp snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_intel_dspcfg soundwire_intel soundwire_generic_allocation uvcvideo snd_soc_core snd_usb_audio coretemp videobuf2_vmalloc videobuf2_memops snd_compress snd_usbmidi_lib videobuf2_v4l2 soundwire_cadence videobuf2_common kvm_intel snd_rawmidi snd_hda_codec videodev kvm snd_hda_core snd_seq_device snd_hwdep irqbypass pcspkr nvidia(POE) serio_raw mc joydev soundwire_bus at24 snd_pcm_oss snd_mixer_oss snd_pcm drm snd_timer snd soundcore evdev x38_edac acpi_cpufreq ext4 crc16 mbcache jbd2 crc32c_generic hid_logitech_hidpp hid_logitech_dj sg hid_generic sd_mod usbhid t10_pi crc_t10dif crct10dif_generic hid crct10dif_common mptsas ahci mptscsih libahci xhci_pci aic7xxx libata mptbase uhci_hcd ehci_pci
[ +0.000069] xhci_hcd scsi_transport_sas scsi_transport_spi e1000e ehci_hcd i2c_i801 i2c_smbus scsi_mod ptp usbcore usb_common pps_core button
[ +0.000015] CPU: 0 PID: 24553 Comm: EMT-0 Tainted: P OE 5.10.0-0.deb10.16-amd64 #1 Debian 5.10.127-2~bpo10+1
[ +0.000002] Hardware name: Sun Microsystems Ultra 24/Ultra 24, BIOS 1.56 01/21/2011
[ +0.000002] RIP: 0010:kernel_fpu_begin_mask+0xc9/0xe0
[ +0.000003] Code: c4 10 5b c3 65 8a 05 7e 5f 9e 4d 84 c0 74 92 0f 0b eb 8e f0 80 4f 01 40 48 81 c7 40 14 00 00 e8 dd fb ff ff eb a5 db e3 eb c4 <0f> 0b e9 7b ff ff ff e8 bb 23 85 00 66 66 2e 0f 1f 84 00 00 00 00
[ +0.000002] RSP: 0018:ffffba77c3f9fb30 EFLAGS: 00010002
[ +0.000002] RAX: 0000000080000001 RBX: 0000000000000003 RCX: ffffba77c7819000
[ +0.000002] RDX: 0000000000000000 RSI: ffffba77c793d000 RDI: 0000000000000003
[ +0.000001] RBP: ffffba77c3f9fb50 R08: 0000000000000000 R09: 0000000000000010
[ +0.000002] R10: ffffba77c3ffc000 R11: 0000000000000000 R12: ffffba77c793d000
[ +0.000002] R13: ffffba77c1a969e0 R14: 0000000000000000 R15: ffffba77c793d000
[ +0.000002] FS: 00007f81c54f8700(0000) GS:ffff95f473c00000(0000) knlGS:0000000000000000
[ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ +0.000001] CR2: 00000000e1042000 CR3: 000000013f1c4000 CR4: 00000000000426f0
[ +0.000002] Call Trace:
[ +0.000030] SUPR0FpuBegin+0x13/0x20 [vboxdrv]
[ +0.000006] ? up+0x12/0x50
[ +0.000004] ? irq_exit_rcu+0x3e/0xa0
[ +0.000002] ? sysvec_apic_timer_interrupt+0x34/0x80
[ +0.000014] ? VBoxHost_RTThreadCtxHookEnable+0x32/0x40 [vboxdrv]
[ +0.000003] ? update_load_avg+0x7e/0x5c0
[ +0.000012] ? supdrvIOCtlFast+0x58/0xb0 [vboxdrv]
[ +0.000011] ? VBoxDrvLinuxIOCtl_7_0_12+0x57/0x230 [vboxdrv]
[ +0.000003] ? __schedule+0x2c6/0x770
[ +0.000003] ? __x64_sys_ioctl+0x84/0xc0
[ +0.000003] ? do_syscall_64+0x33/0x80
[ +0.000002] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ +0.000003] ---[ end trace 1be0adc72d562556 ]---Can anyone here give me some idea as to what could be causing this?
ie: what all this means.
Thanks in advance.
Best,
A.
Hello:
... will try with a USB flash drive ...
tl,dr
I was able to trace the issue to a power supply problem.
ie: I overestimated the power supplied by the lead to the now archived OEM DVD writer.
As a result, the installer checking the integrity of a large file made for a sustained peak that was not met by that lead.
That is why it repeatedly failed at the same place.
Once I removed the hardware causing this, that problem went away.
But another problem remains.
The process of copying from the USB installer media and writing to the destination USB drive seems to cause the same problem as it gets stuck at 32% when installing the base files which means I need to relocate the extra hardware feeding from the DVD power plug.
Best,
A.
Hello:
... a file like this in /etc/logrotate.d ...
... rotate the file weekly and keep ...
In my opinion, there's no need to keep .xsession.errors files.
They are generated every time the xserver is started and the last one is appended to the previous one, which is why it can grow to huge sizes.
Limiting the .xsession-errors file to any size you deem suitable while keeping the last NNN lines will get you all the information you may need/want to see if you are up to doing some serious debugging.
That said, even with that setup, much if not all of the information shown is of no value to the average desktop user.
ie: not a maintainer/developer.
In my case, practically all of it is made up of (endessly repeating) Gtk-WARNING entries for which the only solution would seem to be some fix in a future version of Gtk (?).
eg:
(wrapper-2.0:2996): Gtk-WARNING **: 06:29:35.182: Theme parsing error: <data>:1:49: The style property GtkWidget:focus-padding is deprecated and shouldn't be used anymore. It will be removed in a future version
--- snip ---
(volumeicon:2859): Gtk-WARNING **: 06:29:34.463: Theme parsing error: gtk-widgets.css:1344:25: The style property GtkRange:slider-width is deprecated and shouldn't be used anymore. It will be removed in a future version
--- snip ---
(Firefox-esr:3339): Gtk-WARNING **: 06:30:12.326: Theme parsing error: gtk-widgets.css:1347:28: The style property GtkRange:stepper-spacing is deprecated and shouldn't be used anymore. It will be removed in a future versionIn the five or so years I have dealt with the .xsession-errors file, I've only found one warning I was able to fix.
It was related to a double-buffer setting in the conky.conf file, a mistake on my part when editing/adding some modifications.
As always, YMMV.
Best,
A.