LuaGRUB - a GRand Unified Bootloader for CC

Ever wanted to test multiple OSes at once? Changed your configs so you have an unreasonable amount of space on your computer? This is for you!

LuaGRUB is a bootloader based off GNU GRUB. It's purpose is to allow you to have multiple operating systems on one machine, and choose one at boot. If the OS supports it, you can even tell one OS to reboot directly into another (even into CraftOS). It features a simple color GUI that resembles as closely as possible the build of GNU GRUB I use every day. This is a very early version (I started a week ago), so many OSes will not be compatible, especially if they use absolute paths. There is a fix planned for 2.0, so stay tuned.

Update: I just added documentation!
It'll get better over time!

Screenshots:

Spoiler

To install:

> pastebin get Ri2ZSxVF launcher
> launcher

The launcher will rename itself to 'launcher' if that's not its name, so make sure you don't have anything else named launcher in the root folder.
The pastebin might be out-of-date; for the latest stable version, check here: https://github.com/skwerlman/LGRUB-stable

Found a bug? Have a suggestion? If you already have a GitHub account, please use the issue tracker at https://github.com/s.../LuaGRUB/issues
If you'd rather not make one, you can always post here, but I don't check the forums as frequently as GitHub, so I might take a while to respond.

Have a GitHub? Want to help? PM me!

APIs used:
Drawing.lua from OneOS by oeed used with permission.

Looks pretty good, but the Pastebin code isn't working. It says the paste has been removed.

I've copied it off GitHub though.

How do I 'install' an OS in to the bootloader?

You should fix the pastebin link or a moderator will lock the topic.
But as oeed says it looks pretty good.

I had an idea for something like this a while ago, but I like the way this one looks :)/>

Is there documentation on how to add it and stuff?

oeed, on 18 March 2014 - 09:17 AM said:

Looks pretty good, but the Pastebin code isn't working. It says the paste has been removed.

I've copied it off GitHub though.

How do I 'install' an OS in to the bootloader?

Oops, I'll fix that now.
You have to install the OS to the '/os' folder, inside of its own folder (i.e. '/os/OneOS/'). If you want the OS to have a display name instead of a path on the launcher, you should have a file named 'name.grub' containing the OS's name on the first line.
Oh, and I just want to note that I don't think I'll be compatible with OneOS or PearOS until 2.0. (Unless you want to change all of your paths to relative :D/> )

Apemanzilla, on 18 March 2014 - 01:16 PM said:

I had an idea for something like this a while ago, but I like the way this one looks :)/>

Is there documentation on how to add it and stuff?

Documentation is coming, I just have to write it…

Pastebin link fixed.
Documentation should be done by tomorrow. DONE!

skwerlman, on 19 March 2014 - 04:06 AM said:

You have to install the OS to the '/os' folder, inside of its own folder (i.e. '/os/OneOS/'). If you want the OS to have a display name instead of a path on the launcher, you should have a file named 'name.grub' containing the OS's name on the first line.
Oh, and I just want to note that I don't think I'll be compatible with OneOS or PearOS until 2.0. (Unless you want to change all of your paths to relative :D/> )

Ah ok.

The absolute path issue is something you should try to fix asap, it's a make or break feature.

Relative paths are annoying to keep in order. If you could just make it search through the folder structure for files named "info.grub" which would contain the name, program to run, etc, I think it would be a lot more useful.

oeed, on 19 March 2014 - 05:48 AM said:

skwerlman, on 19 March 2014 - 04:06 AM said:

You have to install the OS to the '/os' folder, inside of its own folder (i.e. '/os/OneOS/'). If you want the OS to have a display name instead of a path on the launcher, you should have a file named 'name.grub' containing the OS's name on the first line.
Oh, and I just want to note that I don't think I'll be compatible with OneOS or PearOS until 2.0. (Unless you want to change all of your paths to relative :D/> )

Ah ok.

The absolute path issue is something you should try to fix asap, it's a make or break feature.

That's my #1 priority right now.

Apemanzilla, on 19 March 2014 - 05:52 AM said:

Relative paths are annoying to keep in order. If you could just make it search through the folder structure for files named "info.grub" which would contain the name, program to run, etc, I think it would be a lot more useful.

What advantages would it have over changing how paths are resolved?

skwerlman, on 19 March 2014 - 05:57 AM said:

oeed, on 19 March 2014 - 05:48 AM said:

skwerlman, on 19 March 2014 - 04:06 AM said:

You have to install the OS to the '/os' folder, inside of its own folder (i.e. '/os/OneOS/'). If you want the OS to have a display name instead of a path on the launcher, you should have a file named 'name.grub' containing the OS's name on the first line.
Oh, and I just want to note that I don't think I'll be compatible with OneOS or PearOS until 2.0. (Unless you want to change all of your paths to relative :D/>/> )

Ah ok.

The absolute path issue is something you should try to fix asap, it's a make or break feature.

That's my #1 priority right now.

Apemanzilla, on 19 March 2014 - 05:52 AM said:

Relative paths are annoying to keep in order. If you could just make it search through the folder structure for files named "info.grub" which would contain the name, program to run, etc, I think it would be a lot more useful.

What advantages would it have over changing how paths are resolved?

I'm not recoding my entire OS to use relative paths, for multiple reasons.

Apemanzilla, on 19 March 2014 - 11:22 AM said:

skwerlman, on 19 March 2014 - 05:57 AM said:

oeed, on 19 March 2014 - 05:48 AM said:

skwerlman, on 19 March 2014 - 04:06 AM said:

You have to install the OS to the '/os' folder, inside of its own folder (i.e. '/os/OneOS/'). If you want the OS to have a display name instead of a path on the launcher, you should have a file named 'name.grub' containing the OS's name on the first line.
Oh, and I just want to note that I don't think I'll be compatible with OneOS or PearOS until 2.0. (Unless you want to change all of your paths to relative :D/>/> )

Ah ok.

The absolute path issue is something you should try to fix asap, it's a make or break feature.

That's my #1 priority right now.

Apemanzilla, on 19 March 2014 - 05:52 AM said:

Relative paths are annoying to keep in order. If you could just make it search through the folder structure for files named "info.grub" which would contain the name, program to run, etc, I think it would be a lot more useful.

What advantages would it have over changing how paths are resolved?

I'm not recoding my entire OS to use relative paths, for multiple reasons.

My plan is to actually alter how paths are interpreted by the computer (i.e. sandboxing), with the express purpose of not requiring authors to recode their OSes.
Also, most OSes have a file named startup, so if they were all at root, then there would be conflicts. This way, each OS gets its own space that it thinks is root, no matter how it's written.

skwerlman, on 19 March 2014 - 11:26 AM said:

My plan is to actually alter how paths are interpreted by the computer (i.e. sandboxing), with the express purpose of not requiring authors to recode their OSes.
Also, most OSes have a file named startup, so if they were all at root, then there would be conflicts. This way, each OS gets its own space that it thinks is root, no matter how it's written.

If the OS uses something like setfenv, os.run, or setmetatable they could unknowingly end up in the root folder again.

Apemanzilla, on 19 March 2014 - 11:36 AM said:

skwerlman, on 19 March 2014 - 11:26 AM said:

My plan is to actually alter how paths are interpreted by the computer (i.e. sandboxing), with the express purpose of not requiring authors to recode their OSes.
Also, most OSes have a file named startup, so if they were all at root, then there would be conflicts. This way, each OS gets its own space that it thinks is root, no matter how it's written.

If the OS uses something like setfenv, os.run, or setmetatable they could unknowingly end up in the root folder again.

How? I'm replacing fs and os in _G

skwerlman, on 19 March 2014 - 01:04 PM said:

Apemanzilla, on 19 March 2014 - 11:36 AM said:

skwerlman, on 19 March 2014 - 11:26 AM said:

My plan is to actually alter how paths are interpreted by the computer (i.e. sandboxing), with the express purpose of not requiring authors to recode their OSes.
Also, most OSes have a file named startup, so if they were all at root, then there would be conflicts. This way, each OS gets its own space that it thinks is root, no matter how it's written.

If the OS uses something like setfenv, os.run, or setmetatable they could unknowingly end up in the root folder again.

How? I'm replacing fs and os in _G

In that case, it should work but just make sure not to crash it or you lose access to those entirely.

Apemanzilla, on 19 March 2014 - 03:17 PM said:

skwerlman, on 19 March 2014 - 01:04 PM said:

Apemanzilla, on 19 March 2014 - 11:36 AM said:

skwerlman, on 19 March 2014 - 11:26 AM said:

My plan is to actually alter how paths are interpreted by the computer (i.e. sandboxing), with the express purpose of not requiring authors to recode their OSes.
Also, most OSes have a file named startup, so if they were all at root, then there would be conflicts. This way, each OS gets its own space that it thinks is root, no matter how it's written.

If the OS uses something like setfenv, os.run, or setmetatable they could unknowingly end up in the root folder again.

How? I'm replacing fs and os in _G

In that case, it should work but just make sure not to crash it or you lose access to those entirely.

I figured that one out, lol:

Spoiler

skwerlman, on 19 March 2014 - 07:23 PM said:

Apemanzilla, on 19 March 2014 - 03:17 PM said:

skwerlman, on 19 March 2014 - 01:04 PM said:

Apemanzilla, on 19 March 2014 - 11:36 AM said:

skwerlman, on 19 March 2014 - 11:26 AM said:

My plan is to actually alter how paths are interpreted by the computer (i.e. sandboxing), with the express purpose of not requiring authors to recode their OSes.
Also, most OSes have a file named startup, so if they were all at root, then there would be conflicts. This way, each OS gets its own space that it thinks is root, no matter how it's written.

If the OS uses something like setfenv, os.run, or setmetatable they could unknowingly end up in the root folder again.

How? I'm replacing fs and os in _G

In that case, it should work but just make sure not to crash it or you lose access to those entirely.

I figured that one out, lol:

Spoiler

Welcome to the world of sandboxing XD

Just want to say, not dead; work is just going slowly….