Hi Johann,
Am 01.04.2016 17:38 schrieb "Jóhann B. Guðmundsson" :
> So if your server has the role of an web server and the web service fails
to run or is not run ( for example you forgot to enable it, or you
misconfigured it before rebooting ) or that phone home service failed since
it could not c
2016-04-01 18:42 GMT+03:00 Jóhann B. Guðmundsson :
> So if your server has the role of an web server and the web service fails to
> run or is not run ( for example you forgot to enable it, or you
> misconfigured it before rebooting ) or that phone home service failed since
> it could not contact it
On 04/01/2016 03:15 PM, Tobias Hunger wrote:
On Fri, Apr 1, 2016 at 4:59 PM, Jóhann B. Guðmundsson
wrote:
That makes no sense that an boot is not market completed until it manage to
contact it's update servers but inline with other hacks coreOS is doing in
relation with systemd.
I sense a lo
On 04/01/2016 03:15 PM, Alex Crawford wrote:
On 04/01, Jóhann B. Guðmundsson wrote:
That makes no sense that an boot is not market completed until it manage
to contact it's update servers but inline with other hacks coreOS is
doing in relation with systemd.
To what hacks, exactly, are you ref
Hi Alex,
On Fri, Apr 1, 2016 at 5:14 PM, Alex Crawford wrote:
> On 04/01, Tobias Hunger wrote:
>> IIRC both coreos and chormeOS only mark a boot as successful after
>> talking to their respective update servers. The assumption apparently
>> is that the OS can fix itself when it is able to communi
On 04/01, Jóhann B. Guðmundsson wrote:
> That makes no sense that an boot is not market completed until it manage
> to contact it's update servers but inline with other hacks coreOS is
> doing in relation with systemd.
To what hacks, exactly, are you referring?
-Alex
signature.asc
Description
On Fri, Apr 1, 2016 at 4:59 PM, Jóhann B. Guðmundsson
wrote:
> That makes no sense that an boot is not market completed until it manage to
> contact it's update servers but inline with other hacks coreOS is doing in
> relation with systemd.
I sense a lot of negativity here:-)
A server needs to p
On 04/01, Tobias Hunger wrote:
> IIRC both coreos and chormeOS only mark a boot as successful after
> talking to their respective update servers. The assumption apparently
> is that the OS can fix itself when it is able to communicate properly
> with its own update server.
This isn't quite right.
On 04/01/2016 12:44 PM, Tobias Hunger wrote:
Hi Jóhann and Vasiliy,
IIRC both coreos and chormeOS only mark a boot as successful after
talking to their respective update servers. The assumption apparently
is that the OS can fix itself when it is able to communicate properly
with its own update s
Hi Jóhann and Vasiliy,
IIRC both coreos and chormeOS only mark a boot as successful after
talking to their respective update servers. The assumption apparently
is that the OS can fix itself when it is able to communicate properly
with its own update server.
It would be nice if something similar c
On 04/01/2016 10:52 AM, Vasiliy Tolstov wrote:
2016-04-01 13:50 GMT+03:00 Jóhann B. Guðmundsson :
AFAIK the android boot process fires an standard broadcasting action
"ACTION_BOOT_COMPLETED" once system services are up and running in memory,
which is the time when it considered the boot being
2016-04-01 13:50 GMT+03:00 Jóhann B. Guðmundsson :
> AFAIK the android boot process fires an standard broadcasting action
> "ACTION_BOOT_COMPLETED" once system services are up and running in memory,
> which is the time when it considered the boot being completed and "stable".
Thanks, how about Ch
On 04/01/2016 10:11 AM, Vasiliy Tolstov wrote:
2016-04-01 13:08 GMT+03:00 Jóhann B. Guðmundsson :
I dont see how you plan on implement this if not with either a secondary
program loader which stores an redundant environment or an kernel support
that does the similar/same thing I mean you need
2016-04-01 13:08 GMT+03:00 Jóhann B. Guðmundsson :
> I dont see how you plan on implement this if not with either a secondary
> program loader which stores an redundant environment or an kernel support
> that does the similar/same thing I mean you need to have a watchdog
> support,boot counter whi
On 03/31/2016 02:31 PM, Michal Sekletar wrote:
We don't need to extend the kernel in order to implement this
particular mechanism. After new kernel is installed, you make it
default and mark as "tentative". Then, after first successful boot of
newly added bootloader entry you just remove the fl
On Thu, Mar 31, 2016 at 11:10 AM, Jóhann B. Guðmundsson
wrote:
>
>
> On 03/30/2016 03:49 PM, Michal Sekletar wrote:
>>
>> On Mon, Mar 21, 2016 at 1:42 PM, Vasiliy Tolstov
>> wrote:
>>
>>> Now i want to have two entries and assign priority to it via systemd,
>>> in my use-case i want to know last
On 03/30/2016 03:49 PM, Michal Sekletar wrote:
On Mon, Mar 21, 2016 at 1:42 PM, Vasiliy Tolstov wrote:
Now i want to have two entries and assign priority to it via systemd,
in my use-case i want to know last succeseful boot entry and use it.
After upgrade i want to boot from new antry and if
2016-03-30 18:49 GMT+03:00 Michal Sekletar :
>
> I don't believe this is currently possible. I've tried to implement
> similar scheme in the past. I should probably resurrect that effort,
>
> https://github.com/systemd/systemd/pull/1894
>
> In the meantime, you can change default boot entry manuall
On Mon, Mar 21, 2016 at 1:42 PM, Vasiliy Tolstov wrote:
> Now i want to have two entries and assign priority to it via systemd,
> in my use-case i want to know last succeseful boot entry and use it.
> After upgrade i want to boot from new antry and if it fails - change
> priority to lower level..
I'm happy with systemd and its efi loader support.
Now i want to have two entries and assign priority to it via systemd,
in my use-case i want to know last succeseful boot entry and use it.
After upgrade i want to boot from new antry and if it fails - change
priority to lower level...
Does it possi
20 matches
Mail list logo
