Apparently the only reason /dev/sda is in the computer at all is because it has the MBR on it. Hmm, maybe not: It is an LVM volume, /dev/system?
How do I change the location of the MBR to another disk, say /dev/sdb?
On 2014-08-19 03:36 (GMT) jimoe666 composed:
> Apparently the only reason /dev/sda is in the computer at all is because
> it has the MBR on it. Hmm, maybe not: It is an LVM volume, /dev/system?
Is there anything in 13.1’s fstab mounting anything on it?
> How do I change the location of the MBR to another disk, say /dev/sdb?
Every disk that needs to have the boot process initiated by the BIOS needs an
MBR. You can’t do away with the need, or change its location on a given disk.
BIOS code boots a computer by loading the MBR of the first BIOS HD and
letting whatever code lies there take control. To use a different MBR for
controlling boot requires making a different disk be the first BIOS HD.
Options for doing that include recabling, eliminating a disk, and using the
BIOS either via setup or a boot time menu to rearrange disk order logically,
making a particular disk be treated as physical BIOS first HD.
Whether your current sdb7 is to be switched to be sda7 or sdc7 or not
switched at all, whichever disk is sda will have to have MBR code that does
the job you need done. You could simplify a bit by converting the current sdb
into sda via cable switching, but you’d still need code on sda’s MBR to get
the boot process pointed in the right direction, either installing only to
sda, or installing to both sda and sdX7. As long as you’re not sure why you
have sda at all, and not multibooting, I’d shuffle disks so that the current
sdb becomes sda, then install Grub at least to sda.
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/
Drop to SuperUser Terminal.
Give me the output (in code tags) of:
fdisk -l
and
parted -l
Go into Yast, launch the Partitioner app (but at this point do not change anything in there).
In the left panel, select Hard Disks
Get a screenshot showing all of the right panel. If it is cut off, move the slider and get a 2nd screenshot of the remainder.
Post the screenshot(s) at SUSE Paste (<= that is a link) and provide a link to the screenshots.
I am off to bed now, I will look in when I get up.
Well, just re-installing the boot loader by entering YaST->Boot Loader and pressing OK should take care of that if it is configured to boot from the MBR.
But apparently it isn’t, although once upon a time grub2 has been installed to the MBR obviously.
At least one of those things should “fix” it then:
- enable “Boot from Master Boot Record” in YaST->Boot Loader, the “new” grub2 (with references to the /root partition should now be written to the MBR as well, replacing the old one that reads grub.cfg from that separate partition.
- make sure “write generic boot code to MBR” is enabled in “Boot Loader Options”, but I’m not sure whether this would really wipe out your MBR and replace it with a generic one.
- run “sudo grub2-install /dev/sda”, this would freshly install grub to the MBR (ignoring the respective configuration in YaST), similar to #1.
On 2014-08-19 11:06, wolfi323 wrote:
>
> mrmazda;2660096 Wrote:
>> I don’t remember anything in this thread discussing fixing MBR of sda
> Well, just re-installing the boot loader by entering YaST->Boot Loader
> and pressing OK should take care of that if it is configured to boot
> from the MBR.
> But apparently it isn’t, although once upon a time grub2 has been
> installed to the MBR obviously.
>
> At least one of those things should “fix” it then:
> - enable “Boot from Master Boot Record” in YaST->Boot Loader, the “new”
> grub2 (with references to the /root partition should now be written to
> the MBR as well, replacing the old one that reads grub.cfg from that
> separate partition.
> - make sure “write generic boot code to MBR” is enabled in “Boot Loader
> Options”, but I’m not sure whether this would really wipe out your MBR
> and replace it with a generic one.
> - run “sudo grub2-install /dev/sda”, this would freshly install grub to
> the MBR (ignoring the respective configuration in YaST), similar to #1.
But there is a complication:
BIOS boots sda, apparently, which has grub on MBR. And then it, using
the /boot partition on that same disk, boots Linux which is on sdb
(different disk).
So I would endeavour to find out if there is anything in sda that is
used, and then tell the bios to boot from sdb instead, configuring that
sdb to boot, probably by installing grub in the MBR of sdb, and
considering that root is in a logical partition. There are no primaries
in that disk.
So first step: what is in sda? In the LVM?
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Yes.
So installing grub2 there again with reference to the new /boot “should just work” ™.
Grub2 can access other drives/partitions…
The MBR in sda is doing an unwanting thing anyway, so there’s no problem if it gets lost IMHO.
So I would endeavour to find out if there is anything in sda that is
used, and then tell the bios to boot from sdb instead, configuring that
sdb to boot, probably by installing grub in the MBR of sdb, and
considering that root is in a logical partition. There are no primaries
in that disk.
Would also be possible of course.
You should change the drive order in YaST (“Installation Details”) then as well accordingly, btw, this would affect to which driver it installs grub2 when told to install it to the MBR.
OTOH, if sdb’s MBR only contains generic boot code, I would just let YaST do its thing then without changing it to install to the MBR.
If sda is simply a data disk it should not be sda but sdb the it is much simpler to set things up on a single boot disk and mount the data disk as needed. You are seeming haveing a problem dealing with a two drive boot. Easy way to do it is to switch the cable. If you must keep this disk configuration then you need a /boot on sda
If you use yast to update grub be sure to pay attention to where the grub code is going to be installed it may not be whee you expect
I am guessing this has been the MBR update problem on /dev/sda. Although I am confused by the “btrfs” reference; /dev/sda is formatted with ext3.
$ grub2-install /dev/sda
/usr/sbin/grub2-bios-setup: warning: your core.img is unusually large. It won't fit in the embedding area.
/usr/sbin/grub2-bios-setup: error: filesystem `btrfs' doesn't support blocklists.
However, this went well:
$ grub2-install /dev/sdb
Installation finished. No error reported.
And I now have a bootable MBR on /dev/sdb. Yay! I can adjust the boot order in the BIOS and verify it is what I want when that system becomes available later today.
Fraser_Bell requested these:
$ fdisk -l
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
Disk label type: dos
Disk identifier: 0x0003bd17
Device Boot Start End Blocks Id System
/dev/sda1 * 63 144584 72261 83 Linux
/dev/sda2 4209030 46154744 20972857+ 8e Linux LVM
/dev/sda3 46154745 488392064 221118660 8e Linux LVM
/dev/sda4 144585 4209029 2032222+ 8e Linux LVM
Partition table entries are not in disk order
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
Disk label type: dos
Disk identifier: 0x0000c1c1
Device Boot Start End Blocks Id System
/dev/sdb1 2048 490233855 245115904 f W95 Ext'd (LBA)
/dev/sdb5 4096 321535 158720 83 Linux
/dev/sdb6 323584 4530175 2103296 82 Linux swap / Solaris
/dev/sdb7 4532224 88422399 41945088 83 Linux
/dev/sdb8 88424448 490207231 200891392 83 Linux
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
Disk label type: dos
Disk identifier: 0x0001999b
Device Boot Start End Blocks Id System
/dev/sdc1 16065 488392064 244188000 83 Linux
Disk /dev/mapper/system-home: 26.8 GB, 26843545600 bytes, 52428800 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
Disk /dev/mapper/system-root: 21.5 GB, 21474836480 bytes, 41943040 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
Disk /dev/mapper/system-swap: 2147 MB, 2147483648 bytes, 4194304 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
$ parted -l
Model: ATA Hitachi HDT72502 (scsi)
Disk /dev/sda: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 32.3kB 74.0MB 74.0MB primary ext3 boot, type=83
4 74.0MB 2155MB 2081MB primary lvm, type=8e
2 2155MB 23.6GB 21.5GB primary lvm, type=8e
3 23.6GB 250GB 226GB primary reiserfs lvm, type=8e
Model: ATA Maxtor 6L250S0 (scsi)
Disk /dev/sdb: 251GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 1049kB 251GB 251GB extended lba, type=0f
5 2097kB 165MB 163MB logical ext4 type=83
6 166MB 2319MB 2154MB logical linux-swap(v1) type=82
7 2320MB 45.3GB 43.0GB logical btrfs type=83
8 45.3GB 251GB 206GB logical btrfs type=83
Model: ATA ST3250318AS (scsi)
Disk /dev/sdc: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 8225kB 250GB 250GB primary ext3 type=83
Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/system-root: 21.5GB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Number Start End Size File system Flags
1 0.00B 21.5GB 21.5GB ext3
Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/system-swap: 2147MB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Number Start End Size File system Flags
1 0.00B 2147MB 2147MB linux-swap(v1)
Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/system-home: 26.8GB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Number Start End Size File system Flags
1 0.00B 26.8GB 26.8GB ext3
From Yast::System Partitioner
Device Size | F|Enc|Type |FS Type |Label|Mount Point |Start| End
/dev/sda | 232.89 GB | Hitachi-HDT72502| | | | 0|30400
/dev/sda1 | 70.57 MB | Linux native | Ext3 | | | 0| 8
/dev/sda2 | 20.00 GB | Linux LVM | | | | 262| 2872
/dev/sda3 | 210.88 GB | Linux LVM | | | | 2873|30400
/dev/sda4 | 1.94 GB | Linux LVM | | | | 9| 261
/dev/sdb | 233.76 GB | Maxtor-6L250S0 | | | | 0|30514
/dev/sdb1 | 233.76 GB | Extended | | | | 0|30514
/dev/sdb5 | 155.00 MB | Linux native | Ext4 | | | 1| 20
/dev/sdb6 | 2.01 GB | Linux swap | Swap | | swap | 20| 281
/dev/sdb7 | 40.00 GB | Linux native | BtrFS | | / | 282| 5504
/dev/sdb8 | 191.58 GB | Linux native | BtrFS | | /home | 5504|30513
/dev/sdc | 232.89 GB | ST3250318AS | | | | 0|30400
/dev/sdc1 | 232.88 GB | Linux native | Ext3 | | /data01 | 1|30400
No.
/dev/sda is definitely not formatted with ext3. 
/dev/sda doesn’t have any filesystem at all, it is your (first) hard disk, not a partition.
$ grub2-install /dev/sda /usr/sbin/grub2-bios-setup: warning: your core.img is unusually large. It won't fit in the embedding area. /usr/sbin/grub2-bios-setup: error: filesystem `btrfs' doesn't support blocklists.
It tries to save the core.img to your / partition (to /boot). And this is btrfs.
Why the core.img would be unusually large and won’t fit in the embedding area I don’t know though.
And it’s even more strange that it worked the second time…
Just be aware that you have /boot now on a btrfs partition, and grub2’s btrfs support is not complete yet.
In particular it doesn’t have write support, so don’t use “grub2-boot-once” to set a boot entry for the next boot, do not use KDE’s “boot entry selection” feture when selecting Restart, and do not hibernate, as grub2 cannot reset that selection any more. All of that will make you lose your boot menu.
If it does happen, remove the file /boot/grub2/grubenv to restore it.
However, this went well:
$ grub2-install /dev/sdb Installation finished. No error reported.
And I now have a bootable MBR on /dev/sdb. Yay! I can adjust the boot order in the BIOS and verify it is what I want when that system becomes available later today.
This might have been unnecessary. If sdb only contained generic boot code, it would have been enough to just change the order in the BIOS.
Your problems are now clear.
sdb is combined ext4 and BTRFS, None of sda is mounted. The only mount points are swap, root & home (on sdb) and data01 on sdc.
You should make sure everything is backed up. Best bet would be to back up each partition on sdb separately, so they can be restored individually.
You should change drive positioning on the cables and/or change the jumpers so the first drive in your PC is the one that is currently sdb. Then set up your BIOS appropriately.
Personally, with what I see, I would do a fresh install, but I am going to assume you do not want to do that, so:
It would be best if you clear the drive (currently sdb) after backup and recreate your partitioning scheme, making certain that root (/) and /home are at least the same size as they are now, or larger. From the sounds of it, I think you would be better off with a generic MS-DOS partition table and ext4, but if you want to stick to BTRFS, that is up to you. Just start studying, then.
Once a clean partitioning scheme has been created, then restore your partition backups one at a time.
Re-install Grub to the same drive (when switching it around earlier, it should now be sda instead of sdb). You can either install Grub to the MBR, or you could install Grub to the root partition. If you install it to the root partition, you should make certain the root partition is set with the boot flag.
Of course, Wolfi will likely disagree with me, but …
Good luck.
On 2014-08-19 18:36 (GMT) wolfi323 composed:
> Why the core.img would be unusually large and won’t fit in the embedding
> area I don’t know though.
The “unusually large” message is a Grub2 misleader, IIRC. Its common >32k
size is too large to fit the 31k boot track of typical partitioning on pre-4k
sector disks. Disks partitioned on his circa 2009 vintage disks likely used
an older partitioner that didn’t care (and possibly didn’t know) about
“advanced format” (4k) sectors, or 4k compatible partitioning.
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/
Hm, it’s 28k here:
:~> ls -lh /boot/grub2/i386-pc/core.img
-rw-r--r-- 1 root root 28K 14. Mär 16:27 /boot/grub2/i386-pc/core.img
:~> ls -l /boot/grub2/i386-pc/core.img
-rw-r--r-- 1 root root 27856 14. Mär 16:27 /boot/grub2/i386-pc/core.img
Maybe the EFI one is bigger? (but the OP should have MBR booting IIRC)
Otherwise your explanation sounds plausible though. It is embedded into the gap after the MBR, before the first partition, right?
So it was embedded on /dev/sdb on the second call, where the first call tried to embed it on /dev/sda, which apparently had a too small gap.
Anyway, I would not recommend to use /boot on a btrfs partition, because of the shortcomings of grub2’s btrfs support.
One of them is the missing blocklist support ( https://bugzilla.novell.com/show_bug.cgi?id=841247 ), the other one missing write support (as already mentioned, Access Denied and Access Denied), and then there’s this:
Access Denied
It should work though, as long as you don’t set a temporary default boot entry. I’m using it on one of my systems since November.
@Fraser_Bell: No, I do not completely disagree with you…
On 2014-08-20 08:16 (GMT) wolfi323 composed:
> mrmazda Wrote:
>> On 2014-08-19 18:36 (GMT) wolfi323 composed:
>> > Why the core.img would be unusually large and won’t fit in the embedding
>> > area I don’t know though.
>> The “unusually large” message is a Grub2 misleader, IIRC. Its common 32k
>> size is too large to fit the 31k boot track of typical partitioning onpre-4k
>> sector disks.
> Hm, it’s 28k here:
Your system is probably simpler than OP’s, who has:
3 disks
LVM (sda2, sda3, sda4)
EXT3 (sda1, sdc1)
EXT4 (sdb5)
BTRFS (sdb7, sdb8)
No native primaries on sdb (which has the 13.1 installation)
Doing some Googling on the issue of core.img size it seems clear that the
more complicated the partitioning, the larger core.img tends to be, and the
less likely its size will fit within the at most 62 available 512 byte boot
track sectors common to older partitioning schemes like the OP has on sda.
All discussion I found on the issue seemed to be on Arch, Fedora, *buntu and
other pages than on opensuse.org, but see e.g.
http://forums.fedoraforum.org/showthread.php?t=274701 generally even though
RAID rather than LVM seems to be the size barrier breaker.
…
> Otherwise your explanation sounds plausible though. It is embedded into
> the gap after the MBR, before the first partition, right?
That is the upstream Grub2 mantra, but what yast did during 13.1 installation
I’m not going to venture a guess. Someone interested might be able to poke
through OP’s y2logs and find out. The partitioning on sdb is perplexing to
me. Discussing further why it is what it is seems pointless. OP just needs a fix.
The most expedient fix to me seems obvious, shuffle things via cabling or
BIOS so that the operating system disk is BIOS HD0, aka sda, then reinstall
Grub to MBR or EXT partition on it.
The optimal fix would involve both the relocation and complete repartitioning
of and reinstallation on the physical 13.1 disk.
Another fix would be to restore the original 13.1 mount scheme, then
uninstall Plymouth to free up space in /boot for kernels and initrds, and
finally rebuild the existing initrds, though IIRC booting from sdb5 has since
been broken and Grub would still need to be reinstalled as yast did it for
13.1 originally.
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 17:56, wolfi323 wrote:
> OTOH, if sdb’s MBR only contains generic boot code, I would just let
> YaST do its thing then without changing it to install to the MBR.
Careful, generic MBR can not boot logical partitions, as those in sdb.
(see the sdb table he posted somewhere here)
You have to mark as bootable the extended partition (which is a primary,
after all), install grub there, which then loads the root partition
which is a logical one.
This is a typical setup on dual boot machines (because Windows is
already using 3 primaries) and the only other one left is the extended.
It is atypical on the OP case, because sda2, 3, 4, do not exist.
And some people strongly dislike having grub on the extended partition.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
That’s true, yes.
But at the time I wrote this I thought there is only one core.img that is installed by the grub2 package.
Now I saw that this is not owned by the package.
Still, I’m not sure.
Shouldn’t grub2 just read that from /boot?
Why would that file be stored in /boot otherwise?
It still has to embed the code to read that though.
So maybe that code was too big.
Well, I don’t know, at least not all details.
And I don’t have the will and time to research that at the moment…
You’re right.
I didn’t remember all the details when I wrote this.
But I thought YaST (or perl-bootloader) should take care of this, and install the grub2 code to the active partition (which doesn’t have to be /, but could be a different, primary/logical, one).
But now I had a look again, and the OP doesn’t have any active partition on sdb. So it wouldn’t have worked probably.
OTOH, YaST->Boot Loader does have an option to mark the corresponding partition as active, which is enabled by default.
Moot now anyway, as he did install grub2 to the MBR of sdb…
> grub2-install /dev/sdb
>
> And I now have a bootable MBR on /dev/sdb. Yay!
> I can adjust the boot order in the BIOS and verify it is
> what I want when that system becomes available later today.
>
That worked. I updated the BIOS to only check the disk (that is later assigned /dev/sdb) for the bootstrap loader.
I now have spare disk drive with which to amuse myself…
$ ll -h /boot/grub2/i386-pc/core*
-rw-r--r-- 1 root root 38K Aug 19 10:55 /boot/grub2/i386-pc/core.img
Yes, a bit larger than 32K.
On 2014-08-20 18:36 (GMT) wolfi323 composed:
> I had a look again, and the OP doesn’t have any active partition
> on sdb. So it wouldn’t have worked probably.
> OTOH, YaST->Boot Loader does have an option to mark the corresponding
> partition as active, which is enabled by default.
No active flag has any relevance to:
1-Grub Legacy
2-Grub2
3-Linux kernel
The purpose the active flag serves, AFAIK, is exclusively to signal
legacy-compatible MBR code which primary partition shall be given boot control.
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-20 20:26 (GMT) jimoe666 composed:
>> grub2-install /dev/sdb
>> And I now have a bootable MBR on /dev/sdb. Yay!
>> I can adjust the boot order in the BIOS and verify it is
>> what I want when that system becomes available later today.
> That worked. I updated the BIOS to only check the disk (that is later
> assigned /dev/sdb) for the bootstrap loader.
> I now have spare disk drive with which to amuse myself…
For sure sda, but how is it now a spare if it wasn’t already? If you mean it
contains nothing important, you could fix that by installing Factory on it
and becoming an openSUSE tester. 
Anyway, congratulations that the pain appears to be over. 
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/
That’s true.
But it has relevance for the generic boot loader code in the MBR.
The purpose the active flag serves, AFAIK, is exclusively to signal
legacy-compatible MBR code which primary partition shall be given boot control.
No.
The generic boot loader code in the MBR loads the actual boot loader from the active partition.
I.e. it looks for the active partition, loads its PBR and jumps into the code.
So to be able to boot with generic code in the MBR, there has to be an active partition that contains the actual boot loader code.