Boot & Disk

Reinstalling GRUB after Windows install

Reinstall GRUB after Windows install

Here is how to reinstall GRUB after you have had to install windows, and windows has overwritten your master boot record (MBR) so that you can't get back into Linux.

sux - <-this is optional, just use 'su'
grub
find /boot/grub/stage1 // Will print something like (hd0,1)
or
find /boot/grub/menu.lst
root (hd0,1)
setup (hd0) <- ignore prompt for partition
quit

Enable harddisk spin-down / sleep mode / standby

Aan elke harddisk in een Linux systeem kun je een aparte time-out geven wanneer deze een spin-down moet gaan doen (standby / sleepmode).

Zodra een harddisk in standmode staat gebruikt deze fors minder stroom. Hiervoor kun je het volgende commando gebruiken

   hdparm -S 60 /dev/sdd

Met bovenstaande commando wordt er een time-out toegekend van 5 minuten aan de systeem disk.

Zodra de systeem disk langer dan 5 minuten niet gebruikt wordt dan zal deze een spin-down gaan doen.

1 Minuut is 12 'eenheden' van 5 seconden.

bron: http://www.olino.org/articles/2007/02/25/het-bouwen-van-een-zuinige-server-deel-3

Linux Software RAID: growing filesystems and adding disks

Adding partitions

When new disks are added, existing raid partitions can be grown to use the new disks. After the new disk was partitioned, the RAID level 1/4/5/6 array can be grown for example using this command (assuming that before growing it contains three drives):

mdadm --add /dev/md1 /dev/sdb3
mdadm --grow --raid-devices=4 /dev/md1

The process can take even 10 hours. There is a critical section at start, which cannot be backed up. To allow recovery after unexpected power failure, an additional option --backup-file= can be specified.

Expanding existing partitions

It is possible to migrate the whole array to larger drives (e.g. 250 GB to 1 TB) by replacing one by one. In the end the number of devices will be the same, the data will remain intact, and you will have more space available to you.

Extending an existing RAID array

In order to increase the usable size of the array, you must increase the size of all disks in that array. Depending on the size of your disks, this may take days to complete. It is also important to note that while the array undergoes the resync process, it is vulnerable to irrecoverable failure if another drive were to fail. It would (of course) be a wise idea to completely back up your data before continuing.

First, choose a drive and completely remove it from the array

mdadm -f /dev/md0 /dev/sdd1
mdadm -r /dev/md0 /dev/sdd1

Next, partition the new drive so that you are using the amount of space you will eventually use on all new disks. For example, if you are going from 100 GB drives to 250 GB drives, you will want to partition the new 250 GB drive to use 250 GB, not 100 GB. Also, remember to set the partition type to 0xDA - Non-fs data (or 0xFD, Linux raid autodetect if you are still using the deprecated autodetect).

fdisk /dev/sde

Now add the new disk to the array:

mdadm --add /dev/md0 /dev/sde1

Allow the resync to fully complete before continuing. You will now have to repeat the above steps for *each* disk in your array. Once all of the drives in your array have been replaced with larger drives, we can grow the space on the array by issuing:

mdadm --grow /dev/md0 --size=max

The array now represents one disk using all of the new available space.

Extending the filesystem

Now that you have expanded the underlying partition, you must now resize your filesystem to take advantage of it. For an ext2/ext3 filesystem:

resize2fs /dev/md0

For a reiserfs filesystem:

resize_reiserfs /dev/md0

Please see filesystem documentation for other filesystems.

LVM: Growing the PV

LVM (logical volume manager) abstracts a logical volume (that a filesystem sits on) from the physical disk. If you are used to LVM then you are likely used to growing LVs (logical volumes), but what we grow here is the PV (physical volume) that sits on the md device (RAID array).

For further LVM documentation, please see the Linux LVM HOWTO

Growing the physical volume is trivial:

pvresize /dev/md0

A before-and-after example is:

root@barcelona:~# pvdisplay
  --- Physical volume ---
  PV Name               /dev/md0
  VG Name               server1_vg
  PV Size               931.01 GB / not usable 558.43 GB
  Allocatable           yes
  PE Size (KByte)       4096
  Total PE              95379
  Free PE               42849
  Allocated PE          52530
  PV UUID               BV0mGK-FRtQ-KTLv-aW3I-TllW-Pkiz-3yVPd1

root@barcelona:~# pvresize /dev/md0
  Physical volume "/dev/md0" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized

root@barcelona:~# pvdisplay
  --- Physical volume ---
  PV Name               /dev/md0
  VG Name               server1_vg
  PV Size               931.01 GB / not usable 1.19 MB
  Allocatable           yes
  PE Size (KByte)       4096
  Total PE              238337
  Free PE               185807
  Allocated PE          52530
  PV UUID               BV0mGK-FRtQ-KTLv-aW3I-TllW-Pkiz-3yVPd1

The above is the PV part after md0 was grown from ~400GB to ~930GB (a 400GB disk to a 1TB disk). Note the PV Size descriptions before and after.

Once the PV has been grown (and hence the size of the VG, volume group, will have increased), you can increase the size of an LV (logical volume), and then finally the filesystem, eg:

lvextend -L +50G -n home_lv server1_vg
resize2fs /dev/server1_vg/home_lv

The above grows the home_lv logical volume in the server1_vg volume group by 50GB. It then grows the ext2/ext3 filesystem on that LV to the full size of the LV, as per Extending the filesystem above.

Partitions

Per 1 augustus 2010

/dev/sda (SDD-80GB)

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048     4208639     2103296   82  Linux swap / Solaris             swap
/dev/sda2   *     4208640    46153727    20972544   83  Linux                            /
/dev/sda3        46153728   156301311    55073792   83  Linux                            /home

/dev/sdb (HDD-250GB)

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1              63    62637434    31318686    7  HPFS/NTFS/exFAT
/dev/sdb2       467419136   469506047     1043456    c  W95 FAT32 (LBA)
/dev/sdb3       469507849   488386312     9439232    7  HPFS/NTFS/exFAT
/dev/sdb4   *    62637435   467411174   202386870    5  Extended
/dev/sdb5        62637498    66734009     2048256   82  Linux swap / Solaris             swap
/dev/sdb6        66734073   333059579   133162753+  83  Linux                            /data
/dev/sdb7       333059643   406444499    36692428+  83  Linux                            / oude 11.3 mag weg
/dev/sdb8       406444563   467411174    30483306   83  Linux                            / openSUSE 12.1 

1 ntfs
 4 extended
 5 swap
 6 ext4       /data
 7 ext4       /      opensuse 11.3 productie
 8 ext4       /      opensuse 11.4 testing (factory)
2 fat32       HP_TOOLS
3 ntfs        HP_RECOVERY

Using GRUB to boot multiple operating systems, the correct way

Often when you want to use more than one Operating System on your computer, you run into GRUB issues.

When you install an OS, or upgrade an installed OS, problems can occur when the new install overwrites your GRUB setup, leaving you with unbootable OS's. It is possible to correct these issues, but that is an annoying exercise that you will have to repeat every time you update stuff.

chainloader

In order to solve this issue for once and for all, the solution is to make 1 partition the 'master GRUB' partition. This GRUB will contain only so called 'chainloader' commands, pointing to all the 'child' partitions containing the OS's. Those partitions will contain the GRUB's from those OS's. So we create a 2 stage boot process:

In this scenario let all the OS's manage their own partitions, and THIS IS IMPORTANT: don't let them update our 'master GRUB' partition. They can update their own GRUB during updates etc.

MBR info

Note that the 'grub-install' method has the added protection of not inadvertantly overwriting your partition table if it had been modified since your last MBR backup.

This is because the 512byte MBR sector is actually two parts:

  1. The first 446 bytes is the grub stage1 bootloader (or the windows bootloader after you’ve reinstalled windows and it “helpfully” overwrites grub).
  2. The last 64 bytes is where your partition table is stored.

So, if you only want to backup the bootloader in the MBR, remember to change the bs=512 to bs=446.

What You Absolutely Need to Know

In order to use grub to boot a computer, you need to know the following:

  1. The partition containing the kernel
  2. Within that partition, the directory path and filename of the kernel
  3. The partition containing /sbin/init

In addition, you might need the partition, path and filename of the initrd file, but usually this is not necessary with grub.

NOTE

I have seen cases in which a kernel would kernel panic without an initrd statement, and would boot with it. The interesting thing is, once I got it booting, I could remove the initrd statement, rerun grub's setup, and it would now boot without the initrd statement. If you get kernel panics and it isn't obvious why, don't hesitate to insert an initrd statement.

Now let's take a look at an example. Imagine a system in which /dev/hda1 is mounted as /boot, and /dev/hda9 is mounted as /. Within /boot the kernel filename is vmlinuz-i686-up-4GB. Now let's answer the four questions:

  1. The partition containing the kernel = /dev/hda1, or (hd0,0) in grub-speak
  2. Within that partition, the directory path and filename of the kernel = /vmlinuz-i686-up-4GB(Remember, /dev/hda1 is mounted directly to /boot, so it contains the kernel directly)
  3. The partition containing /sbin/init is /dev/hda9

In that case, here are the grub commands you would input to boot that system:

grub> root (hd0,0)
grub> kernel /vmlinuz-i686-up-4GB root=/dev/hda9
grub> boot

The preceding is usually sufficient to boot a Linux box. The standalone root statement tells the partition containing the kernel. The kernel statement describes the path and filename, within the partition containing the kernel of the kernel. The argument to the root= argument to the kernel statement tells the partition containing /sbin/init, which of course turns out to be the root partition in the booted system.

Be careful of these duelling root keywords. The standalone one is the root as seen from grub, and contains the kernel. The argument to the kernel statement is the root as seen from the fully booted system, and contains /sbin/init.

Be careful also of where you use grub partition notation and where you use Linux partition notation. You use grub partition notation ((hd0,0)) everywhere except the root= argument to the kernel statement. In the root= argument you use the Linux partition notation. Note that in Linux notation, the drive starts with a for the first IDE port master, then b for the first IDE port slave, then c for the second IDE port master, and  d for the second IDE port slave, on and on throughout your IDE ports. In Linux notation, the partition number within the drive starts with 1.

In grub partition notation, the first accessible hard drive is (hd0), the next accessible hard drive (even if it's on the 3rd, 4th or higher IDE port) is (hd1), and so forth. In grub partition notation, the partition number is zero based. Thus:

/dev/hda1 is the same partition as (hd0,0)

Occasionally you'll need to specify an initrd, although this is rare. If so, after the kernel statement and of course before the boot statement, insert the following:

initrd /initrd-i686-up-4GB.img

It's absolutely essential that if you do use an initrd statement, that the initrd file you reference must match the kernel you referenced earlier.

NOTE

I have seen cases in which a kernel would kernel panic without an initrd statement, and would boot with it. The interesting thing is, once I got it booting, I could remove the initrd statement, rerun grub's setup, and it would now boot without the initrd statement. If you get kernel panics and it isn't obvious why, don't hesitate to insert an initrd statement.

Another documented way to boot from grub is to put the grub-root in the kernel statement itself instead of as a separate entity:

grub> kernel (hd0,0)/vmlinuz-i686-up-4GB root=/dev/hda9
grub> boot

If you do that, you'll need to also specify the grub root ((hd0,0)) on any initrd statement.

Booting Up Foreign Distros

Let's say you're a United States English speaker using grub to bust back into a Knoppix machine that lost its boot loader. The commands discussed previously would put you in Knoppix just fine, but the error messages and even the console keyboard would be German (Deutsch). If you wanted to boot up in American English, you'd add the argument lang=us to the kernel statement, like this:

grub> kernel (hd0,0)/vmlinuz-i686-up-4GB root=/dev/hda9 lang=us
grub> boot

or

grub> root (hd0,0)
grub> kernel /vmlinuz-i686-up-4GB root=/dev/hda9 lang=us
grub> boot

The Single Partition Configuration

The preceding example detailed a system with a dedicated /boot partition. Especially in these days of modern bioses that can boot past cylinder 1024, many people don't use a separate partition for /boot. Imagine if the root partition were /dev/hda1, and /boot was just another directory on that partition. In that case, here are the commands you'd use:

grub> root (hd0,0)
grub> kernel /boot/vmlinuz-i686-up-4GB root=/dev/hda1
grub> boot

The only difference is here the grub root is the same as the booted system root.

Having Grub Do Your Research For You

Often you know the partition containing the kernel, the kernel directory and name, and which partition mounts to root after boot. In that case booting Linux from grub is trivial.

Other times you're not so lucky. Like when you accidentally messed up LILO, or when you or someone else installed Windows, inadvertently overwriting the boot loader on the MBR. That's when you need grub the most, but that's also when you're least likely to know the partition containing the kernel, the partition that will ultimately be root, and the name of the kernel. Luckily,  grub can help.

Your first step is to find the partition containing the kernel and the partition containing /sbin/init. Now type the following at the grub> prompt:

find /sbin/init

On a machine with three different Linux OS's installed, the answer would come back something like this:

grub> find /sbin/init

 (hd0,8)
 (hd0,11)
 (hd1,11)
grub>

In the preceding example, you've found three different partitions containing /sbin/init:

Grub partition specification

Linux partition specification

(hd0,8)

/dev/hda9

(hd0,11)

/dev/hda12

(hd1,11)

/dev/hde12Note: I infer that hd1 maps to hde because on this particular machine there are two hard disks, one at hda and one at hde.

Next, find all partitions containing the kernel. Our first attempt assumes that at least one kernel will have filename vmlinuz.:

grub> find /vmlinuz

 (hd0,0)
 (hd0,11)
 (hd1,11)
grub>

Then perform the same search for vmlinuz in a directory called /boot:

grub> find /boot/vmlinuz

 (hd0,11)
 (hd1,11)
grub>

Here we find only two of the three we found in the first attempt, because on this machine, (hd0,0) is mounted as /boot on one of the OS's.

Grub's find command is limited. It can find only regular files, not directories. Usually the entire directory path must be specified, although for some reason it finds a couple /boot/vmlinuz when you use find on /vmlinuz. Don't count on that behavior.

Another technique for finding info in grub is to use its file completion feature. Let's say you know the kernel is on (hd0,0) and the kernel file begins with vml. Press the tab key after issuing this partial command:

null (hd0,0)/vmlinuz

Grub performs file completion much like you see at a Linux command prompt.

grub> null (hd0,0)/vmlinuz

 Possible files are: vmlinuz vmlinuz-2.6.3-7mdk vmlinuz-2.6.3-7mdk-i686-up-4GB
vmlinuz-i686-up-4GB
grub>

In the preceding, the word null is not a keyword, but instead a word chosen because it is not a keyword. Instead of "null", you could have used "whatever" or "bogus" or any other non-keyword. Once you get the list, you can complete a little more and then press tab again, just like at a bash prompt. By doing so you minimize the likelihood of transcription errors.

Occasionally grub won't easily give you all the necessary information. If you need more information than grub can conveniently provide, boot Knoppix. See Troubleshooters.Com's Knoppix Knowhow site for details.

Making a Full grub Boot Floppy

In this document's first article you created a simple Grub boot floppy without a filesystem. This is adequate to boot a computer, but not to install grub on the computer. Installing grub requires a boot floppy with grub on a filesystem. You can do that on any Linux box on which grub is installed. The following are the steps:

[root@mydesk root]# mkfs -t ext2 -c /dev/fd0u1440
[root@mydesk root]# umount /dev/fd0
[root@mydesk root]# umount /dev/fd0u1440
[root@mydesk root]# mkdir /mnt/test
[root@mydesk root]# mount /dev/fd0u1440 /mnt/test
[root@mydesk root]# mkdir -p /mnt/test/boot/grub
[root@mydesk root]# cp /boot/grub/stage1 /mnt/test/boot/grub
[root@mydesk root]# cp /boot/grub/stage2 /mnt/test/boot/grub
[root@mydesk root]# chmod a-w /mnt/test/boot/grub/stage2
umount /dev/fd0u1440
[root@mydesk root]# grub
grub> root (fd0)
grub> setup (fd0)
grub> quit
[root@mydesk root]#

You now have a bootable grub floppy with which you can boot a computer. One more thing should go on the floppy -- an example menu.lst. The menu.lst file is what brings up a "grub menu", and is vital for actually installing the grub bootloader on another computer. On the computer you need to boot, you can edit the menu.lst file to produce a grub menu on boot, and to actually install grub on the system. Note that the example menu.lst shoud NEVER be copied to the floppy before all the steps listed above this paragraph. Here is a typical session showing how to perform the copy. Note that once again, a mount and unmount must be performed.

[root@mydesk root]# mount /dev/fd0u1440 /mnt/test
[root@mydesk root]# cp -p /usr/share/doc/grub-doc-0.93/menu.lst /mnt/test/boot/grub/
stage1  stage2  
[root@mydesk root]# cp -p /usr/share/doc/grub-doc-0.93/menu.lst /mnt/test/boot/grub/menu.lst.example
[root@mydesk root]# umount /dev/fd0u1440
[root@mydesk root]#

Installing grub From Floppy

Do not perform this exercise until you've practiced the earlier exercises. Knowledge of the operation of the grub command line interface is vital to creating and installing a menu driven grub.

WARNING

This exercise walks you through creating a floppy based grub boot floppy on a grub installation on computer 1, and then using that floppy to boot and configure grub on computer 2. It WILL wipe out any existing boot loader from computer 2. Hopefully it will replace that boot loader with grub, but there are no guarantees. In fact, this document addresses only Linux grub setups, so if you have Windows or BSD installed, this document cannot help you recover.Therefore, computer 2 MUST be an experimental computer whose data and OS you can afford to lose.

In the Making a Full grub Boot Floppy exercise you created a boot diskette with stage1, stage2, and an example menu.lst named menu.lst.example. Now it's time to use that floppy on another system. As mentioned in the preceding warning, that other system must be an experimental system whose boot loader you can afford to overwrite, possibly unsuccessfully.

Insert the full grub boot floppy in the experimental computer, shut the computer down in an orderly fashion, and reboot the computer. During BIOS boot, make sure the computer's first boot drive is the floppy.

It is very likely that the the other system has grub installed. To temporarily move its files aside, do the following:

mv /boot/grub /boot/orggrub
mv /sbin/grub /sbin/orggrub
mv /sbin/grub-install /sbin/orggrub-install

Basically, rename directory /boot/grub, and then rename all grub executables. In this way you're simulating a machine that has never had grub installed, yet you can "put back" the files with a couple more renames. However, it is not so simple to "put back" the MBR.

The basic procedure is as follows:

  1. Boot from the grub floppy
  2. Copy files from the floppy to /boot/grub on the hard disk
  3. Configure /boot/grub/menu.lst for this computer
  4. Reboot from floppy, and install grub

Boot from the grub floppy

grub> root (hd0,0)
grub> kernel /vmlinuz-i686-up-4GB root=/dev/hda9
grub> boot

As mentioned before, if booting to a foreign language distro, use the appropriate lang= kernel argument so that you can work in your native tongue. If everything went right, your experimental system is now booted.

Copy files from the floppy to /boot/grub on the hard disk

First make sure there's no /boot/grub. If there is, rename it, because you sure don't want to overwrite it just to perform this exercise.

Now perform the following commands:

mkdir /mnt/test
mount /dev/fd0u1440 /mnt/test
cp -Rp /mnt/test/boot/grub /boot

Configure /boot/grub/menu.lst for this computer

If you began this document as a grub newbie, the sample menu.lst that ships with grub would have been useless to you. What a difference a few exercises can make. You now know how to boot a computer from the grub> prompt. You know the difference between the grub root and the root directory seen by Linux after bootup. You know how to structure a grub kernel statement.

A menu.lst file is basically just the same list of commands you'd use at the grub> prompt, except that the boot command is not included. The example menu.lst has commands for installing operating systems from mach to Windows, and it even has an entry that installs grub on the system and another that changes the menu colors. All of that is extraneous. What you want to do is delete all the non-Linux stuff, and configure the Linux commands to match your experimental machine's kernel partition, Linux root partition, and kernel filename. The following is an example of such an edited example file saved as menu.lst:

#

# Sample boot menu configuration file
#
# Boot automatically after 30 secs.
timeout 30
# By default, boot the first entry.
default 0
# Fallback to the second entry.
'''# fallback 1    # BE SURE TO COMMENT THIS OUT

'''

# For booting GNU/Linux
title GNU/Linux
root (hd0,0)
kernel /boot/vmlinuz-2.6.7 root=/dev/hda1 lang=us

A few notes are in order:

Your /boot/grub/menu.lst file is now complete. If you created it correctly, you can now install grub from your floppy:

Reboot from floppy, and install grub

Insert your full grub boot floppy in the experimental machine, and reboot. The machine boots to the floppy, and you are presented with the grub> prompt. From there, installation is easy, assuming you've done the previous steps correctly:

grub> root (hd0,0)

grub> setup (hd0)
grub> reboot

The machine reboots again, and if you remove the floppy, you are presented a 1 item grub menu. This is what it looks like:

gnulinuxmenu.gif
gnulinuxmenu.gif

Pressing Enter on that item boots the kernel listed in your menu.lst. A few notes are in order:

Summary

Thats it. You created a bootable floppy with stage1, stage2 and an example menu file, and used that floppy to install a grub bootloader on a machine. This is how you can take a machine with a blown bootloader and configure it to boot with grub.

However, your "grub installation" falls short. None of the grub executables are there:

Also, many files normally placed in /boot/grub are not there:

The other thing you don't have is the documentation that usually comes in /usr/share/grub.Once you get the machine booting in a stable manner, you'll probably want to install grub from a package manager or by compiling the source. Be sure to back up your existing /boot/grub/menu.lst.

Working With a Fully Installed grub

You don't want to reboot to floppy just to get to a grub> prompt or to make changes to the bootloader on your MBR. Once you've installed the full grub package you don't need to. You can use grub-install to install a newly configured boot loader without resorting to your boot floppy. You can use grub to view the results of a new menu.lst.

After you've installed grub (or restored the original installation by undoing the renames), edit your menu.lst , insert a second entry that boots the 2.4 kernel instead of the 2.6, name each entry for its kernel number, and restore the. Here is the resulting file:

#

# Sample boot menu configuration file
#
# Boot automatically after 30 secs.
timeout 30
# By default, boot the first entry.
default 0
# Fallback to the second entry.
fallback 1
# For booting GNU/Linux
title 26
root (hd0,0)
kernel /boot/vmlinuz-2.6.7 root=/dev/hda1 lang=us
# For booting GNU/Linux
title 24
root (hd0,0)
kernel /boot/vmlinuz-2.4.27 root=/dev/hda1 lang=us

The preceding file has two boot choices: One for the 2.6 kernel (appropriately named 26) and one for the 2.4 kernel (appropriately named 24). It defaults to 26, but if for some reason 26 won't boot it falls back to 24.

Once the file is saved, perform the following command:

grub-install /dev/hda1

NOTE

To get the same result, you can also run grub, either from a command line or via a grub boot floppy, and perform the following command sequence:

grub> root (hd0,0)
grub> setup (hd0)

The preceding assumes that the kernel is located on (hd0,0), which is otherwise known as /dev/hda1, and that you're installing it to the MBR of the first hard disk, also known as /dev/hda.

The next time you boot your computer, you'll see choices 26 and 24, and they'll do the right thing, as follows:

If you want to view the menu without rebooting, try this command:

grub --config-file hd0, 0/boot/grub/menu.lst

In the preceding, note that you need to escape the parentheses of the grub partition because otherwise the shell will interpret those parentheses as special characters. Perform that command and you'll see the menu, which looks like the following:

26and24menu.gif
26and24menu.gif

However, you cannot actually boot from grub run on the command line.

Options from the grub menu

We all hope every item on the menu produces a clean boot. If not, you can either edit individual commands in a given menu choice by pressing the  e key, or drop down to the grub command prompt by pressing the c key. Generally speaking, you edit commands if you suspect the menu choice is close to a correct configuration, and you drop directly to the grub command prompt if you suspect the menu item to be totally wrong, or if you need the facilities of grub's find command or its command completion feature.

Why Dedicated?

If you've ever had four or more Linux distros on one box, you already know the answer. Install a new distro, and you lose the ability to boot the others. Oh sure, some distros are nice enough to try to detect the others, but often label them wrong. Some distros don't even try, but assume they're the only distro on the disk. Some distros overwrite everything with LILO.

When installing, removing and tweaking multiple distros on a single box, what you really need is a single menu of all boots. Ideally, you don't want that menu associated with a distro, because it it were, it would be overwritten every time you remove or reinstall that distro.

This document walks you through creating a 1 MB hard disk partition containing the grub boot code and the grub menu for all your various boots. By keeping this one and only one menu up to date, you avoid the confusion of constantly having to re-import all other boots every time you install something new. Because the partition is only a single megabyte, you avoid the temptation to cannibalize it for something else.

Once your grub partition is in place, adding a distro is as simple as installing that distro, then mounting the grub partition, and adding the new distro's grub boot information (menu.lst) to the boot distro's menu.lst, and then resetting the hard disk MBR to point to the grub partition.

Creating Your Grub Partition

Unless you have very strange hardware with special booting needs, you can fit all Grub code into a 1MB partition. Create the partition with fdisk. The fdisk program is able to make tiny partitions not on cylinder boundaries. Other programs such as cfdisk round to the nearest cylinder boundary, thereby making this partition much bigger than it needs to be. For the same reason, use fdisk to create the partition after this one, to make sure that no space is left in the middle. From then on, assuming partitions are big, other partitioning programs are fine, because a few megabytes on one side or the other of a 2GB partition aren't significant.

If you're working with a very old bios with the ancient 1024 cylinder limitation, it should be very near the front of the disk (make it /dev/hda1). Remember, it's only a megabyte in size, so it's not going to "push out" any other partitions with this limitation (typically the /boot partition). As a practical matter, modern bios implementations don't have this limitation, so on modern machines you can put the grub partition anywhere.

Try to make sure to remember the device number (/dev/hda1) or whatever) housing the grub partition. However, if worst comes to worst, you can quickly see which partition using this command:

fdisk -lu /dev/hda

The preceding command prints out the number of sectors used by each partition. The Grub partition will be the smallest, because no modern operating system can be housed in a 1MB partition.

Once you've used fdisk to create the partition, format it with the mkfs.ext2 command. There's no use making this an ext3 partition, because it's small enough to fsck anyway.

Setting Up Your Grub Partition

This is simply a matter of copying files. At the very least, you must have these three files:

  1. stage1
  2. stage2
  3. menu.lst

You can copy stage1 and stage2 from the /boot/grub directory of the booted OS, or any partition. However, if you have any unusual hardware or journaling file systems besides ext3, you'll need some of the "stage1_5" files. In such a case, ALL the stage files must be copied from the same source. On your currently booted distro, perform the following command:

locate stage

Here are some of the files that command shows on my Mandriva 2006 system:

I could copy ALL those files to the grub partition, or just stage1 and stage2.Here's how I'd do it:

mkdir /mnt/test
mount /dev/hda1 /mnt/test
mkdir -p /mnt/test/boot/grub
cp -p /lib/grub/i386-mandriva/* /mnt/test/boot/grub

Note that on my system, a du command reveals that all those files consume only 376KB, so there's plenty of room.

The only thing left to do is create /mnt/test/boot/grub/menu.lst.

Making Your menu.lst

If possible, find a partition whose menu.lst contains choices for booting several different partitions. If the partition having such a menu.lst were /dev/hda7 and your Grub partition were /dev/hda1, and you mounted them as /mnt/hda1 and  /mnt/hda7, you'd perform the following command:

cp /mnt/hda7/boot/grub/menu.lst /mnt/hda1/boot/grub

Now that you have a starter for menu.lst, edit the file and pull in the info from menu.lst files from other partitions, straight into your editor. In each case, delete out the new global information and keep only the info for each new boot. Be careful that you don't get two different choices for essentially the same boot.

Occasionally, on LILO-only distributions, you might find no menu.lst file. In that case, import that distro's /etc/lilo.conf and translate LILO menu info to Grub menu info. It's not difficult if you do it slowly.

As you edit the file, make different versions so that if it doesn't work you can try a simpler version.

Making it Happen at Boot Time

You've made your menu.lst on your Grub partition, complete with boot info from every distro on the system. The trouble is, that menu file won't be consulted at boot time. To get the boot to consult it, you need to tell the hard disk's MBR to consult your Grub partition. Assuming your Grub partition is /dev/hda1, here's how you do it:

# grub
grub> root (hd0,0)
grub> setup (hd0)
grub> quit
# reboot

In the preceding command sequence, the first runs the grub executable. The second sets the root to (hd0,0), which is grub-speak for /dev/hda1. The third command tells grub to install code on the MBR that looks to /dev/hda1 for boot code. The fourth command terminates the grub command, and the fifth reboots the computer. When the computer reboots, if all went well you should see the menu you set up on your grub partition. If not, troubleshoot. If need be, bust back into the machine using the Grub techniques on the Grub From the Ground Up page, using either a Grub floppy or a Knoppix CD.

Adding a New Distro

This is where you start to see the real benefit of the dedicated Grub partition. In the bad old days, installing one more distro on your hard disk would necessitate a long and difficult search for other boots, culminating in voluminous troubleshooting. Now you simply edit your Grub partition's menu.lst and add the boots (not the globals) from the latest distro addition. Booted into the latest distro, signed in as root, it would go something like this:

  1. Mount /dev/hda1 /mnt/test
  2. cd /mnt/test/boot/grub
  3. cp -p menu.lst menu.lst.bup
  4. vim menu.lst
  5. Within vim:
    1. G  to get to the bottom
    2. o <Enter><Enter><Enter><Enter> (in order to open a space)
    3. :r /boot/grub/menu.lst
      1. NOTE: If the new version had /etc/lilo.conf and no /boot/grub/menu.lst, you might need to read in lilo.conf and then translate. It's not particularly difficult.
    4. Delete all global info brought in by the new menu.lst, and also any boots you don't need.
    5. :wq
  6. Run Grub, and within Grub do this:
    1. grub> root (hd0,0)
    2. setup (hd0)
  7. Reboot the computer, and your list should include all old boots as well as those brought in by the new boots.

The Case for Doing this On Every Hard Disk

A tiny dedicated Grub partition makes it easy to include a dedicated Knoppix partition, along with anything else you might need on the hard drive.

I find life much easier with a Knoppix partition on every hard disk I own. On dedicated data drives, it allows me to grab my data if my system drive should become defunct. It allows easy transfer of data between an old data disk and its replacement, either with the old disk still in the production computer and the new disk in a spare computer, or the new disk in the production computer and the old disk in the spare computer (in other words, you forgot to do it before shutting down the production computer with the old disk -- it happens).

You never know when somebody, some time, will dual or tri-boot the system. Or install six different OS's on it. Having a dedicated Grub partition makes such events much easier to handle.

Install Linux on an SSD

When you want to install Linux to an SSD, there are a lot of things to think about. This wiki post will look at all those things.

1. start your partitons on a 4k boundary

Because SSD's use 'blocks' of 4k in size, you must line up the partition boudaries on a block boudary for the best performance.

In fact, it is even better to start your partitons on a 512k block boundary. To do that, start fdisk with the parameters '-H 32 -C 32 -c' and create a completely new partitiontable.

fdisk -H 32 -C 32 -c

'''Note: Intel SSD's uses smaller blocks so use a different command:

fdisk -H 16 -S 16 -c'''

2. Optimize I/O

To adjust the stripe width and stride of an EXT4 filesystem, use this command to create a new filesystem:

mkfs.ext4 -E stride=128,stripe-width=128 /dev/sdaX

where sdaX is of course your ssd partition.

To tune an already existing filesystem, you can use:

tune2fs -E stride=128,stripe-width=128 /dev/sdaX

Intel users should use the value 32 for the stripe width

Use a different scheduler

You can also use a different i/o scheduler, the deadline scheduler, because the one that is used as a standard in the kernel is optimized for magnetic hard drives.

Modify /etc/rc.local (or /etc/rc.d/boot.local on openSUSE) and insert just before 'exit 0'

echo deadline > /sys/block/sda/queue/scheduler

3. Use TRIM

3.1 first, check if your SSD supports the TRIM command

hdparm -I /dev/sda | egrep "Enabled|TRIM"

3.2 second, your kernel needs to be > 2.6.33

uname -r

3.3 without special mount options, TRIM will not be used. To enable TRIM, use the 'discard' mount option in /etc/fstab.

/dev/sdaX    /    ext4    discard,etc. etc. etc.......

Also, you can use the noatime option to minmize the wear on the disk, so that would make the fstab line:

/dev/sdaX    /    ext4    noatime,discard,etc. etc. etc.......

Re-using an SSD

On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were manufactured, thus restoring it to its factory default write performance. Write performance is known to degrade over time even on SSDs with native TRIM support.

When you want to reformat an SSD, it is best to completely wipe the disk. That way the algorithm will also be reset to get the best possible performance in your new configuration. To do that, you can use hdparm XXXX to be added.. XXXXXXX

Further performance enhancements

To increase system performance and to eliminate unnecessary write actions to the SSD, you can use a RAM disk.

Add this line to /etc/fstab:

tmpfs    /tmp    tmpfs    defaults,noatime,mode=1777    0 0

Btrfs

btrfs device scan

btrfs filesystem show

mkfs.btrfs /dev/sdX

mkfs.btrfs /dev/sda /dev/sdb /dev/sdc

mkfs.btrfs -m raid0 /dev/sda /dev/sdb /dev/sdc

mkfs.btrfs -m raid10 -d raid10 /dev/sda /dev/sdb /dev/sdc

btrfs subvolume create /mnt/nonsense

where /mnt is the mountpoint of the btrfs volume

btrfs subvolume list /mnt 

mkdir /mnt/snapshots
btrfs subvolume snapshot /mnt/nonsense /mnt/snapshots/vrijdag

btrfs device add /dev/sda8 /mnt

btrfs delete /dev/sdb /mnt

btrfs fi df /

snapper list

for i in {1..20000}; do snapper delete $i; done

2015:

btrfs balance start /tmp/bla

als geen ruimte vrij:

btrfs balance start -musage=50 -dusage=50 /tmp/bla

btrfs fi show /tmp/bla
btrfs fi df /tmp/bla

Onderhoud:

btrfs scrub is used to scrub a btrfs filesystem, which will read all data and metadata blocks from all devices and verify checksums. Automatically repair corrupted blocks if there’s a correct copy available.

btrfs scrub start -B /tmp/bla
fstrim /tmp/bla

for conventiaonal HD's:

btrfs filesystem defragment /tmp/mnt/bla

recursief een directory:

btrfs filesystem defragment -r /tmp/mnt/bla

Fix grub

mount /dev/sda5 /mnt

grub edit

F2 into grub CLI

insmod ntldr

insmod ntfs

insmod chain

set root=(hd0,msdos1)

chainloader +1

boot

Usb drives

USB Drives Overzicht

USB Stick

Capacity

speed

Contents

Remarks

Voyager

8GB

24

Windows 10 home??

Example

RedHat

16

7

Leap 15.5

X86_64

WitteSticker

2

10-15

GPartEd live 2024

20220202

SanDisk

32GB

130

KDE Live! TW

bootable

Ictivity

3.8GB

?

audioanalyzer files

FAT16

Dupaco

4GB

3

HANTEK

openSUSE

4GB

26

leeg

Example

Example

Example

Example

Example

Example

Example

Example

Example

Example

Example

Example

Example

Example

Example

Example

 

drive (capacity): speed    current image
voyager(8): 24           win10 home?
redhat(16): 7            opensuse tumbleweed       20180723
opensuse(4): 26          GPARTED Live              20200820
opensusekoord:           supergrubbootdisk
dupaco(4): 3             opensuse Leap 15.0 NET
Sandisk(32): 130         kde live TW
Emtec:                     Ansible cursus dump
wittesticker(2): 10-15


measured on Envy.


pi3:/etc/sysconfig/network # hdparm -t /dev/mmcblk0

/dev/mmcblk0:
 Timing buffered disk reads:  66 MB in  3.09 seconds =  21.39 MB/sec

pi3:/etc/sysconfig/network # hdparm -t /dev/sdb    <-- this is the redhat usb disk

/dev/sdb:
 Timing buffered disk reads:  38 MB in  3.03 seconds =  12.55 MB/sec

pi3:/etc/sysconfig/network # hdparm -t /dev/sda  <--- dit is de snelle sandisk

/dev/sda:
 Timing buffered disk reads:  88 MB in  3.05 seconds =  28.82 MB/sec

GRUB

Published on Linux.com | The source for Linux information (https://www.linux.com)

Home > How to Rescue a Non-booting GRUB 2 on Linux

How to Rescue a Non-booting GRUB 2 on Linux [1]

Submitted by cschroder [2] on 

Afbeelding2.png
Afbeelding2.png

Once upon a time we had legacy GRUB, the Grand Unified Linux Bootloader version 0.97. Legacy GRUB had many virtues, but it became old and its developers did yearn for more functionality, and thus did GRUB 2 come into the world.

GRUB 2 is a major rewrite with several significant differences. It boots removable media, and can be configured with an option to enter your system BIOS. It's more complicated to configure with all kinds of scripts to wade through, and instead of having a nice fairly simple /boot/grub/menu.lst file with all configurations in one place, the default is /boot/grub/grub.cfg. Which you don't edit directly, oh no, for this is not for mere humans to touch, but only other scripts. We lowly humans may edit /etc/default/grub, which controls mainly the appearance of the GRUB menu. We may also edit the scripts in /etc/grub.d/. These are the scripts that boot your operating systems, control external applications such as memtest and os_prober, and theming./boot/grub/grub.cfg is built from /etc/default/grub and /etc/grub.d/* when you run the update-grub command, which you must run every time you make changes.

The good news is that the update-grub script is reliable for finding kernels, boot files, and adding all operating systems to your GRUB boot menu, so you don't have to do it manually.

We're going to learn how to fix two of the more common failures. When you boot up your system and it stops at the grub> prompt, that is the full GRUB 2 command shell. That means GRUB 2 started normally and loaded the normal.mod module (and other modules which are located in /boot/grub/[arch]/), but it didn't find your grub.cfg file. If you see grub rescue> that means it couldn't find normal.mod, so it probably couldn't find any of your boot files.

How does this happen? The kernel might have changed drive assignments or you moved your hard drives, you changed some partitions, or installed a new operating system and moved things around. In these scenarios your boot files are still there, but GRUB can't find them. So you can look for your boot files at the GRUB prompt, set their locations, and then boot your system and fix your GRUB configuration.

GRUB 2 Command Shell

The GRUB 2 command shell is just as powerful as the shell in legacy GRUB. You can use it to discover boot images, kernels, and root filesystems. In fact, it gives you complete access to all filesystems on the local machine regardless of permissions or other protections. Which some might consider a security hole, but you know the old Unix dictum: whoever has physical access to the machine owns it.

When you're at the grub> prompt, you have a lot of functionality similar to any command shell such as history and tab-completion. The grub rescue> mode is more limited, with no history and no tab-completion.

If you are practicing on a functioning system, press C when your GRUB boot menu appears to open the GRUB command shell. You can stop the bootup countdown by scrolling up and down your menu entries with the arrow keys. It is safe to experiment at the GRUB command line because nothing you do there is permanent. If you are already staring at the grub> or grub rescue>prompt then you're ready to rock.

The next few commands work with both grub> and grub rescue>. The first command you should run invokes the pager, for paging long command outputs:

grub> set pager=1

There must be no spaces on either side of the equals sign. Now let's do a little exploring. Type ls to list all partitions that GRUB sees:

grub> ls

(hd0) (hd0,msdos2) (hd0,msdos1)

What's all this msdos stuff? That means this system has the old-style MS-DOS partition table, rather than the shiny new Globally Unique Identifiers partition table (GPT). (See Using the New GUID Partition Table in Linux (Goodbye Ancient MBR) [3]. If you're running GPT it will say (hd0,gpt1). Now let's snoop. Use the ls command to see what files are on your system:

grub> ls (hd0,1)/

lost+found/ bin/ boot/ cdrom/ dev/ etc/ home/ lib/

lib64/ media/ mnt/ opt/ proc/ root/ run/ sbin/

srv/ sys/ tmp/ usr/ var/ vmlinuz vmlinuz.old

initrd.img initrd.img.old

Hurrah, we have found the root filesystem. You can omit the msdos and gpt labels. If you leave off the slash it will print information about the partition. You can read any file on the system with the cat command:

grub> cat (hd0,1)/etc/issue

Ubuntu 14.04 LTS \n \l

Reading /etc/issue could be useful on a multi-boot system for identifying your various Linuxes.

Booting From grub>

This is how to set the boot files and boot the system from the grub> prompt. We know from running the ls command that there is a Linux root filesystem on (hd0,1), and you can keep searching until you verify where /boot/grub is. Then run these commands, using your own root partition, kernel, and initrd image:

grub> set root=(hd0,1)

grub> linux /boot/vmlinuz-3.13.0-29-generic root=/dev/sda1

grub> initrd /boot/initrd.img-3.13.0-29-generic

grub> boot

The first line sets the partition that the root filesystem is on. The second line tells GRUB the location of the kernel you want to use. Start typing /boot/vmli, and then use tab-completion to fill in the rest. Type root=/dev/sdX to set the location of the root filesystem. Yes, this seems redundant, but if you leave this out you'll get a kernel panic. How do you know the correct partition? hd0,1 = /dev/sda1. hd1,1 = /dev/sdb1. hd3,2 = /dev/sdd2. I think you can extrapolate the rest.

The third line sets the initrd file, which must be the same version number as the kernel.

The fourth line boots your system.

On some Linux systems the current kernels and initrds are symlinked into the top level of the root filesystem:

$ ls -l /

vmlinuz -> boot/vmlinuz-3.13.0-29-generic

initrd.img -> boot/initrd.img-3.13.0-29-generic

So you could boot from grub> like this:

grub> set root=(hd0,1)

grub> linux /vmlinuz root=/dev/sda1

grub> initrd /initrd.img

grub> boot

Booting From grub-rescue>

If you're in the GRUB rescue shell the commands are different, and you have to load the normal.mod andlinux.mod modules:

grub rescue> set prefix=(hd0,1)/boot/grub

grub rescue> set root=(hd0,1)

grub rescue> insmod normal

grub rescue> normal

grub rescue> insmod linux

grub rescue> linux /boot/vmlinuz-3.13.0-29-generic root=/dev/sda1

grub rescue> initrd /boot/initrd.img-3.13.0-29-generic

grub rescue> boot

Tab-completion should start working after you load both modules.

Making Permanent Repairs

When you have successfully booted your system, run these commands to fix GRUB permanently:

# update-grub

Generating grub configuration file ...

Found background: /usr/share/images/grub/Apollo_17_The_Last_Moon_Shot_Edit1.tga

Found background image: /usr/share/images/grub/Apollo_17_The_Last_Moon_Shot_Edit1.tga

Found linux image: /boot/vmlinuz-3.13.0-29-generic

Found initrd image: /boot/initrd.img-3.13.0-29-generic

Found linux image: /boot/vmlinuz-3.13.0-27-generic

Found initrd image: /boot/initrd.img-3.13.0-27-generic

Found linux image: /boot/vmlinuz-3.13.0-24-generic

Found initrd image: /boot/initrd.img-3.13.0-24-generic

Found memtest86+ image: /boot/memtest86+.elf

Found memtest86+ image: /boot/memtest86+.bin

done

# grub-install /dev/sda

Installing for i386-pc platform.

Installation finished. No error reported.

When you run grub-install remember you're installing it to the boot sector of your hard drive and not to a partition, so do not use a partition number like /dev/sda1.

But It Still Doesn't Work

If your system is so messed up that none of this works, try the Super GRUB2 live rescue disk [4]. The official GNU GRUB Manual 2.00 [5] should also be helpful.

Tutorial Category: 

Tutorials [6]

Source URL: https://www.linux.com/learn/how-rescue-non-booting-grub-2-Linux

Links:[1] https://www.linux.com/learn/how-rescue-non-booting-grub-2-Linux[2] https://www.linux.com/users/cschroder[3] https://www.linux.com/learn/tutorials/730440-using-the-new-guid-partition-table-in-linux-good-bye-ancient-mbr-[4] http://www.supergrubdisk.org/[5] https://www.gnu.org/software/grub/manual/grub.html[6] https://www.linux.com/tutorials/category/tutorials

RAID

RAID vergroten

Ter referentie, hier enkele veel gebruikte commando's:

 # cat /proc/mdstat: geef status, ook rebuild voortgang
 # mdadm -D /dev/md[012]: detail over RAID 
 # mdadm - -stop /dev/md2, eerst umount /dev/md2: om een RAID te stoppen
 # mdadm - -assemble - -scan: assemble all raids
 # mdadm - -assemble /dev/md1 /dev/sda2 /dev/sdb2 /dev/sdc2: assemblatie
 # mdadm -f /dev/sda1: fail deze partitie (mark as FAULTY)
 # mdadm -r /dev/sda1: remove deze partitie
 # mdadm - -re-add /dev/md1 /dev/sdb2 *(veel gebruikt): om een recently removede schijf weer toe te voegen
doe dit nadat de schijf er weer is.
 # mdadm -a /dev/mdx: hot add listed devices
 # mdadm - -stop /dev/md2: stop de array
 # Mdadm -A - -scan: start the arrays

De volgende stappen zijn nodig:

0. zet de automatische reboot van de server UIT!

1. Selekteer een disk en verwijder hem van de array. Voer de 2 commando’s achter elkaar uit:

# mdadm -f /dev/md1 /dev/sdd1  - fail device
# mdadm -r /dev/md1 /dev/sdd1  - remove device

Het laatste commando doet het niet als drive al weg is, dus doe het voor loskoppelen. Daarna de oude drive loshalen en sluit de nieuwe drive aan.

2. partitioneer de nieuwe drive naar de volledige grootte. Laat op linux FS staan, dit werkt ook – PvdM 2017

# fdisk /dev/sdd

g: create new GPT partition table n: new partition en 4x enter w: write and quit:

3. Voeg de nieuwe disk aan het array toe:

# mdadm --add /dev/md1 /dev/sde1   - add device, start immediate rebuild

4. Daarna kun je het hele proces in de gaten houden met:

# watch cat /proc/mdstat
# mdadm –detail /dev/md1

5. Wacht tot de resync klaar is. Hierna moet de stappen 1-4 herhalen voor elke schijf. 6. Hierna kun je de ruimte op het array vergroten:

# mdadm --grow /dev/md0 --size=max - change the size of an active array

Dit duurt even, de extra (lege haha) ruimte wordt nu gesyncd.

7. Het array bevat nu 1 disk met alle beschikbare ruimte. 8. Nu de onderliggende partitie is vergroot, moet je je filesystem resizen. Maar eerst wil je een filesystemcheck uitvoeren. Dit kan niet als het gemount is.

# umount [mountpoint]
# fsck /dev/md1

9. For an ext2/ext3/ext4 filesystem:

# resize2fs /dev/md1

Na het wegvallen van 1 harddisk

# mdadm /dev/md1 --add /dev/sdX

en dan werkt het weer

Swap file on BTRFS

Then start GParted or another disk management app, delete the swap partition, expand your partitions (BTRFS can be grown online, no need for reboot).
Create a subvolume to store your swap. Then create a swap file:

https://wiki.archlinux.org/title/Swap#Swap_file

You may wish to disable Copy On Write on your swap file.

Test harddisk for bad blocks

# badblocks -e 10 -s -w /dev/mmcblk0

-e max bad block count
Specify a maximum number of bad blocks before aborting the test. The default is 0, meaning the test will continue until the end of the test range is reached.

-s show progress

-w use write mode

-n Use non-destructive read-write mode.
By default only a non-destructive read-only test is done. This option must not be combined with the -w option, as they are mutually exclusive.

Pass completed, X bad blocks found (R/W/C errors)

The three numbers in the parentheses correspond to:

# smartctl -t long /dev/device

remember no smart on sd cards

Partitions-hupsie

hd0

476GB

Grub2: boot USB from GRUB prompt

When the PC will not boot from USB, you can use GRUB2 to boot from the USB.

In the GRUB menu: Press 'c' to go the GRUB prompt

grub> ls
(hd0) (hd0,msdos1) ...
grub> set root=hd0,msdos1 
grub> chainloader /efi/boot/bootx64.efi
grub> boot

The USB boot menu will appear.

The above is of course an example, every situation will be different. But the idea is the same.

Best way to use GRUB in a multiboot system

default 0
timeout 8
gfxmenu (hd0,1)/boot/message
title Suse
   rootnoverify (hd0,1)
   chainloader +1
title Arch
   rootnoverify (hd0,2)
   chainloader +1
title Debian
   rootnoverify (hd0,6)
   chainloader +1

How to resue your system when the kernel won't boot

SUSE Broken? Don’t fear the chroot !

Posted by johnlange on September 22, 2009 06:45 pm under SUSE, Tech Tip

SUSE hasn’t let me down very often but recently I had a bad experience while applying some updates to an OpenSUSE laptop. There were quite a few updates so I undocked the laptop so I could relax while they downloaded.

For reasons that I have not yet resolved, the wirless networking became unstable and as a result, the updates had to be aborted.

Unfortunately, a new kernel was part of the updates and when the laptop rebooted it was in a bad state. X windows wouldn’t start and critically, there were no network drivers for the new kernel. To make matters worse, OpenSUSE does not keep the old kernels in /boot (why is that?) so there was nothing to fall back on.

With nothing left to do, it was time to try rescue mode and in a few short steps I had the system fully working again. Here is what I did:

# mount /dev/sda2 /mnt
# mount /dev/sda1 /mnt/boot
… etc.

# mount --bind /proc /mnt/proc
# mount --bind /sys /mnt/sys
# mount --bind /dev /mnt/dev

# chroot /mnt

# zypper up

I rebooted and everything was back to normal.

How to restore MBR on harddisk

MBR / Hard Disk Layout

The MBR is the very first part of your hard disk stores the boot loader and the partition table.

Basically it comes to this: The MBR is 512 bytes . . the first 446 bytes are for the boot loader, and the bytes from 446 to 512 are for the partition table. If you delete the full 512 bytes you will not only delete the boot loader but you will have lost the partition table as well . . . so . . be careful !

If you back up the MBR to floppy you do:

# dd if=/dev/hda of=/dev/fd0/boot.mbr bs=512 count=1

Once the disk is clean and you want to restore:

# dd if=/dev/fd0/boot.mbr of=/dev/hda bs=512 count=1

This will restore the original partition table and the boot loader you had in the MBR.

Now, if you only want to clear the boot loader part ( and keep the partition table intact ) you do:

# dd if=/dev/zero of=/dev/hda bs=446 count=1

How to resque a hanging linux

key

function

r

Remove X's control over the keyboard

e

End all processes except init (SIGTERM)

i

Kill all processes except init (SIGKILL)

s

Write diskcache to disk

u

Remount all mounted filesystems read-only

b

Reboot!