Core doesn't update mbr grub

spaceman · posted: 2016-07-02 17:03

I can issue sudo update-grub all day but it doesn't effect the MBR grub menu. I have to boot into Xubuntu and fiddle in grub-customizer.

Suggestion about where to start troubleshooting this as teh search engines have failed me (again).

anticapitalista · posted: 2016-07-02 17:27

Did you install grub to MBR when installing core?
If you didn't then you have to run update-grub from the OS that controls grub.

I just installed core (in VB), installed grub to MBR, rebooted, installed the latest 4.6.2 kernel and update-grub works as expected

spaceman · posted: 2016-07-02 18:00

Yes, I do install GRUB to MBR when I install (I actually belt and braces do Y and enter).

Is this because of having more than one hard drive and or several several distros? Just throwing it out there.

anticapitalista · posted: 2016-07-02 18:03

Does update-grub not pick up any new kernels in antiX-core? Or doesn't it pick up kernel changes on another partition/drive?

spaceman · posted: 2016-07-02 18:39

Code: Select all

sudo update-grub
Generating grub configuration file ...
Found background: /usr/share/wallpaper/back.jpg
Found background image: /usr/share/wallpaper/back.jpg
Found linux image: /boot/vmlinuz-4.4.10-gnu-antix.1-amd64-smp
Found initrd image: /boot/initrd.img-4.4.10-gnu-antix.1-amd64-smp
Found memtest86+ image: /boot/memtest86+.bin
Found memtest86+ multiboot image: /boot/memtest86+_multiboot.bin
Found Fedora release 23 (Twenty Three) on /dev/sda10
Found Ubuntu 16.04 LTS (16.04) on /dev/sda5
Found Debian GNU/Linux (stretch/sid) on /dev/sda6
Found antiX 15 (15) on /dev/sda7
done

Which is nice, then you reboot and the GRUB menu is unchanged. __{{emoticon}}__

So I pick Xubuntu on sda5 and open up Grub-customizer and change environment to antiX on sda8 simplest thing to do is save this config then use grub-customizer to write to the MBR and reboot and carry on as normal. I've been experiencing this for several iterations of antiX but let it slide as I have a workaround (and we've all got stuff to get on with). I thought I'd just point this out (and the sources.list issue) to squash a couple of paper cut bugs. __{{emoticon}}__

anticapitalista · posted: 2016-07-02 19:30

Post the contents of /boot/grub/grub.cfg on core after you have done an update-grub

Dave · posted: 2016-07-03 02:30

Multiple disks?
Xubuntu?

I do not see anything in the grub upgrade from antix that shows anything about another disk, nor the presence of Xubuntu. Perhaps antix is installed to the mbr of what is seen by antix as sda and does indeed update it, however because it is not set in the bios as the primary boot disk? I mean is sda the same drive in xubuntu as is in antiX? Maybe a blkid will tell. I have a feeling that possibly antix sda = bios disk2 and xubuntu sda = bios disk1?

spaceman · posted: 2016-07-03 09:47

Good call Dave, I kicked around that idea for a while, I even tried booting off these two other drives to check..

Code: Select all

$ blkid
/dev/sda2: UUID="30c590a1-20b9-4b1f-b985-b4771bd04aae" TYPE="swap" PARTUUID="b89497ef-02"
/dev/sda5: UUID="39a8ef8e-007f-4615-b8f2-80f3b27f2192" TYPE="ext4" PARTUUID="b89497ef-05"
/dev/sda6: UUID="fb88d313-f0a7-45dc-bbab-ba2e07256346" TYPE="ext4" PARTUUID="b89497ef-06"
/dev/sda7: LABEL="antiX MX-15" UUID="1ee5c3ed-d2fd-48e4-96ce-77e52439be62" TYPE="ext4" PARTUUID="b89497ef-07"
/dev/sda8: LABEL="antiX Core 16" UUID="41bed77e-d0be-444a-96e9-99f8464f0217" TYPE="ext4" PARTUUID="b89497ef-08"
/dev/sda9: UUID="b5abc6b8-a1ea-448e-91ae-b0e7ee18d4e4" TYPE="ext4" PARTUUID="b89497ef-09"
/dev/sda10: LABEL="Fedora 23" UUID="52b39609-5c46-40e9-9ff6-6fbb1c4e6ecd" TYPE="ext4" PARTUUID="b89497ef-0a"
/dev/sda11: UUID="d2e62af7-4b63-4da5-8e3b-ee15f37c4c3a" TYPE="ext4" PARTUUID="b89497ef-0b"
/dev/sdb2: LABEL="Store" UUID="2065af80-2d6c-47a2-9313-b5a074b75134" TYPE="ext4" PARTUUID="9e3ef936-02"
/dev/sdb3: LABEL="Games" UUID="726ee618-8eba-424f-9d85-a80714683c44" TYPE="ext4" PARTUUID="9e3ef936-03"
/dev/sdc1: LABEL="VM" UUID="9f6413c7-905b-4eca-9842-a080415b6657" TYPE="ext4" PARTUUID="c47a1027-01"
/dev/sdc2: LABEL="LocalBackup" UUID="f6d73b88-615f-4c8f-90a4-89ac85c7edce" TYPE="ext4" PARTUUID="c47a1027-02"

In the same way that grub-update will identify antiX as Debian from other distros, Xubuntu is always Ubuntu, Xubuntu is installed on sda5. antiX: sda8, MX-15 sda7...hmmm...all extended partitions... __{{emoticon}}__

$dmesg...

Code: Select all

[ 1045.161193] REISERFS warning (device sda1): sh-2006 read_super_block: bread failed (dev sda1, block 8, size 1024)
[ 1045.161198] REISERFS warning (device sda1): sh-2006 read_super_block: bread failed (dev sda1, block 64, size 1024)
[ 1045.161200] REISERFS warning (device sda1): sh-2021 reiserfs_fill_super: can not find reiserfs on sda1
[ 1045.162150] EXT4-fs (sda1): unable to read superblock
[ 1045.163087] EXT4-fs (sda1): unable to read superblock
[ 1045.163995] EXT2-fs (sda1): error: unable to read superblock
[ 1045.164879] SQUASHFS error: squashfs_read_data failed to read block 0x0
[ 1045.164881] squashfs: SQUASHFS error: unable to read squashfs_super_block
[ 1045.165823] FAT-fs (sda1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
[ 1045.165968] FAT-fs (sda1): bogus number of reserved sectors
[ 1045.165970] FAT-fs (sda1): Can't find a valid FAT filesystem
[ 1045.166857] FAT-fs (sda1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
[ 1045.166997] FAT-fs (sda1): bogus number of reserved sectors
[ 1045.166999] FAT-fs (sda1): Can't find a valid FAT filesystem
[ 1045.167920] isofs_fill_super: bread failed, dev=sda1, iso_blknum=16, block=32
[ 1045.207543] UDF-fs: error (device sda1): udf_read_tagged: read failed, block=256, location=256
[ 1045.207960] UDF-fs: error (device sda1): udf_read_tagged: tag version 0x0000 != 0x0002 || 0x0003, block 0
[ 1045.207970] UDF-fs: error (device sda1): udf_read_tagged: read failed, block=512, location=512
[ 1045.207977] UDF-fs: error (device sda1): udf_read_tagged: tag version 0x0000 != 0x0002 || 0x0003, block 0
[ 1045.207978] UDF-fs: error (device sda1): udf_read_tagged: tag version 0x0000 != 0x0002 || 0x0003, block 0
[ 1045.207980] UDF-fs: warning (device sda1): udf_load_vrs: No anchor found
[ 1045.207981] UDF-fs: Rescanning with blocksize 2048
[ 1045.208004] UDF-fs: error (device sda1): udf_read_tagged: read failed, block=256, location=256
[ 1045.208006] UDF-fs: error (device sda1): udf_read_tagged: read failed, block=512, location=512
[ 1045.208007] UDF-fs: warning (device sda1): udf_load_vrs: No anchor found
[ 1045.208008] UDF-fs: warning (device sda1): udf_fill_super: No partition found (1)
[ 1045.210656] XFS (sda1): Invalid superblock magic number
[ 1045.217325] MINIX-fs: unable to read superblock
[ 1045.218262] attempt to access beyond end of device
[ 1045.218264] sda1: rw=16, want=3, limit=2
[ 1045.218266] hfsplus: unable to find HFS+ superblock
[ 1045.219372] qnx4: no qnx4 filesystem (no root dir).
[ 1045.220278] ufs: You didn't specify the type of your ufs filesystem

mount -t ufs -o ufstype=sun|sunx86|44bsd|ufs2|5xbsd|old|hp|nextstep|nextstep-cd|openstep ...

>>>WARNING<<< Wrong ufstype may corrupt your filesystem, default is ufstype=old
[ 1045.221226] hfs: can't find a HFS filesystem on dev sda1

Urrgghh...that looks ugly. I had hope that wiping and reconfiguring the drive (not needing a static Windows partition any more) would resolve these kinds of errors...that I've only actually seen in antiX. sda1 does not hold a HFS filesystem, sda1 is an extended partition to hold the logical partitions will all my distros installed...

Oh and sorry Anti, I got distracted (it's easily done)...

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://pastebin.com/nbPKcKKe"
linktext was:"grub.cfg"
====================================

dolphin_oracle · posted: 2016-07-03 12:40

is the grub-install command in the cli-installer correct? it doesn't use a"boot-directory" switch, but rather a"root-directory" switch. I'll confess that I don't know the ends and outs of the grub-install, but the command in the graphical installer is different.

spaceman · posted: 2016-07-03 13:29

The ugly filesystem output is"purely cosmetic" it's a bug in
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772526"
linktext was:"os-prober"
====================================
(which those baskets over at Ubuntu have fixed) and is still present in Debian (stretch) v1.71 (I tested it.) Essentially the message is correct and you would not expect an extended partition container to have a filesystem...

I think the problem could go back to what cli-installer invokes. I now have grub updating a treat only issuing update-grub but I had to issue grub-install --recheck /dev/sda (not sure if --recheck is necessary) first. If the grub doesn't think it's installed to the MBR then it is behaving correctly only updating the root partition and not touching the MBR. Dolphin_Oracle has called it first. __{{emoticon}}__