Bug#724756: grub-pc: Latest version of grub produces a core.img that is too large to install.

2013-12-10 Thread Michael Lustfield
On Tue, Dec 10, 2013 at 1:09 PM, Colin Watson cjwat...@debian.org wrote:

 On Tue, Dec 10, 2013 at 12:45:41PM -0600, Michael Lustfield wrote:
  On Tue, Nov 12, 2013 at 8:47 PM, Colin Watson cjwat...@debian.org
 wrote:
   Note that systems that were installed with modern versions of the
 Debian
   installer aren't affected by this bug, since that aligns the first
   partition to a 1MB boundary by default; this is actually a good idea
 for
   performance reasons too so I recommend you look into converting your
   systems to that if at all possible since this isn't an easy bug to fix
   in any other way.
 
  How can I convert an installed system to that? This image was created
 with
  a recent (at the time) Debian installer. Right now, I have to use a super
  grub2 boot disk to boot the servers.

 You have to use something like gparted from a live CD to move the
 partitions around.  This is inherently risky and requires taking backups
 first, unfortunately.

   I agree this is a real problem, though.  Could I please see the exact
   size in bytes of /boot/grub/i386-pc/core.img so that I can make sure
 I'm
   comparing the right thing?  I don't get quite the same figures as you
 in
   my local tests, and for this kind of thing every byte matters.
 
  # du /boot/grub/i386-pc/core.img
  34/boot/grub/i386-pc/core.img

 That's kilobytes, not bytes.  Try this instead:

   ls -l /boot/grub/i386-pc/core.img


Sorry, I forgot to reply to the bug too.

It's 33106 bytes.


Bug#724756: grub-pc: Latest version of grub produces a core.img that is too large to install.

2013-11-12 Thread Colin Watson
On Fri, Sep 27, 2013 at 09:46:56AM -0500, Michael Lustfield wrote:
 After upgrading to the latest version of grub-pc in Debian jessie, th core.img
 file went from 32K to 36K. This makes it no longer possible to install grub to
 the MBR. It seems that some of the modules are significantly larger than they
 should be and this is making it impossible to install grub to what seems to be
 a very common setup. The only thing extra I'm using is LVM. Adding RAID and 
 LVM
 support should still keep core.img under the 32K limit. This is an issue on
 over 400 systems for me, so just moving the first partition over and doing a
 --force will not be an option, nor should it be required.

Note that systems that were installed with modern versions of the Debian
installer aren't affected by this bug, since that aligns the first
partition to a 1MB boundary by default; this is actually a good idea for
performance reasons too so I recommend you look into converting your
systems to that if at all possible since this isn't an easy bug to fix
in any other way.

I agree this is a real problem, though.  Could I please see the exact
size in bytes of /boot/grub/i386-pc/core.img so that I can make sure I'm
comparing the right thing?  I don't get quite the same figures as you in
my local tests, and for this kind of thing every byte matters.

It looks to me as though we're still a bit over the limit for
biosdisk+ext2+part_msdos+lvm with a current upstream build, although
only by 409 bytes rather than 1394 in my test system (2.00-18).  Adding
mdraid1x brings it up to 896 bytes with current upstream and 1394 with
2.00-18.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#724756: grub-pc: Latest version of grub produces a core.img that is too large to install.

2013-09-27 Thread Michael Lustfield
Package: grub-pc
Version: 2.00-19
Severity: important

Dear Maintainer,


After upgrading to the latest version of grub-pc in Debian jessie, th core.img
file went from 32K to 36K. This makes it no longer possible to install grub to
the MBR. It seems that some of the modules are significantly larger than they
should be and this is making it impossible to install grub to what seems to be
a very common setup. The only thing extra I'm using is LVM. Adding RAID and LVM
support should still keep core.img under the 32K limit. This is an issue on
over 400 systems for me, so just moving the first partition over and doing a
--force will not be an option, nor should it be required.

Version 1.99-27+deb7u1 did not have this issue (but was close).

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/sys-root / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
/dev/mapper/sys-boot /boot ext2 rw,relatime,errors=continue 0 0
/dev/mapper/sys-home /home ext4 rw,relatime,data=ordered 0 0
/dev/mapper/sys-opt /opt ext4 rw,relatime,data=ordered 0 0
/dev/mapper/sys-var /var ext4 rw,relatime,data=ordered 0 0
/dev/mapper/sys-varlog /var/log ext4 rw,relatime,data=ordered 0 0
/dev/mapper/homedirs-7460 /srv/homedirs/7460 ext4 rw,relatime,data=ordered 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/sda
(hd1)   /dev/sdb
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  load_env
fi
set default=0

if [ x${feature_menuentry_id} = xy ]; then
  menuentry_id_option=--id
else
  menuentry_id_option=
fi

export menuentry_id_option

if [ ${prev_saved_entry} ]; then
  set saved_entry=${prev_saved_entry}
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z ${boot_once} ]; then
saved_entry=${chosen}
save_env saved_entry
  fi
}

function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_msdos
insmod lvm
insmod ext2
set root='lvm/sys-root'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint='lvm/sys-root'  
d19dfc15-d628-44da-a4e7-97269b289293
else
  search --no-floppy --fs-uuid --set=root d19dfc15-d628-44da-a4e7-97269b289293
fi
font=/usr/share/grub/unicode.pf2
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
set timeout=5
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-d19dfc15-d628-44da-a4e7-97269b289293' {
load_video
insmod gzio
insmod part_msdos
insmod lvm
insmod ext2
set root='lvm/sys-boot'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint='lvm/sys-boot'  
89e952f3-c83a-4911-bab9-7c8f5a1b8228
else
  search --no-floppy --fs-uuid --set=root 
89e952f3-c83a-4911-bab9-7c8f5a1b8228
fi
echo'Loading Linux 3.10-3-amd64 ...'
linux   /vmlinuz-3.10-3-amd64 root=/dev/mapper/sys-root ro  quiet
echo'Loading initial ramdisk ...'
initrd  /initrd.img-3.10-3-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-d19dfc15-d628-44da-a4e7-97269b289293' {
menuentry 'Debian GNU/Linux, with Linux 3.10-3-amd64' --class debian 
--class gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-3.10-3-amd64-advanced-d19dfc15-d628-44da-a4e7-97269b289293' {
load_video
insmod gzio
insmod part_msdos
insmod lvm
insmod ext2
set root='lvm/sys-boot'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint='lvm/sys-boot' 
 89e952f3-c83a-4911-bab9-7c8f5a1b8228
else
  search --no-floppy --fs-uuid --set=root 
89e952f3-c83a-4911-bab9-7c8f5a1b8228
fi
echo'Loading Linux 3.10-3-amd64 ...'
linux   /vmlinuz-3.10-3-amd64 root=/dev/mapper/sys-root ro