Posts Tagged ‘boot’

Debian installation on Lenovo h50-50

septiembre 27, 2016


I am going to describe some notes on how to install Debian on Lenovo h50.

BIOS / UEFI modification

First of all you need to press F1 several times at boot time so that Lenovo BIOS Setup Utility appears.

Under Security tab I enter into Secure Boot menu and I change Secure Boot into Disabled. Windows seems to boot ok despite this change.

Under Startup tab I see that CSM is disabled. I keep it disabled because Debian supports UEFI out of the box. I disable Quick Boot to avoid Windows starting in its own and bypassing out Boot order.

While we are still in Startup tab we open Primary Boot Sequence  and make sure the USB HDD entry is in the first place.

Finally I press F10 to save the changes and exit.

Shrink Windows

I won’t explain it here but you usually need to shrink Windows (even using Gparted live disk) so that you can install Debian in a partition of its own.

Boot from Debian AMD64 Netinst installation disk

I used Debian 8.6.0 Debian AMD64 Netinst installation disk myself. I used dd to put the iso image into a usb stick (also known as pendrive).

You just insert the usb stick into the computer and press the ON/OFF switch. The installation disk should appear.


You can add an additional usb stick so that the integrated wifi dongle works out of the box. I have not tested it myself. I used the Etherned card. Other than that it’s a pretty straight-forward Debian installation.

Enable Debian as the first OS

Once again you need to press F1 several times at boot time so that Lenovo BIOS Setup Utility appears.

Under Startup tab we open Primary Boot Sequence and under SATA 1 it shows:

  • Windows Boot Manager
  • debian

I modify its order thanks to + or – keys so that it shows:

  • debian
  • Windows Boot Manager

Finally I press F10 to save the changes and exit.

Nvidia boot

The first boot test was done with screens connected to the Nvidia video card. Grub was shown but then somehow it froze. By removing the quiet boot parametre at boot (press ‘e’ key) I saw the error:

fb: switching to nouveaufb from simple

As I don’t need a full effect desktop I decided to remove nouveau driver altoghether:

First of all at grub I need to edit the Debian entry with ‘e’ and at the kernel line which shows:

linux /boot/vmzlinuz... root=UUID=e39...    ro quiet

where I remove quiet and I blacklist nouveau driver on the fly:

linux /boot/vmzlinuz... root=UUID=e39...    ro modprobe.blacklist=nouveau

I press F10 to be able to boot.

Nvidia boot final fix

Once I am able to boot into my system I edit the file:


so that the line:





We save the file and apply changes by running:



Next time we reboot everything is working fine. However the simple xserver configuration does not detect the additional attached screen. Maybe nouveau with additional switches (or an updated nouveau driver) would do it.

Using Intel Graphics card

As I don’t need nvidia I don’t mind using Intel graphics card. But this BIOS does not enable it by default if it detects the Nvidia cards.

So we have to modify the BIOS once again to use the Intel Graphics card.

Once again you need to press F1 several times at boot time so that Lenovo BIOS Setup Utility appears.

Under Devices tab we open Video setup and in Select Active Video we select IGD instead of Auto .

Finally I press F10 to save the changes and exit.


Of course you don’t have to forget to connect the screens into the Intel graphics plugs (instead of the Nvidia) ones.

Now both screens are autodetected.

Anuncio publicitario

Super Kexec Disk mockup

noviembre 29, 2014

Yet another mockup.

Kexec let’s you boot into another Linux kernel from a live or running Linux kernel. So that makes things interesting because you can use a live kernel from a live cd in order to boot into another one but, just before it, you have a full GNU/Linux with their tools.

I had already known about kexec but I wasn’t aware that it was so useful. I thought the main purpose would be to update your kernel without having to reboot your machine.

After writing my Kernel box disk idea article I discussed it in Super Grub irc channel. Bfree and Smx explained me about Kexec and what you could do with it.

I haven’t used kexec myself yet and I don’t fully understand how an initrd is built depending on kernel modules you need on boot to mount root’s partition. So, some ideas you see here might be not right.


So Super Kexec App scans all your installed distributions thanks to the great variety of modules included in the Super Kexec Disk live cd. You are prompted to choose to the distribution you want to boot into.

Super Kexec Disk mockup - Distros Detected

Super Kexec Disk mockup – Distros Detected

Once you have selected which distribution you want to boot you are given the opportunity to choose which modules should have your initrd (will be created on the fly for being your kernel companion). Super Kexec app suggests you initially which modules you will need so that the Kernel knows how to mount its root partition from it.

Super Kexec Disk mockup - Modules detected

Super Kexec Disk mockup – Modules detected

Once you have decided which modules will needed to be loaded you can fine-tune the kernel boot parametres. Super Kexec App will have selected the current Super Kexec Disk boot options for you. If you already forced Super Kexec Disk to boot into nomodeset it’s highly probable that you want your booted system to have that option too. From this screen you will also be able to blacklist kernel modules (just in case some of them hang your system on boot) or force an specific systemd target (runlevel).

Super Kexec Disk mockup - Boot parametres

Super Kexec Disk mockup – Boot parametres

Finally a summary about what you are going to do is prompted and you can:

  • Boot into your Linux Kernel + Generated Initrd
  • Review the settings if you made a mistake
  • Exit from the Super Kexec App
Super Kexec Disk mockup - Summary

Super Kexec Disk mockup – Summary

Finally there should be another option named: Force this boot into the distribution so that:

  • Initrd is copied into /boot directory
  • /etc/grub.d/08_super_kexec is created
  • 08_super_kexec defines an entry to boot your kernel and the generated initrd with the choosen boot parametres

and somehow it should guess that Grub2 might need to be reinstalled into the MBR with enforced LVM+RAID capabilites if needed.

So that’s it, once you have a system that can modify another and at the same you can boot a system from it it sounds a bit like Rescatux and a bit like Super Grub2 Disk. Not everyday we see a system like this.

Am I going to implement Super Kexec App as a Rescatux application (instead of doing an only Super Kexec Disk as this mockup describes)?

Don’t think so. Making a Rescatux option to rebuild an initrd with several modules from your chroot and then add some Grub2 entries to boot into it. Yes, that make sense when you somehow manage to remove LVM support from your initrd while your root partition is in LVM. (Or you copy-and-paste a Distribution from Ext4 to LVM).

Not in the short term I will implement it.

If you think about any useful use case or task that might make worth implementing these option please drop a comment so that I am aware of it.

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.


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

Auto Super Grub Disk 1.7 disponible

junio 2, 2009

La novedad de la versión tiene soporte para Ubuntu 9.04 y ext4.

Para quien no sólo sepa Auto Super Grub Disk que funciona en Windows. Está muy recortada para que sólo haga un par de cosas:  Arreglar el arranque de Linux (lo que es lo mismo restaurar el grub en el mbr) e intentar arrancar linux.


Super Grub Disk 0.9795

mayo 15, 2009

La versión 0.9795 de Super Grub Disk está disponible.

Esta versión técnicamente añade soporte para ext4.

En la práctica esto significa que podemos arrancar o arreglar Ubuntu 9.04 sin ningún tipo de problema. En realidad sólo he probado lo de arrancar pero me imagino que no habrá ningún problema.

El parche para añadir soporte de ext4 lo cogí del último paquete de código fuente del grub de Ubuntu.

Con Tuxed modificamos el parcheado porque no se adaptaba del todo bien al código de Super Grub Disk.

Una de las razones es que entre otras cosas el SGD se basa en parte de codigo de OpenSuSE para poder detectar varios kernels diferentes de forma más fácil.