pibakery

pibakery copied to clipboard

In my workplace (IT department at a local school district) our setup scripts often involve rebooting a couple times. There should be a feature to have the Raspberry Pi reboot and continue the current running script. That way I could reboot in the middle of the first run script and then continue running scripts to setup a Pi if needed.

I'll have a think about this - it should be possible to do, and even make backwards compatible with older PiBakery versions. I have an idea of how I could do it, and I'll try it out when I have time. It won't be my first priority, though.

Thanks for your interest in PiBakery!

@dsdude123 I'm thinking of ways to implement this now, and I can get it to work, but I'm not sure how it should work if it's used with oneveryboot. Any thoughts?

butting in, not the OP. Does it need to work with oneveryboot? If meets the objective if it is only available for onfirstboot doesn't it?

My issue is that at the moment, if I pushed the block out, it would be available in older versions of PiBakery where I can't block it from being added to everyboot, which means it could be dragged out into the everyboot category.

At the moment I'm thinking it would just do nothing if in everyboot, and in newer versions of PiBakery it would not allow it to be added to everyboot scripts.

again, I not the OP, but that sounds acceptable to me.

I am not quite sure I exactly understand the way you thinking about this implementation. Is it just a "reboot" block that could be place in-between other blocks?

In that case, on connect you can traverse the block tree and figure out if it's been placed on the "every boot" block, and in that case just revert the connection so that if a user drags it there it "disconnects" immediately.

What @carlosperate said is what the block should be. Basically the block should allow a user to reboot during the first boot script and then continue running the first boot script. For example, A user could install a program and then reboot before installing other programs during the first boot stage. This block likely would have no benefit to the everyboot script and shouldn't be usable in that script.

In that case, on connect you can traverse the block tree and figure out if it's been placed on the "every boot" block, and in that case just revert the connection so that if a user drags it there it "disconnects" immediately.

This would be the ideal solution, and is actually what I do already with the "reboot" and "shutdown" blocks. This issue is that since I can't push out updates to the PiBakery application that will automatically update the app on user's computers (they have to manually download the updated application), this wouldn't work if users didn't update.

What I can do (and at the moment I'm thinking this would be the best solution) is for future versions of PiBakery to not allow this block to be added to Every Boot, and for older versions the actual block code would check if it's being run under Every Boot, and if it is, it would just exit that block without doing anything.

The only alternative (which actually might make more sense?) is that the block would be allowed to run under oneveryboot, and if it's found to be running oneveryboot, it would temporarily disable the oneveryboot code, reboot, and when the Pi comes back up again, would finish running the rest of the blocks, and then enable the oneveryboot code again, which would actually achieve the reboot and continue function. (that's one big sentence! Hopefully it makes sense to you)

Thoughts?

Yeah sorry, I just realised the blocks for pibakery are not actual blockly blocks (where you can have events), but JSON files that (I assume) somehow autogenerate the block definitions. I’m not quite sure if your implementation would allow any of this logic to be applied to the blocks repository. I assume as well that no additional JS code can be attached to the “blockly generator”?

About the “on-every-boot” disabling, it’s probably the only way this could be implemented, it could work, but it feels a bit fragile and it would leave you hanging if something doesn’t go quite right. Does anything essential for the OS or pibakery depend on running on this “on-every-boot”?

Does anything essential for the OS or pibakery depend on running on this “on-every-boot”?

No, it's just used for PiBakery.

I'll have a look at this block soon - I just need to find out where the bug with the macOS installer is first.

Is this still open ??

any progress on this?