edit: There is not two different devices --> There is two different images.
         Installer (that is like ubuntu installer) including the image 
(that is like ubuntu)
         The installer image does not set the watchdog timeout by default.
         But the IMAGE (that is not installer) is setting the watchdog 
timeout by default.
11 Mayıs 2023 Perşembe tarihinde saat 13:07:27 UTC+3 itibarıyla Erdem 
Kahraman şunları yazdı:

> Okay the story is that;
>
> In my case there is two different devices. You can think them like ubuntu 
> and ubuntu installer. (not similar with ubuntu, I want to only show the 
> hierarchy between the images)
>
> These two images are using efibootguard as bootloader.
>
> At the installer image, there is a program that is checking watchdog on 
> the device.
>
> I want to inform the user if there is any watchdogs are available to use.
>
> After then if there is no watchdog to use, user has already took a warning 
> like "WARNING: Cannnot probe watchdog".
>
> If the user want to continue without the watchdog feature, user will 
> proceed the installation without watchdog.
>
> And the image (that is not installer) will set the watchdog timeout and 
> also will set a variable at the runtime (I was thinking like that) 
> watchdog_may_fail = 1 then even if there is a setted unsupported watchdog, 
> it will not work.
>
> In this case also we need to get "watchdog probed or not" info from 
> userspace too. Because installer will inform the user about watchdog probe.
>
> At the installer side I need to learn if there is a watchdog probed or not 
> to inform the user.
>
> At the image (that is not installer) side I need to set watchdog_may_fail 
> = 1 because I'll put the image to the installer by default watchdog timeout 
> setted.
>
> 11 Mayıs 2023 Perşembe tarihinde saat 12:31:01 UTC+3 itibarıyla Jan Kiszka 
> şunları yazdı:
>
>> On 11.05.23 11:24, Erdem Kahraman wrote: 
>> >>Well, you effectively set it to 0 on all those devices that are not 
>> >>supported yet. If someone uses such device in production AND something 
>> >>goes wrong during an update, this would create a frozen device. In the 
>> >>worst case, someone would even have to travel to it and perform a 
>> >>power-cycle on-site. How will you address such a case in your user 
>> stories? 
>> > 
>> > Yes you are right the hardcoded way is so risky 
>> > 
>> > I want to make it clear, 
>> > We can set a variable that is watchdog_may_fail = 1 at the runtime. 
>> > Then efibootguard will turn the error_exit to WARNING when this 
>> variable 
>> > is set. 
>> > Wouldn't we be able to overcome this situation in this way? 
>> > 
>>
>> This does not address the point I made: How do you ensure that this 
>> degradation of safety is noticed by the user on devices not yet 
>> supported by EBG? That might be more of an integration topic, but I'd 
>> like to hear the complete story to asses if a certain feature extension 
>> in EBG makes sense. And to be able to document that story in the end in 
>> our README so that user do not misuse it accidentally. 
>>
>> Jan 
>>
>> > 
>> > Erdem Kahraman <[email protected] <mailto:[email protected]>>, 11 
>> > May 2023 Per, 12:21 tarihinde şunu yazdı: 
>> > 
>> > >Well, you effectively set it to 0 on all those devices that are not 
>> > >supported yet. If someone uses such device in production AND something 
>> > >goes wrong during an update, this would create a frozen device. In the 
>> > >worst case, someone would even have to travel to it and perform a 
>> > >power-cycle on-site. How will you address such a case in your user 
>> stories? 
>> > 
>> > Yes you are right the hardcoded way is so risky 
>> > 
>> > I want to make it clear, 
>> > We can set a variable that is watchdog_may_fail = 1 at the runtime. 
>> > Then efibootguard will turn the error_exit to WARNING when this 
>> > variable is set. 
>> > Wouldn't we be able to overcome this situation in this way? 
>> > 
>> > 
>> > Jan Kiszka <[email protected] <mailto:[email protected]>>, 
>> > 3 May 2023 Çar, 19:08 tarihinde şunu yazdı: 
>> > 
>> > On 03.05.23 17:55, Erdem Kahraman wrote: 
>> > > Great you are right but I am going to send the image to 
>> > different devices. 
>> > > I dont know is it supporting or not. 
>> > > I just want to if it is supporting; yes please enable the 
>> > watchdog, if 
>> > > it is not please go on. 
>> > 
>> > That case was not in scope for EBG so far. 
>> > 
>> > > 
>> > > In your case there is only one device to use, but it is a 
>> > generic image 
>> > > for several different devices. 
>> > > I can not be in interactive with device when the image sent to 
>> > customer. 
>> > > 
>> > > So I can not set the wdog timer as 0 
>> > 
>> > Well, you effectively set it to 0 on all those devices that are not 
>> > supported yet. If someone uses such device in production AND 
>> > something 
>> > goes wrong during an update, this would create a frozen device. 
>> > In the 
>> > worst case, someone would even have to travel to it and perform a 
>> > power-cycle on-site. How will you address such a case in your 
>> > user stories? 
>> > 
>> > Jan 
>> > 
>> > > 
>> > > Thanks 
>> > > 3 Mayıs 2023 Çarşamba tarihinde saat 18:50:02 UTC+3 itibarıyla Jan 
>> > > Kiszka şunları yazdı: 
>> > > 
>> > >     On 03.05.23 17:46, Erdem Kahraman wrote: 
>> > >     > I want to enable watchdog and I want success watchdog 
>> > experience for 
>> > >     > several devices, And I want; if there is unsupported 
>> > watchdog I 
>> > >     want to 
>> > >     > say to ebg "never mind please go on" 
>> > >     > 
>> > >     > But if there is any error like "Cannot probe watchdog 
>> > >     (Unsupported)", I 
>> > >     > dont want to exit the boot. 
>> > >     > 
>> > >     > Actually mentioning at code 
>> > >     > 
>> > <https://github.com/siemens/efibootguard/blob/master/main.c#L177 
>> > <https://github.com/siemens/efibootguard/blob/master/main.c#L177> 
>> > >    
>> >  <https://github.com/siemens/efibootguard/blob/master/main.c#L177 <
>> https://github.com/siemens/efibootguard/blob/master/main.c#L177>>>; I 
>> > >     > dont want to use as "error_exit" maybe it should be 
>> > "WARNING" ? 
>> > >     > 
>> > >     > I can pass this error by patching it but is there any 
>> > other way? 
>> > > 
>> > >     If you install EBG on a device that EBG does not support 
>> > or where the 
>> > >     firmware already enables the watchdog, just set the 
>> > timeout to 0, and 
>> > >     EBG will skip watchdog handling. 
>> > > 
>> > >     Jan 
>> > > 
>> > >     > 
>> > >     > 3 Mayıs 2023 Çarşamba tarihinde saat 18:32:13 UTC+3 
>> > itibarıyla Jan 
>> > >     > Kiszka şunları yazdı: 
>> > >     > 
>> > >     > On 03.05.23 17:08, Erdem Kahraman wrote: 
>> > >     > > Hello community, 
>> > >     > > 
>> > >     > > I want to use the efibootguard's watchdog by using a 
>> > generic 
>> > >     device. 
>> > >     > > 
>> > >     > > There is too different hardwares and I want to 
>> > activate the 
>> > >     > watchdog of 
>> > >     > > ebg if it is supporting.  
>> > >     > > 
>> > >     > > But when I test it, if the watchdog device not 
>> > existing or not 
>> > >     > > supporting by ebg, the boot sequence gives error and 
>> > exitting. 
>> > >     > > 
>> > >     > > Is there any way to pass error if there is no watchdog 
>> > or not 
>> > >     > supported 
>> > >     > > watchdog? 
>> > >     > 
>> > >     > I'm not yet sure what exactly your are looking for, some 
>> > >     recommendation 
>> > >     > on how to debug a not-yet-working own driver in EBG? Or 
>> > a better 
>> > >     > understanding how EBG is matching a driver with the 
>> > found hardware? 
>> > >     > 
>> > >     > Jan 
>> > >     > 
>> > >     > -- 
>> > >     > Siemens AG, Technology 
>> > >     > Competence Center Embedded Linux 
>> > >     > 
>> > >     > -- 
>> > >     > You received this message because you are subscribed to 
>> > the Google 
>> > >     > Groups "EFI Boot Guard" group. 
>> > >     > To unsubscribe from this group and stop receiving emails 
>> > from it, 
>> > >     send 
>> > >     > an email to [email protected] 
>> > <mailto:[email protected]> 
>> > >     > <mailto:[email protected] 
>> > <mailto:[email protected]>>. 
>> > >     > To view this discussion on the web visit 
>> > >     > 
>> > >    
>> >  
>> https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com
>>  
>> <
>> https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com>
>>  
>> <
>> https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com
>>  
>> <
>> https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com>>
>>  
>> <
>> https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com?utm_medium=email&utm_source=footer
>>  
>> <
>> https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>  
>> <
>> https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com?utm_medium=email&utm_source=footer
>>  
>> <
>> https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com?utm_medium=email&utm_source=footer>>>.
>>  
>>
>> > > 
>> > >     -- 
>> > >     Siemens AG, Technology 
>> > >     Competence Center Embedded Linux 
>> > > 
>> > > -- 
>> > > You received this message because you are subscribed to the Google 
>> > > Groups "EFI Boot Guard" group. 
>> > > To unsubscribe from this group and stop receiving emails from 
>> > it, send 
>> > > an email to [email protected] 
>> > <mailto:efibootguard-dev%[email protected]> 
>> > > <mailto:[email protected] 
>> > <mailto:efibootguard-dev%[email protected]>>. 
>> > > To view this discussion on the web visit 
>> > > 
>> > 
>> https://groups.google.com/d/msgid/efibootguard-dev/592af421-2e69-4e9c-b1ca-585b9aa2cb9fn%40googlegroups.com
>>  
>> <
>> https://groups.google.com/d/msgid/efibootguard-dev/592af421-2e69-4e9c-b1ca-585b9aa2cb9fn%40googlegroups.com>
>>  
>> <
>> https://groups.google.com/d/msgid/efibootguard-dev/592af421-2e69-4e9c-b1ca-585b9aa2cb9fn%40googlegroups.com?utm_medium=email&utm_source=footer
>>  
>> <
>> https://groups.google.com/d/msgid/efibootguard-dev/592af421-2e69-4e9c-b1ca-585b9aa2cb9fn%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>>  
>>
>> > 
>> > -- 
>> > Siemens AG, Technology 
>> > Competence Center Embedded Linux 
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> > Groups "EFI Boot Guard" group. 
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> > an email to [email protected] 
>> > <mailto:[email protected]>. 
>> > To view this discussion on the web visit 
>> > 
>> https://groups.google.com/d/msgid/efibootguard-dev/CALk5RRsjsH-nYvvASOz%3DiobVr%3DmhCLOjzrdNa4O0j%2BqjMxN5qw%40mail.gmail.com
>>  
>> <
>> https://groups.google.com/d/msgid/efibootguard-dev/CALk5RRsjsH-nYvvASOz%3DiobVr%3DmhCLOjzrdNa4O0j%2BqjMxN5qw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>>  
>>
>>
>> -- 
>> Siemens AG, Technology 
>> Competence Center Embedded Linux 
>>
>>

-- 
You received this message because you are subscribed to the Google Groups "EFI 
Boot Guard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/efibootguard-dev/a9f4e750-89f6-45df-979f-0630f785450bn%40googlegroups.com.

Reply via email to