Re: [systemd-devel] systemd efi boot and default entry
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 contact it's home server due to wide variety of possible network related issue or was booted into a different boot target or due to simple type unit (mis)ordering that would constitute as the operating system failing to boot? Yes. My server is stateless and immutable. So it has one configuration set up to do one task. When I deploy a new state (think: /usr partition, kernel, /etc) I need to boot into that new state. If the server fails to do its job after a reboot (as determined by some check I define), then it should definitely reboot into the previous state. > I dont follow that logic and with my administrator hat on would never want to have my servers rely or depend on such boot completion logic sorry. That is fine for you to not want that. But please do not dismiss my use-cases in such a round-about way. When a boot is successful depends a lot on the context of the system. Feel free to implement a sane default, but please allow for a wide range of customizations. Your laptop is a very different use-case than a small device in an inaccessible location: If networking does not work in your laptop, you are right there to fix it. In an sensor taking measurements at the bottom of the ocean, loss of networking due to a buggy kernel driver is much harder/expensive to fix. Best Regards, Tobias ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd efi boot and default entry
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's home server due to wide variety of possible > network related issue or was booted into a different boot target or due to > simple type unit (mis)ordering that would constitute as the operating system > failing to boot? > > I dont follow that logic and with my administrator hat on would never want > to have my servers rely or depend on such boot completion logic sorry. So i think that final stage of success mast be configured by end-user (or overrided). My question firstly for notebook/netbook. But for server this is useful too (and vm). As i see efi/uefi based boot faster than grub based and more simple. -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd efi boot and default entry
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 lot of negativity here:-) A server needs to provide some set of functionality. Only once that functionality is available the server has booted successfully. 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's home server due to wide variety of possible network related issue or was booted into a different boot target or due to simple type unit (mis)ordering that would constitute as the operating system failing to boot? I dont follow that logic and with my administrator hat on would never want to have my servers rely or depend on such boot completion logic sorry. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd efi boot and default entry
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 referring? The environment one [¹] 1. https://lists.freedesktop.org/archives/systemd-devel/2015-December/035364.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd efi boot and default entry
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 communicate properly >> with its own update server. > > This isn't quite right. The boot is marked successful as update-engine.service > starts. It does not wait for a network connection. In fact, update_engine > doesn't reach out to the update service until a few minutes have passed. Oh, sorry, I must have misunderstood something then:-) Thanks for correcting me! Best Regards, Tobias ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd efi boot and default entry
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: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd efi boot and default entry
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 provide some set of functionality. Only once that functionality is available the server has booted successfully. If it never gets to that state, then it should revert back to the previous known-good state where that functionality was still available. So all you should provide is a tool to report a successful (or failed) boot and act accordingly, so that such tests are easy to set up (and a way to trigger those tests, but systemd does cover that already:-). I don't think doing more than that makes sense. Best Regards, Tobias ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd efi boot and default entry
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. The boot is marked successful as update-engine.service starts. It does not wait for a network connection. In fact, update_engine doesn't reach out to the update service until a few minutes have passed. -Alex signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd efi boot and default entry
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 server. It would be nice if something similar could be implemented with systemd in a straight-forward way IMHO. 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. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd efi boot and default entry
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 could be implemented with systemd in a straight-forward way IMHO. Best Regards, Tobias On Fri, Apr 1, 2016 at 1:18 PM, Jóhann B. Guðmundsson wrote: > > > 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 completed and >>> "stable". >> >> >> Thanks, how about ChromeOS ? >> > > Dont know, dont care. Upstart ( which ChromeOS uses as it's init system ) is > history... > > JBG > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd efi boot and default entry
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 completed and "stable". Thanks, how about ChromeOS ? Dont know, dont care. Upstart ( which ChromeOS uses as it's init system ) is history... JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd efi boot and default entry
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 ChromeOS ? -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd efi boot and default entry
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 to have a watchdog support,boot counter which get's cleared when system decides it's up and stable,boot limit which tells it how many times it should try with an given entry, an entry which points to which kernel/image/snapshot to use right? I'm pretty sure Kay and Lennart must have thought things through so they just dont add just some half ass, none future proof, working solution that give administrators and embedded distribution fake notion of redundancy or a "fail-safe" when images and or kernel or the OS itself get's update/upgraded. If this cannot or will not be reliably implemented there is no point in implementing this in the first place from my pov. In my POV - provide systemd service file that started after all stuff (may be this is systemd --user service or something like this) . I think that successful start - run my preferred DE. It would not be type units that would determine when boot is considered completed since you cannot reliably rely on that. 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". JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd efi boot and default entry
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 which get's cleared when system decides it's up and > stable,boot limit which tells it how many times it should try with an given > entry, an entry which points to which kernel/image/snapshot to use right? > > I'm pretty sure Kay and Lennart must have thought things through so they > just dont add just some half ass, none future proof, working solution that > give administrators and embedded distribution fake notion of redundancy or a > "fail-safe" when images and or kernel or the OS itself get's > update/upgraded. > > If this cannot or will not be reliably implemented there is no point in > implementing this in the first place from my pov. In my POV - provide systemd service file that started after all stuff (may be this is systemd --user service or something like this) . I think that successful start - run my preferred DE. -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd efi boot and default entry
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 flag, because it is known to work. 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 which get's cleared when system decides it's up and stable,boot limit which tells it how many times it should try with an given entry, an entry which points to which kernel/image/snapshot to use right? I'm pretty sure Kay and Lennart must have thought things through so they just dont add just some half ass, none future proof, working solution that give administrators and embedded distribution fake notion of redundancy or a "fail-safe" when images and or kernel or the OS itself get's update/upgraded. If this cannot or will not be reliably implemented there is no point in implementing this in the first place from my pov. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd efi boot and default entry
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 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 don't believe this is currently possible. I've tried to implement >> similar scheme in the past. I should probably resurrect that effort, >> > > Had you finished writing the kernel driver that implements some kind of ( > sysfs? ) boot counting scheme? > ( There is no point in implementing something in systemd until that is in > place ) 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 flag, because it is known to work. I withdrew my PR because we discussed this with Kay and we were not sure we liked proposed scheme which uses file on disk as "tentative" marker. Michal ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd efi boot and default entry
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 it fails - change priority to lower level... I don't believe this is currently possible. I've tried to implement similar scheme in the past. I should probably resurrect that effort, Had you finished writing the kernel driver that implements some kind of ( sysfs? ) boot counting scheme? ( There is no point in implementing something in systemd until that is in place ) JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd efi boot and default entry
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 manually by > selecting it in the menu and pressing 'd' key. If you have time for this - i'll be very happy. -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd efi boot and default entry
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 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 manually by selecting it in the menu and pressing 'd' key. Michal ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel