Posts Tagged ‘super grub2 disk’

Kernel boot parametres option for Super Grub2 Disk mockup

noviembre 28, 2014

Yet another mockup :).

So once you have selected which Kernel you want to from you can choose between different set of Kernel boot parametres:

  • Knoppix cheatcodes. Just in case you want to boot your installed Knoppix with those options.

    super grub2 disk boot parametres mockup knoppix

    super grub2 disk boot parametres mockup based on knoppix boot cheatcodes

  • Blacklist modules. This is very useful when trying to debug which module is making your system to crash or reboot at boot time.

    SG2D mockup - Blacklist modules

    SG2D mockup – Blacklist modules

  • Systemd target. Choose an specific systemd ‘runlevel’.

    SG2D mockup Systemd targets

    SG2D mockup Systemd targets

  • Miscelanea. Any other Kernel boot parametre.

    SG2D Kernel boot parametres mockup miscelanea

    SG2D Kernel boot parametres mockup miscelanea

  • Choose root partition. Just in case you want to try to boot your Debian GNU/Linux but trying to use Ubuntu kernel. Usually it might not work 100%, but it’s worth a try in some special circumstances.

    SG2D Boot parametre Mockup - Choose root partition

    SG2D Boot parametre Mockup – Choose root partition

I’m not interested in implementing it because I think not so many few people would use when trying to boot into their distro from Super Grub2 Disk. Maybe the blacklist option is the most useful one.

But it’s something I would maintain if I ever implemented it. Not like the Kernel box idea.

Do you use often use an specific boot parametre? Why?

Kernel box disk idea

noviembre 27, 2014

This is a thing I’m not going to implement because although it’s very easy from technical point of view having to take care of all the kernel versions and their (so big) source code would easily become a burden.

So, this is an idea or mockup.

What is Kernel box?

An special Super Grub2 Disk which includes several Linux kernels and initrds.

Super Grub2 Disk - Kernel box - Mockup

Super Grub2 Disk – Kernel box – Mockup

What can you do with Kernel box?

  • Try a new kernel without installing it.
  • Being able to boot your distribution because you did not install a kernel when installing it.
  • Being able to boot your distribution after realising that you have deleted your /boot partition where not only the grub files were but also the kernel files.

How would it work?

I guess I would detect a Linux root partition by finding /sbin/init (or whatever it’s named in systemd) and probably by checking /etc/issue for a possible name for the distro.

Once the user chooses the distro which he wants to start (not choosing boot verb here on purpose :)) he is prompted about the kernel + initrd that wants to try.

Available initrd

There should be the original kernel and initrd from the most popular GNU/Linux distributions out there available. There should be special initrds for these special cases (RAID5 + LVM and the like).

Advanced mode

I’m not sure if it makes sense technically but you could use a kernel from SuSE 11 with Ubuntu 13.10’s initrd.

Boot parametres improvement

You can add most usual boot parametres from a list. Either you can exclude a module to load, you can turn of acpi or another special boot parametre for your video card. I will write probably write about this idea in another post because it was originally intented for normal Super Grub2 Disk.

About implementing it

I don’t mind spending an afternoon and coding the Super Grub2 Disk part if someone devotes himself on building up the rest of the system:

  • Code an script to obtain new kernels and initrds semiautomatically and update Super Grub2 Disk scripts accordingly.
  • Keep an updated version monthly
  • And most importantly keeping the Kernel and Initrd source code organised so that anyone can download it so that we complain to GPL.
  • Not sure if it’s needed. Automate the building of the different kernels from their source code to even ensure we comply GPL.

Feedback

  • Any thoughts on the idea?
  • Any other tricks around what Super Grub2 Disk does that could improve it like this one?

ReactOS Hook up version idea, Super Grub2 Disk and Rescatux

diciembre 31, 2013

Introduction

I happen to have seen a Reactos talk video recently. In the following video:

which was recorded at Google Montreal on October 2013, Alex Ionescu explains what ReactOS is and what they have achieved with it.

One of the interesting ideas is that they are developing the entire OS. Not only the kernel but the entire operating system. They say the are probably the ones to do that in the open source world. Somebody at Youtube complained about BSDs systems doing the same. I’m not sure if he is right. What Alex explains is that in Gnu/Linux systems the programs are adapted or taken from upstream releases but that they do all their programs and libraries from scratch instead. Probably the only thing that they borrow from upstream is wine.

That means that once you have the entire OS you will be able to use a whole set of well defined libraries. That is one of the reasons why Windows has suceeded. Giving binary compatibility for many years. Compare that to the fragmentation in Gnu/Linux ecosystem.

Don’t get me wrong, I love Gnu/Linux fragmentation because of the innovation that it draws. But if our objetive was to draw people to Gnu/Linux systems and not only its freedom you will need to do it the Microsoft way: Make it easier for developers.

Ubuntu is trying to do so with QT QML if I’m not mistaken. You write once an application and it will work in the desktop, your tablet and your smartphone.
I’m not sure what’s the Red Hat strategy towards developers but its many years of support operating system releases help a lot.

SuSE has taken a workaround by making a system that lets you build your application for several type of distributions and so on.

Well, I’m going to stop because this seem to be an article inside another article. 🙂

So many have ideas have arisen after seeing that video related to my own projects.

Freeldr

Freeldr is the open source loader for ReactOS. It is meant to replace ntldr. Although it’s main wiki page does not say much about its features you can go to its discussion page where its changelog is shown and this thread about having the idea of having Grub by default in ReactOS to learn that:

FreeLDR can just boot Windows NT, ReactOS, Linux and multiboot.

And that is compared to GRUB:

GRUB can boot almost everything from NTLDR to Linux, to XNU, to BSD, to self-withstanding utilities.

Freeldr and Super Grub2 Disk

I’m not sure but I think that Super Grub Disk once had ReactOS support. You could boot a ReactOS system with it. Regarding ReactOS support in Super Grub2 Disk just cloning the option that tries to load ntldr but multibooting freeldr.sys (as indicated in its wiki) should do it. That would make Super Grub2 Disk capable of booting ReactOS.

The other option is to incorporate freeldr.sys in Super Grub2 Disk so that it can boot the Freeldr boot menu to boot Windows installation with a broken ntldr file. I think that Grub2 can also bypass ntldr but I’m not sure that we have already implemented that in Super Grub2 Disk, I don’t see it in the sources, but I remember we had a similar option. I will have to check with Jordan.

Freeldr and Rescatux

Once you have seen what you can do with Super Grub2 Disk then Rescatux is just a matter of fixing things.

  • Add an option to Rescatux to reinstall a generic MBR code to chainload partition where freeldr is. And fix freeldr load in the partition itself. That means adding an option to recover ReactOS boot. I guess I will have to decrypt what these lines from the wiki mean. Probably saving some information with dd and then putting it back with dd.

You can install the official FreeLoader’s boot sector in that partition’s first sector. However, take care, because this can break the file system’s “superblock”, that usually resides in it’s first sector. In particular, you can’t simply copy the FAT boot sector to the first sector of a FAT partition, because this would overwrite the Bios Parameter Block (which is the name of the FAT superblock). There are some programs that can do this for you, so Google for them.

  • Add an option to replace freeldr with a good one (found in Rescatux itself). That is reinstall ReactOS boot.
  • Add an option to add freeldr next to ntldr and reinstall freeldr so that Window systems boots again but by means of freeldr only.

Rescue Unit tests

Alex explains that he automates some tests to check if ReactOS functionality is changed by any change or another. It’s interesting because they not only use two different compilers: GCC and Mingw but they also use different machines: Virtualbox machine, KVM machine and actual machines. That is RosBuild, the ReactOS BuildBot.

The funny thing is that they have contributed to find bugs in all of these projects. Might be GCC or Mingw that do not produce the expected binary results. Might be the different virtual systems that do not virtualise the real hardware as fair as they could.

The first idea is to do Rescue unit tests. Probably I will only use KVM or Virtualbox as the main system but I will define some unit tests for Rescue. The idea is to have broken systems (Windows not booting, Windows with a password set, etc). Then, somehow Rescatux is being run unattented just like if the user had selected some options in the wizard.

The great thing would be to do it like Microsoft seems to check its help messages (graphically) but I suppose I will have to add some switches to the wizard scripts so that they read input not from zenity or python scripts but from a file.

So, if Windows is not booting, Rescatux fixes it, and then if Windows is still not booting that means that a recent commit has broken the Fix Windows option code.

I suppose that my tools will have to be improved because of my complex use cases. What I mean is that while ReactOS probably has a set of unit tests that tries in a freshly installed system (if you see the video you will learn that they also test automatically the installer) in the Rescatux case I will have several input virtual machines (One or two hard disks with more or less broken Operating systems) and several unit tests. But not every virtual machine match a given unit test. E.g. I cannot try to clear Windows password in a Gnu/Linux only system.

The second idea is to borrow the tools that they use for perfoming these tests in that hardware being real or virtual. I can do it because their tools are open source tools. I will also check if other big Gnu/Linux systems or Live systems have similar Quality Assurance systems. I probably check GRML site.

Everything will imply having to borrow or hire a powerful virtual server. bTactic will probably help me on that.

Nowin project and ReactOS Hook-up version

ReactOS has recalled me my (vaporware) NoWin project. The idea behind Nowin could be applied in ReactOS: Share your documents. Try to work in ReactOS as normal, however if something does not work as expected just reboot into Windows. The thing is that in Windows you have both the same configuration for your programs and, of course, your same data (My documents, etc.).

I remember having headaches in Nowin (although the idea was to use wine libraries) about thinking on how to translate Windows letter drives to unix directories. That would make easier that recent opened files would work in either Firefox, Thunderbird or similar apps when booted into Gnu/Linux (these were the applications that at the time had a version both Operating System: Gnu/Linux and Windows).

Now that I think of it I could try to do the same nowadays with another operating system (virtualised) that shows the shared data and configuration via a network. And that could be improved. No need to reboot into one or another OS, just use it as a virtualised one, and get a visual connection to the program. Well, that seems pretty similar to Ulteo and somehow to QubesOS so nothing invented here. Well, the sharing data and configurations part. I will have to study this sudden idea to see if it’s worth implementing it.

Back to the main article translate Windows letter drives to unix directories would not be needed in ReactOS.

So if you have a working Windows installation and you install the Hook-up version of ReactOS you get what I describe above:

You still can boot into Windows and use all of its functionality but at the same time you can boot into ReactOS and help debugging it but using the same configurations, data and files that you have in your original Windows. There’s the little thing about being afraid of loosing data because ReactOS NTFS driver not being as good as the original one, that’s something I have to ask for. Humm… I need to learn how Registry is handled in a per user basis in Windows. If the registry user file is system-specific and not home-specific (talking here from a UNIX point of view (/) versus (/home)) then things complicate too much.

This hook-up idea seems very similar to their recent idea (explained in the video above) to either replace an original windows library in a windows system with a ReactOS one and check if the system behaves in the same way. Or the other way round, put a windows library in ReactOS and check if there is anything difference in behaviour compared to when ReactOS system had its own library.

Making sure that both the Windows system and the ReactOS system share the same configuration, data and files should improve testing quality.

Well, I think I’m going to subscribe to some ReactOS mailing lists to see if some of the ideas described here make sense.