how to add module options

[fxkl47BF]

i have an old analog camera and usb capture device
the capture device is a kworld dvd maker usb2.0
i'm working on debian 10.13 and kernel 4.19.0-25-amd64
the capture device has svideo and composite inputs
the module em28xx identifies it as
EM2860/SAA711X Reference Design (card=19)
xawtv can play the video just fine
but i have to manually set it for ntsc and composite input
how can i set options in /etc/modules for ntsc and composite input

Re: how to add module options

[Marco M.]

Am 27.09.2023 um 08:36:00 Uhr schrieb fxkl4...@protonmail.com:

> but i have to manually set it for ntsc and composite input

How do you set it?

Re: how to add module options

[fxkl47BF]

On Wed, 27 Sep 2023, Marco M. wrote:

> Am 27.09.2023 um 08:36:00 Uhr schrieb fxkl4...@protonmail.com:
>
>> but i have to manually set it for ntsc and composite input
>
> How do you set it?
>
open xawtv and change settings

Re: how to add module options

[Marco M.]

Am 27.09.2023 um 08:56:37 Uhr schrieb fxkl4...@protonmail.com:

> On Wed, 27 Sep 2023, Marco M. wrote:
> 
> > Am 27.09.2023 um 08:36:00 Uhr schrieb fxkl4...@protonmail.com:
> >  
> >> but i have to manually set it for ntsc and composite input  
> >
> > How do you set it?
> >  
> open xawtv and change settings

Maybe xawtv has an option to save these changes.

Re: Sunrise and Sunset from terminal

[Carles Pina i Estany]

Hi,

sudo apt install python3-ephem

And in one line:

"""
(LATITUDE=51.5; LONGITUDE=0.12; python3 -c "import ephem; o=ephem.Observer(); 
o.lat, o.lon = $LATITUDE, $LONGITUDE; print('Sunrise:', 
o.next_rising(ephem.Sun()).datetime(), 'Sunset:', 
o.next_setting(ephem.Sun()).datetime())")
"""

The output:

Sunrise: 2023-09-28 05:34:38.906872 Sunset: 2023-09-27 17:14:27.209178

It fits in an alias :-)

The () is to avoid leaving LATITUDE and LONGITUDE defined.

I wouldn't use an external service for this, it can be avoided.

On 23 Sep 2023 at 23:51:44, s...@gmx.com wrote:
> Is there a way to get sunrise and sunset time from command interpreter?
> I want to use its output for a script!
-- 
Carles Pina i Estany
https://carles.pina.cat || Wiktionary translations: https://kamus.pina.cat

Trixie upgrade

[mick.crane]

I only changed "bookworm" to "trixie in sources.list.
"apt update"
"apt upgrade"
"apt autoremove"

coinor-libcoinmplv5 was held back but
"apt full-upgrade" upgraded it.
Don't know what that was about but all seems painless.

mick

Re: Trixie upgrade

[Michael Kjörling]

On 27 Sep 2023 12:27 +0100, from mick.cr...@gmail.com (mick.crane):
> I only changed "bookworm" to "trixie in sources.list.
> "apt update"
> "apt upgrade"
> "apt autoremove"
> 
> coinor-libcoinmplv5 was held back but
> "apt full-upgrade" upgraded it.
> Don't know what that was about but all seems painless.

Last I looked, apt update / apt upgrade / apt full-upgrade was the
recommended upgrade method for a major-release Debian upgrade.

_Running only apt update / apt upgrade will leave you with a partially
upgraded system_ with some parts from the new version of Debian (that
which you are upgrading to) and some parts held back at the version
from the old version of Debian (that which you are upgrading from).

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

Re: "sudo apt-get install android-tools-adb" ... (then no device listed)

[Anssi Saari]

David Wright  writes:

> You'd have to specify a set of criteria to test. I just treat
> /media/samsungd like any other filesystem, copying files in the
> usual manner.

Well, when I last tried MTP in Linux I got maybe half of a directory
listing and then it hung there. Concluded it doesn't work but to be sure
it's been a minute.

Re: Sunrise and Sunset from terminal

[Curt]

On 2023-09-27, Carles Pina i Estany  wrote:
>
> Hi,
>
> sudo apt install python3-ephem
>

I think hdate could also work for this.

Re: Debian live boot corrupting secure boot

[Valerio Vanni]

Il 27/09/2023 05:22, Jeffrey Walton ha scritto:

On Tue, Sep 26, 2023 at 10:20 PM Valerio Vanni  wrote:


Motherboard is an Asus H510M-A.

I found the issue on latest versions of Clonezilla, but then I tried
with plain Debian live and the behavior is the same.

Booting a recent Debian USB key do some modification on secure boot that
prevents some older OS to boot.

The cycle is:

1) Machine brand new: secure boot is active, Windows 10 shows it active,
I can boot an old Clonezilla live (2.8.1-12) as many times as I want.

2) I boot from USB drive Debian Live 12
https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.1.0-amd64-kde.iso

A note: to trigger the issue, there's no need to go on and load OS. It's
enough to see the first page (that with grub entries) and then shutdown.

3) At next boots, secure boot refuses to boot from Clonezilla live
2.8.1-12. The error is
"verification failed 0x1A security violation"
Windows 10 can still start, and shows secure boot active. Only if I
disable secure boot from BIOS, I can start clonezilla.

4) I reflash BIOS, same version, and go to point 1.

Tested many times.


The failure at (3) sounds like what happened when old grub images were
blacklisted in the UEFI Revocation List dbx. Also see
.

You should probably stop doing (4).


But this way I would have to disable secure boot to load old Clonezilla.
Disable secure boot, launch clonezilla, restore image, reenable secure 
boot, start OS.


It's more complicated.


On that machine,

Re: Debian live boot corrupting secure boot

[Valerio Vanni]

On Wed, 27 Sep 2023 09:54:31 +0700 Max Nikulin  wrote:
I found the issue on latest versions of Clonezilla, but then I tried 


   ^^

with plain Debian live and the behavior is the same.


Does it mean that you can not boot your *old* Clonezilla live after booting a 
latest Clonezilla? If so, it is better to discuss the issue with shim or grub 
developers.


Yes. If I load a Clonezilla live newer than 3.1.0-11, then I cannot boot 
anymore 2.8.1-12.




1) Machine brand new: secure boot is active, Windows 10 shows it active, I can boot an old Clonezilla live (2.8.1-12) as many times as I want. 


An old image may be signed by a key later added to certificate revocation 
lists. If so, secure boot just works as it is supposed to do.


I didn't consider that... But it makes sense.


2) I boot from USB drive Debian Live 12

https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.1.0-amd64-kde.iso


If it can be reproduced with a contemporary Clonezilla or e.g. a Fedora image 
then it is not a Debian issue. If it is specific to namely Debian (I am unsure 
concerning Ubuntu, Debian derivatives) then it is better to file a bug 
providing more details.


As I said, the image that is not loaded anymore is older Clonezilla.
The image that alters secure boot is newer Clonezilla, and then I found 
that newer Debian does the same.
I still haven't found an old version of Debian that cannot boot after 
newer one (but I only tried 10 live, so far).



4) I reflash BIOS, same version, and go to point 1.


How old is your BIOS? Maybe you just restore obsolete list signing of keys.


Perhaps... I have no option during reflash.

BIOS has 9 month. One month ago a new version has been released: some 
day ago I installed it but it behaves just like the previous.



I suggest to compare

efibootmgr -v

output in the state when Clonezilla may be booted and when it fails. In 
addition public keys and certificate revocation list should be compared (unsure 
concerning commands).


I'll try as soon as I have another identical machine.


My opinion is that just loading boot images without installing OS should not 
modify firmware state. In this sense it may be a bug.


Not only I didn't install any OS, I didn't boot any image. It's enough 
to reach first page (grub entries) and the damage is done.



On the other hand, forgot old images if you have secure boot enabled.


Or forget the new ones ;-)

Re: Debian live boot corrupting secure boot

[The Wanderer]

On 2023-09-27 at 18:04, Valerio Vanni wrote:

> Il 27/09/2023 05:22, Jeffrey Walton ha scritto:
> 
>> On Tue, Sep 26, 2023 at 10:20 PM Valerio Vanni
>>  wrote:

>>> 3) At next boots, secure boot refuses to boot from Clonezilla
>>> live 2.8.1-12. The error is
>>> "verification failed 0x1A security violation"
>>> Windows 10 can still start, and shows secure boot active. Only if
>>> I disable secure boot from BIOS, I can start clonezilla.
>>>
>>> 4) I reflash BIOS, same version, and go to point 1.
>>>
>>> Tested many times.
>> 
>> The failure at (3) sounds like what happened when old grub images
>> were blacklisted in the UEFI Revocation List dbx. Also see
>> .
>> 
>> You should probably stop doing (4).
> 
> But this way I would have to disable secure boot to load old Clonezilla.
> Disable secure boot, launch clonezilla, restore image, reenable secure 
> boot, start OS.

Well, why do you need to load old Clonezilla? Surely the new version of
the Clonezilla live boot environment should work just as well as the old
one?

The only candidate reasons I can think of are "I have data files which I
still need to use with the Clonezilla live boot environment, and the old
version includes tools which are compatible with those files, but the
new one does not", and "I have a lot of already-created boot media with
the old version of the Clonezilla live boot environment, and I don't
want to discard or re-create all of that boot media".

The former would be a valid reason, but would also seem a bit odd;
backwards-incompatible breaks like that do not AFAIK tend to come along
very often, especially not in system-imaging solutions.

The latter would be understandable, but you'd have the choice between
doing that discard-all-the-old thing, or living with the downsides of
disabling Secure Boot.

-- 
   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: Debian live boot corrupting secure boot

[Max Nikulin]

On 28/09/2023 05:35, Valerio Vanni wrote:

On Wed, 27 Sep 2023 09:54:31 +0700 Max Nikulin wrote:
My opinion is that just loading boot images without installing OS 
should not modify firmware state. In this sense it may be a bug.


Not only I didn't install any OS, I didn't boot any image. It's enough 
to reach first page (grub entries) and the damage is done.


Thinking more, I have realized that updating secure boot keys in 
firmware may be the only way for grub to boot. You may try to search for 
docs and discussions to confirm such guess.


After a vulnerability found in shim or grub (that allows to boot 
malicious code having no proper signature) old keys used by Linux 
distributions are revoked, new ones are generated. New images signed by 
new keys are published.


Consider booting of a new image on a box having outdated set of keys 
(old BIOS). The machine is unaware of new keys, so unless keys are 
updated, it prohibits booting of new images as insecure ones. With up to 
day keys, certificate revocation list is loaded as well making booting 
of older (and thus vulnerable) images impossible. That is why just 
loading of an .EFI file may prevent further booting of old images.


Perhaps loading of updated key chain might be made transient affecting 
current boot only. I have no idea what are the obstacles: it is not 
allowed by secure boot policy, it is not supported by firmware, it is 
unreliable due to bugs in firmware, or it is just not implemented in 
shim or grub.



On the other hand, forgot old images if you have secure boot enabled.


Or forget the new ones ;-)


I have never tried it, but perhaps you may enroll your own keys and 
rebuild old images to put EFI files signed by you. See "master owner keys".


With outdated keys secure boot does not protect you. Is it Windows that 
prevents you from just turning secure boot off? I would not be surprised 
if during some update of Windows, certificate revocation list will be 
updated as well, so you would not be able to boot your old Clonezilla 
any more.


Why you avoiding up to date Clonezilla? Does it have backward 
compatibility issues making old backup useless?