Re: Why is Firefox crashing so much lately?

[Andrew M.A. Cater]

On Wed, Jul 17, 2024 at 08:00:06PM -0700, Van Snyder wrote:
> On Wed, 2024-07-17 at 22:17 -0400, e...@gmx.us wrote:
> > On 7/17/24 21:25, Gary Dale wrote:
> > > I'm running Debian/Trixie on an AMD64 system, using the Plasma 5
> > > over X
> > > desktop. Firefox 115.12.0esr is crashing multiple times per day. It
> > > frequently happens when page I'm transfers to another page that
> > > creates a  > PDF or just has a complicated link. It's annoying.
> 
> I upgraded from Debian 10 to Debian 12.5 "Bookworm." The NVidia 390
> driver no longer works, so I had software rendering because nouveau
> apparently can't do GPU rendering. Rather than crashing, the system
> essentially froze. After waiting for a VERY long time, I would give up
> and cycle power, with my reboot set up to start an empty session, not
> the one I had going at time of the power cycle. I replaced the graphics
> card with a Quadro K2200, which works with the nvidia-drivers package
> that's still part of the Debian 12.5 distro. With GPU rendering, I no
> longer have the problem.
> 

HOW did you upgrade? Did you go via 11?

Did you purge all Nvidia drivers at that point? Nouveau works fairly well
if there's no other trace of Nvidia on the system. Freezing is definitely
a symptom of drivers fighting.

> I can't do that with my old Dell Vostro 1700 because the NVidia
> graphics chip is soldered to the motherboard, and it needs the 340
> driver, which is also no longer available.
> 

If this is the Dell with dual chipsets - one Nvidia to do the heavy 
graphics, an Intel chipset for basics - like a bunch of gaming laptops
you'd need to look at the Debian Nvidia pages for primus and so on.

If it *just* has Nvidia - at this point, use Nouveau - stop trying to
use Nvidia drivers on old hardware and that Dell is 2008 vintage?

Software movces on - the very latest Nvidia drivers are "more free" but
also incorporate entire RISC-V chipsets on board the latest cards.

> I tried several of the methods discussed in this thread to get the
> drivers working, but had no success. Maybe I was just holding my mouth
> wrong.
> 
See above.

> > 
> > 
> > I have Firefox 115.13.0esr and it rarely crashes for me, and I have
> > dozens
> > of tabs open.  I use straight XFCE, no Plasma.  Could be it doesn't
> > do PDFs
> > well?  I use Zathura to view PDFs.  It's rather ... "feature free",
> > so I may
> > change.
> > 

Also works for me under GNOME but my usage is light - I don't keep
dozens of tabs open.

All a moot point - we'll probably get 128.* soonest as that's the new
ESR.

All best, as ever,

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

> > Can you say what that site is?
> > 
> > --
> >     An idea that is not dangerous is unworthy of
> >     being called an idea at all. -- Oscar Wilde
> > 
> 

Re: Why is Firefox crashing so much lately?

[mick.crane]

On 2024-07-18 04:00, Van Snyder wrote:

On Wed, 2024-07-17 at 22:17 -0400, e...@gmx.us wrote:

On 7/17/24 21:25, Gary Dale wrote:
> I'm running Debian/Trixie on an AMD64 system, using the Plasma 5
> over X
> desktop. Firefox 115.12.0esr is crashing multiple times per day. It
> frequently happens when page I'm transfers to another page that
> creates a  > PDF or just has a complicated link. It's annoying.


I upgraded from Debian 10 to Debian 12.5 "Bookworm." The NVidia 390
driver no longer works, so I had software rendering because nouveau
apparently can't do GPU rendering. Rather than crashing, the system
essentially froze. After waiting for a VERY long time, I would give up
and cycle power, with my reboot set up to start an empty session, not
the one I had going at time of the power cycle. I replaced the graphics
card with a Quadro K2200, which works with the nvidia-drivers package
that's still part of the Debian 12.5 distro. With GPU rendering, I no
longer have the problem.


My only issue is random system freezes seemingly caused by the browser.
I remembered that that was the reason I installed the nvidia 470 driver.
on originally Bookworm -> Trixie with Vivaldi browser it was stable.

This fresh install of Trixie has had system freeze with firefox
with nouveau driver. Less so (touch wood) with Vivaldi.
There was a message while I was fiddling about that the
 nvidia Quadro K4000 is not supported by something or other.
Perhaps I should invest in a newer graphics card.
mick

Re: web site displays blank page

[Greg Wooledge]

On Thu, Jul 18, 2024 at 02:27:39 -0400, Felix Miata wrote:
> Russell L. Harris composed on 2024-07-18 06:06 (UTC):
> > Would someone kindly verify that chewy.com is accessible?
> 
> https://www.chewy.com/ looks normal from FL in Chromium:

Works for me in Google Chrome.

Re: web site displays blank page

[Roger Price]

On Thu, 18 Jul 2024, Greg Wooledge wrote:


On Thu, Jul 18, 2024 at 02:27:39 -0400, Felix Miata wrote:

Russell L. Harris composed on 2024-07-18 06:06 (UTC):

Would someone kindly verify that chewy.com is accessible?


https://www.chewy.com/ looks normal from FL in Chromium:

Works for me in Google Chrome.


ping www.chewy.com replies: 64 bytes from
   g2a02-26f0-2b00-06a2----0c35.deploy.static.akamaitechnologies.com
   (2a02:26f0:2b00:6a2::c35): icmp_seq=1 ttl=49 time=18.8 ms

Lynx replies: waiting for response.
w3m replies:  Waiting for reply...
W3C validator replies: 429 Too Many Requests

curl --head replies: HTTP/2 429
   content-type: text/html; charset=utf-8
   x-kpsdk-ct: 0r17x8iBB9ocm6h...
   access-control-expose-headers: x-kpsdk-ct,x-kpsdk-r,x-kpsdk-c ...

The access-control-expose-headers looks like unneeded complexity by chewy. 
Even Microsoft doesn't do it.


Roger

Re: web site displays blank page

[mindaugas]

Hello.

Site works fine here (Firefox 128.0)

On 7/18/24 14:24, Roger Price wrote:

On Thu, 18 Jul 2024, Greg Wooledge wrote:


On Thu, Jul 18, 2024 at 02:27:39 -0400, Felix Miata wrote:

Russell L. Harris composed on 2024-07-18 06:06 (UTC):

Would someone kindly verify that chewy.com is accessible?


https://www.chewy.com/ looks normal from FL in Chromium:

Works for me in Google Chrome.


ping www.chewy.com replies: 64 bytes from
g2a02-26f0-2b00-06a2----0c35.deploy.static.akamaitechnologies.com
   (2a02:26f0:2b00:6a2::c35): icmp_seq=1 ttl=49 time=18.8 ms

Lynx replies: waiting for response.
w3m replies:  Waiting for reply...
W3C validator replies: 429 Too Many Requests

curl --head replies: HTTP/2 429
   content-type: text/html; charset=utf-8
   x-kpsdk-ct: 0r17x8iBB9ocm6h...
   access-control-expose-headers: x-kpsdk-ct,x-kpsdk-r,x-kpsdk-c ...

The access-control-expose-headers looks like unneeded complexity by 
chewy. Even Microsoft doesn't do it.


Roger

Re: web site displays blank page

[eben]

On 7/18/24 02:06, Russell L. Harris wrote:

My ISP is RTA.  I am in a rural area near Austinn, Texas, and have a > 10/1 
microwave link.  Could the problem be with RTA?


It's probably a routing issue between you and them. Or maybe "delivery
content network" (That's what it's called, right?  A company with fat pipes
in several places that rents out their bandwidth.) got temporarily
misconfigured.  their I've had instances where one or more sites become
inaccessible for minutes or hours, then work again.


Would someone kindly verify that chewy.com is accessible?


Works.  With JS off it looks the same, but none of the menus work.

--
6 x 9 = 42
  13
--DNA (paraphrased)

Cookie (&/or JavaScript) issue? - was [Re: web site displays blank page

[Richard Owlett]

On 07/18/2024 01:16 AM, Alain D D Williams wrote:

On Thu, Jul 18, 2024 at 06:06:05AM +, Russell L. Harris wrote:

When I try to visit www.chewy.com a blank page.  This is a major pet
supply web site.  Other web sites display as usual without problems.
I phoned CHEWY and they say their system is on-line.

I have tried two different computers and both Firefox and Chromium.  I
updated Debian-12.  I emptied the browser cache.  No change.

A week or two ago, chewy.com displayed perfectly.

My ISP is RTA.  I am in a rural area near Austinn, Texas, and have a
10/1 microwave link.  Could the problem be with RTA?

Would someone kindly verify that chewy.com is accessible?


HTTP code 429 means "Too Many Requests (RFC 6585)"

$ curl --head https://www.chewy.com/
HTTP/2 429
content-type: text/html; charset=utf-8

[ *SNIP* what I couldn't understand ]

SeaMonkey 2.49.4 on Debian 9.13 *CAN* display that page.
[establishes that old vs new client side software in not the issue]

HOWEVER I can duplicate your symptom.
Due to personal needs/preferences I surf with many disabled options
[including JavaScript and cookies].

My test procedure was:
Opened https://www.chewy.com/ .
   I got a blank page and SeaMonkey's status line said "Done"
Closed window.
Enabled JavaScript.
Opened https://www.chewy.com/ .
   I got a blank page with sets of "transferring data"/"Done" messages
   SeaMonkey's status line then said "Done"
   The screen remained blank with mouse cursor indicating activity.
   SeaMonkey displayed message box titled "Unresponsive script" saying:
 > A script on this page may be busy, or it may have stopped 
responding.

 > You can stop the script now, open the script in the debugger, or let
 > the script continue.
 >
 > Script: 
https://www.chewy.com/149e9513…TQ5N2EtYTYyNC0wNTMxZjg5NjJkZjI:27

   I opened the debugger and got a tool I don't know how to use. It was
 apparent that it gave enough information that a knowledgeable user
 could diagnose the exact failure mode.
Closed window.
Enabled JavaScript *and* cookies
Opened https://www.chewy.com/ .
   I got a perfectly normal page.

I'm assuming the "Unresponsive script" box is SeaMonkey's response to a 
"HTTP code 429".


Hope this helps.

Re: Cookie (&/or JavaScript) issue? - was [Re: web site displays blank page

[eben]

On 7/18/24 08:23, Richard Owlett wrote:

On 07/18/2024 01:16 AM, Alain D D Williams wrote:

On Thu, Jul 18, 2024 at 06:06:05AM +, Russell L. Harris wrote:

When I try to visit www.chewy.com a blank page.  This is a major pet
supply web site.  Other web sites display as usual without problems.
I phoned CHEWY and they say their system is on-line.

I have tried two different computers and both Firefox and Chromium.  I
updated Debian-12.  I emptied the browser cache.  No change.

A week or two ago, chewy.com displayed perfectly.

My ISP is RTA.  I am in a rural area near Austinn, Texas, and have a
10/1 microwave link.  Could the problem be with RTA?

Would someone kindly verify that chewy.com is accessible?


HTTP code 429 means "Too Many Requests (RFC 6585)"

$ curl --head https://www.chewy.com/
HTTP/2 429


HOWEVER I can duplicate your symptom.
Due to personal needs/preferences I surf with many disabled options
[including JavaScript and cookies].


Good point.  Further testing was indeed warranted.

If I enables JS for appsflyer.com I get a warning about DRM-protected media.
 So maybe your version of Firefox _thinks_ it can handle DRM, but really can't?

--
Are you confident that you appear to be professional in your electronic
communication?  Consider this: A: No
   Q: Can I top post? from n...@xx.co.uk

Re: web site displays blank page

[Richard Owlett]

On 07/18/2024 07:14 AM, e...@gmx.us wrote:

On 7/18/24 02:06, Russell L. Harris wrote:
My ISP is RTA.  I am in a rural area near Austinn, Texas, and have a > 
10/1 microwave link.  Could the problem be with RTA?


It's probably a routing issue between you and them. Or maybe "delivery
content network" (That's what it's called, right?  A company with fat pipes
in several places that rents out their bandwidth.) got temporarily
misconfigured.  their I've had instances where one or more sites become
inaccessible for minutes or hours, then work again.


Would someone kindly verify that chewy.com is accessible?


Works.  With JS off it looks the same, but none of the menus work.


Using SeaMonkey 2.49.4 on Debian 9.13 [also see my response to Alain]
   With JS off but cookies enabled I see 11 cookies and blank page.
   With JS on and cookies enabled I see 16 cookies and normal page.

Re: Why is Firefox crashing so much lately?

[Gary Dale]

On 2024-07-17 21:25, Gary Dale wrote:
I'm running Debian/Trixie on an AMD64 system, using the Plasma 5 over 
X desktop. Firefox 115.12.0esr is crashing multiple times per day. It 
frequently happens when page I'm transfers to another page that 
creates a PDF or just has a complicated link. It's annoying.


To visit some pages, I have to use Chromium instead.  Earlier today I 
had to rename a sessionstore-backups json file because Firefox got 
caught in loop where it recognized it had a new tab open but the tab 
caused it to crash.


I also have found that at least one site refuses to work with 115. 
That's been going on for a while. Again, I have to use Chromium for 
that site.


Thanks for the tips guys, but I'm not going to switch to XFCE, I'm using 
an old AMD graphics card, it's a desktop machine, and the problem isn't 
specific to PDFs - although that seems to be one of the major triggers.


My system has been upgrading from earlier versions of Debian since 
Potato. I've been on Trixie since it became the new testing. This 
crashing of Firefox is a new issue - had few problems with Trixie before 
that.


I'm beginning to suspect it may be related to my recent introduction of 
a Pi-Hole into my network. Could it be a problem for Firefox when it 
gets a 0.0.0.0 address returned on a DNS lookup?

Re: web site displays blank page

[Dan Ritter]

e...@gmx.us wrote: 
> On 7/18/24 02:06, Russell L. Harris wrote:
> > My ISP is RTA.  I am in a rural area near Austinn, Texas, and have a > 10/1 
> > microwave link.  Could the problem be with RTA?
> 
> It's probably a routing issue between you and them. Or maybe "delivery
> content network" (That's what it's called, right?  A company with fat pipes
> in several places that rents out their bandwidth.) got temporarily
> misconfigured.  their I've had instances where one or more sites become
> inaccessible for minutes or hours, then work again.


Content delivery network -- in this case, Akamai, which I used
to work for 20 years ago.

The 429 error indicates either that the local node is
overwhelmed (unlikely) or that the client has asked for a limit
on traffic to prevent a giant bill.

-dsr-

Re: Cookie (&/or JavaScript) issue? - was [Re: web site displays blank page

[Richard Owlett]

On 07/18/2024 08:13 AM, e...@gmx.us wrote:

On 7/18/24 08:23, Richard Owlett wrote:

On 07/18/2024 01:16 AM, Alain D D Williams wrote:

On Thu, Jul 18, 2024 at 06:06:05AM +, Russell L. Harris wrote:

When I try to visit www.chewy.com a blank page.  This is a major pet
supply web site.  Other web sites display as usual without problems.
I phoned CHEWY and they say their system is on-line.

I have tried two different computers and both Firefox and Chromium.  I
updated Debian-12.  I emptied the browser cache.  No change.

A week or two ago, chewy.com displayed perfectly.

My ISP is RTA.  I am in a rural area near Austinn, Texas, and have a
10/1 microwave link.  Could the problem be with RTA?

Would someone kindly verify that chewy.com is accessible?


HTTP code 429 means "Too Many Requests (RFC 6585)"

$ curl --head https://www.chewy.com/
HTTP/2 429


HOWEVER I can duplicate your symptom.
Due to personal needs/preferences I surf with many disabled options
[including JavaScript and cookies].


Good point.  Further testing was indeed warranted.

If I enables JS for appsflyer.com I get a warning about DRM-protected 
media.
  So maybe your version of Firefox _thinks_ it can handle DRM, but 
really can't?




You snipped too much ;{
I don't use ANY version of Firefox.
I use SeaMonkey 2.49.4 on Debian 9.13 .
They have a common ancestor - Netscape Navigator.
For appsflyer.com with JavaScript *AND* cookies disabled, I see an 
apparently normal page and clicking any URL works.
I suspect that enabling JavaScript would allow what I suspect to be 
drop-down menus [e.g "Kickstart app growth" etc.] to work.

Due to security concerns, I will NOT enable either JavaScript or cookies
for for an unknown site marketing software. [dating back to days of 
vacuum tube CPUs I'm naturally suspicious ;]

Re: web site displays blank page

[Jeffrey Walton]

On Thu, Jul 18, 2024 at 10:06 AM Dan Ritter  wrote:
>
> e...@gmx.us wrote:
> > On 7/18/24 02:06, Russell L. Harris wrote:
> > > My ISP is RTA.  I am in a rural area near Austinn, Texas, and have a > 
> > > 10/1 microwave link.  Could the problem be with RTA?
> >
> > It's probably a routing issue between you and them. Or maybe "delivery
> > content network" (That's what it's called, right?  A company with fat pipes
> > in several places that rents out their bandwidth.) got temporarily
> > misconfigured.  their I've had instances where one or more sites become
> > inaccessible for minutes or hours, then work again.
>
>
> Content delivery network -- in this case, Akamai, which I used
> to work for 20 years ago.
>
> The 429 error indicates either that the local node is
> overwhelmed (unlikely) or that the client has asked for a limit
> on traffic to prevent a giant bill.

I think the company is currently in a downward spiral. Saving money
sounds like a plausible reason for the problems with its website.
Confer, 
.

Jeff

Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

[Celejar]

Hello,

I'm currently on kernel 6.9.8 (amd64 / Sid). Installing 6.9.9 fails due to
running out of space on /boot:

*
update-initramfs: Generating /boot/initrd.img-6.9.9-amd64
zstd: error 70 : Write error : cannot write block : No space left on device
E: mkinitramfs failure zstd -q -9 -T0 70
update-initramfs: failed for /boot/initrd.img-6.9.9-amd64 with 1.
*

It turns out that the initrd for 6.9.9 is more than 7x the size of the
one for 6.9.8!

*
~$ ls -l /boot/initrd.img*
-rw-r--r-- 1 root root  27491557 Jul  8 13:45 /boot/initrd.img-6.9.8-amd64
-rw-r--r-- 1 root root 205739589 Jul 16 14:29 /boot/initrd.img-6.9.9-amd64
*

Diffing the two initrd files suggests that the problem stems from the
fact that 6.9.9 is including the NVIDIA GPU System Processor (GSP)
firmware in the initrd:

https://download.nvidia.com/XFree86/Linux-x86_64/510.39.01/README/gsp.html

Arch dealt with this 6 months ago - they claim that the problem
actually began in kernel 6.7:

https://bbs.archlinux.org/viewtopic.php?id=291900
https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/issues/238

I'm not sure why I'm hitting this now - did Debian just change
something? Is anyone else hitting this? Is this documented somewhere?
Is there a straightforward fix / workaround?

-- 
Celejar

Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

[Dan Ritter]

Celejar wrote: 
> Hello,
> 
> I'm currently on kernel 6.9.8 (amd64 / Sid). Installing 6.9.9 fails due to
> running out of space on /boot:

... 
 
> I'm not sure why I'm hitting this now - did Debian just change
> something? Is anyone else hitting this? Is this documented somewhere?
> Is there a straightforward fix / workaround?

Of course something changed: it's Sid.

It will probably be straightened out before it hits stable.

Do you need this firmware? If so, do you need it at boot time?
There are kernel build options. Building it as a module and
making sure that initrd doesn't include it is pretty normal for
a number of kernel modules.

-dsr-

Re: Why is Firefox crashing so much lately?

[Sven Joachim]

On 2024-07-17 21:25 -0400, Gary Dale wrote:

> I'm running Debian/Trixie on an AMD64 system, using the Plasma 5 over
> X desktop. Firefox 115.12.0esr is crashing multiple times per day. It
> frequently happens when page I'm transfers to another page that
> creates a PDF or just has a complicated link. It's annoying.

Apparently this is bug #1072557[1] in mesa.

> To visit some pages, I have to use Chromium instead.  Earlier today I
> had to rename a sessionstore-backups json file because Firefox got
> caught in loop where it recognized it had a new tab open but the tab
> caused it to crash.

I experienced a similar problem on my laptop where firefox-esr crashed
shortly after the start before even reloading the current tab in all
open windows.  The workaround was to run it with LIBGL_ALWAYS_SOFTWARE=1
set in the environment.

Cheers,
   Sven


1. https://bugs.debian.org/1072557

Re: Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

[Celejar]

Dan Ritter wrote:

> Celejar wrote: 
> > Hello,
> > 
> > I'm currently on kernel 6.9.8 (amd64 / Sid). Installing 6.9.9 fails due to
> > running out of space on /boot:
> 
> ... 
>  
> > I'm not sure why I'm hitting this now - did Debian just change
> > something? Is anyone else hitting this? Is this documented somewhere?
> > Is there a straightforward fix / workaround?
> 
> Of course something changed: it's Sid.

The question is whether this is a change Debian made to the kernel
packaging, an upstream change,, or something I inadvertently changed on
my system. If either of the former two, Debian really needs to document
something like this.

> It will probably be straightened out before it hits stable.

Great. As I noted, Arch seems to have gotten a handle on this six
months ago. In the meantime, Debian really should document breaking
changes like this. Is a bug report in order?

> Do you need this firmware? If so, do you need it at boot time?
> There are kernel build options. Building it as a module and
> making sure that initrd doesn't include it is pretty normal for
> a number of kernel modules.

I suppose that I can do this if I have to, but I'd rather not mess
around with stuff I don't really understand without an official guide
to the process.

-- 
Celejar

Re: Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

[Andy Smith]

Hi,

On Thu, Jul 18, 2024 at 11:35:15AM -0400, Celejar wrote:
> I'd rather not mess around with stuff I don't really understand
> without an official guide to the process.

I don't mean this to be snarky, but that desire seems incompatible
with running Debian sid. I honestly think it's an unreasonable
expectation to want official guides for every transitory broken
state in a development tree.

Asking if a specific thing is  a known issue that is being worked
on? Sure. Expecting it to be documented before any user hits it? Not
so much.

Thanks,
Andy

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

Re: web site displays blank page

[Russell L. Harris]

On Thu, Jul 18, 2024 at 08:14:26AM -0400, e...@gmx.us wrote:

On 7/18/24 02:06, Russell L. Harris wrote:

My ISP is RTA.?? I am in a rural area near Austin, Texas, and have a
10/1 microwave link.?? Could the problem be with RTA?


It's probably a routing issue between you and them. Or maybe "delivery
content network" (That's what it's called, right?  A company with fat pipes
in several places that rents out their bandwidth.) got temporarily
misconfigured.  their I've had instances where one or more sites become
inaccessible for minutes or hours, then work again.


CHEWY is a large nation-wide outfit.  I suspect the trouble is with
RTA, because of frequent freezes when viewing a certain news website,
while all other streams are uninterrupted with my 10/1 service from
RTA.  


I just installed Konqueror and rebooted my firewall (ipFire), but I
still get a blank page for CHEWY.COM.

What should I try next?

RLH

Re: Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

[Andrew M.A. Cater]

On Thu, Jul 18, 2024 at 03:42:30PM +, Andy Smith wrote:
> Hi,
> 
> On Thu, Jul 18, 2024 at 11:35:15AM -0400, Celejar wrote:
> > I'd rather not mess around with stuff I don't really understand
> > without an official guide to the process.
> 
> I don't mean this to be snarky, but that desire seems incompatible
> with running Debian sid. I honestly think it's an unreasonable
> expectation to want official guides for every transitory broken
> state in a development tree.
> 

If you run Sid, you are *expected* to be able to solve all your own
problems. There are no guarantees other than if it breaks, you get
to keep both pieces :)

I recognise your name: you are an experienced user, but if you're not
ready for speed of change / likelihood of serious breakage, please *don't*
run Sid.

The pace of change is high - apart from the freeze period prior to a major
release, the likelihood of random breakage is very high. If there is a major
transition (versions of GNOME, Qt versions for KDE, usrmerge for example)
you could run into breakages that will last a few weeks.

This is not the place for debugging Sid, I'm afraid, there are too few
of us here that would run Sid normally.

All the very best, as ever,

Andy
(amaca...@debian.org)


> Asking if a specific thing is  a known issue that is being worked
> on? Sure. Expecting it to be documented before any user hits it? Not
> so much.
> 
> Thanks,
> Andy
> 
> -- 
> https://bitfolk.com/ -- No-nonsense VPS hosting
> 

Re: Why is Firefox crashing so much lately?

[Van Snyder]

On Thu, 2024-07-18 at 07:55 +, Andrew M.A. Cater wrote:
> On Wed, Jul 17, 2024 at 08:00:06PM -0700, Van Snyder wrote:
> > On Wed, 2024-07-17 at 22:17 -0400, e...@gmx.us wrote:
> > > On 7/17/24 21:25, Gary Dale wrote:
> > > > I'm running Debian/Trixie on an AMD64 system, using the Plasma
> > > > 5
> > > > over X
> > > > desktop. Firefox 115.12.0esr is crashing multiple times per
> > > > day. It
> > > > frequently happens when page I'm transfers to another page that
> > > > creates a  > PDF or just has a complicated link. It's annoying.
> > 
> > I upgraded from Debian 10 to Debian 12.5 "Bookworm." The NVidia 390
> > driver no longer works, so I had software rendering because nouveau
> > apparently can't do GPU rendering. Rather than crashing, the system
> > essentially froze. After waiting for a VERY long time, I would give
> > up
> > and cycle power, with my reboot set up to start an empty session,
> > not
> > the one I had going at time of the power cycle. I replaced the
> > graphics
> > card with a Quadro K2200, which works with the nvidia-drivers
> > package
> > that's still part of the Debian 12.5 distro. With GPU rendering, I
> > no
> > longer have the problem.
> > 
> 
> HOW did you upgrade? Did you go via 11?
> 
> Did you purge all Nvidia drivers at that point? Nouveau works fairly
> well
> if there's no other trace of Nvidia on the system. Freezing is
> definitely
> a symptom of drivers fighting.

Fresh install on reformatted boot and root partitions.

> > I can't do that with my old Dell Vostro 1700 because the NVidia
> > graphics chip is soldered to the motherboard, and it needs the 340
> > driver, which is also no longer available.
> > 
> 
> If this is the Dell with dual chipsets - one Nvidia to do the heavy 
> graphics, an Intel chipset for basics - like a bunch of gaming
> laptops
> you'd need to look at the Debian Nvidia pages for primus and so on.

One chipset.

> If it *just* has Nvidia - at this point, use Nouveau - stop trying to
> use Nvidia drivers on old hardware and that Dell is 2008 vintage?

I gave up trying to install the NVidia 340 driver on Debian 12.5. If
the rendering is unbearably slow, I'll revert to Debian 10.

> Software movces on - the very latest Nvidia drivers are "more free"
> but
> also incorporate entire RISC-V chipsets on board the latest cards.

I can't upgrade a soldered-in chip.

Re: Re: Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

[Celejar]

Andy Smith wrote:

> Hi,
> 
> On Thu, Jul 18, 2024 at 11:35:15AM -0400, Celejar wrote:
> > I'd rather not mess around with stuff I don't really understand
> > without an official guide to the process.
> 
> I don't mean this to be snarky, but that desire seems incompatible
> with running Debian sid. I honestly think it's an unreasonable
> expectation to want official guides for every transitory broken
> state in a development tree.

That's fair. I think I meant more that I was just going to stick with
6.9.8 until this gets sorted out, rather than muck around and deviate
from the default kernel / initrd build settings without official
documentation of the process.

> Asking if a specific thing is  a known issue that is being worked
> on? Sure. Expecting it to be documented before any user hits it? Not
> so much.

I understand, and largely agree.

> Thanks,
> Andy

-- 
Celejar

Re: Re: Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

[Celejar]

Andrew M.A. Cater wrote:

> On Thu, Jul 18, 2024 at 03:42:30PM +, Andy Smith wrote:
> > Hi,
> > 
> > On Thu, Jul 18, 2024 at 11:35:15AM -0400, Celejar wrote:
> > > I'd rather not mess around with stuff I don't really understand
> > > without an official guide to the process.
> > 
> > I don't mean this to be snarky, but that desire seems incompatible
> > with running Debian sid. I honestly think it's an unreasonable
> > expectation to want official guides for every transitory broken
> > state in a development tree.

...

> This is not the place for debugging Sid, I'm afraid, there are too few

It's not? Where, then, is the place for debugging Sid?

> of us here that would run Sid normally.

Really? I had the impression that lots of list subscribers / readers
run Sid. Are there statistics on this?

-- 
Celejar

Nvidia chipsets and Debian 12 [WAS Re: Why is Firefox crashing so much lately?]

[Andrew M.A. Cater]

On Thu, Jul 18, 2024 at 10:41:50AM -0700, Van Snyder wrote:
> On Thu, 2024-07-18 at 07:55 +, Andrew M.A. Cater wrote:
> > 
> > HOW did you upgrade? Did you go via 11?
> > 
> Fresh install on reformatted boot and root partitions.
> 

OK

> > > I can't do that with my old Dell Vostro 1700 because the NVidia
> > > graphics chip is soldered to the motherboard, and it needs the 340
> > > driver, which is also no longer available.
> > > 
> One chipset.
> 
> > If it *just* has Nvidia - at this point, use Nouveau - stop trying to
> > use Nvidia drivers on old hardware and that Dell is 2008 vintage?
> 
> I gave up trying to install the NVidia 340 driver on Debian 12.5. If
> the rendering is unbearably slow, I'll revert to Debian 10.
> 

Please *don't* do that. Debian 10 is out of security support. Debian 11
will receive a final security update on 31st August as it transitions
to Freexian and LTS. Please use Debian stable wherever feasible.

> > Software movces on - the very latest Nvidia drivers are "more free"
> > but
> > also incorporate entire RISC-V chipsets on board the latest cards.
> 

These are the very latest cards for a desktop/workstation.

> I can't upgrade a soldered-in chip.
>

So just use Nouveau already on a ~15 year old laptop.

All the very best, as ever,

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

Re: Re: Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

[Greg Wooledge]

On Thu, Jul 18, 2024 at 13:50:21 -0400, Celejar wrote:
> Really? I had the impression that lots of list subscribers / readers
> run Sid. Are there statistics on this?

Nah, sid users are just louder, on average.  Stable users don't have
as much to talk about, because our stuff just works. ;-)

Re: Nvidia chipsets and Debian 12

[Felix Miata]

Andrew M.A. Cater composed on 2024-07-18 17:51 (UTC):

> So just use Nouveau already on a ~15 year old laptop.

FTR, technically not a good recommendation. Nouveau has multiple meanings.
Employing each individual meaning generally is suboptimal, as it includes the
"reverse-engineered, experimental" nouveau DDX display driver from the .deb
xserver-xorg-video-nouveau, when the default DIX display driver, modesetting,
which is newer technology (though over a decade old), and neither
reverse-engineered nor experimental, would otherwise be employed.

To use the modesetting DIX display driver, the nouveau kernel module is 
required.
libdrm-nouveau2 is normally a must as well, as is libgl1-mesa-dri, which 
provides
nouveau_dri.so.
-- 
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

Re: Why is Firefox crashing so much lately?

[Gary Dale]

On 2024-07-18 09:52, Gary Dale wrote:

On 2024-07-17 21:25, Gary Dale wrote:
I'm running Debian/Trixie on an AMD64 system, using the Plasma 5 over 
X desktop. Firefox 115.12.0esr is crashing multiple times per day. It 
frequently happens when page I'm transfers to another page that 
creates a PDF or just has a complicated link. It's annoying.


To visit some pages, I have to use Chromium instead.  Earlier today I 
had to rename a sessionstore-backups json file because Firefox got 
caught in loop where it recognized it had a new tab open but the tab 
caused it to crash.


I also have found that at least one site refuses to work with 115. 
That's been going on for a while. Again, I have to use Chromium for 
that site.


Thanks for the tips guys, but I'm not going to switch to XFCE, I'm 
using an old AMD graphics card, it's a desktop machine, and the 
problem isn't specific to PDFs - although that seems to be one of the 
major triggers.


My system has been upgrading from earlier versions of Debian since 
Potato. I've been on Trixie since it became the new testing. This 
crashing of Firefox is a new issue - had few problems with Trixie 
before that.


I'm beginning to suspect it may be related to my recent introduction 
of a Pi-Hole into my network. Could it be a problem for Firefox when 
it gets a 0.0.0.0 address returned on a DNS lookup?


For those asking for a particular site, here's one that has crashed 
Firefox twice on me - but not when I visit the page. When I scroll down 
using the mouse wheel, it's crashed three times when I get to around item 9.

Re: web site displays blank page

[cgibbs]

On 2024-07-18, Russell L. Harris  wrote:

> When I try to visit www.chewy.com a blank page.  This is a major 
pet
> supply web site.  Other web sites display as usual without 
problems.

> I phoned CHEWY and they say their system is on-line.
>
> I have tried two different computers and both Firefox and Chromium. 
I

> updated Debian-12.  I emptied the browser cache.  No change.

I tried accessing it with my main browser, Seamonkey 2.53.18.2.
The page briefly displayed, then blanked out.  Firefox 115.7.0esr
displayed the page properly.  Oddly enough, I tried Seamonkey again
and it worked.  My copy of Seamonkey is using NoScript 5.1.9,
which I often have to disable to display web pages.

For what it's worth, I entered http://www.chewy.com on the address
bar.  On all subsequent attempts, this gets changed to https:.

I'm having this problem on an increasing number of web sites;
I suspect that web page building tools are becoming more and
more hostile toward any browsers except for the anointed few
(Edge and Chrome, plus Safari for the Mac folks).

--
/~\  Charlie Gibbs  |  We'll go down in history as
\ /|  the first society that wouldn't
X   I'm really at ac.dekanfrus |  save itself because it wasn't
/ \  if you read it the right way.  |  cost-effective.  -- Kurt 
Vonnegut

Re: Nvidia chipsets and Debian 12 [WAS Re: Why is Firefox crashing so much lately?]

[Gary Dale]

On 2024-07-18 13:51, Andrew M.A. Cater wrote:

On Thu, Jul 18, 2024 at 10:41:50AM -0700, Van Snyder wrote:

On Thu, 2024-07-18 at 07:55 +, Andrew M.A. Cater wrote:

HOW did you upgrade? Did you go via 11?


Fresh install on reformatted boot and root partitions.


OK


I can't do that with my old Dell Vostro 1700 because the NVidia
graphics chip is soldered to the motherboard, and it needs the 340
driver, which is also no longer available.


One chipset.


If it *just* has Nvidia - at this point, use Nouveau - stop trying to
use Nvidia drivers on old hardware and that Dell is 2008 vintage?

I gave up trying to install the NVidia 340 driver on Debian 12.5. If
the rendering is unbearably slow, I'll revert to Debian 10.


Please *don't* do that. Debian 10 is out of security support. Debian 11
will receive a final security update on 31st August as it transitions
to Freexian and LTS. Please use Debian stable wherever feasible.


Software movces on - the very latest Nvidia drivers are "more free"
but
also incorporate entire RISC-V chipsets on board the latest cards.

These are the very latest cards for a desktop/workstation.


I can't upgrade a soldered-in chip.


So just use Nouveau already on a ~15 year old laptop.

All the very best, as ever,

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


I've been using Debian 12 (Bookworm) on my notebook for the past year 
without issues. It does require the NVidia drivers for the external 
display to work - something to do with the on-board AMD graphics chipset 
apparently.

Re: Why is Firefox crashing so much lately?

[mick.crane]

getting elderly is brilliant.
After getting everything just nice, experienced several system crashes.
"I'll install the nvidia driver and see if that fixes it."
Then I remember why I tried to remove the nvidia driver.
an upgrade caused X to refuse to start.
Install No3 and halfway through making it nice.
My reasoning for installing trixie is that because I'm slow,
if there are any issues, I've more time to sort them out.
mick

Remote desktop Debian -> ChromeBook

[Nicolas George]

Hi.

I want to display a desktop and applications running on a Debian box on
the screen and keyboard of a ChromeBook. Over LAN+WLAN mostly, but if it
can also work more remotely in degraded mode it would be nice.

I see various options to try: VNC with a native Android client, VNC with
a client running in the Linux sandbox, x2go in the sandbox, Xpra in the
sandbox, etc.

Would perchance somebody here have already investigated a similar need
and be able to tell which solutions are the most promising in terms of
reliability and user experience.

If not, I will post my findings eventually.

Thanks in advance.

-- 
  Nicolas George

Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

[The Wanderer]

On 2024-07-18 at 13:50, Celejar wrote:

> Andrew M.A. Cater wrote:

>> This is not the place for debugging Sid, I'm afraid, there are too
>> few
> 
> It's not? Where, then, is the place for debugging Sid?

I'm no longer anything *close* to an expert in this area (having not run
sid myself in well over a decade), but my understanding is: debugging
sid is done in the BTS, collaboratively among Debian developers and that
subset of non-DD users who run sid, and preferably involves those users
investigating causes and filing bug reports with the results of those
investigations.

By taking on yourself the risk and burden of running sid, you are
volunteering to be one of those who helps notice issues before they
reach testing, and report those issues so that the machinery of the
archive can stop the package versions which those issues from migrating
to testing. Ideally, you are also volunteering to be one of those who
helps the package maintainers track down and fix the issues.

-- And, by doing that, you are volunteering to help protect those who do
*not* run sid from having to encounter those issues. It's an admirable
thing to do, really, if you have the time and energy and so forth to
spare for it.

(I just doubt whether a lot of those who currently run sid understand
that that is what they are volunteering for, given the pattern of "what
to update against" recommendations that I remember seeing, which was
rather at odds with what I expected and what I myself would have
recommended.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

[Michael Kjörling]

On 18 Jul 2024 13:47 -0400, from cele...@gmail.com (Celejar):
>> I don't mean this to be snarky, but that desire seems incompatible
>> with running Debian sid. I honestly think it's an unreasonable
>> expectation to want official guides for every transitory broken
>> state in a development tree.
> 
> That's fair. I think I meant more that I was just going to stick with
> 6.9.8 until this gets sorted out, rather than muck around and deviate
> from the default kernel / initrd build settings without official
> documentation of the process.

The process for doing that is setting up an apt pin either to force
the kernel packages to a particular, known good version, or to block
installation of a particular, problematic version of the kernel
packages.

I agree with what others have already said. If you're running Sid,
problems are par for the course, and you're expected to be able to
either help fix those issues (by filing and collaborating about bug
reports against the affected packages, and maybe contributing patches
to fix issues that you run across), solve those problems on your own
system (and ideally submit patches), or wait them out until the
package maintainers fix them (either based on bug reports filed by
others, or by noticing the issue themselves). Sometimes more than one
of those. Yes, maybe it'll work out great with the particular set of
packages you have installed; all the more power to you in that case.
Over time that becomes ever more unlikely, though, because at one
point or another any package is going to be involved in some sort of
major transition (the switch to a 64-bit time_t, a major libc upgrade,
a default init system change, or whatever else might happen as time
goes on).

-- 
Michael Kjörling 🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: umask - default user settings?

[songbird]

Greg Wooledge wrote:
...
> It only becomes *hard* when Desktop Environments are introduced into the
> picture.

  so far, agreed, i poked at it a bit the other day to see
if MATE would work with the roughly (user-@1000,etc) systemd
unit approach but that didn't accomplish anything i could tell.

  no more time this week for such journeys and
exploritations...  but i'll continue reading along as i get
time as the topic is interesting and convoluted which are
the best sort of puzzles.  :)


  songbird

Re: Remote desktop Debian -> ChromeBook

[Xiyue Deng]

Nicolas George  writes:

> Hi.
>
> I want to display a desktop and applications running on a Debian box on
> the screen and keyboard of a ChromeBook. Over LAN+WLAN mostly, but if it
> can also work more remotely in degraded mode it would be nice.
>
> I see various options to try: VNC with a native Android client, VNC with
> a client running in the Linux sandbox, x2go in the sandbox, Xpra in the
> sandbox, etc.
>
> Would perchance somebody here have already investigated a similar need
> and be able to tell which solutions are the most promising in terms of
> reliability and user experience.
>
> If not, I will post my findings eventually.
>
> Thanks in advance.

I have been using Chrome Remote Desktop[1] for a few years, and it has
been very reliable.  Everything is handled through a web page so you
need not install anything in the Android subsystem.  Recently (about a
year actually) it added support for pipewire so sound handling is also
seamless now.

[1] https://remotedesktop.google.com/

-- 
Xiyue Deng

Re: Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

[Celejar]

The Wanderer wrote:

> On 2024-07-18 at 13:50, Celejar wrote:
> 
> > Andrew M.A. Cater wrote:
> 
> >> This is not the place for debugging Sid, I'm afraid, there are too
> >> few
> > 
> > It's not? Where, then, is the place for debugging Sid?
> 
> I'm no longer anything *close* to an expert in this area (having not run
> sid myself in well over a decade), but my understanding is: debugging
> sid is done in the BTS, collaboratively among Debian developers and that
> subset of non-DD users who run sid, and preferably involves those users
> investigating causes and filing bug reports with the results of those
> investigations.
> 
> By taking on yourself the risk and burden of running sid, you are
> volunteering to be one of those who helps notice issues before they
> reach testing, and report those issues so that the machinery of the
> archive can stop the package versions which those issues from migrating
> to testing. Ideally, you are also volunteering to be one of those who
> helps the package maintainers track down and fix the issues.
> 
> -- And, by doing that, you are volunteering to help protect those who do
> *not* run sid from having to encounter those issues. It's an admirable
> thing to do, really, if you have the time and energy and so forth to
> spare for it.

Done:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076561

-- 
Celejar

Re: Remote desktop Debian -> ChromeBook

[Nicolas George]

Xiyue Deng (12024-07-18):
> I have been using Chrome Remote Desktop[1] for a few years, and it has
> been very reliable.  Everything is handled through a web page so you
> need not install anything in the Android subsystem.  Recently (about a
> year actually) it added support for pipewire so sound handling is also
> seamless now.

Thanks. But it looks that it has the traffic going through Google's
servers, which is absolutely not an option for me. I definitely want
something local and entirely under my control. Even better if the
Android client comes from F-Droid.

Regards,

-- 
  Nicolas George

Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

[The Wanderer]

On 2024-07-18 at 10:32, Celejar wrote:

> Hello,
> 
> I'm currently on kernel 6.9.8 (amd64 / Sid). Installing 6.9.9 fails due to
> running out of space on /boot:
> 
> *
> update-initramfs: Generating /boot/initrd.img-6.9.9-amd64
> zstd: error 70 : Write error : cannot write block : No space left on device
> E: mkinitramfs failure zstd -q -9 -T0 70
> update-initramfs: failed for /boot/initrd.img-6.9.9-amd64 with 1.
> *
> 
> It turns out that the initrd for 6.9.9 is more than 7x the size of the
> one for 6.9.8!
> 
> *
> ~$ ls -l /boot/initrd.img*
> -rw-r--r-- 1 root root  27491557 Jul  8 13:45 /boot/initrd.img-6.9.8-amd64
> -rw-r--r-- 1 root root 205739589 Jul 16 14:29 /boot/initrd.img-6.9.9-amd64
> *
> 
> Diffing the two initrd files suggests that the problem stems from the
> fact that 6.9.9 is including the NVIDIA GPU System Processor (GSP)
> firmware in the initrd:
> 
> https://download.nvidia.com/XFree86/Linux-x86_64/510.39.01/README/gsp.html
> 
> Arch dealt with this 6 months ago - they claim that the problem
> actually began in kernel 6.7:
> 
> https://bbs.archlinux.org/viewtopic.php?id=291900

From relatively deep in this thread, the issue appears to be that the
GSP firmware references the same files multiple times via directory
symlinks, and mkinitcpio was not detecting that, but rather was creating
an actual new directory and populating it with additional copies of the
files for each such symlink.

The (a?) proposed solution appears to have been to update mkinitcpio so
that it *does* detect this: "if the parent directory of the current file
to be added is a symlink, create that symlink instead of adding the
file", or logic to that effect. I haven't followed far enough to see
whether that was actually done, but it seems(?) to have gotten far
enough for a patch doing it to have been proposed.

I imagine that the solution for the Debian side may wind up being
analogous, albeit probably for mkinitramfs (or some tool it relies on),
since I don't see a mkinitcpio in at least the parts of the archive I
can quickly search against.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

[Ash Joubert]

On 2024-07-19 02:32, Celejar wrote:

I'm currently on kernel 6.9.8 (amd64 / Sid). Installing 6.9.9 fails due to
running out of space on /boot:
update-initramfs: Generating /boot/initrd.img-6.9.9-amd64
zstd: error 70 : Write error : cannot write block : No space left on device
E: mkinitramfs failure zstd -q -9 -T0 70
update-initramfs: failed for /boot/initrd.img-6.9.9-amd64 with 1.
It turns out that the initrd for 6.9.9 is more than 7x the size of the
one for 6.9.8!


I had the same problem. The cause is not the kernel upgrade but the 
refactoring of non-free firmware packages. firmware-misc-nonfree now 
recommends firmware-nvidia-graphics, causing it to be installed:


$ apt-cache show firmware-misc-nonfree
[...]
Recommends: firmware-nvidia-graphics, firmware-intel-graphics, 
firmware-intel-misc, firmware-mediatek



I am not using an nvidia gpu so the fix for me was:

apt-get purge firmware-nvidia-graphics


There was NEWS when I dist-upgraded:

$ zcat /usr/share/doc/firmware-misc-nonfree/NEWS.Debian.gz
firmware-nonfree (20230625-3~exp1) experimental; urgency=medium

  Several firmware files were moved from firmware-misc-nonfree into
  their own package:
  - firmware-nvidia-graphics: This package now holds the firmware files for
Nvidia GPU hardware.
  - firmware-intel-graphics: This package now holds the firmware files
for Intel Graphics Media Driver chips (mostly i915) as found in
'modern' Intel CPUs with integrated graphics in the Broadwell and
the various 'Lake' CPU series.
  - firmware-intel-misc: This package now holds the firmware files for 
Intel
devices and chips which do not belong in one of the other Intel 
firmware

packages. These devices/chips include for example Omni-Path devices,
Ethernet/Network chips/devices and QuickAssist Technology crypto
accelerators.
  - firmware-mediatek: This package now holds the firmware files for
devices and chips made by MediaTek and Ralink, which is part of
MediaTek.

 -- Diederik de Haas   Thu, 18 Jan 2024 14:00:00 
+0100



Kind regards,

--
Ash Joubert (they/them) 
Director / Game Developer
Transient Software Limited 
New Zealand

Re: Remote desktop Debian -> ChromeBook

[Paul van der Vlis]

Op 18-07-2024 om 23:20 schreef Nicolas George:

Hi.

I want to display a desktop and applications running on a Debian box on
the screen and keyboard of a ChromeBook. Over LAN+WLAN mostly, but if it
can also work more remotely in degraded mode it would be nice.

I see various options to try: VNC with a native Android client, VNC with
a client running in the Linux sandbox, x2go in the sandbox, Xpra in the
sandbox, etc.

Would perchance somebody here have already investigated a similar need
and be able to tell which solutions are the most promising in terms of
reliability and user experience.

If not, I will post my findings eventually.


I use VNC and a SSH-tunnel to do remote-desktop between Debian and 
Debian. I use a server (my server) for the connection, but peer-to-peer 
is also possible. And a VPN instead of a SSH-tunnel.


Some ASCII art:
client  <--ssh-->  myserver  <--ssh-->  me

On the client side, I use "tigervnc-scraping-server" and a SSH tunnel to 
my server. A 3 line script on the client initiates the connection


On myserver the SSH tunnel from the client logs in without a password or 
key, but I use "nologin" as shell. You could also use a key.


I use Remmina to connect to myserver, I guess this is not available for 
a Chromebook, but there will be another VNC client what can connect to 
"localhost:5900" using a SSH-tunnel.


Copy/paste does not work in VNC. (For that reason I also have another 
connection method: SSH using the same server).


I have it a long time working, and it works fine.

With regards,
Paul






--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl

Re: VirtualBox (VB) and Windows on Debian

[sd]

On Wednesday, 17 July 2024 21:31:00 BST Jeffrey Walton wrote:
> On Tue, Jul 16, 2024 at 1:35 PM jeremy ardley  
wrote:
> > On 16/7/24 19:31, Tom Browder wrote:
> > > I haven't looked at VB in a long time, but I have a real need for a
> > > Windows host
> > > to port some Linux libraries to Windows in order to support the Raku
> > > language.
> > > 
> > > I now have lots of memory and disk space which was always a significant
> > > issue when I used it before, and my use case is much different. Then I
> > > was trying to show Windows users how they could run Linux, now I want to
> > > help Windows folks to use a new programming language that was developed
> > > on *nix systems.
> > > 
> > > Thus my question is: Has anyone use a recent version of VB to run
> > > Windows with satisfactory results? (Note I still have a legal copy of
> > > Win 10 on a CD as well as a portable DVD player with a USB connector.)
> > > 
> > > Thank you my fellow Debian users!
> > 
> > VirtualBox is not supported on Debian 12.
> > 
> > There are alternatives that include:
> > 
> > - KVM/QEMU
> > 
> > - VMWare Workstation Pro (which is now free for private use)
> > 
> > In my experience KVM/QEMU is fairly stable. The VMWare product not so
> > much.
> > 
> > Given everything is virtual you can easily try all options in an hour or
> > two.
> 
> Add a "mee too" for KVM/QEMU/libvirt. The components are managed by
> the kernel, so there are usually no technical problems, like unsigned
> modules. Virt Manager takes a little getting used to, but everything
> you need is there.
> 
> The only downside to KVM/QEMU/libvirt is networking in some cases.
> Configuring a VM to use your local DHCP server is a pain because you
> have to setup and configure the bridging yourself. And the
> documentation to do it does not exist.

Out of interest, how is one supposed to do it now? I set mine up ages ago via 
/etc/network/interfaces - eg..

auto br0
iface br0 inet dhcp
bridge_portsenp4s0
bridge_stp  off
bridge_fd   0
bridge_maxwait  0

..but I have no idea how to do it now. Manpage says 'brctl' is obsolete and 
points to 'bridge' which I've never used.

Re: web site displays blank page

[Russell L. Harris]

I'm having this problem on an increasing number of web sites;
I suspect that web page building tools are becoming more and
more hostile toward any browsers except for the anointed few
(Edge and Chrome, plus Safari for the Mac folks).


I once had a W7P machine which helped me check such matters, but
hardware failures on my ancient machines necessitated that I wipe W7P
and install Debian.  I need to replace that box.

I finally got hold of a support tech at RTA in Smithville, and found
that www.chewy.com displays properly on a Windows machine at their
Smithville office.

RLH

Re: umask - default user settings?

[Max Nikulin]

On 19/07/2024 04:11, songbird wrote:

   so far, agreed, i poked at it a bit the other day to see
if MATE would work with the roughly (user-@1000,etc) systemd
unit approach but that didn't accomplish anything i could tell.


It would be great if those, who tried it, reported more precise what 
they did.


- Did you call "systemctl daemon-reload" for *system* instance after 
adding a drop-in for user@1000.service?
- Did you do logout after in the case of *user* service.d override? It 
is not enough to execute "systemd --user daemon-reload".
- Does MATE use scopes and services to run applications an components? 
"ps xwf" and "systemd-cgls" trees may clarify where started applications 
appear.

Re: web site displays blank page

[Max Nikulin]

On 19/07/2024 00:17, Russell L. Harris wrote:

CHEWY is a large nation-wide outfit.  I suspect the trouble is with
RTA, because of frequent freezes when viewing a certain news website,
while all other streams are uninterrupted with my 10/1 service from
RTA.


Some web sites are rather aggressive with their protection against DDoS 
and content scraping. Wget, curl, browsers blocking cookies and 
JavaScript may easily be banned. If you are unlucky, whole subnet of 
your provider may be temporary blocked. I have not tried if it is 
applied to the particular site.

Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

[songbird]

The Wanderer wrote:
...
> By taking on yourself the risk and burden of running sid, you are
> volunteering to be one of those who helps notice issues before they
> reach testing, and report those issues so that the machinery of the
> archive can stop the package versions which those issues from migrating
> to testing. Ideally, you are also volunteering to be one of those who
> helps the package maintainers track down and fix the issues.

  there is no such contract.  just like Debian Developers and
other volunteers are not forced to do work they would not wish
to do.  however, Debian Developers and others do have a social
agreement and other rules they do pledge to abide by.

  a simple user?  anyone using any version, there's no contract
we agree to for such use.


> -- And, by doing that, you are volunteering to help protect those who do
> *not* run sid from having to encounter those issues. It's an admirable
> thing to do, really, if you have the time and energy and so forth to
> spare for it.
>
> (I just doubt whether a lot of those who currently run sid understand
> that that is what they are volunteering for, given the pattern of "what
> to update against" recommendations that I remember seeing, which was
> rather at odds with what I expected and what I myself would have
> recommended.)

  i usually run testing and parts of unstable, but also stable.

  i contribute where i can when i can, but i'm certainly not
bound by any formal agreement or contract (nor could i real-
istically honor one were it somehow attempted to be imposed).

  i understand your intent and that is how i feel myself but i
would not state it so strongly.  i consider it all on my best
efforts and under the time contraints i have.  sometimes i can
be interrupted at any moment caring for a parent so that is
a first priority no matter what.


  songbird

Re: umask - default user settings?

[songbird]

Max Nikulin wrote:
> On 19/07/2024 04:11, songbird wrote:
>>so far, agreed, i poked at it a bit the other day to see
>> if MATE would work with the roughly (user-@1000,etc) systemd
>> unit approach but that didn't accomplish anything i could tell.
>
> It would be great if those, who tried it, reported more precise what 
> they did.
>
> - Did you call "systemctl daemon-reload" for *system* instance after 
> adding a drop-in for user@1000.service?
> - Did you do logout after in the case of *user* service.d override? It 
> is not enough to execute "systemd --user daemon-reload".
> - Does MATE use scopes and services to run applications an components? 
> "ps xwf" and "systemd-cgls" trees may clarify where started applications 
> appear.

  neither of those show all the programs that i have
included on the panels, but there are cgroups and some
of the other programs listed.

  the missing programs are indeed being started since i
use them all the time.


  songbird

Re: VirtualBox (VB) and Windows on Debian

[George at Clug]

On Friday, 19-07-2024 at 10:15 s...@swampdog.co.uk wrote:
> On Wednesday, 17 July 2024 21:31:00 BST Jeffrey Walton wrote:
> > On Tue, Jul 16, 2024 at 1:35 PM jeremy ardley  
> wrote:
> > > On 16/7/24 19:31, Tom Browder wrote:
> > > > I haven't looked at VB in a long time, but I have a real need for a
> > > > Windows host
> > > > to port some Linux libraries to Windows in order to support the Raku
> > > > language.
> > > > 
> > > > I now have lots of memory and disk space which was always a significant
> > > > issue when I used it before, and my use case is much different. Then I
> > > > was trying to show Windows users how they could run Linux, now I want to
> > > > help Windows folks to use a new programming language that was developed
> > > > on *nix systems.
> > > > 
> > > > Thus my question is: Has anyone use a recent version of VB to run
> > > > Windows with satisfactory results? (Note I still have a legal copy of
> > > > Win 10 on a CD as well as a portable DVD player with a USB connector.)
> > > > 
> > > > Thank you my fellow Debian users!
> > > 
> > > VirtualBox is not supported on Debian 12.
> > > 
> > > There are alternatives that include:
> > > 
> > > - KVM/QEMU
> > > 
> > > - VMWare Workstation Pro (which is now free for private use)
> > > 
> > > In my experience KVM/QEMU is fairly stable. The VMWare product not so
> > > much.
> > > 
> > > Given everything is virtual you can easily try all options in an hour or
> > > two.
> > 
> > Add a "mee too" for KVM/QEMU/libvirt. The components are managed by
> > the kernel, so there are usually no technical problems, like unsigned
> > modules. Virt Manager takes a little getting used to, but everything
> > you need is there.
> > 
> > The only downside to KVM/QEMU/libvirt is networking in some cases.
> > Configuring a VM to use your local DHCP server is a pain because you
> > have to setup and configure the bridging yourself. And the
> > documentation to do it does not exist.
> 
> Out of interest, how is one supposed to do it now? I set mine up ages ago via 
> /etc/network/interfaces - eg..
> 
> auto br0
> iface br0 inet dhcp
>   bridge_portsenp4s0
>   bridge_stp  off
>   bridge_fd   0
>   bridge_maxwait  0
> 
> ..but I have no idea how to do it now. Manpage says 'brctl' is obsolete and 
> points to 'bridge' which I've never used.

After I uninstalled Network Manager, I found this page very useful for setting 
up a bridge:

https://wiki.debian.org/BridgeNetworkConnections#Manual_bridge_setup

Configuring bridging in /etc/network/interfaces

If you like static IP’s, then you can just add the static IP options under the 
br0 interface setup. For example:

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

 # The loopback network interface
 auto lo br0
 iface lo inet loopback

 # Set up interfaces manually, avoiding conflicts with, e.g., network manager
 iface eth0 inet manual

 iface eth1 inet manual

 # Bridge setup
 iface br0 inet static
bridge_ports eth0 eth1
address 192.168.1.2
broadcast 192.168.1.255
netmask 255.255.255.0
gateway 192.168.1.1


One day I would like to learn all that this page explains, but I think the 
above is easier:

https://wiki.debian.org/NetworkConfiguration#Bridging
Bridging

I keep trying to convince myself that I should learn and then use 
systemd-networkd :

https://wiki.debian.org/SystemdNetworkd
bridging over a bond

https://wiki.archlinux.org/title/systemd-networkd

https://major.io/p/creating-a-bridge-for-virtual-machines-using-systemd-networkd/
Creating a bridge for virtual machines using systemd-networkd
3.1 Network bridge with DHCP

Yet another way (just how many network configuration systems does Linux have?)

https://wiki.archlinux.org/title/Network_bridge

I guess you had found these web pages or ones like them yourself, but in case 
you had not, hope they are a help?

I use the first example that uses "/etc/network/interfaces" which appears to 
work for servers when Network Manager is not installed but on systems that have 
Network Manager I have experience some delay issues with networking when 
starting up the computer. And I gave up on setting up Bridges on Wireless 
network interfaces as I think each wireless connection is treated as a new 
network interface.

George.
> 
> 
> 
> 
>