16 Dec
2024
16 Dec
'24
5:24 a.m.
Greetings, one and all.
Not even remotely a TDE problem, but you lot are known to throw a float to a drowning man
even if he fell off some other boat.
System is an Asus vanilla AMD-64 running Debian Trixie and TDE Testing. Was running fine,
long uptimes. Got up yesterday to an exploded reboot, so something had taken place during
the night. Did a power-off reboot. Now it booted to the point of /dev/sda1 clean. Tried a
reboot from grub using linux advanced mode. Once I got it to boot all the way in rescue
mode. Fiddled around, found nothing wrong, rebooted. That's the last time I saw TDE.
Poking around, I saw a case similar to mine in which it was suggested that the bios needed
upgrading. I looked, and the date on my bios was in 2013, leading ne to think it was
possible that this was true, even though I'd changed nothing since it had been booting
just fine. So on another machine I d/led the latest bios file and flashed it. Which of
course wiped all my settings because bioses seem to be dumb.
Now, when I start the machine it of course has the bios banner, and then grub, and then:
ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has valid Length but zero
Address: 0x[many zeros]/0x1 (20240322/tbfadt-611)
amd_pstate: the_CPC object is not present in SBIOS or ACPI disabled
r8169 0000:05:00.0: can't disable ASPM; OS doesn't have ASPM control
/dev/sda1: recovering journal
/dev/sda1: clean, 435913/4579328 files, 5183079/18310546 blocks
If I do a warm reboot, it dies at the bios banner. After a minute it tells me the boot
device (normal hard drive) is not supported and to set the comparability mode, press F1 to
set it. Which I do, and bext boot gives me:
grub>
Which is no use at all so I reboot and now again have a normal grub menu. This time I
select Advanced mode for my Linux boot. Now it boots happily along. And I can boit into
Debian, TDE, the whole works, though now I am in rescue mode (which looks and acts just
like any ordinary boot).
Which is where I am now. In slight terror it will crash again, but otherwise wondering how
I can proceed to make things normal again,
Anyone have any ideas?
dep
Pictures: http://www.ipernity.com/doc/depscribe/album
Column: https://ofb.biz/author/dep/
16 Dec
16 Dec
6:02 a.m.
dep composed on 2024-12-16 05:24 (UTC):
Not even remotely a TDE problem, but you lot are known
to throw a float to a drowning man even if he fell off some other boat.
System is an Asus vanilla AMD-64 running Debian Trixie
and TDE Testing. Was running fine, long uptimes. Got up yesterday to an exploded reboot,
so something had taken place during the night. Did a power-off reboot. Now it booted to
the point of /dev/sda1 clean. Tried a reboot from grub using linux advanced mode. Once I
got it to boot all the way in rescue mode. Fiddled around, found nothing wrong, rebooted.
That's the last time I saw TDE.
Poking around, I saw a case similar to mine in which
it was suggested that the bios needed upgrading. I looked, and the date on my bios was in
2013, leading ne to think it was possible that this was true, even though I'd changed
nothing since it had been booting just fine. So on another machine I d/led the latest bios
file and flashed it. Which of course wiped all my settings because bioses seem to be dumb.
Now, when I start the machine it of course has the
bios banner, and then grub, and then:
ACPI BIOS Warning (bug): Optional FADT field
Pm2ControlBlock has valid Length but zero Address: 0x[many zeros]/0x1
(20240322/tbfadt-611)
amd_pstate: the_CPC object is not present in SBIOS or ACPI disabled
r8169 0000:05:00.0: can't disable ASPM; OS doesn't have ASPM control
/dev/sda1: recovering journal
/dev/sda1: clean, 435913/4579328 files, 5183079/18310546 blocks
If I do a warm reboot, it dies at the bios banner.
After a minute it tells me the boot device (normal hard drive) is not supported and to set
the comparability mode, press F1 to set it. Which I do, and bext boot gives me:
grub>
Which is no use at all so I reboot and now again have
a normal grub menu. This time I select Advanced mode for my Linux boot. Now it boots
happily along. And I can boit into Debian, TDE, the whole works, though now I am in rescue
mode (which looks and acts just like any ordinary boot).
Which is where I am now. In slight terror it will
crash again, but otherwise wondering how I can proceed to make things normal again,
Anyone have any ideas?
UEFI BIOS are known to have a myriad of possible bugs, especially older ones, like
from 2013. BIOS updates are known to have risks. Motherboard makers historically
have recommended to skip them unless yours is known to have particular problem
solved by a newer BIOS. As when UEFI booting, booting is under the control of the
UEFI firmware, and the content of NVRAM, corruption of it upon upgrade poses a
high risk of things like what happened to you. Are your Trixie and Sid installed
in UEFI mode? If yes, show us output from efibootmgr -v. You may need to purge
some junk from NVRAM and/or add a new Trixie or Sid NVRAM entry using efibootmgr
to re-institute predicable boot behavior.
Check your installations for automatic upgrades to installation and/or firmware.
One of these could be the reason why the reboot explosion. I disable and or purge
such things from my installations. They're mine. I decide if and when it's time
for things like upgrades or new kernel additions to occur on mine.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
6:25 a.m.
said Felix Miata via tde-users:
| UEFI BIOS are known to have a myriad of possible bugs, especially older
| ones, like from 2013. BIOS updates are known to have risks. Motherboard
| makers historically have recommended to skip them unless yours is known
| to have particular problem solved by a newer BIOS. As when UEFI booting,
| booting is under the control of the UEFI firmware, and the content of
| NVRAM, corruption of it upon upgrade poses a high risk of things like
| what happened to you. Are your Trixie and Sid installed in UEFI mode? If
| yes, show us output from efibootmgr -v. You may need to purge some junk
| from NVRAM and/or add a new Trixie or Sid NVRAM entry using efibootmgr
| to re-institute predicable boot behavior.
Here's the output:
BootCurrent: 0004
Timeout: 0 seconds
BootOrder: 0004,0000,0001,0002,0003
Boot0000* ubuntu
HD(4,GPT,f3d5923e-cff9-4b47-beb9-be3a8442e1a0,0x800,0x96000)/File(\EFI\ubuntu\shimx64.efi)
dp: 04 01 2a 00 04 00 00 00 00 08 00 00 00 00 00 00 00 60 09 00 00 00
00 00 3e 92 d5 f3 f9 cf 47 4b be b9 be 3a 84 42 e1 a0 02 02 / 04 04 34 00
5c 00 45 00 46 00 49 00 5c 00 75 00 62 00 75 00 6e 00 74 00 75 00 5c 00 73
00 68 00 69 00 6d 00 78 00 36 00 34 00 2e 00 65 00 66 00 69 00 00 00 / 7f
ff 04 00
Boot0001* UEFI OS
HD(4,GPT,f3d5923e-cff9-4b47-beb9-be3a8442e1a0,0x800,0x96000)/File(\EFI\BOOT\BOOTX64.EFI)
dp: 04 01 2a 00 04 00 00 00 00 08 00 00 00 00 00 00 00 60 09 00 00 00
00 00 3e 92 d5 f3 f9 cf 47 4b be b9 be 3a 84 42 e1 a0 02 02 / 04 04 30 00
5c 00 45 00 46 00 49 00 5c 00 42 00 4f 00 4f 00 54 00 5c 00 42 00 4f 00 4f
00 54 00 58 00 36 00 34 00 2e 00 45 00 46 00 49 00 00 00 / 7f ff 04 00
Boot0002* ubuntu
HD(4,GPT,f3d5923e-cff9-4b47-beb9-be3a8442e1a0,0x800,0x96000)/File(EFI\Ubuntu\grubx64.efi)
dp: 04 01 2a 00 04 00 00 00 00 08 00 00 00 00 00 00 00 60 09 00 00 00
00 00 3e 92 d5 f3 f9 cf 47 4b be b9 be 3a 84 42 e1 a0 02 02 / 04 04 32 00
45 00 46 00 49 00 5c 00 55 00 62 00 75 00 6e 00 74 00 75 00 5c 00 67 00 72
00 75 00 62 00 78 00 36 00 34 00 2e 00 65 00 66 00 69 00 00 00 / 7f ff 04
00
Boot0003* Hard Drive BBS(HD,,0x0)
414d474f414d4e4faf000000010000006f0057004400430020005700440036003000300033004600520059005a002d00300031004600300044004200300000000501090002000000007fff040002010c00d041030a0000000001010600001103120a000000ffff00007fff040001043e00ef47642dc93ba041ac194d51d01b4ce6390056004500480030004c004c00320020002000200020002000200020002000200020002000200000007fff0400414d424f
dp: 05 01 09 00 02 00 00 00 00 / 7f ff 04 00
data: 41 4d 47 4f 41 4d 4e 4f af 00 00 00 01 00 00 00 6f 00 57 00 44 00
43 00 20 00 57 00 44 00 36 00 30 00 30 00 33 00 46 00 52 00 59 00 5a 00 2d
00 30 00 31 00 46 00 30 00 44 00 42 00 30 00 00 00 05 01 09 00 02 00 00 00
00 7f ff 04 00 02 01 0c 00 d0 41 03 0a 00 00 00 00 01 01 06 00 00 11 03 12
0a 00 00 00 ff ff 00 00 7f ff 04 00 01 04 3e 00 ef 47 64 2d c9 3b a0 41 ac
19 4d 51 d0 1b 4c e6 39 00 56 00 45 00 48 00 30 00 4c 00 4c 00 32 00 20 00
20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 00 00 7f
ff 04 00 41 4d 42 4f
Boot0004* debian
HD(4,GPT,f3d5923e-cff9-4b47-beb9-be3a8442e1a0,0x800,0x96000)/File(\EFI\debian\shimx64.efi)
dp: 04 01 2a 00 04 00 00 00 00 08 00 00 00 00 00 00 00 60 09 00 00 00
00 00 3e 92 d5 f3 f9 cf 47 4b be b9 be 3a 84 42 e1 a0 02 02 / 04 04 34 00
5c 00 45 00 46 00 49 00 5c 00 64 00 65 00 62 00 69 00 61 00 6e 00 5c 00 73
00 68 00 69 00 6d 00 78 00 36 00 34 00 2e 00 65 00 66 00 69 00 00 00 / 7f
ff 04 00
In that I don't have ubuntu on the machine anymore, and haven't for awhile,
I'm a little bit surprised that it's there. I do not know which of the
other three I should keep. Ever since the big BIOS rejiggering of a decade
ago, what once was clear has been a mystery to me. So in addition to not
knowing which one(s) to keep, I have no idea how to get rid of any I don't
want or need. Suggestions, advice, or knowledge from the above?
| Check your installations for automatic upgrades to installation and/or
| firmware. One of these could be the reason why the reboot explosion. I
| disable and or purge such things from my installations. They're mine. I
| decide if and when it's time for things like upgrades or new kernel
| additions to occur on mine.
I do not have anything set to automatically upgrade, for exactly the reason
you state. And I should note that the problem appeared before the BIOS
upgrade -- which from the date brought me clear to 2014 -- which does seem
to have been successful.
--
dep
Pictures: http://www.ipernity.com/doc/depscribe/album
Column: https://ofb.biz/author/dep/
9:58 a.m.
dep composed on 2024-12-16 06:25 (UTC):
BootCurrent: 0004
Timeout: 0 seconds
BootOrder: 0004,0000,0001,0002,0003
Boot0000* ubuntu
HD(4,GPT,f3d5923e-cff9-4b47-beb9-be3a8442e1a0,0x800,0x96000)/File(\EFI\ubuntu\shimx64.efi)
Boot0001* UEFI OS
HD(4,GPT,f3d5923e-cff9-4b47-beb9-be3a8442e1a0,0x800,0x96000)/File(\EFI\BOOT\BOOTX64.EFI)
Boot0002* ubuntu
HD(4,GPT,f3d5923e-cff9-4b47-beb9-be3a8442e1a0,0x800,0x96000)/File(EFI\Ubuntu\grubx64.efi)
Boot0003* Hard Drive BBS(HD,,0x0)
Boot0004* debian
HD(4,GPT,f3d5923e-cff9-4b47-beb9-be3a8442e1a0,0x800,0x96000)/File(\EFI\debian\shimx64.efi)
In that I don't have ubuntu on the machine
anymore, and haven't for awhile,
I'm a little bit surprised that it's there. I do not know which of the
other three I should keep. Ever since the big BIOS rejiggering of a decade
ago, what once was clear has been a mystery to me. So in addition to not
knowing which one(s) to keep, I have no idea how to get rid of any I don't
want or need. Suggestions, advice, or knowledge from the above?
1 & 3 are fallbacks that should have no need to disturb. As Ubuntu is no longer
present on the system, then can be removed using efibootmgr, which provides a man
page.
dep composed on 2024-12-16 06:47 (UTC):
strangely, memtest no longer appears in my grub menu,
and i have no memtest
executable.
memtest86+ is in the boot menu of most GNU/Linux installation media. There's also
memtest86 in both free and nonfree versions that I have more faith in for use with
UEFI PCs and Macs using DDR4 and newer RAM: https://www.memtest86.com/
> IMO when things die unexpectidly while powered up
it's
> hdd/ram/somecard/mainboard in this order.
Dr. Klepp left PSUs out of that list.
we'll see if it repeats. i very much hope it
doesn't. i wondered if a log
i've had running -- a ping every three seconds with the result written to
disk -- might have stressed something. and it has on occasion over the
years suffered from what seems to be something overheating, such as when
it tries to compile a heap of nvidia modules.
Failing electrolytic capacitors are notorious causes of random system failure.
Most caps on motherboards made around 12 or less years ago have been replaced by
polys that are magnitudes more reliable. An Asus from 2013 probably has only
polys, or polys for all the most important ones. OTOH, you're unlikely to find
anything but electrolytics in power supplies and various addon components. If your
PSU is out of warranty, get its cover off to inspect for leakage and swelling. If
you find swollen tops, or obvious leakage, not to be confused with splattered
glue, they or your PSU need to be replaced. Not all electrolytics manifest obvious
signs of failure. Major brand names are not a guarantee that any given PSU was
made entirely of quality parts to start with. Cheap PSUs often provided with
budget cases are unlikely to have any quality caps. Visit badcaps.net for details
on evaluating what you find.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
6:16 a.m.
Anno domini 2024 Mon, 16 Dec 05:24:39 +0000
dep via tde-users scripsit:
Greetings, one and all.
Not even remotely a TDE problem, but you lot are known to throw a float to a drowning man
even if he fell off some other boat.
System is an Asus vanilla AMD-64 running Debian Trixie and TDE Testing. Was running fine,
long uptimes. Got up yesterday to an exploded reboot, so something had taken place during
the night. Did a power-off reboot. Now it booted to the point of /dev/sda1 clean. Tried a
reboot from grub using linux advanced mode. Once I got it to boot all the way in rescue
mode. Fiddled around, found nothing wrong, rebooted. That's the last time I saw TDE.
Poking around, I saw a case similar to mine in which it was suggested that the bios
needed upgrading. I looked, and the date on my bios was in 2013, leading ne to think it
was possible that this was true, even though I'd changed nothing since it had been
booting just fine. So on another machine I d/led the latest bios file and flashed it.
Which of course wiped all my settings because bioses seem to be dumb.
Now, when I start the machine it of course has the bios banner, and then grub, and then:
ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has valid Length but zero
Address: 0x[many zeros]/0x1 (20240322/tbfadt-611)
amd_pstate: the_CPC object is not present in SBIOS or ACPI disabled
r8169 0000:05:00.0: can't disable ASPM; OS doesn't have ASPM control
/dev/sda1: recovering journal
/dev/sda1: clean, 435913/4579328 files, 5183079/18310546 blocks
If I do a warm reboot, it dies at the bios banner. After a minute it tells me the boot
device (normal hard drive) is not supported and to set the comparability mode, press F1 to
set it. Which I do, and bext boot gives me:
grub>
Which is no use at all so I reboot and now again have a normal grub menu. This time I
select Advanced mode for my Linux boot. Now it boots happily along. And I can boit into
Debian, TDE, the whole works, though now I am in rescue mode (which looks and acts just
like any ordinary boot).
Which is where I am now. In slight terror it will crash again, but otherwise wondering
how I can proceed to make things normal again,
Anyone have any ideas?
1) make a backup - just in case it's your harddisk that's dying.
2) run memtest.
3) preoare a backup machine
IMO when things die unexpectidly while powered up it's hdd/ram/somecard/mainboard in
this order.
The error on r8169: that's a bug of the hardware or kernel, not sure which to blame.
It leads to dropping network connections now and then and with network-manager the kernel
modul crashes when you have wifi enabled and plug in the lan cable. I notized it to appear
~ 2 months ago (amd AMD Ryzen 7 PRO 4750U on lenovo T14 AMD gen1). You can work around it
with "pcie_aspm=off pcie_port_pm=off" added to /default/grub.
Nik
dep
Pictures: http://www.ipernity.com/doc/depscribe/album
Column: https://ofb.biz/author/dep/
____________________________________________________
tde-users mailing list -- users(a)trinitydesktop.org
To unsubscribe send an email to users-leave(a)trinitydesktop.org
Web mail archive available at
https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskt…
--
Please do not email me anything that you are not comfortable also sharing with the NSA,
CIA ...
6:47 a.m.
said Dr. Nikolaus Klepp via tde-users:
| 1) make a backup - just in case it's your harddisk that's dying.
check.
| 2) run memtest.
strangely, memtest no longer appears in my grub menu, and i have no memtest
executable.
| 3) preoare a backup machine
that might be a big bite.
| IMO when things die unexpectidly while powered up it's
| hdd/ram/somecard/mainboard in this order.
we'll see if it repeats. i very much hope it doesn't. i wondered if a log
i've had running -- a ping every three seconds with the result written to
disk -- might have stressed something. and it has on occasion over the
years suffered from what seems to be something overheating, such as when
it tries to compile a heap of nvidia modules.
| The error on r8169: that's a bug of the hardware or kernel, not sure
| which to blame. It leads to dropping network connections now and then
| and with network-manager the kernel modul crashes when you have wifi
| enabled and plug in the lan cable. I notized it to appear ~ 2 months ago
| (amd AMD Ryzen 7 PRO 4750U on lenovo T14 AMD gen1). You can work around
| it with "pcie_aspm=off pcie_port_pm=off" added to /default/grub.
yeah, i kind of figured that out -- i have disabled the onboard networking
in favor of a standalone card and imagine it's that. what i don't
understand is why boot stopped entirely with the check of /dev/sda1, which
it found to be okay but then did not proceed, and why everything works if
i boot into rescue mode -- again, from my grub menu, not from a usb drive
or anything. and right now it is the only drive in the system.
--
dep
Pictures: http://www.ipernity.com/doc/depscribe/album
Column: https://ofb.biz/author/dep/
7:36 a.m.
Anno domini 2024 Mon, 16 Dec 06:47:08 +0000
dep via tde-users scripsit:
[...]
yeah, i kind of figured that out -- i have disabled the onboard networking
in favor of a standalone card and imagine it's that. what i don't
understand is why boot stopped entirely with the check of /dev/sda1, which
it found to be okay but then did not proceed, and why everything works if
i boot into rescue mode -- again, from my grub menu, not from a usb drive
or anything. and right now it is the only drive in the system.
Without the kernel bootlog nobody can say for sure. But check the SMART readings of your
hdd. It will not tell you if the controller failed. For memtest: get the memtest iso at
https://memtest.org/ - no silver bullet, but who knows. Indication of bad ram might be the
ram or the mainboard or the cpu ... at least you can narrow it down :)
Nik
--
Please do not email me anything that you are not comfortable also sharing with the NSA,
CIA ...
2:15 p.m.
On 12/16/24 02:41, Dr. Nikolaus Klepp via tde-users wrote:
Anno domini 2024 Mon, 16 Dec 06:47:08 +0000
dep via tde-users scripsit:
Nik, that site above has been highjacked to sell a billing app that is
not free. It claims to be memtest86 but anything clicked on eventually
leads to a dead end without a download ever starting.
[...]
yeah, i kind of figured that out -- i have disabled the onboard networking
in favor of a standalone card and imagine it's that. what i don't
understand is why boot stopped entirely with the check of /dev/sda1, which
it found to be okay but then did not proceed, and why everything works if
i boot into rescue mode -- again, from my grub menu, not from a usb drive
or anything. and right now it is the only drive in the system.
Without the kernel
bootlog nobody can say for sure. But check the SMART readings of your hdd. It will not
tell you if the controller failed. For memtest: get the memtest iso at
https://memtest.org/ - no silver bullet, but who knows. Indication of bad ram might be the
ram or the mainboard or the cpu ... at least you can narrow it down :)
Nik
--
Please do not email me anything that you are not comfortable also sharing with the NSA,
CIA ...
____________________________________________________
tde-users mailing list -- users(a)trinitydesktop.org
To unsubscribe send an email to users-leave(a)trinitydesktop.org
Web mail archive available at
https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskt…
.
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
2:21 p.m.
On 12/16/24 02:41, Dr. Nikolaus Klepp via tde-users wrote:
Anno domini 2024 Mon, 16 Dec 06:47:08 +0000
dep via tde-users scripsit:
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
[...]
yeah, i kind of figured that out -- i have disabled the onboard networking
in favor of a standalone card and imagine it's that. what i don't
understand is why boot stopped entirely with the check of /dev/sda1, which
it found to be okay but then did not proceed, and why everything works if
i boot into rescue mode -- again, from my grub menu, not from a usb drive
or anything. and right now it is the only drive in the system.
Without the kernel
bootlog nobody can say for sure. But check the SMART readings of your hdd. It will not
tell you if the controller failed. For memtest: get the memtest iso at
https://memtest.org/ - no silver bullet, but who knows. Indication of bad ram might be the
ram or the mainboard or the cpu ... at least you can narrow it down :)
Nik
I take it back, I finally did find the download and got it. But its a whole batch of
clicks to get there.
--
Please do not email me anything that you are not comfortable also sharing with the NSA,
CIA ...
____________________________________________________
tde-users mailing list -- users(a)trinitydesktop.org
To unsubscribe send an email to users-leave(a)trinitydesktop.org
Web mail archive available at
https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskt…
.
2:33 p.m.
Anno domini 2024 Mon, 16 Dec 09:21:11 -0500
gene heskett via tde-users scripsit:
--
Please do not email me anything that you are not comfortable also sharing with the NSA,
CIA ...
On 12/16/24 02:41, Dr. Nikolaus Klepp via tde-users wrote:
> Anno domini 2024 Mon, 16 Dec 06:47:08 +0000
> dep via tde-users scripsit:
>> [...]
>> yeah, i kind of figured that out -- i have disabled the onboard networking
>> in favor of a standalone card and imagine it's that. what i don't
>> understand is why boot stopped entirely with the check of /dev/sda1, which
>> it found to be okay but then did not proceed, and why everything works if
>> i boot into rescue mode -- again, from my grub menu, not from a usb drive
>> or anything. and right now it is the only drive in the system.
> Without the kernel bootlog nobody can say for sure. But check the SMART readings of
your hdd. It will not tell you if the controller failed. For memtest: get the memtest iso
at https://memtest.org/ - no silver bullet, but who knows. Indication of bad ram might be
the ram or the mainboard or the cpu ... at least you can narrow it down :)
>
> Nik
>
> I take it back, I finally did find the download and got it. But its a whole batch of
clicks to get there.
Well, some people think that clicking mouse buttons is a good motoric exercise :)
Nik
--
Please do not email me anything that you are not comfortable also sharing with the NSA,
CIA ...
____________________________________________________
tde-users mailing list -- users(a)trinitydesktop.org
To unsubscribe send an email to users-leave(a)trinitydesktop.org
Web mail archive available at
https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskt…
.
Cheers, Gene Heskett, CET.
3:10 p.m.
On 12/16/24 09:39, Dr. Nikolaus Klepp via tde-users wrote:
Anno domini 2024 Mon, 16 Dec 09:21:11 -0500
gene heskett via tde-users scripsit:
That site could be used as an example of overkill., I had to
prelaunch
FF in its own workspace, then click on the link before FF worked right.
Now k3b is being difficult.
On 12/16/24 02:41, Dr. Nikolaus Klepp via
tde-users wrote:
> Anno domini 2024 Mon, 16 Dec 06:47:08 +0000
> dep via tde-users scripsit:
>> [...]
>> yeah, i kind of figured that out -- i have disabled the onboard networking
>> in favor of a standalone card and imagine it's that. what i don't
>> understand is why boot stopped entirely with the check of /dev/sda1, which
>> it found to be okay but then did not proceed, and why everything works if
>> i boot into rescue mode -- again, from my grub menu, not from a usb drive
>> or anything. and right now it is the only drive in the system.
> Without the kernel bootlog nobody can say for sure. But check the SMART readings of
your hdd. It will not tell you if the controller failed. For memtest: get the memtest iso
at https://memtest.org/ - no silver bullet, but who knows. Indication of bad ram might be
the ram or the mainboard or the cpu ... at least you can narrow it down :)
>
> Nik
>
> I take it back, I finally did find the download and got it. But its a whole batch of
clicks to get there.
Well, some people think that clicking mouse buttons is a good
motoric exercise :)
Nik
--
Please do not email me anything that you are not comfortable also sharing with the NSA,
CIA ...
____________________________________________________
tde-users mailing list -- users(a)trinitydesktop.org
To unsubscribe send an email to users-leave(a)trinitydesktop.org
Web mail archive available at
https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskt…
.
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
--
Please do not email me anything that you are not comfortable also sharing with the NSA,
CIA ...
____________________________________________________
tde-users mailing list -- users(a)trinitydesktop.org
To unsubscribe send an email to users-leave(a)trinitydesktop.org
Web mail archive available at
https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskt…
.
Cheers, Gene Heskett, CET. 
17 Dec
17 Dec
12:24 a.m.
On Mon, Dec 16, 2024 at 09:21:11AM -0500, gene heskett via tde-users wrote:
I take it back, I finally did find the download and
got it. But its a
whole batch of clicks to get there.
My main desktop died, so I'm using an older fallback machine with
Firefox 45. (I believe the current version is about 131 or so.) It's so
old that most of the internet simply doesn't work with it, and the bits
that do, I almost always have to manually add a security override for
HTTPS sites.
(Yes yes, I know this is bad.)
On the memtest site, aside from allowing a https exception, it took
exactly one short scroll plus two clicks to start the download process:
- scroll down past the screen shots, ads and the FAQs to the downloads
- click one of the download links
- click once to close the popup ad that appeared
and Bob's your uncle.
Of course there would have been a few more clicks if I had bothered to
close the google ads on the page, but why bother?
--
Steven
5
days inactive
6
days old
11 comments
5 participants
participants (5)
-
dep -
Dr. Nikolaus Klepp -
Felix Miata -
gene heskett -
Steven D'Aprano