Re: Dell BIOS issue reading Disk Extended data

2021-03-31 Thread Jordan Uggla 
This should *not* be made default because grub's native drivers don't
get very much testing, and they do cause grub to hang on some
hardware, but you can likely get around this limitation with:

grub-install --target=i386-pc --disk-module native /dev/sdX

If you want to test it without installing grub in this way to your
primary drive(s), you can boot from a grub USB and run "nativedisk" at
the grub shell. This will switch from firmware based disk access to
entirely grub native driver access (while accounting for the device
name changes and updating $prefix accordingly). For safety reasons,
this will disable firmware based access to all drives.

This works by including grub's native drivers in the embedded
core.img. For GPT disks (or arrays), which I assume you're using with
8TB capacity, grub's core.img is embedded in the BIOS Boot Partition.
As long as the BIOS Boot Partition is within 2TB of the beginning of
the disk (usually, it's just the first partition, and is 1MiB large)
you'll be able to load it just fine through INT13 and from that point
on (if your hardware is supported) you'll no longer be depending on
the boot firmware or be affected by its disk access bugs.


On Wed, Mar 31, 2021 at 7:45 AM Guilherme Piccoli
 wrote:
>
> On Tue, Mar 30, 2021 at 2:43 PM K, Narendra  wrote:
> > > On Fri, Jan 22, 2021 at 3:41 PM Limonciello, Mario
> > >  wrote:
> > > >
> > > > >
> > > > > Hello Dell folks, I'm Guilherme Piccoli from Canonical - first of
> > > > > all, apologies for the out-of-nowhere communication. We've been
> > > > > investigating an issue that seems to date long time ago, and
> > > > > eventually we could narrow it to what appears to be a Dell BIOS bug.
> > > > > Notice I'm also looping a kernel x86 ML and grub-devel, just for the
> > > > > purpose of archiving such discussion in public lists, to help others
> > > > > that may find such an issue in the future.
> > > > >
> > > > > Since I don't have contacts of Dell representatives, I've just
> > > > > raised a list of people from Dell contributing to kernel in the last
> > > > > 2 years - maybe one of you could point me towards the path of a
> > > > > proper contact/channel to discuss such an issue. If not, I'm sorry 
> > > > > for the
> > > noise.
> > > > > Let me detail the problem we're observing - notice all of this is
> > > > > about legacy BIOS mode, not UEFI.
> > > >
> > > > Most of the guys you CC'ed from Dell work on client related things,
> > > > not servers.  So I'll move some of the client guys off of this thread 
> > > > into BCC.
> > > > @K, Narendra can you please raise this with the appropriate team?
> > > >
> > >
> > > Thanks Mario and K, Narendra - do we have any news about that?
> > > Cheers,
> >
> > Hi Guilherme,
> >
> > Sorry for the delay in responding.
> >
>
> No problem Narendra K, thanks for your response!
>
> > I checked with the team about the findings shared in this thread. Please 
> > find the details -
> >
> > The behavior seems to be working as designed. Legacy BIOS Option ROM 
> > implements logical block addressing support only up to 2TB.
> > The option ROM will respond with 2TB as the size when queried by INT13h 
> > function 48h. For booting from volumes > 2TB, UEFI is needed.
>
> So, just confirming, Dell doesn't support > 2TB offsets even using the
> extended 64-bit offset from service 48h? I just want to confirm that
> is a support limitation from Dell, I've tested another vendor and that
> works in their machine, I could address > 2TB devices.
>
> In case this is unsupported by Dell, do you have an official
> documentation I can refer, to our customer?
> Thanks again,
>
> Guilherme
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Adding spoken lenguages to the menu

2017-05-31 Thread Jordan Uggla 
es
}

because your menuentry will create a new context with a *copy* of
$lang, will change that copy, then will exit destroying the changed
copy and leaving you back with $lang having a value of "en". Super
GRUB2 Disk works around this by using configfile within the menuentry
to re-load the grub.cfg within the new context. This means that if you
change languages 20 times you will be 21 layers deep in submenus and
contexts (which users will only notice if they press escape to go to
the previous menu, or possibly cause an overflow if they're really
ambitious). I figured that was good enough for SG2D, but it's probably
not good enough for upstream grub. Now that I've said all that, it
looks like $lang may be special in this regard since quick test showed
that such a menuentry actually *did* successfully change the language
used for grub's interface. This may be a bug, or may be me
misunderstanding something.

5: Even if the above weren't the case, I can't see how re-executing
the grub.cfg after a language change can be avoided since you need to
re-run each menuentry command such that the title will expand to the
new different translation.

I don't have a lot of free time at the moment (I shouldn't have spent
it on this message in the first place to be honest) but I'll try to
help when I can and if you want to take code from Super GRUB2 Disk
that I wrote I am willing to say that my copyright assignment to grub
covers that code as well. That said 1: I Am Not A Lawer, 2: Do *not*
copy any code from SG2D or anywhere else without clearly stating where
it came from when you submit it to grub.

I hope that helps and I really hope you're able to add this feature!

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Menu for booting BTRFS snapshots

2017-03-02 Thread Jordan Uggla 
Grub's view of things at boot is necessarily different from the view
from your booted GNU/Linux environment, and indeed if you dual boot
two GNU/Linux OSs they will each mount each other's volumes to
different areas. Presumably /snaps/ is a mountpoint where you have
configured that your btrfs be mounted, with the right mount options
such that you can access your snapshots. Grub's grub.cfg is read
before any OS's fstab, so from grub's point of view "/snaps/" is most
likely just an empty directory. In addition, grub's view of a btrfs
filesystem starts at the top level subvolume so the path to that
"/snaps/" directory from grub is likely /@/snaps/ (though it depends
on the naming scheme you and your distribution have used). You will
most likely notice this when looking at other paths in your grub.cfg
(from parts generated by grub-mkconfig). Thankfully grub has a handy
utility for helping you find the path that grub will need to access a
file at boot, given the path to a file on your booted system:
grub-mkrelpath.

TLDR: If you run "grub-mkrelpath /snaps/rxe-boot/grub2/grub.cfg" you
will get as output the path that grub will need to access your
grub.cfg at boot.


Also, if you're just reading from that grubenv to get a list of
subvolumes, you should know that grub can iterate over files and
directories using for loops and globbing just like bash, and so
(depending on your exact layout of snapshots) you can most likely
dynamically generate a menu with one entry per snapshot. And by
dynamically I don't mean "re-run grub-mkconfig to generate a new
grub.cfg", I mean they can literally be detected at boot by grub using
grub-script.

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)

On Thu, Mar 2, 2017 at 1:40 PM, Robert LeBlanc <rob...@leblancnet.us> wrote:
> I'm trying to add some menuentry items to move between btrfs
> snapshots. I've added the following in the non-snapshot
> /etc/grub.d/40_custom.
>
> menuentry 'RXE Snapshot' {
>load_env -f /snaps/rxe-boot/grub2/grubenv
>configfile /snaps/rxe-boot/grub2/grub.cfg
> }
>
> It loads the config for my RXE snapshot, but in doesn't select the
> default menuentry as specified in the snapshot's grubenv. This makes
> it so that it won't boot automatically into a snapshot kernel (I
> created a 09_header file to add a noop menuentry that tells me I'm
> using the RXE snapshot config and that is what is selected). It
> doesn't matter if load_env is before or after configfile. Other than
> this, it works as expected.
>
> I don't think I can use chainload because it is a 'directory' on the
> btrfs file system.
>
> Any ideas on how to accomplish what I want?
>
> Thank you,
> 
> Robert LeBlanc
> PGP Fingerprint 79A2 9CA4 6CC4 45DD A904  C70E E654 3BB2 FA62 B9F1
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Exercise: Booting from a LiveUSB ISO and contents on /dev/sda6

2015-11-01 Thread Jordan Uggla 
On Mon, Nov 2, 2015 at 3:27 AM, Philip Rhoades  wrote:
> People,
>
> I want to enlarge my root partition on a Fedora 23 x86_64 system and I know
> I can boot on a LiveUSB stick and use [g]parted from there to do what I want
> but I thought I would try creating a small partition with the ISO and its
> contents in it to see if I could do what I want without needing to use the
> USB stick.

Since this is an end user support question, rather than a patch or
discussion about developing grub, it should be posted to
help-g...@gnu.org rather than grub-devel. I have CC'd helo-grub. In
your replies, please include help-grub and *remove* grub-devel from
any further replies. This problem is also actually more Fedora
specific than grub related, as explained below.

>
> The contents of /dev/sda6 is:
>
> dr-xr-xr-x   3 root root   4096 May 22 05:03 EFI
> dr-xr-xr-x   2 root root   4096 May 22 05:05 LiveOS
> dr-xr-xr-x   2 root root   4096 May 22 05:03 isolinux
> drwx--   2 root root  16384 Nov  2 06:08 lost+found
> -r--r--r--   1 root root   2460 May 22 05:04 Fedora-Legal-README.txt
> -rw-r-   1 qemu qemu 1007681536 Oct  7 20:14
> Fedora-Live-Xfce-x86_64-22-3.iso
> -r--r--r--   1 root root   1063 May 22 05:04 LICENSE
>
>
> I have made a little progress but I still can't get a boot - here is the
> current state of the relevant section of my grub2.cfg (I have been trying
> various changes):
>
> menuentry "Fedora 22 XFCE ISO Boot (x86_64 bit)" {
> insmod part_gpt
> set isoname="Fedora-Live-Xfce-x86_64-22-3"
> echo $isoname
> set isofile="${isoname}.iso"
> echo $isofile
> loopback loop (hd0,gpt6)/$isofile
> echo $loop
> linux (loop)/isolinux/vmlinuz0 root=live:CDLABEL=${isoname}
> rootfstype=auto ro rd.live.image rd.luks=0 rd.md=0 rd.dm=0
> iso-scan/filename=${isofile}

iso-scan/filename= is a kernel parameter that Fedora does not support,
as Fedora does not support loop booting (booting from the iso file on
a filesystem rather than burned to a DVD or extracted to a hard
drive). Please file a bug report against Fedora asking them to add
such support, or extract the iso (which you have also done already),
or use a distribution that supports loop booting such as Ubuntu. For
instructions on loop booting an Ubuntu iso (or any other iso which
ships with a loopback.cfg) please see
http://www.supergrubdisk.org/wiki/Loopback.cfg#How_do_you_use_a_loopback.cfg_to_boot_an_iso.3F
.

> initrd (loop)/isolinux/initrd0.img
> }
>
> During the attempted boot I see the first two "echo"s but then get messages
> that "linux" and "initrd" commands do not exist . . is it something simple I
> am missing?

This is a Fedora specific problem, with upstream grub you would not
have this problem. I am not very familiar with Fedora's secure boot
setup, but I suspect that is the reason that the "linux" and "initrd"
commands are not available, and that instead you need to use
"linuxefi" and "initrdefi".

>
> Thanks,
>
> Phil.
> --
> Philip Rhoades
>
> PO Box 896
> Cowra  NSW  2794
> Australia
> E-mail:  p...@pricom.com.au
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Exercise: Booting from a LiveUSB ISO and contents on /dev/sda6

2015-11-01 Thread Jordan Uggla 
On Mon, Nov 2, 2015 at 3:56 AM, Fajar A. Nugraha <l...@fajar.net> wrote:
> IIRC in the past there was a requirement where the loopfile needed to be
> unfragmented? Can't remember the details though.

No such requirement exists for grub's loopback command. That was only
needed for forks of grub legacy that used "map --hook".

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Kernel panics (in QEMU) when booting with GRUB2 + OVMF + QEMU.

2015-08-15 Thread Jordan Uggla 
On Fri, Aug 14, 2015 at 11:29 PM, Andrei Borzenkov arvidj...@gmail.com wrote:
 On 14.08.2015 09:45, Mark Lee wrote:

 To all,

 I've encountered a bug when using GRUB2 + OVMF + QEMU on Arch Linux 64
 bit.
 The issue can be reproduced when running the latest git code from grub as
 well.

 ISSUE: Kernel panics (in QEMU) when booting with GRUB2 + OVMF + QEMU.


 Once kernel is loaded, GRUB task is over. Why do you think it is GRUB issue?

I worked with Mark in #grub and there were symptoms that Mark has not
described here that lead me to believe that there is either a grub or
OVMF bug, and that is why I asked him to post here.

First Mark demonstrated that the same image, with the same version of
grub and same grub.cfg, was succeeding when booted via BIOS with qemu,
but not when booted via OVMF with qemu, and that the particular error
message before the kernel panic was indicative of the initramfs not
having been loaded. Having largely ruled out misconfiguration I asked
Mark to try running the linux and initrd commands manually at the
grub shell to see if there were any error messages being displayed.

Mark did this and replied that while the linux command succeeded, the
initrd command failed, and in a way that clearly indicates a bug
somewhere. Specifically, while Mark entered something like initrd
/boot/initramfs-foo-bar, and everything he had typed was echoed back
to him on screen as expected, the error message he received was (if I
recall correctly) something about the file /boot/initra not being
found. In other words, the error message indicated that somewhere the
file name entered had been truncated. I suspect that this happened
when grub was interpreting the grub.cfg as well, and thus the linux
command succeeded but the initramfs command failed, and while grub
still tried to boot, the missing initramfs resulted in the kernel
panic.This, along with other symptoms from previous tries, seems to
indicate to me that there is memory corruption somewhere, either due
to a bug in grub or in OVMF.

I don't have access to the IRC logs of our conversation today (but I
will have access to them Monday) so I'm going by my memory alone.
Hopefully Mark can give the exact error messages he received from
trying to enter the initramfs command directly, or possibly even
reproduce that test and post screenshots or serial output logs of it.
I have not had a chance to try to reproduce this myself, and I don't
know when I will have time to do so.

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Future of installing GRUB to LVM volumes (and loop devices)

2015-05-16 Thread Jordan Uggla 
On Sat, May 16, 2015 at 7:10 AM, Sebastian Pipping
sebast...@pipping.org wrote:
 On 16.05.2015 05:47, Jordan Uggla wrote:
 The setup is a single plain partition in an LVM volume.

 The following commands reproduce the setup (in RAM if /tmp is tmpfs).
 With a plain LVM volume, the error is the same tough.

   # tmpfile=$(mktemp)
   # echo ${tmpfile}
   # truncate --size=$((100*1024**2)) ${tmpfile}
   # loop_device_2=$(losetup --show -f ${tmpfile})
   # echo ${loop_device_2}
   # vgcreate vg ${loop_device_2}
   # lvcreate --name lv -l 100%free vg
   # sleep 1

   # parted /dev/vg/lv --script mklabel msdos
   # parted /dev/vg/lv --script mkpart primary ext4 4m 100%
   # sleep 1
   # mkfs.ext4 /dev/mapper/vg-lv1
   # mkdir /mnt/lv-root
   # mount /dev/mapper/vg-lv1 /mnt/lv-root
   # mkdir /mnt/lv-root/boot
   # grub-install --boot-directory=/mnt/lv-root/boot /dev/mapper/vg-lv ;

 That is a nonsensical grub-install command.

 I do not approve of calling nonsense on me.  Don't do that.  Thanks.

I did not intend to insult you, and I'm sorry that my message did.
That said, without a device.map specifying that /dev/mapper/vg-lv will
be seen as a drive from the booting environment, that grub-install
command literally does not make sense. You are telling grub to prepare
an environment that cannot possibly work.



 You're telling grub-install that you want grub's boot sector and
 core.img to be installed to a device that cannot possibly be accessed
 by your BIOS (unless you have a BIOS that understands LVM). It may be
 that it should be failing with a better error message, or that there
 is a better example of what should be working that isn't, but I would
 never expect this command to work. I'm not even sure what semantics
 you would expect from this command, and if it happened to do what you
 wanted it to do in the past I can only imagine that that was a lucky
 quirk of the implementation.

 The tempfile and loop device are for (1) not messing with any
 producution LVM volume group of the host system and (2) for being able
 to write to work with RAM rather than wasting disk cycles.
 If that looks wierd to you: it's for reproduction purposes.
 As I wrote above With a plain LVM volume, the error is the same.

Note that I made no mention of the tempfile or the loop device. The
command makes just as little sense with a plain LVM volume. The part
that makes no sense is installing grub's boot sector to something that
is clearly an LVM volume (without a device.map clarifying that it will
look like a drive at boot).


 For the second half, the host BIOS does not have to be able to boot from
 that GRUB since I'm creating a virtual machine image here.  In the mail
 starting this thread I explained:

Using grub-install from a host to install grub for use in a VM (where
the devices involved will be exposed differently to the the VM than
they are to the host) is exactly what the device.map is for. For grub
to properly prepare such a setup (without getting lucky due to a quirk
of the implementation) grub-install needs to know how the devices will
be exposed to the VM.


   I have a case where grub-install is asked to install to an
   LVM volume [1] that is later passed to Xen to boot a Xen guest.
   Inside the Xen guest the LVM volume is seen as a regular hard disk.

   [1] from inside a tool called grmldeboostrap [2], a wrapper around
   deboostrap installing Debian to a given block device

Please correct me if I am wrong, but it seemed like in earlier mails
it was said that this does work if you add a device.map entry like
(hd0) /dev/mapper/vg-lv. If that is the case, then I don't see
anything wrong (except lack of documentation and poor error messages).

I think that grub-install --boot-directory=/mnt/lv-root/boot
/dev/mapper/vg-lv without a device.map should not be expected to
work.

I think that grub-install --boot-directory=/mnt/lv-root/boot
/dev/mapper/vg-lv with a device.map clarifying the usage of
/dev/mapper/vg-lv as a virtual drive should work.

If you disagree still, and think that the case without a device.map
should work, I ask how you think that grub should detect that this
device is intended to be used with a VM, and how that VM will expose
the device to the guest?

It's much more common in my experience that users pass non-drive
devices to grub-install (usually /dev/md0) because they are confused,
not because they are preparing a VM where that device will show up as
a drive. I do not think that it is good to always assume that a device
passed to grub-install will be exposed as drive at boot. I think to
make such an assumption, and have grub-install not error out, would
lead to users thinking that grub-install /dev/mapper/vg-lv or
grub-install /dev/md0 on their non virtual machine setups had
succeeded, where it had actually silently broken their ability to
boot.

All of that said, we don't currently protect users from this in all
cases, and we certainly could to a much better job of reporting
helpful error

Re: about an grub 2.00 installation error

2014-10-28 Thread Jordan Uggla 
On Mon, Oct 27, 2014 at 5:34 PM, Sun, Ning ning@intel.com wrote:
 Hi,
 I encountered an error when installing grub 2.00 on my Linux system(boot
 from EFI BIOS), the error showed “source_dir doesn't exist. Please specify
 --target or –directory”
 The error occurred after I run this command:
 #grub-install –boot-directory=/boot /dev/sda

 Is there anyone encountered the similar error and have a solution to it?

grub-devel is for discussion related to the development of GNU GRUB,
not user support. Please send support questions to help-g...@gnu.org
instead.

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Add config option to prefer Linux kernel versions by substring match

2014-09-11 Thread Jordan Uggla 
On Sun, Sep 7, 2014 at 12:37 PM, Doug Brunner d...@doug-brunner.com wrote:
 Hi all,

 First time submitting - please let me know if I'm doing anything wrong.

 This patch adds an option, GRUB_LINUX_PREF_VERSION_SUBSTR, that can be set to 
 prioritize Linux kernels containing a
 given substring. This takes precedence over version ordering, so if you have 
 3.14.1-generic, 3.14.2-generic,
 3.8.13-fnord1, and 3.8.13-fnord2 and the substring is 'fnord', the order is:
 3.8.13-fnord2
 3.8.13-fnord1
 3.14.2-generic
 3.14.1-generic

 Rationale: I and others, (see e.g. 
 http://askubuntu.com/questions/216398/set-older-kernel-as-default-grub-entry) 
 needed
 to change the Linux kernel version GRUB sets as default. The process is 
 error-prone: you have to figure out where in the
 GRUB menu it will appear, then enter that in /etc/default/grub, and if the 
 menu position changes due to new kernels
 added to the system you have to do it all over again. I had older kernels 
 with a distinctive local version naming scheme
 that I wanted preferred over the stock kernels, but it could also be used to 
 specify a particular kernel version.

Your rationale, as stated, is completely solved by using the menuentry
ID, as documented in info -f grub -n 'Simple configuration' , rather
than using a menuentry number. The answer given to that askubuntu.com
question is a poor one, as noted by one of the commentors (though that
commenter recommends menuentry titles, which have their own issues,
again as documented in the texinfo manual).

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] [PATCH 1/4] Add an option to exclude devices from search results.

2013-12-22 Thread Jordan Uggla 
 regexp

found_a_cfg=false
found_multiple_cfgs=false

for cfg in (*)/boot/grub/grub.cfg (*)/grub/grub.cfg (*)/boot/grub2/grub.cfg \
   (*)/grub2/grub.cfg; do
  regexp --set=1:cfg_device '^\((.*)\)/' $cfg
  probe --set=cfg_device_uuid --fs-uuid (${cfg_device})

  if [ $this_uuid != $cfg_device_uuid ]; then
    if [ $found_a_cfg = true ]; then found_multiple_cfgs=true; fi

    found_a_cfg=true

    menuentry $cfg $cfg_device $cfg {
  cfg_device=$2
  cfg=$3

  root=$cfg_device
  configfile $cfg
    }
  fi
done

if [ $cfg_found != true ]; then
  echo $Error: Could not find any grub.cfg files.
else if [ $multiple_cfg_found != true ]; then # We found exactly one grub.cfg
  timeout=0 # Don't bother showing the menu, just use the grub.cfg we found.
fi

One obvious downside of the above is that all devices (including
possibly slow ones) are searched rather than stopping at the first
grub.cfg found. To fix that properly would require a way to exclude
devices with certain UUIDs (or UUID-files) from being searched by the
search command.

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Console Resolution with GRUB2

2013-03-02 Thread Jordan Uggla 
On Fri, Mar 1, 2013 at 10:56 PM, D.J.J. Ring, Jr. n...@arrl.net wrote:
 Chris,

 That doesn't explain why if I go back to grub-legacy everything works.  I

My guess is that you simply didn't have the same mode configured in
grub legacy as you do in grub2. If you don't think that's the case
then please give us some data to work with to determine what the
difference actually is.

Assuming that you're currently using grub2, and that you want a
console and grub menu resolution of 1024x768 please do the following,
in the order given:

1: Ensure that GRUB_GFXMODE in /etc/default/grub is set to 1024x768,
that GRUB_GFXPAYLOAD is either not set, set to keep or also set to
1024x768

2: Run grub-mkconfig -o /boot/grub/grub.cfg to ensure that these
settings have been applied to the grub.cfg in use.

3: Save the full contents of both /etc/default/grub and
/boot/grub/grub.cfg so that you can include them in your reply email.

4: Save the output of grub-install --version.

5: Reboot and confirm that your console resolution is not 1024x768.

6: Install grub legacy.

7: Configure grub legacy to hand off a mode of 1024x768.

8: Save the full contents of your /boot/grub/menu.lst .

9: Save the output of grub-install --version again.

10: Reboot and confirm that your console resolution *is* 1024x768.

Then reply with the two saved outputs of grub-install --version and
the full contents of /etc/default/grub, /boot/grub/grub.cfg, and
/boot/grub/menu.lst .

Please do not reply with any other unrelated discussion for now, I
would like to stick to one thing at a time to prevent this thread from
getting more chaotic.

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Console Resolution with GRUB2

2013-03-01 Thread Jordan Uggla 
Frankly this entire thread is absurd, confusing the situation immensely.

All that you need to know is that GRUB_GFXMODE in /etc/default/grub
specifies the resolution for grub's menu, and that (unless
GRUB_GFXPAYLOAD is set explicitly to something else) this same mode is
passed on to the kernel.

So if GRUB_GFXMODE=640x480 is not getting you what you want, then
you're not seeing a difference between grub legacy and grub2, you're
seeing a difference between older *kernels* and newer *kernels* with
technology like Kernel Mode Setting. Grub doesn't control what the
linux kernel does for its ttys beyond the mode it hands off and the
kernel parameters that it passes. Check with your distribution to see
the best way to get a lower resolution (or larger fonts) for your
ttys.

All this discussion of writing a grub.cfg by hand and everything else
is tangental to the actual problem that you're having, which is that
the linux kernel and the way that distributions configure things has
changed, not grub.

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: bootable RAID, number of member disks limitation

2013-01-08 Thread Jordan Uggla 
On Thu, Jan 3, 2013 at 11:42 PM, Chris Murphy ch...@colorremedies.com wrote:

 On Jan 3, 2013, at 3:00 PM, Vladimir 'φ-coder/phcoder' Serbinenko 
 phco...@gmail.com wrote:

 GRUB has no limitation on number on devices other than free memory to
 hold structures and 2^32 for IDs. If there is any other limit it's a bug
 and please file a bug report with the images in question (no need to
 install, just use grub-fstest) However BIOS limits the number of disks
 that can be accessed. Theoretically there could be up to 128 (or 256 if
 you use floppy numbers as well) accessible through BIOS. The convention
 is to use only 16 possible IDs for HDD (0x80-0x8f). In practice many
 BIOSes are limited to less (8 is usual limit).

 I'm totally unclear on how to use grub-fstest.

I don't have a GNU/Linux system (other than my phone) to test this
with at the moment, but I think grub-fstest --diskcount=11
/dev/sd{a..k} ls -- -l should list all 11 disks, and their
partitions, with information about the filesystem each contains. If
(loop0,msdos1) is one of the devices that makes up this btrfs volume
then you should be able to list files on the filesystem with:

grub-fstest --diskcount=11 /dev/sd{a..k} ls '(loop0,msdos1)/'


 Should ls at grub rescue report all attached devices?

Yes, if it doesn't then that's a pretty clear indication that your
boot firmware can't properly handle many drives. You can also try
grub-install --disk-module=native /dev/sdX to test if grub can
access all of the drives using its own native disk drivers rather than
relying on the boot firmware.


 With single disk btrfs only (no md RAID), at a grub command prompt, ls reports
 (hd0) (hd0,msdos1) (hd1) (hd2) (hd3)

 Yet there are 11 devices attached. This is VirtualBox, so this very well may 
 be a vbox limitation. I haven't tried it with KVM's SEABIOS yet.


I am surprised to hear that this problem is appearing with VirtualBox
rather than real hardware. If this is a bug in VirtualBox's BIOS then
a bug report should definitely be filed with them.

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: --recheck option

2012-07-05 Thread Jordan Uggla 
On Thu, Jul 5, 2012 at 5:19 AM, yannubu...@gmail.com
yannubu...@gmail.com wrote:
 Dear GRUB devs/helpers,

 A) Which are the situations where the --recheck option of grub-install must
 NOT be used? why grub-install wouldn't systematically probe a device map by
 default?

With grub 2.00, it does.
http://www.gnu.org/software/grub/manual/grub.html#Device-map .


 B) Some people recommend to use grub-install /dev/sdX  grub-install
 --recheck /dev/sdX, do you think it is correct/useful?

As explained in the above documentation, grub utilities no longer need
a device.map file. Back when they did still need one, the first time
someone ran grub-install it would write a device.map (if one didn't
already exist). If that got out sync somehow then a later grub-install
might fail, and if that happened using the --recheck option (which
would write a new device.map, overwriting the old one) might allow the
installation to succeed.

Now, grub-install probes on the fly if no device.map exists, and never
creates a device.map file itself, and so grub-install --recheck ...
now actually simply deletes the device.map file, causing grub-install
to go back to the default state of probing on the fly.

Running grub-install twice is redundant, and adding the '--recheck' is
also usually not needed option at this point but won't hurt anything
(except in very specific situations like when you're passing an LVM
logical volume to a virtual machine as if it were a normal disk, in
which case you should know what you're doing and have a backup of your
device.map anyway).

So the advice is a little silly at this point, but not harmful.

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Boot dell in uefi mode from usb stick

2012-06-12 Thread Jordan Uggla 
On Mon, Jun 11, 2012 at 6:38 PM, John Frankish j-frank...@slb.com wrote:
 I'm not sure if this is possible, but I've been trying to boot a dell laptop 
 (latitude e6220) in uefi mode from a usb stick without success.

 Using:

 $ sudo grub-install --target=x86_64-efi --boot-directory=/mnt/sdc1/efi 
 --removable
 Installation finished. No error reported.

This list is for grub development, user support questions should be
sent to help-grub (which I've CCd in my reply).
grub-install's --boot-directory option is for specifying the boot
directory, grub-install's --efi-directory option is for specifying the
directory which is the mountpoint for the EFI System Partition. Since
this is a removable device, you probably don't want it as a semi
permanent EFI boot entry, and you probably want other machines to be
able to boot from it, so you should add the --removable option as
well.

Assuming that sdc1 is a proper EFI System Partition, mounted at
/mnt/sdc1/, that gives you something like sudo grub-install
--target=x86_64-efi --boot-directory=/mnt/sdc1/boot/
--efi-directory=/mnt/sdc1/ --removable. The --efi-directory option
requires grub 2.00 beta6 or newer.

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Boot immediately after GRUB_HIDDEN_TIMEOUT

2012-05-17 Thread Jordan Uggla 
On 04/29/2012 12:14 PM, Mads Kiilerich wrote:
* util/grub.d/00_header.in: Boot immediately after
GRUB_HIDDEN_TIMEOUT. Documentation said: If no key is pressed
during that time, boot immediately.
 
 
 
 ___
 Grub-devel mailing list
 Grub-devel@gnu.org
 https://lists.gnu.org/mailman/listinfo/grub-devel

I don't see anything wrong with the current handling of
GRUB_HIDDEN_TIMEOUT and GRUB_TIMEOUT in grub-mkconfig other than it
contradicting the documentation. I would rather fix the documentation
and avoid any possible issues with grub's behavior changing for
existing configurations with regard to these variables upon upgrading
to grub 2.00. 

Below is a patch which fixes the documentation in grub.texi.

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)

=== modified file 'ChangeLog'
--- ChangeLog   2012-05-15 15:17:06 +
+++ ChangeLog   2012-05-18 01:07:20 +
@@ -1,3 +1,10 @@
+2012-05-17  Jordan Uggla  jordan.ug...@gmail.com
+
+   * docs/grub.texi Fix documentation of GRUB_HIDDEN_TIMOUNT to match the
+   actual implementation. Specifically, clarify that the grub menu will
+   be displayed for GRUB_TIMOUT seconds after the hidden timeout has
+   passed.
+
 2012-05-15  Vladimir Serbinenko  phco...@gmail.com
 
* grub-core/fs/ntfs.c (read_data): Prevent overflow.

=== modified file 'docs/grub.texi'
--- docs/grub.texi  2012-05-03 22:28:53 +
+++ docs/grub.texi  2012-05-18 00:49:41 +
@@ -1135,7 +1135,11 @@
 
 @item GRUB_HIDDEN_TIMEOUT
 Wait this many seconds for a key to be pressed before displaying the menu.
-If no key is pressed during that time, boot immediately.  Unset by default.
+If no key is pressed during that time, display the menu for the number of
+seconds specified in GRUB_TIMEOUT before booting the default entry. We expect
+that most people who use GRUB_HIDDEN_TIMEOUT will want to have GRUB_TIMEOUT 
set 
+to @samp{0} so that the menu is not displayed at all unless a key is pressed.
+Unset by default.
 
 @item GRUB_HIDDEN_TIMEOUT_QUIET
 In conjunction with @samp{GRUB_HIDDEN_TIMEOUT}, set this to @samp{true} to

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Helping upgrading Grub2's documentation

2012-03-08 Thread Jordan Uggla 
On Wed, Mar 7, 2012 at 2:58 PM, Arbiel Perlacremaz
arbiel.perlacre...@gmail.com wrote:
 I would be glad to help upgrade Grub2's documentation.

Firstly, thank you. Documentation is very important and any help you
can give will be greatly appreciated.


 1) Where is the latest Grub manual ?

http://www.gnu.org/software/grub/manual/grub.html is an html version
of the manual and is generally kept fairly up to date. But the source
is a texinfo manual, http://www.gnu.org/software/texinfo/ , kept in
docs/grub.texi in the source tree. You can check out latest grub
source with bzr branch
http://bzr.savannah.gnu.org/r/grub/trunk/grub/;. You can also view the
file at 
http://bazaar.launchpad.net/~vcs-imports/grub/grub2-bzr/view/head:/docs/grub.texi
but since you plan to contribute you'll want to become familiar with
bazaar.

 2) What procedure is to be used to update it ?

You edit docs/grub.texi and submit a patch to this mailing list (with
your changes to docs/grub.texi and a new entry in Changelog). If
you're not familiar with the process of writing/submitting patches
feel free to ask more. There is also a developers manual at
docs/grub-dev.texi; It's aimed more at those wishing to contribute
code, but some of it applies to contributing documentation as well.

 3) Is a complete list of commands available ?

Are you asking about userland utilities like grub-install or
grub-script commands like configfile?

For grub-script commands there is a partial list in the current
manual: http://www.gnu.org/software/grub/manual/grub.html#Commands

You can get a full list by running pager=1; help from the grub
shell. This is obviously not ideal, and will only include commands
available for the platform you're using, for instance grub-pc won't
include the appleloader command. Hopefully someone else can give you
a better list.

 4) Is there a tool to test the commands ?

I'm not sure exactly what you mean. make check does do automated
testing, but not all commands are tested in make check.


 Arbiel

 ___
 Grub-devel mailing list
 Grub-devel@gnu.org
 https://lists.gnu.org/mailman/listinfo/grub-devel

It might also be useful to pop into the #grub IRC channel on freenode,
http://webchat.freenode.net/?channels=grubuio=d4

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Source, configfile and normal

2012-03-08 Thread Jordan Uggla 
On Wed, Mar 7, 2012 at 3:05 PM, Arbiel Perlacremaz
arbiel.perlacre...@gmail.com wrote:
 What are the differences between
 normal file.cfg

The command normal does not take any arguments. It changes from
rescue mode to normal mode. Normal mode then loads $prefix/grub.cfg
automatically. I'm pretty sure that the only time that a user should
ever run normal is documented here:
http://www.gnu.org/software/grub/manual/grub.html#GRUB-only-offers-a-rescue-shell

 configfile file.cfg

All paths in grub are absolute, so it would need to be configfile
/file.cfg, which would execute file.cfg in a new context *and* create
a new menu. It follows basically the same environment variable
semantics as bash file.sh in that only exported variables will be
available to file.cfg, and file.cfg cannot modify the environment
variables of its parent.


 I understand
 source file.cfg
 to be equivalent to the inclusion into the current file of the file.cfg. In
 particular, variables are not to be exported to be available to file.cfg
 commands.

Correct, much like source file.sh in bash.


 Am I right ?

 Arbiel

 ___
 Grub-devel mailing list
 Grub-devel@gnu.org
 https://lists.gnu.org/mailman/listinfo/grub-devel

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Add submenu support to 10_linux (grub-mkconfig)

2012-02-28 Thread Jordan Uggla 
In my first patch I rather stupidly asked gettext for a translation of %s. 
Updated patch below does not have this mistake.

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)

=== modified file 'util/grub-mkconfig.in'
--- util/grub-mkconfig.in   2012-02-26 17:37:54 +
+++ util/grub-mkconfig.in   2012-02-27 08:22:48 +
@@ -206,7 +206,8 @@
   GRUB_INIT_TUNE \
   GRUB_SAVEDEFAULT \
   GRUB_ENABLE_CRYPTODISK \
-  GRUB_BADRAM
+  GRUB_BADRAM \
+  GRUB_ENABLE_SUBMENUS
 
 if test x${grub_cfg} != x; then
   rm -f ${grub_cfg}.new

=== modified file 'util/grub.d/10_linux.in'
--- util/grub.d/10_linux.in 2012-02-26 16:28:05 +
+++ util/grub.d/10_linux.in 2012-02-29 03:03:01 +
@@ -63,15 +63,25 @@
 {
   os=$1
   version=$2
-  recovery=$3
+  type=$3
   args=$4
-  if ${recovery} ; then
-title=$(gettext_quoted %s, with Linux %s (recovery mode))
+
+  case $type in
+  simple)
+title=%s ;;
+  recovery)
+title=$(gettext_quoted %s, with Linux %s (recovery mode)) ;;
+  *)
+title=$(gettext_quoted %s, with Linux %s) ;;
+  esac
+
+  if [ x$type = xsimple ]; then
+printf menuentry '${title}' ${CLASS} {\n ${os}
   else
-title=$(gettext_quoted %s, with Linux %s)
+printf menuentry '${title}' ${CLASS} {\n ${os} ${version}
   fi
-  printf menuentry '${title}' ${CLASS} {\n ${os} ${version}
-  if ! ${recovery} ; then
+
+  if [ x$type != xrecovery ] ; then
   save_default_entry | sed -e s/^/\t/
   fi
 
@@ -145,6 +155,11 @@
 prepare_boot_cache=
 prepare_root_cache=
 
+# Extra indentation to add to menu entries in a submenu. We're not in a submenu
+# yet, so it's empty. In a submenu it will be equal to '\t' (one tab).
+submenu_indentation=
+
+is_first_entry=true
 while [ x$list != x ] ; do
   linux=`version_find_latest $list`
   gettext_printf Found linux image: %s\n $linux 2
@@ -189,12 +204,32 @@
 linux_root_device_thisversion=${GRUB_DEVICE}
   fi
 
-  linux_entry ${OS} ${version} false \
-  ${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}
+  if [ x$GRUB_ENABLE_SUBMENUS = xtrue -a x$is_first_entry = xtrue ]; then
+linux_entry ${OS} ${version} simple \
+${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}
+
+submenu_indentation=\t
+
+cat  EOF
+submenu '$(gettext_quoted Advanced options for ${OS})' {
+EOF
+  fi
+
+  linux_entry ${OS} ${version} advanced \
+  ${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT} \
+  | sed s/^/$submenu_indentation/
   if [ x${GRUB_DISABLE_RECOVERY} != xtrue ]; then
-linux_entry ${OS} ${version} true \
-   single ${GRUB_CMDLINE_LINUX}
+linux_entry ${OS} ${version} recovery \
+single ${GRUB_CMDLINE_LINUX} \
+| sed s/^/$submenu_indentation/
   fi
 
   list=`echo $list | tr ' ' '\n' | grep -vx $linux | tr '\n' ' '`
+  is_first_entry=false
 done
+
+# If submenus are enabled, and at least one kernel was found, then we need to
+# add a closing '}' for the submenu command.
+if [ x$GRUB_ENABLE_SUBMENUS = xtrue -a x$is_first_entry != xtrue ]; then
+  echo '}'
+fi


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: grub legacy to grub2 upgrade path

2012-02-23 Thread Jordan Uggla 
2012/2/22 Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com:

 See parallel thread for heuristics. However note that this setup is
 fundamentally broken

To make it easier to find, said thread is available here:
http://lists.gnu.org/archive/html/grub-devel/2012-02/msg3.html

And ryuo, I assume that phcoder's recent request there for testing of
a patch for this applies to you as well.

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Grub 2 Problem with SSD

2012-02-19 Thread Jordan Uggla 
On Fri, Feb 17, 2012 at 2:41 PM, Gus Zernial gus_zern...@yahoo.com wrote:
 I have a Kubuntu 11.10 on an amd64 system with kernel 3.0.0-16-generic. My 
 grub version is 1.99-12ubuntu5. My root and boot directories were on an 
 OCZ-AGILITY2 SATA II SSD, and /home was and is on conventional SATA hard 
 disks. All was well for several months, untile I suddenly started getting 
 Grub error: out of disk, no boot, drops into grub rescue.

This mailing list is for grub development discussion, not end user
support. Please send your question to help-g...@gnu.org instead. In
short, you have a buggy BIOS and I'll give more details on help-grub.

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Don't create grubenv on ZFS

2012-02-04 Thread Jordan Uggla 
On Thu, Feb 2, 2012 at 3:16 AM, Richard Laager rlaa...@wiktel.com wrote:
 GRUB can't write to ZFS.  Creating a grubenv file leads to a misleading
 sparse file not allowed error on boot.  The attached patch for
 grub-install skips the creation of a grubenv file on ZFS.

I think that not writing /boot/grub/grubenv is a poor work around for
the problem of grubenv not being writable.

1: Even if it doesn't now, I would expect an error message when
save_env is run and no grubenv is present, so there should be an error
message either way.

2: There are uses for grubenv that do not involve writing to it at
boot. Fedora's grub2 documentation recommends grub-set-default as the
best way to change the default menu entry:
http://fedoraproject.org/wiki/Grub2#Setting_default_entry and if I
understand correctly this should continue to work on any filesystem
which grub can read.

3: It can't be determined with certainty that grubenv will be
writeable at boot. I have run into problems where I installed grub to
an SD card and then flipped the write protect switch on the card,
which could not have been anticipated at grub-install time. For this
reason I think the focus should be on graceful degradation and
understandable error messages when save_env is called with a read only
grubenv (and possibly there should be ways to disable calls to grubenv
in grub-mkconfig, especially in the case of Ubuntu's recordfail
modifications).

I do however think that some utilities should warn (but not otherwise
change their behavior) when grubenv does not appear to be writable.
The prime example of this would be grub-reboot. When grub-reboot is
called with a filesytem / abstraction which will prevent grub from
writing to the grubenv at boot, grub-reboot cannot possibly function.
It already degrades to basically having no effect, so there is no harm
in making the changes to grubenv on the off chance the user knows
better, but it should produce a clear warning that grub-reboot cannot
function without a grubenv writeable by grub at boot.

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Variable chosen not being set to the last entry booted

2011-07-21 Thread Jordan Uggla 
On Wed, Jul 20, 2011 at 11:27 AM, Roger Cruz roger_r_c...@yahoo.com wrote:
 I was using grub2-1.97~beta4 and had a grub.cfg file which contains
 menuentry   Windows  {
     saved_entry=${chosen}
     save_env saved_entry
     set root=NvDisk1
     chainloader +1
 }

Grub now behaves more like bash, you need to quote your variables if
they might contain spaces. So you want something like:
saved_entry=$chosen

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Variable chosen not being set to the last entry booted

2011-07-21 Thread Jordan Uggla 
On Thu, Jul 21, 2011 at 8:32 AM, Roger Cruz roger_r_c...@yahoo.com wrote:
 My bad.  I also needed to put the quotes around this one for it to work
 properly
 set default=${saved_entry}

 Thanks for your help Jordan

You're welcome. In the future though please be sure not to use html
when sending email to technical mailing lists, and please also send
support requests to help-g...@gnu.org rather than grub-devel.

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Out of Memory Error

2011-03-29 Thread Jordan Uggla 
2011/3/29 Gus Zernial gus_zern...@yahoo.com:
 Thanks for your reply. First of all, the error is Out of disk, not
 Out of memory, my bad

Out of disk is a very different error from Out of memory. Out of
disk means that you have a buggy BIOS which can't handle large drives
properly. To work around this create a small /boot/ partition near the
beginning of the drive.

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Full documentation for GRUB2

2011-03-26 Thread Jordan Uggla 
On Thu, Mar 24, 2011 at 8:06 AM, Treutwein Bernhard
bernhard.treutw...@verwaltung.uni-muenchen.de wrote:
 Hi Bill  Robert,

 [...]
  Is there some complete official documentation of GRUB2, or is GRUB2 full
  documentation only in source code?;-)

 I think the Grub2 developers would welcome volunteers to help write
 documentation.

 this is kind of a hen  egg problem.

 I would love to help improving the documentation (as I did already for
 Grub Legacy), but I have no idea where to start. Currently I see that
 the official Grub Manual is in a difficult state. It appears to me
 that it is a copy of the Grub Legacy manual, where some parts are
 updated others are plainly wrong (due to being only copied), e.g.
 the remark in the second paragraph of chapter 3 Installation
 http://www.gnu.org/software/grub/manual/grub.html#Installation
 where it is stated that you could install grub by running grub
 itself from a floppy, which isn't possible with Grub 2 anymore.

 I have no idea how I can find out how to use modules where I
 have to guess how to use them. There was a nice remark on
 by phcoder on the request list that there are usb mass storage
 and uhci  ehci modules, which I tried and I was able to confirm
 that insmod'ing uhci.mod and usbms.mod on a system, which is not
 able to boot via bios from usb, enabled this system to boot
 from usb by chainloading (usb0)+1. But it is very time consuming
 and frustrating to experiment with different modules just for
 documentation.

 How can I find out more information about the modules?

The best way to find out information is probably to ask in #grub on
irc.freenode.net. If nobody is around (or you prefer email) then ask
specific questions on grub-devel (since this is an effort to develop
better documentation rather than simple end user support which would
be more appropriate for help-grub). Any contribution to the
documentation is extremely welcome and I'd personally love to help so
you may ping me (Jordan_U) in #grub at any time if you have a
question.


 Is digging into the source an option, is documentation available
 there in comments? I was not able to browse source in Savannah's
 Bazaar since this option is apparently broken?

You can browse the source online via the launchpad mirror:
http://bazaar.launchpad.net/~vcs-imports/grub/grub2-bzr/files .

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Example theme mentioned in manual

2011-01-10 Thread Jordan Uggla 
On Mon, Jan 10, 2011 at 5:00 PM, Matt Sturgeon mtt...@gmail.com wrote:
 Hi,
 I was looking atthe GRUB Manual (1.99) trying to work out how to install a
 theme, and I noticed in the first section of chapter 6 a
 docs/example_theme mentioned which I cannot find anyware. Ive looked in
 Bazaar repos, and downstream (Ubuntu) source/binary packages (I couldnt find
 the upstream source for 1.99).

 So, this could be a bug - example_theme not packaged - or it could be
 another - incorrect referance in manual.

 Also is there no official GRUB Theme? If I had an example_theme I'd be happy
 to develop an official theme.

An official GRUB theme would be great! For example themes see
http://download-mirror.savannah.gnu.org/releases/grub-extras/themes.tgz
as well as http://apebox.org/wordpress/linux/261/. Make sure to be
careful about the licence of any components of the theme (images,
required fonts, etc).

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Example theme mentioned in manual

2011-01-10 Thread Jordan Uggla 
On Mon, Jan 10, 2011 at 7:39 PM, Matt Sturgeon mtt...@gmail.com wrote:
 Quick question though: How do I choose a theme?

 I tried (In Ubuntu Natty 11.04 - GRUB 1.99) setting GRUB_THEME to the
 theme.txt file (/boot/grub/themes/winter/theme.txt) of Colin Bennett's
 originonal Winter theme, which didnt work - am I doing something
 wrong there, is it Ubuntu or is the theme just outdated?

The theme is outdated. An updated version of it is included in the
themes.tar.gz I linked to.

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH] Re: ACPI halt failures in tests

2010-12-23 Thread Jordan Uggla 
On Tue, Nov 23, 2010 at 7:29 AM, Colin Watson cjwat...@ubuntu.com wrote:
 I occasionally get ACPI shutdown failed in qemu during tests.  Since
 this is printed with grub_printf rather than with grub_dprintf or
 whatever, it shows up in the test output and causes tests to fail.  It
 only fails some of the time on my system (less than half).  I've tried
 to insert 'set debug=acpi' into the grub-shell test setup, but it
 stubbornly succeeds when I do that, so I'm not really sure what else to
 try.

 The system seems to shut down happily anyway, presumably because it goes
 on to try other boot methods.  Should we maybe downgrade this to a debug
 message?

I think it's more likely a race condition of sorts; it's assumed that
the code that prints ACPI shutdown failed is unreachable when ACPI
shutdown succeeds, since the code comes after shutdown has been
requested. Part of the reason I think this is that the symptom I've
been seeing is just A or AC being printed, which means that the
shutdown is not synchronous (it's happening in the middle of a
printf). Since in real hardware I can't see this being much of a
problem (except maybe causing false alarms for people who log serial
output), and it would be good to have some type of message on the
screen when ACPI shutdown does fail, I don't think this should be just
a dprintf. Instead I think that the unit test's grub.cfg should
disable serial terminal just before running halt as a work around.

=== modified file 'ChangeLog'
--- ChangeLog   2010-12-10 12:56:45 +
+++ ChangeLog   2010-12-23 09:02:56 +
@@ -1,3 +1,7 @@
+2010-12-23 Jordan Uggal jordan.ug...@gmail.com
+   * tests/util/grub-shell.in: Supress ACPI shutdown failed error
+   to keep unit tests from failing when they shouldn't.
+
 2010-12-10  Colin Watson  cjwat...@ubuntu.com

* .bzrignore: Ignore grub-core/rs_decoder.S.

=== modified file 'tests/util/grub-shell.in'
--- tests/util/grub-shell.in2010-10-18 20:50:01 +
+++ tests/util/grub-shell.in2010-12-23 09:04:34 +
@@ -132,6 +132,8 @@

 cat EOF ${cfgfile}
 source /boot/grub/testcase.cfg
+terminal_output console # Stop serial output to supress
+# ACPI shutdown failed error.
 halt
 EOF

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Use submenus for 10_linux

2010-12-05 Thread Jordan Uggla 
On Sat, Dec 4, 2010 at 4:54 PM, Colin Watson cjwat...@ubuntu.com wrote:

 +             /* To make this work with submenus, we need to extract entries
 +                from the submenu, then return the entry number of the
 +                submenu itself if one of its entries (recursively) matches;
 +                when the submenu is executed for real, it will then have to
 +                call this function again one level down.  This is not going
 +                to be very efficient with a deep menu stack, but it seems
 +                unlikely that many people will bother with more than a
 +                couple of levels.  *

In addition to the performance impact with static submenus, this will
be completely unworkable with dynamically generated submenus. (Yes, I
can think of use cases for a saved default with a dynamically
generated submenu)

I would prefer something like:
GRUB_DEFAULT=Advanced options for UbuntuUbuntu, with Linux 2.6.36.1

Where '' (or some other character) designates the what follows,
Ubuntu, with Linux 2.6.36.1, is an entry within the submenu created
by selecting what precedes it, Advanced options for Ubuntu.

Separately this also highlights an advantage of using a simplified
primary menu title (without a kernel version), as in this case if a
user wanted the default selection to be Ubuntu with the latest
installed kernel they would simply specify:
GRUB_DEFAULT=Ubuntu

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: increasing grubenv file size

2010-12-01 Thread Jordan Uggla 
On Wed, Dec 1, 2010 at 8:57 PM, Gnanasekar Loganathan
l.gnanase...@gmail.com wrote:
 Hi Colin,

 We are storing environment variables like below:

 macaddr=ab:cd:ef:12:34:56
 bootfile=image.gnana
 ipaddr=172.30.16.203
 netmask=255.255.0.0
 serverip=172.30.16.90
 gatewayip=172.16.1.1
 ftpuser=username
 ftppasswd=password
 bootcmd=flash(0,0):-OS-8-3-9-23.bin;default_boot;boot

Are these environment variables being *set* from within grub itself,
or by an administrator booted into an OS? For persistent storage of
environment variables you can simply set the variables with the
grub.cfg, or in a separate cfg file which is sourced by the primary
grub.cfg (like /boot/grub/custom.cfg). Using a normal text file you
can include as many variables as you want, expanding as needed.

That's not to say that it will never be useful to have a larger
grubenv, but it doesn't sound like it's needed in your case.

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Use submenus for 10_linux

2010-11-24 Thread Jordan Uggla 

On 11/24/2010 09:21 AM, Colin Watson wrote:

What do people think of this?  It's a remarkably small change now that
Vladimir's implemented submenus, and I've had a number of requests for
it.


snip


* util/grub.d/10_linux.in: Put second and subsequent menu entries in
a submenu.


snip


+echo submenu \Previous Linux versions\ {


Since most users don't need to know what kernel version is being used by 
default, I think we should simplify the title of the default menu entry 
(by removing the with Linux ...) and have a submenu labeled Advanced 
options for $OS. This submenu would include all kernel entries, 
including the first entry (which would also be booted if you just 
selected the main entry instead of going to the submenu). So the submenu 
would look exactly like the main menu currently does, except only 
listing kernel entries for one OS.


I've attached a proof of concept patch which does this.

--
Jordan Uggla (Jordan_U on irc.freenode.net)
=== modified file 'util/grub.d/10_linux.in'
--- util/grub.d/10_linux.in	2010-11-01 11:49:40 +
+++ util/grub.d/10_linux.in	2010-11-25 01:03:00 +
@@ -55,15 +55,25 @@
 {
   os=$1
   version=$2
-  recovery=$3
+  type=$3
   args=$4
-  if ${recovery} ; then
-title=$(gettext_quoted %s, with Linux %s (recovery mode))
+
+  case $type in
+  simple)
+title=$(gettext_quoted %s) ;;
+  recovery)
+title=$(gettext_quoted %s, with Linux %s (recovery mode)) ;;
+  *)
+title=$(gettext_quoted %s, with Linux %s) ;;
+  esac
+
+  if [ x$type = xsimple ]; then
+printf menuentry '${title}' ${CLASS} {\n ${os}
   else
-title=$(gettext_quoted %s, with Linux %s)
+printf menuentry '${title}' ${CLASS} {\n ${os} ${version}
   fi
-  printf menuentry '${title}' ${CLASS} {\n ${os} ${version}
-  if ! ${recovery} ; then
+
+  if [ x$type != xrecovery ] ; then
   save_default_entry | sed -e s/^/\t/
   fi
 
@@ -114,6 +124,8 @@
   done`
 prepare_boot_cache=
 
+is_first_entry=true
+
 while [ x$list != x ] ; do
   linux=`version_find_latest $list`
   echo Found linux image: $linux 2
@@ -151,12 +163,26 @@
 linux_root_device_thisversion=${GRUB_DEVICE}
   fi
 
-  linux_entry ${OS} ${version} false \
+  if [ x$is_first_entry = xtrue ]; then
+linux_entry ${OS} ${version} simple \
+${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}
+
+cat  EOF
+submenu '$(gettext_quoted Advanced options for ${OS})' {
+EOF
+  fi
+
+  linux_entry ${OS} ${version} advanced \
   ${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}
   if [ x${GRUB_DISABLE_RECOVERY} != xtrue ]; then
-linux_entry ${OS} ${version} true \
+linux_entry ${OS} ${version} recovery \
 	single ${GRUB_CMDLINE_LINUX}
   fi
 
   list=`echo $list | tr ' ' '\n' | grep -vx $linux | tr '\n' ' '`
+  is_first_entry=false
 done
+
+if [ x$is_first_entry != xtrue ]; then #At least 1 kernel found, submenu started
+  echo '}'
+fi

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH] Update grub-install documentation.

2010-09-20 Thread Jordan Uggla 

The documentation for grub-install in docs/grub.texi is mostly just a
leftover from the GRUB legacy documentation, and is therefore
inaccurate in many ways with respect to GRUB2. Attached is a merge
proposal that fixes most of the problems I found with the grub-install
documentation. One problem that I did find that I don't know quite how
to deal with (and haven't in this patch) is this paragraph:

By the way, as noted above, it is quite difficult to guess BIOS drives
correctly under a UNIX-like OS. Thus, grub-install will prompt you to
check if it could really guess the correct mappings, after the
installation. The format is defined in Device map. Please be quite
careful. If the output is wrong, it is unlikely that your computer
will be able to boot with no problem.

The device.map is not needed in most cases, and GRUB2 for all but a
few odd and uncommon cases is completely independent of device
enumeration.  Despite that, a user can create a device.map that would
cause problems with grub-install, for instance (hd0) /dev/md0.  So
some mention of device.map with regard to grub-install is probably
needed, but I'll leave that to someone else to write.
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: jordan.ug...@gmail.com-20100920210151-vdf1002s87z46my8
# target_branch: file:///home/jordan/grub-bzr/grub-trunk/
# testament_sha1: 672157381054a4b4f1842f87eb01970813e873c2
# timestamp: 2010-09-20 14:06:06 -0700
# base_revision_id: phco...@gmail.com-20100920202430-j7zw8icehfwb7g25
# 
# Begin patch
=== modified file 'ChangeLog'
--- ChangeLog   2010-09-20 20:24:30 +
+++ ChangeLog   2010-09-20 21:01:51 +
@@ -1,3 +1,8 @@
+2010-09-20  Jordan Uggla  jordan.ug...@gmail.com
+
+   Update grub-install documetation to account for changes between
+   GRUB legacy and GRUB2.
+
 2010-09-20  Vladimir Serbinenko  phco...@gmail.com
 
Make cutmem accept a region specification.

=== modified file 'docs/grub.texi'
--- docs/grub.texi  2010-09-20 13:03:47 +
+++ docs/grub.texi  2010-09-20 21:01:51 +
@@ -523,13 +523,10 @@
 from the source tarball, or as a package for your OS.
 
 After you have done that, you need to install the boot loader on a
-drive (floppy or hard disk). There are two ways of doing that - either
-using the utility @command{grub-install} (@pxref{Invoking
-grub-install}) on a UNIX-like OS, or by running GRUB itself from a
-floppy. These are quite similar, however the utility might probe a
-wrong BIOS drive, so you should be careful.
+drive using the utility @command{grub-install} (@pxref{Invoking
+grub-install}) on a UNIX-like OS.
 
-Also, if you install GRUB on a UNIX-like OS, please make sure that you
+Before installing grub to your hard drive please make sure that you
 have an emergency boot disk ready, so that you can rescue your computer
 if, by any chance, your hard drive becomes unusable (unbootable).
 
@@ -550,20 +547,11 @@
 @node Installing GRUB using grub-install
 @section Installing GRUB using grub-install
 
-...@strong{caution:} This procedure is definitely less safe, because
-there are several ways in which your computer can become
-unbootable. For example, most operating systems don't tell GRUB how to
-map BIOS drives to OS devices correctly---GRUB merely @dfn{guesses}
-the mapping. This will succeed in most cases, but not
-always. Therefore, GRUB provides you with a map file called the
-...@dfn{device map}, which you must fix if it is wrong. @xref{Device
-map}, for more details.
-
-If you still do want to install GRUB under a UNIX-like OS (such
-as @sc{gnu}), invoke the program @command{grub-install} (@pxref{Invoking
-grub-install}) as the superuser (@dfn{root}).
-
-The usage is basically very simple. You only need to specify one
+To install GRUB under a UNIX-like OS (such as @sc{gnu}), invoke the program
+...@command{grub-install} (@pxref{Invoking grub-install}) as the superuser
+(@dfn{root}).
+
+The usage is very simple. In most cases you only need to specify one
 argument to the program, namely, where to install the boot loader. The
 argument can be either a device file (like @samp{/dev/hda}) or a
 partition specified in GRUB's notation. For example, under Linux the
@@ -579,7 +567,8 @@
 # @kbd{grub-install /dev/hd0}
 @end example
 
-If it is the first BIOS drive, this is the same as well:
+If @samp{/dev/hd0} is mapped to @samp{(hd0)} in the @file{device.map}, this is
+the same as well:
 
 @example
 # @kbd{grub-install '(hd0)'}
@@ -591,7 +580,13 @@
 # @kbd{grub-install hd0}
 @end example
 
-But all the above examples assume that GRUB should use images under
+Because device names specified using grub's internal notation are mapped to
+device nodes as presented by the OS using the @xref{Device map}, which device
+grub is actually installed to depends on the contents of the @file{device.map}.
+To avoid ambiguity and the chance of writing to the wrong device use of the 
OS's
+device naming is recommended.
+
+All the above examples assume that GRUB

Syntax options for dynamic menu generation in grub-script

2010-08-24 Thread Jordan Uggla 
 for static entries).

Points in favor of option two:

 * This is subjective, but I find the syntax of option one hard to
read, both in the grub.cfg and in the menu entries that it creates
when viewed in grub's menu entry editor.

 * Option one only allows for templates of menu entries, where the
source is basically always the same, but acts differently depending on
positional parameters. I have created a script with grub's lua support
which parses a grub legacy menu.lst file by building the source of
each menu entry line by line, replacing grub legacy commands with
their grub2 equivalents. I don't think that such a script would be
possible to create with this grub-script syntax (but would with option
two).


While I only mentioned the two options that were discussed on IRC, I
am sure there are other solutions to be brought to this discussion.

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

standard for loop bootable iso images.

2010-04-11 Thread Jordan Uggla 
Super GRUB2 disk 1.98s1 will include an option that will look for loop
bootable iso files in /boot-isos/ on all devices and, for supported
distributions, present a menu allowing you to boot from them.
Currently the lua script that does this has to search for specific
files on the iso to try to guess the distribution, and from there uses
distribution-specific hard coded paths and kernel parameters. This is
sub-optimal for many reasons, among them that new distributions need
to be added to the script manually and even old ones may need updating
for newer versions of the distribution. (This was the case for grml.)

On the supergrub mailing list I proposed that distributions include a
loopback.cfg, which would be a regular grub.cfg with the addition of
extra kernel parameters needed to loop mount the iso file. To boot
such an iso from grub you would loop mount the iso, set
root=(loop-device), export a variable $iso_path with the path to the
iso file, and then configfile /boot/grub/loopback.cfg. You then get
the distribution's full, up to date, list of options, and no
special-casing of distributions is required.

Creating a suitable loopback.cfg is fairly easy, especially if the
live distribution already uses grub2.  As an example, here is a commit
modifying grml's grub.cfg so that it can be used normally or as a
loopback.cfg (so they only have to maintain one file):
http://tinyurl.com/y52w5se

Adrian responded to my proposal pointing me to
http://mgerards.net/blog/?p=16 and suggesting I ask here if there had
been any progress with that idea. That post suggests having a
multiboot bootloader on the iso, passing the iso path to the
bootloader via the multiboot cmdline.

Any comments on either proposal, or an entirely different one, are
welcome and encouraged.

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH] Add missing dependencies to INSTALL

2010-03-02 Thread Jordan Uggla 
Gettext and qemu ( for make-check ) are missing from INSTALL,
attached patch fixes this.

--
Jordan Uggla (Jordan_U on irc.freenode.net)
=== modified file 'ChangeLog'
--- ChangeLog	2010-03-01 20:00:02 +
+++ ChangeLog	2010-03-02 17:33:56 +
@@ -1,3 +1,8 @@
+2010-03-02  Jordan Uggla  jordan.ug...@gmail.com
+
+	* INSTALL: Add gettext as a dependency and add qemu to a new section,
+	Prerequisites for make-check.
+
 2010-03-01  Vladimir Serbinenko  phco...@gmail.com
 
 	* fs/ext2.c (grub_ext2_read_block): Fix an integer overflow.

=== modified file 'INSTALL'
--- INSTALL	2009-11-25 17:37:04 +
+++ INSTALL	2010-03-02 17:22:06 +
@@ -14,6 +14,7 @@
 * GCC 4.1.3 or later
 * GNU Make
 * GNU Bison 2.3 or later
+* GNU gettext 0.17 or later
 * GNU binutils 2.9.1.0.23 or later
 * Other standard GNU/Unix tools
 
@@ -25,6 +26,10 @@
 * Autoconf 2.60 or later
 * Automake 1.10.1 or later
 
+Prerequisites for make-check:
+
+* qemu, specifically the binary 'qemu-system-i386'
+
 Configuring the GRUB
 
 

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: lua 'grub.run' does not return message text

2010-01-16 Thread Jordan Uggla 
On Thu, Jan 14, 2010 at 1:12 PM,  edgar.sol...@web.de wrote:
 When I run

 err,msg = grub.run(ls)

 only the variable err is filled with the exit code.
 msg is still nil .. I saw documentation that grub.run is supposed to return
 the output in the second variable.

In the latest bzr ( pushed a few minutes ago ) the interface matches
what is documented in http://grub.enbug.org/LUASupport . Be careful
though, it's only the error message that is returned, not the output
of ls. And an error message is only returned if there is an error.
For example:

errno, err_msg = grub.run( ls /boot) --Outputs grub/
print( errno, err_msg ) -- Outputs 0nil

errno, err_msg = grub.run( ls /boot/nonexistent ) -- Outputs nothing
print( errno, err_msg ) -- Outputs 5file not found

If you want to actually list and store devices / files from lua you
should use grub.enum_device() and grub.enum_file() .

-- 
Jordan Uggla ( Jordan_U on irc.freenode.net )


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: lua 'grub.run' does not return message text

2010-01-15 Thread Jordan Uggla 
On Thu, Jan 14, 2010 at 1:12 PM,  edgar.sol...@web.de wrote:
 When I run

 err,msg = grub.run(ls)

 only the variable err is filled with the exit code.
 msg is still nil .. I saw documentation that grub.run is supposed to return
 the output in the second variable.

 I use lua from grub-extras repository
 http://bzr.savannah.gnu.org/lh/grub-extras/
 checked out yesterday.

 What am I doing wrong?

 Thanks .. ede



 ___
 Grub-devel mailing list
 Grub-devel@gnu.org
 http://lists.gnu.org/mailman/listinfo/grub-devel


Looking briefly at the code, grub.run doesn't even attempt to return
the error message ( though that might be a useful feature to add ).
What documentation were you looking at?

-- 
Jordan Uggla ( Jordan_U on irc.freenode.net )


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: lua 'grub.run' does not return message text

2010-01-15 Thread Jordan Uggla 
On Fri, Jan 15, 2010 at 3:52 PM, Jordan Uggla jordan.ug...@gmail.com wrote:
 On Thu, Jan 14, 2010 at 1:12 PM,  edgar.sol...@web.de wrote:
 When I run

 err,msg = grub.run(ls)

 only the variable err is filled with the exit code.
 msg is still nil .. I saw documentation that grub.run is supposed to return
 the output in the second variable.

 I use lua from grub-extras repository
 http://bzr.savannah.gnu.org/lh/grub-extras/
 checked out yesterday.

 What am I doing wrong?

 Thanks .. ede



 ___
 Grub-devel mailing list
 Grub-devel@gnu.org
 http://lists.gnu.org/mailman/listinfo/grub-devel


 Looking briefly at the code, grub.run doesn't even attempt to return
 the error message ( though that might be a useful feature to add ).
 What documentation were you looking at?

 --
 Jordan Uggla ( Jordan_U on irc.freenode.net )


I forgot to mention, you can get the error message from the global
grub_errmsg after running grub.run(), but returning it would be a much
cleaner interface IMHO. It should be easy to also return the error
message but I am going to be very busy with other things until
February so I probably won't be able to work on it myself any time
soon.

-- 
Jordan Uggla ( Jordan_U on irc.freenode.net )


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Problems with grub-reboot/savedefault/default=saved

2010-01-06 Thread Jordan Uggla 
On Tue, Jan 5, 2010 at 3:08 AM, Colin Watson cjwat...@ubuntu.com wrote:
 2: Setting GRUB_DEFAULT=saved in /etc/default/grub also enables savedefault
 functionality. There are many people who would want to use grub-reboot and
 grub-set-default without savedefault. The second patch adds a separate
 variable, GRUB_SAVEDEFAULT, for enabling savedefault.

 How would this interact with setting GRUB_DEFAULT to something other
 than saved, and doesn't 00_header.in also need to be changed to
 actually use the saved entry (it won't be used unless you have
 GRUB_DEFAULT=saved)?

That's correct. Perhaps GRUB_SAVEDEFAULT=true should imply GRUB_DEFAULT=saved?

( if [ x${GRUB_DEFAULT} = xsaved  -o x${GRUB_SAVEDEFAULT} =
xtrue ] ; then GRUB_DEFAULT='${saved_entry}' ;  )

 In my mind, GRUB_DEFAULT was overloaded for this for a good reason; but
 perhaps I'm simply not understanding what you mean, so would you mind
 explaining further how you'd like to see the whole thing laid out?

I am not set on a single layout ( I'd like input from others on
exactly how this should work ). But I do think that it should be
possible to use utilities like grub-set-default and grub-reboot
without also enabling savedefault. As an example use case:

Jane has a server with two boot options, one is a well tested, known
working, configuration and the other is a system for experimenting.
When she has physical access to the server she can select the
experimental option and if anything goes wrong she can reboot into the
stable configuration if needed. When she is administering the server
remotely though, she needs to be sure that she won't completely lose
access to the server if the experimental system fails to boot ( or
bring up the network connection / ssh properly ).

Because of this problem, Jane always wants the safe configuration to
be the default so that if anything goes wrong she can simply power
cycle the machine and fix things from the working system ( I'm not
sure why it's so common that people have the ability to remotely power
cycle but no remote access the console to be able to use the grub
menu, but every person I have talked to that uses grub-reboot is in
such a situation ). If she is in the safe configuration and wants to
remotely switch to the experimental one she uses grub-reboot to
temporarily change the default. Note that she never wants to change
the default permanently, but that's what savedefault will do if she
selects the experimental boot option from the grub menu ( rather than
grub-reboot ) and safedefault is being used.

I would guess, though I have no data to back it up, that in fact most
grub-reboot users do not want to use savedefault.

 5: Since grub2 uses menu entry titles for savedefault instead of numbers,
 the default kernel booted won't be changed when the user installs a new
 kernel. Using titles instead of numbers is good, but an unfortunate
 consequence that users may not realize ( and was not true with savedefault
 in grub-legacy ) is that if users set GRUB_SAVEDEFAULT=true they will never
 actually boot any updated kernels unless they select them manually at the
 grub menu. This could lead to not getting security updates for the kernel,
 and with major upgrades could cause serious problems when the old kernel
 doesn't work with newer userland components like Xorg. I can't think of a
 good way to solve this problem.

 IIRC GRUB Legacy (or at least Debian's update-grub, once upon a time)
 handled this by having a special default entry at the top of the Linux
 kernel list. Would it be worth introducing this to grub-mkconfig?

Recently Vladimir has talked about having submenus ( one debian menu
with separate kernel versions in a submenu for instance ) which will
probably help solve this problem.
-- 
Jordan Uggla ( Jordan_U on irc.freenode.net )


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Problems with grub-reboot/savedefault/default=saved

2009-12-20 Thread Jordan Uggla 
I found another bug. For some reason grub-reboot ( the utility )  
checks if prev_saved_entry ( which has just been set equal to 
saved_entry ) is empty ( zero length or unset ), and if it is 
unsets it. This makes grub-reboot again equivalent to 
grub-set-default the first time you use it. Instead I changed it 
so that if prev_saved_entry is empty it gets set to 0 because 
default=0 is the same as default= but the grub.cfg detects 
that you've used grub-reboot by checking if prev_saved_entry is 
not empty.

I've attached a fix for this and also updated my previous 
patches so they apply cleanly and are consistent with the new 
changes from the savedefault branch that were merged into 
experimental ( using set var=value instead of just var=value ).
-- 
Jordan Uggla ( Jordan_U on irc.freenode.net )
=== modified file 'util/grub-mkconfig_lib.in'
--- old/util/grub-mkconfig_lib.in	2009-12-17 17:34:56 +
+++ new/util/grub-mkconfig_lib.in	2009-12-16 20:12:30 +
@@ -97,8 +97,10 @@
 save_default_entry ()
 {
   if [ x${GRUB_DEFAULT} = xsaved ] ; then
-echo 'set saved_entry=${chosen}'
-echo 'save_env saved_entry'
+echo 'if [ ${boot_once} != true ]; then'
+echo '	set saved_entry=${chosen}'
+echo '	save_env saved_entry'
+echo 'fi'
   fi
 }
 

=== modified file 'util/grub.d/00_header.in'
--- old/util/grub.d/00_header.in	2009-12-17 17:34:56 +
+++ new/util/grub.d/00_header.in	2009-12-16 20:12:30 +
@@ -48,6 +48,7 @@
   save_env saved_entry
   set prev_saved_entry=
   save_env prev_saved_entry
+  set boot_once=true
 fi
 EOF
 

=== modified file 'util/grub-mkconfig.in'
--- old/util/grub-mkconfig.in	2009-12-12 00:43:32 +
+++ new/util/grub-mkconfig.in	2009-12-16 20:22:36 +
@@ -220,7 +220,8 @@
   GRUB_DISABLE_LINUX_UUID \
   GRUB_DISABLE_LINUX_RECOVERY \
   GRUB_GFXMODE \
-  GRUB_DISABLE_OS_PROBER
+  GRUB_DISABLE_OS_PROBER \
+  GRUB_SAVEDEFAULT
 
 if test x${grub_cfg} != x; then
   rm -f ${grub_cfg}.new

=== modified file 'util/grub-mkconfig_lib.in'
--- old/util/grub-mkconfig_lib.in	2009-12-16 20:12:30 +
+++ new/util/grub-mkconfig_lib.in	2009-12-16 20:22:36 +
@@ -96,7 +96,7 @@
 
 save_default_entry ()
 {
-  if [ x${GRUB_DEFAULT} = xsaved ] ; then
+  if [ x${GRUB_SAVEDEFAULT} = xtrue ] ; then
 echo 'if [ ${boot_once} != true ]; then'
 echo '	set saved_entry=${chosen}'
 echo '	save_env saved_entry'

=== modified file 'util/grub-mkconfig_lib.in'
--- old/util/grub-mkconfig_lib.in	2009-12-16 20:22:36 +
+++ new/util/grub-mkconfig_lib.in	2009-12-16 20:25:37 +
@@ -97,10 +97,7 @@
 save_default_entry ()
 {
   if [ x${GRUB_SAVEDEFAULT} = xtrue ] ; then
-echo 'if [ ${boot_once} != true ]; then'
-echo '	set saved_entry=${chosen}'
-echo '	save_env saved_entry'
-echo 'fi'
+echo 'savedefault'
   fi
 }
 

=== modified file 'util/grub.d/00_header.in'
--- old/util/grub.d/00_header.in	2009-12-16 20:12:30 +
+++ new/util/grub.d/00_header.in	2009-12-16 20:25:37 +
@@ -50,6 +50,14 @@
   save_env prev_saved_entry
   set boot_once=true
 fi
+
+function savedefault {
+  if [ \${boot_once} != true ]; then
+set saved_entry=\${chosen}
+save_env saved_entry
+  fi
+}
+
 EOF
 
 case ${GRUB_TERMINAL_INPUT}:${GRUB_TERMINAL_OUTPUT} in

=== modified file 'util/grub.d/00_header.in'
--- old/util/grub.d/00_header.in	2009-12-16 20:25:37 +
+++ new/util/grub.d/00_header.in	2009-12-20 01:45:32 +
@@ -45,10 +45,13 @@
 set default=${GRUB_DEFAULT}
 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
+  if save_env saved_entry; then
+set prev_saved_entry=
+save_env prev_saved_entry
+set boot_once=true
+  else
+set default=\${prev_saved_entry}
+  fi
 fi
 
 function savedefault {

=== modified file 'util/grub-reboot.in'
--- old/util/grub-reboot.in	2009-12-08 01:00:26 +
+++ new/util/grub-reboot.in	2009-12-20 06:57:34 +
@@ -96,7 +96,10 @@
 if [ $prev_saved_entry ]; then
 $grub_editenv ${grubdir}/grubenv set prev_saved_entry=$prev_saved_entry
 else
-$grub_editenv ${grubdir}/grubenv unset prev_saved_entry
+#Set prev_saved_entry to zero. Setting the default to 0 is the same as
+#setting it to  but because of the way grub-reboot is currently
+#implemented prev_saved_entry can't be zero length.
+$grub_editenv ${grubdir}/grubenv set prev_saved_entry=0
 fi
 $grub_editenv ${grubdir}/grubenv set saved_entry=$entry
 

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Problems with grub-reboot/savedefault/default=saved

2009-12-16 Thread Jordan Uggla 
There are multiple problems with grub-reboot/savedefault/default=saved.

1: grub-reboot doesn't restore the default after rebooting, making it 
effectively equivalent to grub-set-default. This is because the 
savedefault functionality currently saves the entry you boot from as the 
new default even when grub-reboot is used. Because of problem #2 there is 
no way ( outside manually editing the grub.cfg ) to use grub-reboot without 
savedefault functionality also enabled ( and thus no configuration where 
grub-reboot isn't broken ). I've added a patch for this to 
the bug report @ http://savannah.gnu.org/bugs/?28161 and as the first patch 
attached to this email.

2: Setting GRUB_DEFAULT=saved in /etc/default/grub also enables savedefault 
functionality. There are many people who would want to use grub-reboot and 
grub-set-default without savedefault. The second patch adds a separate 
variable, GRUB_SAVEDEFAULT, for enabling savedefault.

3: Savedefault functionality currently adds two lines ( one setting a 
variable, the other saving it ) to every menu entry and with my patch for 
fixing grub-reboot, an if statement as well. This clutters the menu entries 
and makes it hard to write and maintain custom menu entries with 
savedefault. The third patch moves this to a function savedefault defined 
in 00_header so entries just have to have savedefault, like in grub 
legacy. And if the implementation of savedefault needs to change, custom 
menu entries will still work unmodified.

4: Even with the first grub-reboot fix the default is still not restored 
when grubenv is not writable ( /boot on lvm for example ). Since 
grub-reboot can't work without a writable grubenv it's at least safer to 
boot into the real default instead of the temporary default. The 
fourth patch sets default=$prev_saved_default if save_env fails. 
Grub-reboot ( the utility ) should also complain when grubenv isn't 
writable by grub. What is the best way to determine that grubenv likely is 
or isn't writable by grub?

5: Since grub2 uses menu entry titles for savedefault instead of numbers, 
the default kernel booted won't be changed when the user installs a new 
kernel. Using titles instead of numbers is good, but an unfortunate 
consequence that users may not realize ( and was not true with savedefault 
in grub-legacy ) is that if users set GRUB_SAVEDEFAULT=true they will never 
actually boot any updated kernels unless they select them manually at the 
grub menu. This could lead to not getting security updates for the kernel, 
and with major upgrades could cause serious problems when the old kernel 
doesn't work with newer userland components like Xorg. I can't think of a 
good way to solve this problem.

-- 
Jordan Uggla ( Jordan_U on irc.freenode.net )
=== modified file 'util/grub-mkconfig_lib.in'
--- old/util/grub-mkconfig_lib.in	2009-12-09 21:03:26 +
+++ new/util/grub-mkconfig_lib.in	2009-12-16 20:12:30 +
@@ -97,8 +97,10 @@
 save_default_entry ()
 {
   if [ x${GRUB_DEFAULT} = xsaved ] ; then
-echo 'saved_entry=${chosen}'
-echo 'save_env saved_entry'
+echo 'if [ ${boot_once} != true ]; then'
+echo '	saved_entry=${chosen}'
+echo '	save_env saved_entry'
+echo 'fi'
   fi
 }
 

=== modified file 'util/grub.d/00_header.in'
--- old/util/grub.d/00_header.in	2009-11-24 00:22:41 +
+++ new/util/grub.d/00_header.in	2009-12-16 20:12:30 +
@@ -46,6 +46,7 @@
   save_env saved_entry
   prev_saved_entry=
   save_env prev_saved_entry
+  boot_once=true
 fi
 EOF
 

=== modified file 'util/grub-mkconfig.in'
--- old/util/grub-mkconfig.in	2009-12-12 00:43:32 +
+++ new/util/grub-mkconfig.in	2009-12-16 20:22:36 +
@@ -220,7 +220,8 @@
   GRUB_DISABLE_LINUX_UUID \
   GRUB_DISABLE_LINUX_RECOVERY \
   GRUB_GFXMODE \
-  GRUB_DISABLE_OS_PROBER
+  GRUB_DISABLE_OS_PROBER \
+  GRUB_SAVEDEFAULT
 
 if test x${grub_cfg} != x; then
   rm -f ${grub_cfg}.new

=== modified file 'util/grub-mkconfig_lib.in'
--- old/util/grub-mkconfig_lib.in	2009-12-16 20:12:30 +
+++ new/util/grub-mkconfig_lib.in	2009-12-16 20:22:36 +
@@ -96,7 +96,7 @@
 
 save_default_entry ()
 {
-  if [ x${GRUB_DEFAULT} = xsaved ] ; then
+  if [ x${GRUB_SAVEDEFAULT} = xtrue ] ; then
 echo 'if [ ${boot_once} != true ]; then'
 echo '	saved_entry=${chosen}'
 echo '	save_env saved_entry'

=== modified file 'util/grub-mkconfig_lib.in'
--- old/util/grub-mkconfig_lib.in	2009-12-16 20:22:36 +
+++ new/util/grub-mkconfig_lib.in	2009-12-16 20:25:37 +
@@ -97,10 +97,7 @@
 save_default_entry ()
 {
   if [ x${GRUB_SAVEDEFAULT} = xtrue ] ; then
-echo 'if [ ${boot_once} != true ]; then'
-echo '	saved_entry=${chosen}'
-echo '	save_env saved_entry'
-echo 'fi'
+echo 'savedefault'
   fi
 }
 

=== modified file 'util/grub.d/00_header.in'
--- old/util/grub.d/00_header.in	2009-12-16 20:12:30 +
+++ new/util/grub.d/00_header.in	2009-12-16 20:25:37 +
@@ -48,6 +48,14 @@
   save_env prev_saved_entry
   boot_once=true
 fi
+
+function

Re: Imminent bugfix release (1.97.1)

2009-11-08 Thread Jordan Uggla 
None of the .sh scripts ( autogen.sh and the scripts it uses ) are
executable; I needed to chmod 744 *.sh before I could run
./autogen.sh successfully. After doing that make failed with an error
in auth.c. This was with revision 1780. I've attached the output from
./configure and make.

On Sun, Nov 8, 2009 at 5:04 PM, Robert Millan r...@aybabtu.com wrote:

 A security problem [1] was found in our password-checking routines,
 which affects GRUB 1.97.  I'll be releasing 1.97.1 tomorrow.

 Additionally, I cherry-picked fixes for a few problems that should
 have made it to the release, like GNU/Hurd support (see NEWS file
 for details).  The release branch is available in:

  sftp://bzr.savannah.gnu.org/srv/bzr/grub/branches/release_1_97/

 If you have time, please test this tree, specially password support,
 to help find possible problems.

 Thanks!

 [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555195

 --
 Robert Millan

  The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all.


 ___
 Grub-devel mailing list
 Grub-devel@gnu.org
 http://lists.gnu.org/mailman/listinfo/grub-devel

checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for cmp... cmp
checking for bison... bison
checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for ruby... /usr/bin/ruby
checking for makeinfo... /usr/bin/makeinfo
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking whether byte ordering is bigendian... no
checking size of void *... 4
checking size of long... 4
checking whether our compiler is apple cc... no
checking for help2man... /usr/bin/help2man
checking for posix_memalign... yes
checking for memalign... yes
checking for asprintf... yes
checking for objcopy... objcopy
checking for strip... strip
checking for nm... nm
checking whether optimization for size works... yes
checking whether -falign-loops works... yes
checking whether -fno-dwarf2-cfi-asm works... yes
checking whether our target compiler is apple cc... no
checking for command to convert module to ELF format... 
checking whether `gcc' generates calls to `__enable_execute_stack()'... no
checking whether `gcc' has `-fPIE' as default... no
checking whether `gcc' accepts `-fstack-protector'... yes
checking whether `gcc' accepts `-mstack-arg-probe'... yes
checking for __bswapsi2... yes
checking for __bswapdi2... yes
checking for __ashldi3... yes
checking for __ashrdi3... yes
checking for __lshrdi3... yes
checking for __trampoline_setup... no
checking for __ucmpdi2... yes
checking whether target compiler is working... yes
checking whether objcopy works for absolute addresses... yes
checking whether linker accepts --build-id=none... yes
checking if C symbols get an underscore after compilation... no
checking if __bss_start is defined by the compiler... yes
checking if edata is defined by the compiler... yes
checking if _edata is defined by the compiler... yes
checking if end is defined by the compiler... yes
checking if _end is defined by the compiler... yes
checking whether addr32 must be in the same line as the instruction... yes
checking for .code16 addr32 assembler support... yes
checking whether an absolute indirect call/jump must not be prefixed with an asterisk... no
checking whether options required for efiemu work... yes
checking for wgetch in -lncurses... yes
checking ncurses/curses.h usability... no
checking ncurses/curses.h presence... no
checking for ncurses/curses.h... no
checking ncurses.h

Sourcing scripts from lua

2009-10-22 Thread Jordan Uggla 
Hi everyone,

Is there a good way to source lua scripts from within lua? I've tried
require() but the function doesn't exist. loadfile() and loadstring()
exist but always return nil.

--
Jordan Uggla ( Jordan_U on irc.freenode.net )


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel