Solus Integrates Clear Linux's clr-boot-manager

[phoronix]

Phoronix: Solus Integrates Clear Linux's clr-boot-manager

The desktop-focused, performance-oriented Solus Linux distribution has pulled in another component from Clear Linux: clr-boot-manager. The clr-boot-manager is responsible for solid kernel and boot-loader management...

http://www.phoronix.com/scan.php?page=news_item&px=Solus-Linux-clr-boot-manager

[pitlord]

Clearly they made a mistake, they shouldn't have chosen a tool that is not written in a proper statically checked compiled language like Rust. They would do better if they wrote a new one in Rust.

[ikey_solus]

Clearly they made a mistake, they shouldn't have chosen a tool that is not written in a proper statically checked compiled language like Rust. They would do better if they wrote a new one in Rust.

I sincerely hope this is the new crop of 4chan-esque memery and that you don't expect anyone to take you seriously with this.

[ikey_solus]

More clever solution than using intel non sense software wrapper is to make a non debug, no CPU Freq governor, 1000 Hz timer custom kernel where you include all your drivers.

...What? Seriously I think almost every answer I've seen from you on Solus posts related to something to do with a Debian 1khz kernel.. I'd love to get the story behind that some day.

Anywho, it's not a "non sense software wrapper". https://github.com/ikeydoherty/clr-boot-manager - research goes a long way.

[starshipeleven]

Interesting, I had a look at https://github.com/ikeydoherty/clr-boot-manager to get some kind of info about what this thing actually does for people not on Solus.

I like that it automates the most annoying parts of setting up EFI booting with a simple boot manager, but it's "multiboot provisions" are a bit unrealistic. If I have understood this correctly.

The way that a kernel is packaged changes significantly with clr-boot-manager. First and foremost, no files shall be shipped in /boot. The distribution should choose a namespace to identify their system in dual-boot situations, i.e:

org.someproject

All paths known to CBM must have follow a specific format and encoding, whereby the version, release number, and type are encoded:

/usr/lib/kernel
-> config-4.9.17-9.lts
-> org.someproject.lts.4.9.17-9
-> System.map-4.9.17-9.lts
-> cmdline-4.9.17-9.lts
-> initrd-org.someproject.lts.4.9.17-9 (Optional)
/usr/src/linux-headers-4.9.17-9.lts
/usr/lib/modules/4.9.17-9.lts

It's not bad, but y'know... all distros do it their own way and it does not usually look even remotely like this, so it's not going to see much use outside Solus and Clear Linux.

Would be cool to have a modular system that generates this stuff from each distro's default system (modular because each distro needs a different procedure to get to this state).

I sincerely hope this is the new crop of 4chan-esque memery and that you don't expect anyone to take you seriously with this.

Everything is better in Rust, you dummy. /sarcasm

[starshipeleven]

More clever solution than posting non sense in forums is to make a long, fun walk with your dog and not touch the computer at all.

Fixed.

[ikey_solus]

It's not bad, but y'know... all distros do it their own way and it does not usually look even remotely like this, so it's not going to see much use outside Solus and Clear Linux.

I wouldn't go as far as that Prior to this Solus used a very classic (and broken by design) kernel package, which effectively contained:

/boot/kernel-$VERSION
/vmlinuz -> boot/kernel-$VERSION

It would then dynamically generate the initrd image through a hook, and through yet more hooks, we'd update GRUB, or statically pathed ESP "bits". They had to remain static as we couldn't know the root= stuff, etc.

This method enforces namespacing on the kernel package, removes the majority of the postinstalls and centralises to a single step (clr-boot-manager update). The major thing to keep in mind here is that you no longer are "allowed" to ship /boot or /.* contents within a kernel package, making it stateless by design. That makes /usr/lib/kernel a staging tree, which is then used to seed clr-boot-manager to populate the ESP (or legacy boot partition). It also allows CBM to repair the ESP and restore the intended contents. By ensuring all components follow a given policy, CBM can do its job right every single time.

Everything is better in Rust, you dummy. /sarcasm

:P

[Vash63]

Does anyone have any experience with this distribution? A lot of the design behind it sounds really smart and desktop-oriented distros are pretty rare still. As a gamer, I can't really consider a distribution that still runs Nvidia 375 though...

[ikey_solus]

Does anyone have any experience with this distribution? A lot of the design behind it sounds really smart and desktop-oriented distros are pretty rare still. As a gamer, I can't really consider a distribution that still runs Nvidia 375 though...

"still" ? We have NVIDIA 375.39 which is the latest long lived stable branch. The short lived branches tend to have problems. It's hardly an old driver. Any reason you need newer?

[kneekoo]

Sweet! What about new ISOs with the latest changes?