Re: pci 0000:00:01:0: MSI quirk detected; subordinated MSI disabled ...

[didier gaumet]

Le 15/04/2021 à 02:29, Albretch Mueller a écrit :


  if I boot up passing to the kernel the start up option:

  knoppix64 debug pci=nomsi noapic

  I would get just two lines further bellow:

  pci :00:01:0: MSI quirk detected; subordinated MSI disabled
  PCI Interrupt Link [LNKA] enabled at IRQ 11
  PCI: setting IRQ 11 as level-triggered

  and the boot process would stop.

  is there a way for me to know what the next step would be? The kernel
boot up logs should be " (do)ing ", "... ok"

[...]

Hello Albretch,

I do not know if there is a way to deduce what the next step is in the 
boot process of a particular hardware. And with systemd, the boot 
procedure is parallelized


I am afraid I have no tried and easy solution to propose to you

I do not know what you motherboard is and how old it is.

What I suggest would be to investigate if your BIOS or UEFI has 
particular settings for PCI and try to adapt them to the hardware 
present and the OS installed/to be installed.


As a further measure, you could try to play with the different kernel 
parameters to see if there is an improvement:

 https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.html

concerned parameters could be:
- *debug* (to increase the level on information you get at boot, but I 
doubt it alittle because the Debian kernel is not built with all debug 
options in order to be quicker at runtime)

- *irq* (whith the nomsi option, the system would, it seems, be in irq mode)
- *acpi*
- *bios* (to try to forbid the bios to be called by the OS to determine 
how to call MSI/IRQ)

- *pci* and *pcie*

As with Knoppix, you can pass a kernel option to the boot in Debian by 
hitting "e" key at boot to edit the command line to launch the kernel


Good luck :-)

Re: [OT] Help with clonezilla-live: LUKS/LVM2 image backup without partclone.dd

[didier gaumet]

Ouch! both the two replies I made yesterday on this list were too rough 
and I should have read the original posts more carefully.

 Sorry for that and not being able to propose a solution :-)

Re: Captura de pantalla (video screencast) con FFMPEG con muy bajos FPS y poca fluidez

[jEsuSdA 8)]

El 14/4/21 a las 9:52, Eduardo Jorge Gil Michelena escribió:

Mira...
Yo tengo una empresa que trabaja editando videos publicitarios en forma 
profesional para Cine, TV y Streaming así que de video tenemos bastante 
experiencia.
Es por ello que te puedo asegurar que Linux está tremendamente atrasado 
en todo lo que sea video y gráfica profesional por lo que no me 
sorprende que al actualizar una maquina a una muchísimo más moderna el 
comportamiento en el trabajo de video sea menos eficiente y más lento. A 
nosotros nos pasa a menudo, con máquinas de 16 núcleos Xeon la sola 
transposición para sólo adaptar las frames a una norma, es una tortura 
pues es tremendamente lenta sobre Linux.


Una solución de compromiso que no resuelve totalmente los tremendos 
atrasos de Linux en cuestión de videos es actualizar los drivers e 
instalar MESA. Eso, con suerte y viento a favor, te podrá sacar 
momentáneamente del paso, pero no te solucionará el tema de la lentitud 
que tiene LINUX al trabajar video y muchos más con hardware gráfico nuevo.


Nosotros hace rato que DEJAMOS de USAR Linux para trabajos en video y 
gráfica porque NO sirve, esta tan desactualizado que los empleados 
editores se quejaban porque les hacía perder mucho tiempo y los 
programas que tenían a mano para editar eran muchísimo más pobres que 
los que puede haber en Windows o Macs. Así que dejamos de usar Linux en 
gráfica, usamos WINDOWS para gráfica y videos mientras dejamos LINUX en 
servers y PC Administrativas.


Para finalizar: Con Linux y algunos programitas se pueden hacer videos 
pero de manera NO profesional y con un desperdicio de recursos 
impresionante. Conocemos que hay películas, animaciones y clips hechos 
enteramente con LINUX pero... lo que no dicen es que lo hecho llevó 
muchísimo más tiempo, más recursos de PC y mucho más esfuerzo que si lo 
hubiesen realizado con Windows.




Hola, Eduardo.
Gracias por compartir tu experiencia.

En mi caso particular, sí que puedo decir que he notado mucho la mejora 
en tareas de edición y codificación y el único problema detectado sería 
con la captura de pantalla.


Respecto a que linux no esté preparado para vídeo, en el caso concreto 
que nos ocupa, y que es el uso de FFMPEG, me llamó mucho la atención lo 
que comentas, dado que a mí siempre me pareció que ffmpeg funcionaba 
genial (hasta mi problema actual) y de hecho es lo que emplean sitios 
como youtube, vimeo y demás servicios web y redes sociales para la 
conversión de vídeo/audio, sobre máquinas Unix/Linux, así que hasta 
ahora pensaba que si ellos empleaban esta tecnología sería porque estaba 
a un buen nivel.


En cualquier caso y tras estar estos días dándole vueltas y haciendo 
pruebas, me voy aproximando más a la idea de que el problema estaría más 
en los drivers de la gráfica o en una combinación de éstos y Xorg, más 
que en el propio ffmeg.


Seguiré probando a ver si doy con la clave. ;)

Un saludo cordial!

Re: pci 0000:00:01:0: MSI quirk detected; subordinated MSI disabled ...

[Gene Heskett]

On Thursday 15 April 2021 03:50:19 didier gaumet wrote:

> Le 15/04/2021 à 02:29, Albretch Mueller a écrit :
> >   if I boot up passing to the kernel the start up option:
> >
> >   knoppix64 debug pci=nomsi noapic
> >
> >   I would get just two lines further bellow:
> >
> >   pci :00:01:0: MSI quirk detected; subordinated MSI disabled
> >   PCI Interrupt Link [LNKA] enabled at IRQ 11
> >   PCI: setting IRQ 11 as level-triggered
> >
> >   and the boot process would stop.
> >
> >   is there a way for me to know what the next step would be? The
> > kernel boot up logs should be " (do)ing ", "... ok"
>
> [...]
>
> Hello Albretch,
>
> I do not know if there is a way to deduce what the next step is in the
> boot process of a particular hardware. And with systemd, the boot
> procedure is parallelized
>
> I am afraid I have no tried and easy solution to propose to you
>
> I do not know what you motherboard is and how old it is.
>
> What I suggest would be to investigate if your BIOS or UEFI has
> particular settings for PCI and try to adapt them to the hardware
> present and the OS installed/to be installed.
>
> As a further measure, you could try to play with the different kernel
> parameters to see if there is an improvement:
>  
> https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.ht
>ml
>
> concerned parameters could be:
> - *debug* (to increase the level on information you get at boot, but I
> doubt it alittle because the Debian kernel is not built with all debug
> options in order to be quicker at runtime)
> - *irq* (whith the nomsi option, the system would, it seems, be in irq
> mode) - *acpi*
> - *bios* (to try to forbid the bios to be called by the OS to
> determine how to call MSI/IRQ)
> - *pci* and *pcie*
>
> As with Knoppix, you can pass a kernel option to the boot in Debian by
> hitting "e" key at boot to edit the command line to launch the kernel
>
> Good luck :-)

Or you could do what I did after fighting with an msi board for several 
years a decade back, feed it to the trash can and replace it with an ARK 
shoebox w/intel atom D-525-MW motherboad that was just enough power to 
get the job done, and Just Worked for a decade. But just in the last 90 
days has been replaced with a stack of Dell 7010's with i5 cpu's, off 
lease stuff for $150/copy. Much faster stuff, and makes 4 of the 6 
running in my farm identical. Simplifies things quite a bit.

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

Re: pci 0000:00:01:0: MSI quirk detected; subordinated MSI disabled ...

[Andrew M.A. Cater]

On Thu, Apr 15, 2021 at 06:30:41AM -0400, Gene Heskett wrote:
> On Thursday 15 April 2021 03:50:19 didier gaumet wrote:
> 
> > Le 15/04/2021 à 02:29, Albretch Mueller a écrit :
> > >   if I boot up passing to the kernel the start up option:
> > >
> > >   knoppix64 debug pci=nomsi noapic
> > >
> > >   I would get just two lines further bellow:
> > >
> > >   pci :00:01:0: MSI quirk detected; subordinated MSI disabled
> > >   PCI Interrupt Link [LNKA] enabled at IRQ 11
> > >   PCI: setting IRQ 11 as level-triggered
> > >
> > >   and the boot process would stop.
> > >
> > >   is there a way for me to know what the next step would be? The
> > > kernel boot up logs should be " (do)ing ", "... ok"
> >

Hello Albretch

Are you still subject to constraints in what you can do with your hardware: I 
know a while back in other threads on this mailing list you said that you had
to use virtual machines / live disks.

Is this a desktop / laptop and do you have the ability to change whatever
settings you need?

All the very best, as ever,

Andy C.


> > [...]
> >
> > Hello Albretch,
> >
> > I do not know if there is a way to deduce what the next step is in the
> > boot process of a particular hardware. And with systemd, the boot
> > procedure is parallelized
> >
> > I am afraid I have no tried and easy solution to propose to you
> >
> > I do not know what you motherboard is and how old it is.
> >
> > What I suggest would be to investigate if your BIOS or UEFI has
> > particular settings for PCI and try to adapt them to the hardware
> > present and the OS installed/to be installed.
> >
> > As a further measure, you could try to play with the different kernel
> > parameters to see if there is an improvement:
> >  
> > https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.ht
> >ml
> >
> > concerned parameters could be:
> > - *debug* (to increase the level on information you get at boot, but I
> > doubt it alittle because the Debian kernel is not built with all debug
> > options in order to be quicker at runtime)
> > - *irq* (whith the nomsi option, the system would, it seems, be in irq
> > mode) - *acpi*
> > - *bios* (to try to forbid the bios to be called by the OS to
> > determine how to call MSI/IRQ)
> > - *pci* and *pcie*
> >
> > As with Knoppix, you can pass a kernel option to the boot in Debian by
> > hitting "e" key at boot to edit the command line to launch the kernel
> >
> > Good luck :-)
> 
> Or you could do what I did after fighting with an msi board for several 
> years a decade back, feed it to the trash can and replace it with an ARK 
> shoebox w/intel atom D-525-MW motherboad that was just enough power to 
> get the job done, and Just Worked for a decade. But just in the last 90 
> days has been replaced with a stack of Dell 7010's with i5 cpu's, off 
> lease stuff for $150/copy. Much faster stuff, and makes 4 of the 6 
> running in my farm identical. Simplifies things quite a bit.
> 
> Cheers, Gene Heskett
> -- 
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page 
> 

Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[Eduardo M KALINOWSKI]

On 15/04/2021 09:12, Celejar wrote:

On Thu, 15 Apr 2021 11:16:59 +0100
piorunz  wrote:


On 15/04/2021 03:15, Celejar wrote:


http://www.daat.ac.il/
https://www.daat.ac.il/

Celejar


I can confirm the problem, by the way.


Their webserver is misconfigured. AFAIR, if they don't support https,
their server should redirect to http page. Instead, they throw 404 error.

Do you have a reference for this as required by the standards?


I don't think this is required by any standard.

But it's certainly bad practice: if they don't want to support https, 
they should disable it, and not return a 404 error. It may not be a 
requirement that the http and https content have to be the same, but it 
certainly makes a lot of sense that they are.


So I'd agree that the website is misconfigured. You might try contacting 
them.


Unlike the HTTPS Everywhere extension, that has a list of sites that 
should be accessed only with https, the built-in Firefox function seems 
to just try to make an https connection, and if it succeeds, assumes 
(reasonably, IMHO) that the site supports https. Since 404 is a valid 
response that in no way indicates lack of https support (on the 
contrary), it then redirects everything to https.


The docs say you can disable https for a specific site: 
https://blog.mozilla.org/security/2020/11/17/firefox-83-introduces-https-only-mode/ 
. But if this happens a lot, it might be simpler to simply disable that 

Firefox feature. Not because it's buggy, but because it make reasonable 
assumptions about websites' behaviours, which unfortunately are not 
followed by everyone.




--
Canada Bill Jones's Motto:
It's morally wrong to allow suckers to keep their money.

Canada Bill Jones's Supplement:
A Smith and Wesson beats four aces.

Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[Celejar]

On Thu, 15 Apr 2021 11:16:59 +0100
piorunz  wrote:

> On 15/04/2021 03:15, Celejar wrote:
> 
> >> It certainly works fine for me. I use https only mode for many months
> >> now. Can you bring an example of a page which returns good page on http,
> >> but 404 error on https?
> >
> > http://www.daat.ac.il/
> > https://www.daat.ac.il/
> >
> > Celejar
> 
> Their webserver is misconfigured. AFAIR, if they don't support https,
> their server should redirect to http page. Instead, they throw 404 error.

Do you have a reference for this as required by the standards?

> Your web browser behaviour is as intended, everything is fine.
> If webadmins of that page don't know their sh*t, are you sure you want
> to use that website? Who knows what else they forgot to implement.

No, everything is not fine. The website in question is a very valuable
one - it contains a wealth of important academic articles that are
valuable to my work. The techie attitude that the value of a resource
is somehow correlated to the technical competence of its implementation
is unfortunate and misguided.

I might indeed be reluctant to trust such a site with sensitive
personal information, but to suggest that we should shun websites just
because their administrators should be doing a better job is illogical.

> Disclaimer: I never worked in IT, all self taught, but I have webpage
> which I put up myself on Debian computer, with https cert (it's free),
> TLS 2.0/3.0 only, PFS, HSTS preload with long duration, OCSP stapling,
> top spec security. These guys? They can't even redirect to their http page.

Celejar

Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[Jonathan Dowland]

On Thu, Apr 15, 2021 at 11:44:21AM +0100, Darac Marjal wrote:

If they don't support https, they shouldn't respond at all.


Perhaps they do, but not for the hostname being used here to access the
web server.


--
Please do not CC me, I am subscribed to the list.

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

Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[Greg Wooledge]

On Thu, Apr 15, 2021 at 11:16:59AM +0100, piorunz wrote:
> TLS 2.0/3.0 only

Nitpick: TLS 1.2 and 1.3.

Re: for the mutt users

[Jonathan Dowland]

On Tue, Apr 13, 2021 at 02:06:29PM +0300, Reco wrote:

On Tue, Apr 13, 2021 at 06:52:57AM -0400, Jude DaShiell wrote:

The mixmaster package comes up as a suggested install for mutt and is
not in debian repositories so far as I know.


It was removed from the main back in 2017, see #880101.


Thanks, I've filed patches for mutt and neomutt to remove the reference.

--
Please do not CC me, I am subscribed to the list.

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

Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[piorunz]

On 15/04/2021 03:15, Celejar wrote:


It certainly works fine for me. I use https only mode for many months
now. Can you bring an example of a page which returns good page on http,
but 404 error on https?


http://www.daat.ac.il/
https://www.daat.ac.il/

Celejar


Their webserver is misconfigured. AFAIR, if they don't support https,
their server should redirect to http page. Instead, they throw 404 error.

Your web browser behaviour is as intended, everything is fine.
If webadmins of that page don't know their sh*t, are you sure you want
to use that website? Who knows what else they forgot to implement.

Disclaimer: I never worked in IT, all self taught, but I have webpage
which I put up myself on Debian computer, with https cert (it's free),
TLS 2.0/3.0 only, PFS, HSTS preload with long duration, OCSP stapling,
top spec security. These guys? They can't even redirect to their http page.


--

With kindest regards, piorunz.

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

Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[Darac Marjal]

On 15/04/2021 11:16, piorunz wrote:
> On 15/04/2021 03:15, Celejar wrote:
>
>>> It certainly works fine for me. I use https only mode for many months
>>> now. Can you bring an example of a page which returns good page on
>>> http,
>>> but 404 error on https?
>>
>> http://www.daat.ac.il/
>> https://www.daat.ac.il/
>>
>> Celejar
>
> Their webserver is misconfigured. AFAIR, if they don't support https,
> their server should redirect to http page. Instead, they throw 404 error.

If they don't support https, they shouldn't respond at all. Receiving a
404 comes after successful TLS negotiation. With HTTPS you first
establish a TCP connection to port 443 on the server, then you establish
a TLS tunnel to the server; only once those are complete can you send
the "GET" verb over the tunnel. The server has then, securely, responded
"I don't have a page called /".

While it's common practice for HTTP  and HTTPS sites to be identical,
it's not really built in to the protocol. I could well see a situation
where a webmaster might configure, say, just the /admin part to be
accessible over HTTPS.

That said, common use is changing. It's now expected that 
http://example.com, https://example.com, http://www.example.com and
https://www.example.com all serve identical content (mostly because
humans are terrible at paying attention to the full URL and just see
that all as "example dot com".

>
> Your web browser behaviour is as intended, everything is fine.
> If webadmins of that page don't know their sh*t, are you sure you want
> to use that website? Who knows what else they forgot to implement.
>
> Disclaimer: I never worked in IT, all self taught, but I have webpage
> which I put up myself on Debian computer, with https cert (it's free),
> TLS 2.0/3.0 only, PFS, HSTS preload with long duration, OCSP stapling,
> top spec security. These guys? They can't even redirect to their http
> page.
>
>
> -- 
>
> With kindest regards, piorunz.
>
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
> ⠈⠳⣄
>



OpenPGP_signature
Description: OpenPGP digital signature

Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[piorunz]

On 15/04/2021 15:49, Erwan David wrote:


If webadmin FORGETS to implement https in 2021, then he deserves losing
his job. 勞



But nothing says that http:// and https:// must have
same content.


 Of course, 404 error on https version of the website it a
great piece of content. Admins are doing great job.

--

With kindest regards, piorunz.

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

Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[mett]

2021-04-15 21:12 に Celejar さんは書きました:

On Thu, 15 Apr 2021 11:16:59 +0100
piorunz  wrote:


On 15/04/2021 03:15, Celejar wrote:

>> It certainly works fine for me. I use https only mode for many months
>> now. Can you bring an example of a page which returns good page on http,
>> but 404 error on https?
>
> http://www.daat.ac.il/
> https://www.daat.ac.il/
>
> Celejar

Their webserver is misconfigured. AFAIR, if they don't support https,
their server should redirect to http page. Instead, they throw 404 
error.


Do you have a reference for this as required by the standards?


Your web browser behaviour is as intended, everything is fine.
If webadmins of that page don't know their sh*t, are you sure you want
to use that website? Who knows what else they forgot to implement.


No, everything is not fine. The website in question is a very valuable
one - it contains a wealth of important academic articles that are
valuable to my work. The techie attitude that the value of a resource
is somehow correlated to the technical competence of its implementation
is unfortunate and misguided.

I might indeed be reluctant to trust such a site with sensitive
personal information, but to suggest that we should shun websites just
because their administrators should be doing a better job is illogical.


Disclaimer: I never worked in IT, all self taught, but I have webpage
which I put up myself on Debian computer, with https cert (it's free),
TLS 2.0/3.0 only, PFS, HSTS preload with long duration, OCSP stapling,
top spec security. These guys? They can't even redirect to their http 
page.


Celejar


Hi,

The site address you provided support https:


So, indeed, some misconfiguration it seems.
Maybe they simply forget to redirect http to https.


Though I agree no need to shun them.

HTH

Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[Jonathan Dowland]

On Thu, Apr 15, 2021 at 01:31:45PM +0100, Jonathan Dowland wrote:

On Thu, Apr 15, 2021 at 11:44:21AM +0100, Darac Marjal wrote:

If they don't support https, they shouldn't respond at all.


Perhaps they do, but not for the hostname being used here to access the
web server.


Although looking at the cert, the CN is for that host (www.daat.ac.il).

--
Please do not CC me, I am subscribed to the list.

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

Re: KVM: GPU passthrough

[Gokan Atmaca]

Hello

> Just to confirm: you have at least two graphics cards? One for
> the host to boot with, one for your guest to take over?

I saw it working in my trials. But of course, since there is only one
graphics card, the image of the host system is gone. :) I am looking
for a motherboard where I can install two graphics cards.

On Fri, Apr 9, 2021 at 2:51 AM Dan Ritter  wrote:
>
> Gokan Atmaca wrote:
> > Hello
> >
> > I want to use the graphics card directly in the virtual machine. IOMMU
> > seems to be running, but unfortunately it doesn't work when I want to
> > start the virtual machine.
> >
> >
> > error:
> > pci,host=:01:00.0,id=hostdev0,bus=pci.0,addr=0x9: vfio
> > :01:00.0: group 1 is not viable
> > Please ensure all devices within the iommu_group are bound to their
> > vfio bus driver.
>
> Just to confirm: you have at least two graphics cards? One for
> the host to boot with, one for your guest to take over?
>
> And you loaded the vfio mod and configured it with the PCI ids
> for your second card? There could be several.
>
> -dsr-

Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[Dan Ritter]

Kenneth Parker wrote: 
> 
> I use lighttpd for eyeblinkuniverse.com, with nano as my editor. I don't
> quite understand the Certificates required for https. I guess it is time
> for some lessons.

The easiest thing to do here is to install certbot.

Assuming that your web root is /var/www and your domain name is
eyeblinkuniverse.com:

certbot certonly --webroot -w /var/www -d eyeblinkuniverse.com -d 
www.eyeblinkuniverse.com

It will ask you some questions, then it should drop some files
in /etc/letsencrypt/live/eyeblinkuniverse.com/

Now you need to combine those files for lighttpd:

cat /etc/letsencrypt/live/eyeblinkuniverse.com/privkey.pem \
/etc/letsencrypt/live/eyeblinkuniverse.com/cert.pem > \
/etc/letsencrypt/live/eyeblinkuniverse/merged.pem

And then tell lighttpd to use it:

$SERVER["socket"] == ":443" {
 ssl.engine   = "enable"
 ssl.ca-file  = "/etc/letsencrypt/live/eyeblinkuniverse.com/chain.pem"
 ssl.pemfile  = "/etc/letsencrypt/live/eyeblinkuniverse.com/merged.pem"
}


And restart lighttpd. Test your new https://www.eyeblinkuniverse.com 

Last step: create a cron job to run once a week that does
this:

certbot renew && \
cat /etc/letsencrypt/live/eyeblinkuniverse.com/privkey.pem \
/etc/letsencrypt/live/eyeblinkuniverse.com/cert.pem > \
/etc/letsencrypt/live/eyeblinkuniverse/merged.pem && \
service lighttpd restart

That should take care of you. If you run into trouble, you're
using the largest issuer of SSL certs and the most popular
client, and the cron job should let you know a month before the
cert actually expires.

-dsr-

Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[piorunz]

On 15/04/2021 13:40, mett wrote:


So, indeed, some misconfiguration it seems.
Maybe they simply forget to redirect http to https.


Though I agree no need to shun them.

HTH


If webadmin FORGETS to implement https in 2021, then he deserves losing
his job. 勞


--

With kindest regards, piorunz.

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

Re: pci 0000:00:01:0: MSI quirk detected; subordinated MSI disabled ...

[Dan Ritter]

Gene Heskett wrote: 
> 
> Or you could do what I did after fighting with an msi board for several 
> years a decade back, feed it to the trash can and replace it with an ARK 


MSI the motherboard manufacturer has nothing to do with the 
PCI feature we are discussing here.

https://www.kernel.org/doc/html/latest/PCI/msi-howto.html

-dsr-

Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[Erwan David]

Le 15/04/2021 à 16:16, piorunz a écrit :

On 15/04/2021 13:40, mett wrote:


So, indeed, some misconfiguration it seems.
Maybe they simply forget to redirect http to https.


Though I agree no need to shun them.

HTH


If webadmin FORGETS to implement https in 2021, then he deserves losing
his job. 勞




But nothing says that http:// and https:// must have 
same content.

Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[Kenneth Parker]

On Thu, Apr 15, 2021, 9:32 AM Dan Ritter  wrote:

> Kenneth Parker wrote:
> >
> > I use lighttpd for eyeblinkuniverse.com, with nano as my editor. I don't
> > quite understand the Certificates required for https. I guess it is time
> > for some lessons.
>
> The easiest thing to do here is to install certbot.
>
> Assuming that your web root is /var/www and your domain name is
> eyeblinkuniverse.com:
>
> certbot certonly --webroot -w /var/www -d eyeblinkuniverse.com -d
> www.eyeblinkuniverse.com
>
> It will ask you some questions, then it should drop some files
> in /etc/letsencrypt/live/eyeblinkuniverse.com/
>
> Now you need to combine those files for lighttpd:
>
> cat /etc/letsencrypt/live/eyeblinkuniverse.com/privkey.pem \
> /etc/letsencrypt/live/eyeblinkuniverse.com/cert.pem > \
> /etc/letsencrypt/live/eyeblinkuniverse/merged.pem
>
> And then tell lighttpd to use it:
>
> $SERVER["socket"] == ":443" {
>  ssl.engine   = "enable"
>  ssl.ca-file  = "/etc/letsencrypt/live/eyeblinkuniverse.com/chain.pem"
>  ssl.pemfile  = "/etc/letsencrypt/live/eyeblinkuniverse.com/merged.pem"
> }
>
>
> And restart lighttpd. Test your new https://www.eyeblinkuniverse.com
>
> Last step: create a cron job to run once a week that does
> this:
>
> certbot renew && \
> cat /etc/letsencrypt/live/eyeblinkuniverse.com/privkey.pem \
> /etc/letsencrypt/live/eyeblinkuniverse.com/cert.pem > \
> /etc/letsencrypt/live/eyeblinkuniverse/merged.pem && \
> service lighttpd restart
>
> That should take care of you. If you run into trouble, you're
> using the largest issuer of SSL certs and the most popular
> client, and the cron job should let you know a month before the
> cert actually expires.
>

Wow.  Thanks!  I had, also discussed this with the Support Staff at
Linode.  You said it "MUCH" clearer than they did.

I am in the process of a System Upgrade (from Ubuntu 14.04 to Debian
Buster) and this will become, one of my, more enjoyable tasks.

Kenneth Parker

>

Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[Celejar]

On Thu, 15 Apr 2021 09:31:11 -0300
Eduardo M KALINOWSKI  wrote:

> 
> On 15/04/2021 09:12, Celejar wrote:
> > On Thu, 15 Apr 2021 11:16:59 +0100
> > piorunz  wrote:
> >
> >> On 15/04/2021 03:15, Celejar wrote:
> >>
> >>> http://www.daat.ac.il/
> >>> https://www.daat.ac.il/
> >>>
> >>> Celejar
> 
> I can confirm the problem, by the way.
> 
> >> Their webserver is misconfigured. AFAIR, if they don't support https,
> >> their server should redirect to http page. Instead, they throw 404 error.
> > Do you have a reference for this as required by the standards?
> 
> I don't think this is required by any standard.
> 
> But it's certainly bad practice: if they don't want to support https, 
> they should disable it, and not return a 404 error. It may not be a 
> requirement that the http and https content have to be the same, but it 
> certainly makes a lot of sense that they are.
> 
> So I'd agree that the website is misconfigured. You might try contacting 
> them.
> 
> Unlike the HTTPS Everywhere extension, that has a list of sites that 
> should be accessed only with https, the built-in Firefox function seems 
> to just try to make an https connection, and if it succeeds, assumes 
> (reasonably, IMHO) that the site supports https. Since 404 is a valid 
> response that in no way indicates lack of https support (on the 
> contrary), it then redirects everything to https.

Thank you. That was my analysis of the problem as well.

> The docs say you can disable https for a specific site: 
> https://blog.mozilla.org/security/2020/11/17/firefox-83-introduces-https-only-mode/
>  

I tried the setting, but it didn't seem to work.

> . But if this happens a lot, it might be simpler to simply disable that 
> 
> Firefox feature. Not because it's buggy, but because it make reasonable 
> assumptions about websites' behaviours, which unfortunately are not 
> followed by everyone.

I may have to do that.

Celejar

Re: pci 0000:00:01:0: MSI quirk detected; subordinated MSI disabled ...

[Alexander V. Makartsev]

On 15.04.2021 23:14, Albretch Mueller wrote:

https://www.kernel.org/doc/html/latest/PCI/msi-howto.html

thank you. it was a confusing coincidence. The thing is that the
motherboard on that box is an:

MSI MS-7641 Ver.3.0 + AMD Athlon II x2 250

  the two links were very good but also "too intertaining" I just need
to get the thing to work for me asap.

lbrtchx


Have you tried to update BIOS? [1] Patch notes look promising.
For me it's usually a first step of troubleshooting and resolving 
possibly hardware related problems.
If first link doesn't lead to support page for your motherboard, you 
have to find your exact motherboard model using search. [2]

If you flash wrong BIOS image you will brick your motherboard.


[1] https://us.msi.com/Motherboard/support/760GM-P23-FX
[2] https://us.msi.com/search/MS-7641?page=1

--
With kindest regards, Alexander.

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

Re: pci 0000:00:01:0: MSI quirk detected; subordinated MSI disabled ...

[didier gaumet]

Le 15/04/2021 à 20:14, Albretch Mueller a écrit :
[...]

and I haven't been able to find their manual/specs for that board
online (most probably for other reasons)

[...]

MSI MS-7641 Ver.3.0 + AMD Athlon II x2 250

[...]

the page of this MB support on the MSI website:
 https://www.msi.com/Motherboard/support/760GM-P23-FX#down-bios

the manual:
 https://download.msi.com/archive/mnu_exe/M7641v3.0.zip
(hit  at boot to access the BIOS)

Re: pci 0000:00:01:0: MSI quirk detected; subordinated MSI disabled ...

[Albretch Mueller]

> What I suggest would be to investigate if your BIOS or UEFI has particular 
> settings for PCI and try
> to adapt them to the hardware present and the OS installed/to be installed.

> As a further measure, you could try to play with the different kernel 
> parameters to see if there is an
> improvement: 
> https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.html
> concerned parameters could be:
> - *debug* (to increase the level on information you get at boot, but I doubt 
> it alittle because
> the Debian kernel is not built with all debug options in order to be quicker 
> at runtime)
> - *irq* (whith the nomsi option, the system would, it seems, be in irq mode)
> - *acpi*
> - *bios* (to try to forbid the bios to be called by the OS to determine how 
> to call MSI/IRQ)
> - *pci* and *pcie*

> As with Knoppix, you can pass a kernel option to the boot in Debian by 
> hitting "e" key at boot to edit the command line to launch the kernel

 Thank you. I have tried every possible option combination with
knoppix and I have studied reports on similar problems by other
people, but I haven't still been able to make that mobo boot up.

 The problem is that the idiots that designed that motherboard make it
hard for you to get to their BIOS (I haven't even figured out that)
and I haven't been able to find their manual/specs for that board
online (most probably for other reasons)

> Or you could do what I did after fighting with an msi board for
> several years a decade back ...

 I may have too, but I must work under constraints and on a short
budget and I must be hopeful as well ;-).

> Are you still subject to constraints in what you can do
> with your hardware: I know a while back in other threads
> on this mailing list you said that you had to use virtual
> machines / live disks.

 Well, yes. I can only access the internet using live CDs/DVDs
(preferably while using knoppix with the toram option). I have higher
powers actively messing with me. Some people tell me that they "mess
with", monitor everyone that I am just aware and I hate them and their
bs because it messes with my line of work.

 I never effing ever connect my work machine to the Internet. I mean,
noticing my doctor telling me whatever with a computer connected to
the Internet makes me anxious and if you think I am "paranoid" all I
have to say is: "thank you". These times being "paranoid" about such
matters is a healthy state of mind.

 So, live DVDs with some extra scripts to customize things a bit and I
am fine to go.

 I like Debian very much, just using apt in the way that it is
supposed to be used assuming that the Internet is a safe, "trusted"
environment is an odd joke to me. we have had these constant back and
forths in the mailing list. I have even been dreaming about coding a
version of apt based on java (japt?), so that you could go anywhere
with any laptop and get all libraries and etc's, it shouldn't be hard
at all but right now I cannot dedicate time and mind to any other
thing.

>MSI the motherboard manufacturer has nothing to do with the
>PCI feature we are discussing here.

>https://www.kernel.org/doc/html/latest/PCI/msi-howto.html

thank you. it was a confusing coincidence. The thing is that the
motherboard on that box is an:

MSI MS-7641 Ver.3.0 + AMD Athlon II x2 250

 the two links were very good but also "too intertaining" I just need
to get the thing to work for me asap.

lbrtchx

Re: GRUB no inicia sistema antiguo (era: debian 11 kde primer arranque)

[Marcelo Giordano]

  
Inicia Debian 11, ejecuta «cat /etc/fstab» y como súperusuario, «blkid»

y copia/pega en el mismo correo la salida de las dos órdenes, que no
serán muy largas, para ver cómo tiene el sistema identificadas las particiones.

Saludos,


root@Marcelo:/home/marcelo# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# systemd generates mount units based on this file, see systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
#           
# / was on /dev/sda6 during installation
UUID=c69220c8-b56c-482a-ba9f-8189ca315311 /   ext4 
errors=remount-ro 0   1

# /boot was on /dev/sda3 during installation
UUID=3b650b31-1fe3-426d-8b49-442a26755a1a /boot   ext4 
defaults    0   2

# /home was on /dev/sda5 during installation
UUID=52981167-db88-4b52-a108-81a6300fa98d /home   ext4 
defaults    0   2

# swap was on /dev/sda1 during installation
UUID=35202928-f425-4dc0-a0d2-aee099c971d9 none    swap 
sw  0   0

/dev/sr0    /media/cdrom0   udf,iso9660 user,noauto 0 0

root@Marcelo:/home/marcelo# blkid
bash: blkid: orden no encontrada


el último comando no pude ejecutarlo. Tampoco pude instalar el paquete

Gracias

Re: Instalar codificación nvenc.

[Eduardo Jorge Gil Michelena]

 La tarjeta de video Nvidia Quadro 4000 es una de las más avanzadas y rápidas 
del mercado destinadas principalmente (casi exclusivamente) a la edición de 
video en forma profesional.

Nosotros hemos tenido dos de estas tarjetas las cuales han dado buenos 
resultados, ahora las cambiamos por unas más modernas Quadro GV100

Nvidia provee de drivers específicos para Linux para sus tarjetas, es 
conveniente instalarlos para obtener un rendimiento aceptable.

Aún así el máximo rendimiento que se le puede sacar a estas tarjetas es bajo 
Windows, no hay duda alguna, Linux siempre ha atrasado años en cuestiones de 
edición de video.

Si bien es posible "tunear", "customizar" o intentar mejorar el comportamiento 
de programas y tarjetas de video bajo Linux esto lleva un tiempo (que es un 
costo alto) y unos dolores de cabeza que no aconsejo tener. Así que si editas 
video a nivel profesional... Linux no es por ahora una alternativa.

Ahora si eres un nerd que intenta a toda costa sacar lo mejor de una PC pues... 
ve por tu camino que has elegido sabiendo que nunca será el mío.


 El jueves, 15 de abril de 2021 20:36:11 ART, Guillermo Martinez 
 escribió:  
 
 Hola, me gustaría explotar la utilidad de renderizdo por la codificación nvenc 
que ofrece mi tarjeta nvidia quadro 4000. Estuve viendo que hay una manera de 
compliar ffmpeg para que tenga soporte a esa utilidad en programas como obs 
studio u shotcut. ¿Alguien me puede ayudar con los pasos a seguir? Estuve 
viendo foros no oficiales, pero resultan confusos, y ya he cargado al sistema 
más de una vez en los intentos.Muchas gracias. Saludos.  

Instalar codificación nvenc.

[Guillermo Martinez]

Hola, me gustaría explotar la utilidad de renderizdo por la codificación
nvenc que ofrece mi tarjeta nvidia quadro 4000.
Estuve viendo que hay una manera de compliar ffmpeg para que tenga soporte
a esa utilidad en programas como obs studio u shotcut.
¿Alguien me puede ayudar con los pasos a seguir?
Estuve viendo foros no oficiales, pero resultan confusos, y ya he cargado
al sistema más de una vez en los intentos.
Muchas gracias. Saludos.

Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[Richard Hector]

On 16/04/21 1:32 am, Dan Ritter wrote:

Last step: create a cron job to run once a week that does
this:

certbot renew && \
cat /etc/letsencrypt/live/eyeblinkuniverse.com/privkey.pem \
/etc/letsencrypt/live/eyeblinkuniverse.com/cert.pem > \
/etc/letsencrypt/live/eyeblinkuniverse/merged.pem && \
service lighttpd restart


Doesn't the certbot package create a cronjob/timer for you?

And I'd probably put the merge in a deploy hook, rather than modifying 
the cronjob and/or systemd timer.


Not to say the above won't work, of course - except that if you create 
or modify the cronjob without touching the systemd timer (and you're 
using systemd), you might get unexpected results.


And I haven't tested my thoughts :-)

Richard