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/
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.
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 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.
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@trinitydesktop.org To unsubscribe send an email to users-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskto...
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.
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 ...
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
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.
-- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ____________________________________________________ tde-users mailing list -- users@trinitydesktop.org To unsubscribe send an email to users-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskto... .
Cheers, Gene Heskett, CET.
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.
Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ____________________________________________________ tde-users mailing list -- users@trinitydesktop.org To unsubscribe send an email to users-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskto... .
Cheers, Gene Heskett, CET.
Anno domini 2024 Mon, 16 Dec 09:21:11 -0500 gene heskett via tde-users scripsit:
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@trinitydesktop.org To unsubscribe send an email to users-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskto... .
Cheers, Gene Heskett, CET.
-- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ...
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:
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 :)
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.
Nik
-- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ____________________________________________________ tde-users mailing list -- users@trinitydesktop.org To unsubscribe send an email to users-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskto... .
Cheers, Gene Heskett, CET.
-- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ____________________________________________________ tde-users mailing list -- users@trinitydesktop.org To unsubscribe send an email to users-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskto... .
Cheers, Gene Heskett, CET.
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?
-
dep -
Dr. Nikolaus Klepp -
Felix Miata -
gene heskett -
Steven D'Aprano