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
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
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
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
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
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
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.
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
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
>
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
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
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
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
>
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
14 matches
Mail list logo