Booting from (undesirable) old partition

opensuse 13.1

The original installation (something like v9.x) created a separate /boot partition. It was sized too small and updated kernel installations would fail for lack of space. I created a /boot directory in the root partition (/), copied the boot files there, updated Yast::System::Boot Loader to boot from the “root partition.” It shows all of the recent kernel updates. (Why all of them since 3.11.6? Why not only the last 3?)

I renamed the original boot partition to “/boot-old.”

All seemed okay at the time. Not so.

Despite how Yast::System::Boot Loader is configured, the system still boots from the files in /boot-old. I am reluctant to remove /boot-old from /etc/fstab as that may render the system unbootable.

How do I convince the system to boot from /boot, not /boot-old?

Maybe “purge-kernels.service” is disabled?
Check with:

systemctl status purge-kernels.service

and enable it with this if necessary:

systemctl enable purge-kernels.service

Or use YaST->System->Services Manager for both.

I renamed the original boot partition to “/boot-old.”

You renamed the mount point, not the partition. :wink:

Despite how Yast::System::Boot Loader is configured, the system still boots from the files in /boot-old. I am reluctant to remove /boot-old from /etc/fstab as that may render the system unbootable.

How do you actually know that the system boots from the old /boot?

Anyway, /boot only contains the kernel/initrd, and grub2’s modules and configuration.
Removing it from /etc/fstab should not give any problems, as it’s only needed by the boot loader, which does not know about your /etc/fstab anyway.

How do I convince the system to boot from /boot, not /boot-old?

Unmount it (if it is mounted), enter YaST->System->Boot Loader and just press OK. This should re-create the grub2 menu using the kernels from /boot on the / partition then and re-install the boot loader (necessary so that it loads grub.cfg from the correct /boot on /).

The old boot partition should be removed from /etc/fstab so it does not get mounted Also it unknown which grub and also if a generic mbr code was used. In any case the MBR need to know where to boot from so if generic a boot flag need set on the root partition and off the old boot. If grub I believe you need to reinstall grub to get thing straight

On 2014-08-18 20:36, gogalthorp wrote:
>
> The old boot partition should be removed from /etc/fstab so it does not
> get mounted Also it unknown which grub and also if a generic mbr code
> was used. In any case the MBR need to know where to boot from so if
> generic a boot flag need set on the root partition and off the old boot.
> If grub I believe you need to reinstall grub to get thing straight

You can use this script:

https://github.com/arvidjaar/bootinfoscript/raw/master/bootinfoscript

to find out how booting is set.

Typically some code in the MBR runs, which either loads grub directly or
loads another boot sector in another partition, and this one then loads
grub. And this one knew that grub files were in one partition, and the
operating system root was in another.

Whatever the combination, if you change the actual boot partition, you
have to modify all that - copying the files is necessary but does not
suffice.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

$ systemctl status purge-kernels.service
purge-kernels.service - Purge old kernels
   Loaded: loaded (/usr/lib/systemd/system/purge-kernels.service; enabled)
   Active: inactive (dead)
           start condition failed at Mon 2014-08-18 12:33:37 MST; 5min ago
           ConditionPathExists=/boot/do_purge_kernels was not met

Maybe because it is looking in /boot-old?

There are only two kernels in /boot-old, 3.7.10 and 3.11.6.4. More recent kernels are in /boot. The boot Grub menu only offers the two old kernels.

Unmount it (if it is mounted), enter YaST->System->Boot Loader and just press OK. This should re-create the grub2 menu using the kernels from /boot on the / partition then and re-install the boot loader (necessary so that it loads grub.cfg from the correct /boot on /).

It still booted from /boot-old.

No. It looks in the rpm database which kernel packages are installed.

Which kernels do you actually have installed?

rpm -qa kernel-*

There are only two kernels in /boot-old, 3.7.10 and 3.11.6.4. More recent kernels are in /boot. The boot Grub menu only offers the two old kernels.

Well, you said that you manually copied kernels to /boot.
If they are not installed as RPMs, purge-kernels will not remove them.

Please also post a directory listing of /boot in addition:

ls -l /boot

It still booted from /boot-old.

And did you try to re-install the boot loader after unmounting /boot-old as I suggested?

$ rpm -qa kernel-*
kernel-devel-3.11.10-17.2.noarch
kernel-firmware-20130714git-2.17.1.noarch
kernel-devel-3.11.10-21.1.noarch
kernel-source-3.11.10-21.1.noarch
kernel-desktop-3.11.10-17.2.x86_64
kernel-syms-3.11.10-21.1.x86_64
kernel-xen-devel-3.11.10-17.2.x86_64
kernel-desktop-3.11.10-21.1.x86_64
kernel-xen-devel-3.11.10-21.1.x86_64
kernel-source-3.11.10-17.2.noarch
kernel-default-devel-3.11.10-21.1.x86_64
kernel-syms-3.11.10-17.1.x86_64
kernel-desktop-devel-3.11.10-21.1.x86_64
kernel-desktop-devel-3.11.10-17.2.x86_64
kernel-default-devel-3.11.10-17.2.x86_64

Well, you said that you manually copied kernels to /boot.
If they are not installed as RPMs, purge-kernels will not remove them.

Please also post a directory listing of /boot in addition:

$ ll /boot/
total 79M
-rw------- 1 root root  512 Aug 14  2013 backup_mbr
lrwxrwxrwx 1 root root    1 Nov 22  2013 boot -> ./
-rw-r--r-- 1 root root 1.5K Oct 17  2013 boot.readme
-rw-r--r-- 1 root root 138K Jun 17 07:22 config-3.11.10-17-desktop
-rw-r--r-- 1 root root 138K Jul 22 08:17 config-3.11.10-21-desktop
drwxr-xr-x 2 root root 4.0K Nov 22  2013 grub/
drwxr-xr-x 7 root root 4.0K Aug 18 09:13 grub2/
lrwxrwxrwx 1 root root    5 Mar 24  2013 grub2-efi.rpmsave -> grub2/
lrwxrwxrwx 1 root root   25 Aug 18 03:48 initrd -> initrd-3.11.10-21-desktop
-rw------- 1 root root  24M Jul 28 03:26 initrd-3.11.10-17-desktop
-rw------- 1 root root  24M Aug 18 03:48 initrd-3.11.10-21-desktop
-rw-r--r-- 1 root root 606K Nov 22  2013 message
-rw-r--r-- 1 root root 730K Jun 17 10:24 symtypes-3.11.10-17-default.gz
-rw-r--r-- 1 root root 731K Jun 17 10:26 symtypes-3.11.10-17-desktop.gz
-rw-r--r-- 1 root root 707K Jun 17 07:18 symtypes-3.11.10-17-xen.gz
-rw-r--r-- 1 root root 730K Jul 22 09:11 symtypes-3.11.10-21-default.gz
-rw-r--r-- 1 root root 731K Jul 22 09:15 symtypes-3.11.10-21-desktop.gz
-rw-r--r-- 1 root root 707K Jul 22 09:40 symtypes-3.11.10-21-xen.gz
-rw-r--r-- 1 root root 257K Jun 17 09:47 symvers-3.11.10-17-desktop.gz
-rw-r--r-- 1 root root 257K Jul 22 09:08 symvers-3.11.10-21-desktop.gz
-rw-r--r-- 1 root root  516 Jun 17 09:46 sysctl.conf-3.11.10-17-desktop
-rw-r--r-- 1 root root  516 Jul 22 09:08 sysctl.conf-3.11.10-21-desktop
-rw-r--r-- 1 root root 2.6M Jun 17 09:21 System.map-3.11.10-17-desktop
-rw-r--r-- 1 root root 2.6M Jul 22 08:59 System.map-3.11.10-21-desktop
-rw-r--r-- 1 root root 5.8M Jun 17 09:46 vmlinux-3.11.10-17-desktop.gz
-rw-r--r-- 1 root root 5.8M Jul 22 09:08 vmlinux-3.11.10-21-desktop.gz
lrwxrwxrwx 1 root root   26 Aug 18 03:48 vmlinuz -> vmlinuz-3.11.10-21-desktop
-rw-r--r-- 1 root root 5.0M Jun 17 13:15 vmlinuz-3.11.10-17-desktop
-rw-r--r-- 1 root root 5.0M Jul 22 10:55 vmlinuz-3.11.10-21-desktop

Hmm. It looks like those have gotten purged now. There used to be kernels from 3.7.

And did you try to re-install the boot loader after unmounting /boot-old as I suggested?

Re-install? As in go to Software Management, remove, install?
Or unmount /boot-old, go to Yast::System::Boot loader, enter OK?

Well, it looks like it should be now.

Re-install? As in go to Software Management, remove, install?
Or unmount /boot-old, go to Yast::System::Boot loader, enter OK?

The latter one.

Although removing and installing the grub2 package would of course also re-create the boot menu.
But that’s overkill, I’d say… :wink:

Some thoughts…
If this really might be an OpenSuSE 9, that architecture is “pre-Novell” and might contain a LiLo bootloader.
If you really want to preserve this old machine, without knowing for sure what is in the bootloader, you might consider chainloading instead of replacing (make one bootloader point to the other as a bootable option).

In any case the old system may be almost impossible to maintain if it’s that old. I don’t think any of its code is maintained anymore, you might consider re-deploying your apps into a new, modern install.

TSU

Well, there never was an OpenSuSE 9, and SuSE 9 was not really “pre-Novell” either. SuSE 9.1 was the first version released by Novell. SuSE 9.0 was indeed the last “pre-Novell” version though.
But that’s irrelevant anyway, I just couldn’t refrain… :wink:
And even on SuSE 8.1, which was the first one I used, grub was the default bootloader already.

But, this is actually a 13.1 system, if you didn’t notice.

He just mentioned that he partitioned the disk when he installed SuSE 9.1, and it has a separate /boot partition therefore, which apparently was suggested by default.
Although I think a separate /boot partition was never suggested by default since 8.1 at least, unless necessary because of / on an LVM or encrypted e.g.
But then I didn’t do fresh installations with every version either.

If you really want to preserve this old machine, without knowing for sure what is in the bootloader, you might consider chainloading instead of replacing (make one bootloader point to the other as a bootable option).

No. Please read the original post again.
He wants to get rid of the separate /boot partition he had on his 13.1 system, and boot from the /boot directory on the / partition instead.

In any case the old system may be almost impossible to maintain if it’s that old.

That’s not what his intentions are.

I don’t think any of its code is maintained anymore, you might consider re-deploying your apps into a new, modern install.

He is actually using a “modern install”, openSUSE 13.1.

Using the “bootinfoscript” gives this bit:

=> Grub2 (v2.00) is installed in the MBR of /dev/sda and looks at sector 1 of 
    the same hard drive for core.img. core.img is at this location and looks 
    for /grub2 and uses an embedded config file:
    
    ---------------------------------------------------------------------------
    search.fs_uuid 5aac3b85-8186-443f-b521-3596a587c60a root hd1,msdos5  
    set prefix=($root)/grub2

In the grub2 settings panel I have the “boot loader location” set to “Boot from Root Partition.” However, it seems to be using the MBR of /dev/sda to decide which root partition to use. In this case the wrong one: “hd1,msdos5” instead of “hd2,msdos7”.

How is the MBR updated?

On 2014-08-18 18:16 (GMT) jimoe666 composed:

> opensuse 13.1

> The original installation (something like v9.x) created a separate /boot
> partition. It was sized too small and updated kernel installations would
> fail for lack of space. I created a /boot directory in the root
> partition (/), copied the boot files there, updated Yast::System::Boot
> Loader to boot from the “root partition.” It shows all of the recent
> kernel updates. (Why all of them since 3.11.6? Why not only the last 3?)

> I renamed the original boot partition to “/boot-old.”

> All seemed okay at the time. Not so.

> Despite how Yast::System::Boot Loader is configured, the system still
> boots from the files in /boot-old. I am reluctant to remove /boot-old
> from /etc/fstab as that may render the system unbootable.

> How do I convince the system to boot from /boot, not /boot-old?

Given:
1-very old version was original installation
2-neutral MBR policy that probably applied at that time:
http://old-en.opensuse.org/Bugs/grub#How_does_a_PC_boot_.2F_How_can_I_set_up_a_working_GRUB.3F
3-currently booting from original /boot partition

I expect:
1-generic MBR code
2-original /boot partition is a primary
3-boot flag remains set on original /boot partition in MBR table
4-upgrades eventually resulting in 13.1 retain Grub Legacy as bootloader in use

I suspect:
1-/etc/grub.conf may not have been updated
2-yast -> bootloader -> bootloader installation: more than one checkbox may
be checked (one should be enough)

Boot from root partition is only appropriate if / is a primary partition or
being chainloaded to.

Boot from MBR should be OK to select, but doing that means giving up neutral
MBR (which seems to matter little or none to most people).

Boot from Extended partition is only appropriate if / is a logical partition.

Output from fdisk -l /dev/sda would be helpful, in addition to Carlos’
suggestion, in suggesting how to proceed.

If root is a primary partition, having done what you already have, fix might
be as simple as:
1-use fdisk (or gparted, or any partitioning tool) to move boot flag from
original boot partition to root partition (if it’s not there already, and
there exclusively)
2-edit /boot/grub/menu.lst as required for the location of root partition (if
not already done)
3-edit /etc/grub/conf (for same reason)(not strictly necessary to achieve
boot, but needed eventually for the benefit of yast)
4-setup Grub (does not require chroot; does not require root be mounted anywhere)
Code:

grub

grub> find /boot/grub/stage1 # locates for you where grub is currently installed
(hd0,0) # likely result
grub> root (hd0,2) # example. actual location of root partition required
grub> setup (hd0,2) # if actual location of root is in fact sda3
grub> quit

(reboot computer)



The wise are known for their understanding, and pleasant
words are persuasive.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata *** http://fm.no-ip.com/

This might help:

============================ Drive/Partition Info: =============================

Drive: sda _____________________________________________________________________

Disk /dev/sda: 250.1 GB, 250059350016 bytes, 488397168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Partition  Boot  Start Sector    End Sector  # of Sectors  Id System

/dev/sda1    *             63       144,584       144,522  83 Linux
/dev/sda2           4,209,030    46,154,744    41,945,715  8e Linux LVM
/dev/sda3          46,154,745   488,392,064   442,237,320  8e Linux LVM
/dev/sda4             144,585     4,209,029     4,064,445  8e Linux LVM


Drive: sdb _____________________________________________________________________

Disk /dev/sdb: 251.0 GB, 251000193024 bytes, 490234752 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Partition  Boot  Start Sector    End Sector  # of Sectors  Id System

/dev/sdb1               2,048   490,233,855   490,231,808   f W95 Extended (LBA)
/dev/sdb5               4,096       321,535       317,440  83 Linux
/dev/sdb6             323,584     4,530,175     4,206,592  82 Linux swap / Solaris
/dev/sdb7           4,532,224    88,422,399    83,890,176  83 Linux
/dev/sdb8          88,424,448   490,207,231   401,782,784  83 Linux


Drive: sdc _____________________________________________________________________

Disk /dev/sdc: 250.1 GB, 250059350016 bytes, 488397168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Partition  Boot  Start Sector    End Sector  # of Sectors  Id System

/dev/sdc1              16,065   488,392,064   488,376,000  83 Linux

/dev/sdb7 is the “root partition” (/) where /boot is located.
/dev/sdb5 is the old boot partition, previously mounted as /boot-old.

On 2014-08-18 23:16 (GMT) jimoe666 composed:

> Using the “bootinfoscript” gives this bit:

> Code:
> --------------------
> => Grub2 (v2.00) is installed in the MBR of /dev/sda and looks at sector 1 of

So much for my theory in last post, sent before this showed up. :-p

I thought upgrades to systems with Grub Legacy were keeping Grub Legacy, at
least by default.

> the same hard drive for core.img. core.img is at this location and looks
> for /grub2 and uses an embedded config file:

> ---------------------------------------------------------------------------
> search.fs_uuid 5aac3b85-8186-443f-b521-3596a587c60a root hd1,msdos5
> set prefix=($root)/grub2
> --------------------

> In the grub2 settings panel I have the “boot loader location” set to
> “Boot from Root Partition.” However, it seems to be using the MBR of
> /dev/sda to decide which root partition to use. In this case the wrong
> one: “hd1,msdos5” instead of “hd2,msdos7”.

> How is the MBR updated?

Can be done in many ways.

What’s in /etc/grub.conf?

How about showing us your partitioning? What to do in an only disk system is
simpler than with more than one disk WRT to bootloader installation &
configuration. :-p

The wise are known for their understanding, and pleasant
words are persuasive.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata *** http://fm.no-ip.com/

There is no /etc/grub.conf

How about showing us your partitioning?

The previous post was the partitioning.

On 2014-08-18 23:46 (GMT) jimoe666 composed:

> This might help:

> Code:
> --------------------
> ============================ Drive/Partition Info: =============================

> Drive: sda _____________________________________________________________________

> Disk /dev/sda: 250.1 GB, 250059350016 bytes, 488397168 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes

> Partition Boot Start Sector End Sector # of Sectors Id System

> /dev/sda1 * 63 144,584 144,522 83 Linux
> /dev/sda2 4,209,030 46,154,744 41,945,715 8e Linux LVM
> /dev/sda3 46,154,745 488,392,064 442,237,320 8e Linux LVM
> /dev/sda4 144,585 4,209,029 4,064,445 8e Linux LVM

> Drive: sdb _____________________________________________________________________

> Disk /dev/sdb: 251.0 GB, 251000193024 bytes, 490234752 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes

> Partition Boot Start Sector End Sector # of Sectors Id System

> /dev/sdb1 2,048 490,233,855 490,231,808 f W95 Extended (LBA)
> /dev/sdb5 4,096 321,535 317,440 83 Linux
> /dev/sdb6 323,584 4,530,175 4,206,592 82 Linux swap / Solaris
> /dev/sdb7 4,532,224 88,422,399 83,890,176 83 Linux
> /dev/sdb8 88,424,448 490,207,231 401,782,784 83 Linux

> Drive: sdc _____________________________________________________________________

> Disk /dev/sdc: 250.1 GB, 250059350016 bytes, 488397168 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes

> Partition Boot Start Sector End Sector # of Sectors Id System

> /dev/sdc1 16,065 488,392,064 488,376,000 83 Linux
> --------------------

> /dev/sdb7 is the “root partition” (/) where /boot is located.
> /dev/sdb5 is the old boot partition, previously mounted as /boot-old.

I don’t remember anything in this thread discussing fixing MBR of sda. When
You tell YaST to boot from root that lives on sdb7, it installs Grub to PBR
of sda7. But nothing’s changed MBR of your sda, which is where it all starts,
to point to other than sdb5, which is why you’re getting the old boot menu.

You could install (update actually, since some code is already there pointing
to sdb5) 13.1’s Grub to sda, but another solution is to add a stanza that
points to sda7 to the Grub menu on sdb5.

Anyone can boot directly from either /boot or root, but only if the
appropriate one lives on a primary partition on the first BIOS disk, and that
partition is active, and there is standard MBR code on that disk. To boot
from root when it’s not on a first BIOS disk and not on a primary, then a
prerequisite step is required, which in your case means Grub needs to go on
sda’s MBR, pointing to sdb7, instead of to sdb5.

All my second disk roots have Grub installed to them, but they are all
chainloaded, either by Grub on a primary on the first BIOS HD, or by some
other bootloader somewhere on the first BIOS HD. I have Grub on no MBR of any
disk under this roof. IOW, all my booting gets started via standard MBR code,
regardless of disk count, and regardless of what I choose to boot (DOS, OS/2,
Windows, Fedora, *buntu, Mageia, but far and away most often, openSUSE).

The wise are known for their understanding, and pleasant
words are persuasive.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata *** http://fm.no-ip.com/

On 2014-08-19 02:06, jimoe666 wrote:
>
> mrmazda;2660093 Wrote:

>> What’s in /etc/grub.conf?
> There is no /etc/grub.conf

That’s because you have grub 2. Grub 1 had that file.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

On 2014-08-19 01:16, jimoe666 wrote:
>
> Using the “bootinfoscript” gives this bit:
>
> Code:
> --------------------
> => Grub2 (v2.00) is installed in the MBR of /dev/sda and looks at sector 1 of
> the same hard drive for core.img. core.img is at this location and looks
> for /grub2 and uses an embedded config file:
>
> ---------------------------------------------------------------------------
> search.fs_uuid 5aac3b85-8186-443f-b521-3596a587c60a root hd1,msdos5
> set prefix=($root)/grub2
> --------------------
>
> In the grub2 settings panel I have the “boot loader location” set to
> “Boot from Root Partition.” However, it seems to be using the MBR of
> /dev/sda to decide which root partition to use. In this case the wrong
> one: “hd1,msdos5” instead of “hd2,msdos7”.

I think that at some point you had it set to, or also to, “boot from MBR”.

> How is the MBR updated?

I think you have to tell it to “create generic MBR” or similar wording.
That should disable the core.img mentioned above (not delete, it though

  • I think).

The result will be that the generic code in the MBR will boot the first
partition marked as bootable.

So also you have to mark “hd2,msdos7” as bootable - wait, that is
impossible! You can only mark as bootable primary partitions. And this
method can only boot partitions on the same disk.

So you need to have Grub 2 installed on the MBR, as it is now, but
pointing to your root partition - but I don’t know if you can have it on
sda and root in sdb… not that easy. With a separate /boot partition in
sda, yes.

You must clarify your purpose.

Is sda still your boot disk? Is Linux root installed in sda, under LVM,
or on a partition on sdb?


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

I did not know until later that the MBR is the problem.

When you tell YaST to boot from root that lives on sdb7, it installs Grub to PBR
of sda7.

You mean sdb7?
What is PBR?

But nothing’s changed MBR of your sda, which is where it all starts,
to point to other than sdb5, which is why you’re getting the old boot menu.

Exactly. How do I fix it?

…[interesting stuff]…

None of that helps with: How do I update the MBR to point to the correct boot?

On 2014-08-19 03:06 (GMT) jimoe666 composed:

> mrmazda;2660096 Wrote:

>> I don’t remember anything in this thread discussing fixing MBR of sda.

> I did not know until later that the MBR is the problem.

>> When you tell YaST to boot from root that lives on sdb7, it installs
>> Grub to PBR
>> of sda7.

> You mean sdb7?

Correct (typo).

> What is PBR?

Partition boot record (first sector of partition, akin to first sector of
disk where MBR lives).

>> But nothing’s changed MBR of your sda, which is where it all starts,
>> to point to other than sdb5, which is why you’re getting the old boot
>> menu.

> Exactly. How do I fix it?

>> …[interesting stuff]…

> None of that helps with: How do I update the MBR to point to the correct
> boot?

Somebody who knows Grub2, or some web HOWTO, will need to provide a
definitive answer how to do so from cmdline, but I believe you should be able
to get YaST to do it by simultaneously selecting both boot from root and boot
from other -> sda (MBR of first BIOS disk). Alternatively, selecting only
boot from sda ought to work, but that would produce a more difficult to solve
failure if sda went AWOL.

The wise are known for their understanding, and pleasant
words are persuasive.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata *** http://fm.no-ip.com/