Bug#741464: grub-pc-bin: hangs after displaying boot menu
Control: tag -1 +patch On Mon, 29 Oct 2018 00:36:00 +0100, Colin Watson wrote: > > On Sun, Feb 01, 2015 at 11:16:59PM +0100, Marco Gamberoni wrote: > > I see this same at_keyboard behaviour: working in VirtualBox, delivering > > garbage on this real hardware: > > - an HP Proliant DL380 Gen5 machine > > - with a Compaq PS/2 keyboard italian layout attached > > - booted from an iso image made with grub-mkrescue (GRUB) 2.02~beta2-15, > > containing a keyboard layout file made with > > ckbcomp -model pc105 -layout it | grub-mklayout -o pc105-it.gkb > [...] > > Having read > > > > http://web.archive.org/web/20040604041507/http://panda.cs.ndsu.nodak.edu/~achapwes/PICmicro/keyboard/atkeyboard.html > > it is obvious what's going on: at_keyboard is using scankey set 1 but the > > keyboard is using set 2 and the keyboard controller is not translating. > > Sorry for the long delay. Are you still in a position to test this? > > I just ran across this upstream commit: > > > https://git.savannah.gnu.org/cgit/grub.git/commit/?id=c4b8bec5fee4e30a165fd14a188cf3ab8eccd095 > > Ignoring the specific hardware mentioned here, it seems like this could > be a plausible cause: if GRUB manages to get out of sync with the > keyboard controller on the command/data sequence, then it could easily > end up confused about which is the current scan code set (see the > changes to query_mode in particular) and so end up using the wrong set, > or possibly even send a nonsense command somehow. It seems worth > testing if you can. I cherry-picked that commit and tested it but it didn't fix the problem. The bug was introduced somewhere between GRUB 2.00 and 2.02 so I used git bisect to find the commit that introduced the bug: https://git.savannah.gnu.org/cgit/grub.git/commit/?id=0c62a5b28e2783d84d266341c4388b494e058114 As far as I understand the change it will no longer poll forever in the module init when the keyboard controller isn't ready. The problem seems to be that we used to initialize the keyboard controller in the module init but now we always do it later when getkey is called. Somehow this messes up things but I have no idea why. I changed it so that it only initializes the keyboard controller when it is ready and doesn't poll when it isn't. Here is the merge request: https://salsa.debian.org/grub-team/grub/merge_requests/6 I've tested this on my old laptop (X200s thinkpad) and the problem goes away with this patch. Kind regards, Jeroen Dekkers
Processed: Re: Bug#741464: grub-pc-bin: hangs after displaying boot menu
Processing control commands: > tag -1 +patch Bug #741464 [grub-pc-bin] grub-pc-bin: freezes after "terminal_input at_keyboard" Added tag(s) patch. -- 741464: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741464 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#741464: grub-pc-bin: hangs after displaying boot menu
On Sun, Feb 01, 2015 at 11:16:59PM +0100, Marco Gamberoni wrote: > I see this same at_keyboard behaviour: working in VirtualBox, delivering > garbage on this real hardware: > - an HP Proliant DL380 Gen5 machine > - with a Compaq PS/2 keyboard italian layout attached > - booted from an iso image made with grub-mkrescue (GRUB) 2.02~beta2-15, > containing a keyboard layout file made with > ckbcomp -model pc105 -layout it | grub-mklayout -o pc105-it.gkb [...] > Having read > > http://web.archive.org/web/20040604041507/http://panda.cs.ndsu.nodak.edu/~achapwes/PICmicro/keyboard/atkeyboard.html > it is obvious what's going on: at_keyboard is using scankey set 1 but the > keyboard is using set 2 and the keyboard controller is not translating. Sorry for the long delay. Are you still in a position to test this? I just ran across this upstream commit: https://git.savannah.gnu.org/cgit/grub.git/commit/?id=c4b8bec5fee4e30a165fd14a188cf3ab8eccd095 Ignoring the specific hardware mentioned here, it seems like this could be a plausible cause: if GRUB manages to get out of sync with the keyboard controller on the command/data sequence, then it could easily end up confused about which is the current scan code set (see the changes to query_mode in particular) and so end up using the wrong set, or possibly even send a nonsense command somehow. It seems worth testing if you can. -- Colin Watson [cjwat...@debian.org]
Bug#741464: grub-pc-bin: hangs after displaying boot menu
On Tue, 31 Mar 2015 19:52:53 +0200 Marco Gamberoni wrote: > In data lunedì 23 marzo 2015 15:17:56, Colin Watson ha scritto: > > [...] > > > > Thanks for the debugging. Would you be able to try with this upstream > > patch, which looks somewhat promising for this? > > > > > > http://git.savannah.gnu.org/gitweb/?p=grub.git;a=commitdiff;h=3c058332499f6c0185c167a7faf37afa808136b7 > > > > Thanks, > > > > > > Have been away, seeing the message now. > I am willing to test the patch. > The patch does not look as I would expect, perhaps I am not understanding it > (just read it, not applied). > > But I have a job, with urgencies that won't allow free time for one or two > weeks. > > Be patient, if you decide to wait for me to test the patch. > > Bye > > Marco Gamberoni > > [...] Hi Marco and Colin, Did you have a chance to test the patch and see if it fixed this problem? Thanks, ~Niels
Bug#741464: grub-pc-bin: hangs after displaying boot menu
In data lunedì 23 marzo 2015 15:17:56, Colin Watson ha scritto: > On Sun, Feb 01, 2015 at 11:16:59PM +0100, Marco Gamberoni wrote: > > Having read > > > > http://web.archive.org/web/20040604041507/http://panda.cs.ndsu.nodak.edu/~achapwes/PICmicro/keyboard/atkeyboard.html > > it is obvious what's going on: at_keyboard is using scankey set 1 but > > the keyboard is using set 2 and the keyboard controller is not > > translating. > > The cause of the mismatch is the XLAT bit in the keyboard controller > > command byte that transitions from 1 to 0 while grub executes > > terminal_input at_keyboard. > [...] > > Thanks for the debugging. Would you be able to try with this upstream > patch, which looks somewhat promising for this? > > > http://git.savannah.gnu.org/gitweb/?p=grub.git;a=commitdiff;h=3c058332499f6c0185c167a7faf37afa808136b7 > > Thanks, > > Have been away, seeing the message now. I am willing to test the patch. The patch does not look as I would expect, perhaps I am not understanding it (just read it, not applied). But I have a job, with urgencies that won't allow free time for one or two weeks. Be patient, if you decide to wait for me to test the patch. Bye Marco Gamberoni _ PGP Fingerprint: 945C CE09 7D11 E1A0 5D8D 306E DAE1 C4A6 0BB3 7A16 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#741464: grub-pc-bin: hangs after displaying boot menu
On Sun, Feb 01, 2015 at 11:16:59PM +0100, Marco Gamberoni wrote: > Having read > > http://web.archive.org/web/20040604041507/http://panda.cs.ndsu.nodak.edu/~achapwes/PICmicro/keyboard/atkeyboard.html > it is obvious what's going on: at_keyboard is using scankey set 1 but > the keyboard is using set 2 and the keyboard controller is not > translating. > The cause of the mismatch is the XLAT bit in the keyboard controller > command byte that transitions from 1 to 0 while grub executes > terminal_input at_keyboard. [...] Thanks for the debugging. Would you be able to try with this upstream patch, which looks somewhat promising for this? http://git.savannah.gnu.org/gitweb/?p=grub.git;a=commitdiff;h=3c058332499f6c0185c167a7faf37afa808136b7 Thanks, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#741464: grub-pc-bin: hangs after displaying boot menu
On Sun, 01 Feb 2015 23:16:59 +0100 I wrote: ... > I suppose the fact that this one liner IS NOT DOING THE JOB (the keyboard > controller does not get the XLAT bit set) > terminal_input at_keyboard ; outb 0x64 0x60 ; outb 0x60 0x40 0x40 > should signify something ... Signifies my face is red... The right one liner is terminal_input at_keyboard ; outb 0x64 0x60 ; outb 0x60 0x64 the last 0x64 is the value to write in the keyboard controller command byte. outb with a mask is incompatible with the way the the keyboard controller command byte is read and written. If I understand the intent of USE_SCANCODE_SET, I suppose line 357 in at_keyboard.c #if !USE_SCANCODE_SET should be #if USE_SCANCODE_SET without the not. Still, I do not find the code that matches the changes in the keyboard controller command byte I am seeing. Ciao, Marco Gamberoni _ PGP Fingerprint: 945C CE09 7D11 E1A0 5D8D 306E DAE1 C4A6 0BB3 7A16 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#741464: grub-pc-bin: hangs after displaying boot menu
On Mon, 15 Dec 2014 10:51:43 +0100 Jeroen Dekkers wrote: > Thu, 16 Oct 2014 17:57:20 +0200 Sven Joachim wrote: ... > I tried to reproduce this in a virtual machine (using kvm), but under > kvm everything seems to work fine including the german keyboard > layout. When I tried it on real hardware I could reproduce the > problem, but instead of freezing I got garbage input after switching > terminal_input to at_keyboard. > > > Kind regards, > > Jeroen Dekkers > > I see this same at_keyboard behaviour: working in VirtualBox, delivering garbage on this real hardware: - an HP Proliant DL380 Gen5 machine - with a Compaq PS/2 keyboard italian layout attached - booted from an iso image made with grub-mkrescue (GRUB) 2.02~beta2-15, containing a keyboard layout file made with ckbcomp -model pc105 -layout it | grub-mklayout -o pc105-it.gkb The iso image boots to a grub command line, where these commands reproduce the buggy behaviour: set debug=atkeyb terminal_input at_keyboard now any key produces garbage, and a message term/at_keyboard.c:461: Unknown key 0xf0 from set 1 Having read http://web.archive.org/web/20040604041507/http://panda.cs.ndsu.nodak.edu/~achapwes/PICmicro/keyboard/atkeyboard.html it is obvious what's going on: at_keyboard is using scankey set 1 but the keyboard is using set 2 and the keyboard controller is not translating. The cause of the mismatch is the XLAT bit in the keyboard controller command byte that transitions from 1 to 0 while grub executes terminal_input at_keyboard. I can prove my theory only using a serial port to maintain a working input channel to grub: serial terminal_input at_keyboard serial_com1 gives a non working at_keyboard and a working serial input. From the serial input, these grub commands make at_keyboard work: outb 0x64 0x60 ; outb 0x60 0x40 0x40 outb is not documented in info grub, what they do is setting to 1 the XLAT bit in the keyboard controller command byte. Now grub happily accepts keymap (cd)/pc105-it.gkb that gives me the working at_keyboard with italian layout I will need it to enter LUKS passphrases. I suppose the fact that this one liner IS NOT DOING THE JOB (the keyboard controller does not get the XLAT bit set) terminal_input at_keyboard ; outb 0x64 0x60 ; outb 0x60 0x40 0x40 should signify something, but I have not found what, looking at at_keyboard.c http://code.metager.de/source/xref/gnu/grub/grub-core/term/at_keyboard.c#grub_keyboard_controller_init Clearly, the initialization performed in grub_keyboard_controller_init is incomplete, but I cannot see where the XLAT bit gets reset after 'terminal_input at_keyboard' command returns. Ciao Marco Gamberoni -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#741464: grub-pc-bin: hangs after displaying boot menu
Hello, I tried if I could reproduce this issue. (In my setup there is a tftp delivering grub installed by grub-mknetdir) I could not get it to hang by "terminal_input at_keyboard". But similar to what Jeroen Dekkers described I was not able anymore to enter sane text with the keyboard. It feels like only every ~10th key appears in grub. (In virtualbox, qemu and on a real machine, with grub from testing and/or a build from upstream git.) I could track it down to calls into the PXE stack. By avoiding these calls normal keyboard input is then still possible when having at_keyboard loaded. (Unfortunately being then not able to load anything via network). By using a test function which does only the protected to real mode switch and back without the actual PXE call, I assume the problem is only with the mode switch itself - somehow resetting keyboard states. Attached patch (against upstream) should help in debugging the problem: - if environment no_nic_poll is set to 1, avoid the problematic PXE call - if environment no_nic_poll is set to 1 make only the switch from protected mode to real and back (and avoids the problematic PXE call) That way the keyboard input stays fluid when using this sequence: set no_nic_poll=1 terminal_input at_keyboard When you now unset the environment the keyboard reacts broken again: unset no_nic_poll (Booting would still be possible if the environment is reset just before downloading any files) Unfortunately I was not able to reproduce it on a plain from harddisk loaded grub. That leaves a couple of questions open: - have the submitter and commenter also a setup involving PXE? - or do we have 2 or 3 different problems? Kind regards, Bernhard From 39a1748cd3a4ec9e7f8e6449e3fd131143b77c05 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= Date: Thu, 18 Dec 2014 01:26:01 +0100 Subject: Help debugging debian bug #741464 --- grub-core/kern/i386/pc/startup.S| 102 +++- grub-core/net/drivers/i386/pc/pxe.c | 7 +++ include/grub/i386/pc/pxe.h | 1 + 3 files changed, 75 insertions(+), 35 deletions(-) diff --git a/grub-core/kern/i386/pc/startup.S b/grub-core/kern/i386/pc/startup.S index 6bb36c6..1fc0011 100644 --- a/grub-core/kern/i386/pc/startup.S +++ b/grub-core/kern/i386/pc/startup.S @@ -159,42 +159,74 @@ FUNCTION(grub_exit) * int grub_pxe_call (int func, void* data, grub_uint32_t pxe_rm_entry); */ FUNCTION(grub_pxe_call) - pushl %ebp - movl %esp, %ebp - pushl %esi - pushl %edi - pushl %ebx - - movl %ecx, %ebx - movl %eax, %ecx - movl %edx, %eax - andl $0xF, %eax - shrl $4, %edx - shll $16, %edx - addl %eax, %edx +pushl %ebp +movl %esp, %ebp +pushl %esi +pushl %edi +pushl %ebx + +movl %ecx, %ebx +movl %eax, %ecx +movl %edx, %eax +andl $0xF, %eax +shrl $4, %edx +shll $16, %edx +addl %eax, %edx + +PROT_TO_REAL +.code16 + +pushl %ebx +pushl %edx +pushw %cx +movw %sp, %bx +lcall *%ss:6(%bx) +cld +addw $10, %sp +movw %ax, %cx + +REAL_TO_PROT +.code32 + +movzwl %cx, %eax + +popl %ebx +popl %edi +popl %esi +popl %ebp +ret - PROT_TO_REAL - .code16 - - pushl %ebx - pushl %edx - pushw %cx - movw %sp, %bx - lcall *%ss:6(%bx) - cld - addw $10, %sp - movw %ax, %cx - - REAL_TO_PROT - .code32 - - movzwl %cx, %eax - - popl %ebx - popl %edi - popl %esi - popl %ebp - ret +/* + * int prot_to_real_to_prot (int func, void* data, grub_uint32_t pxe_rm_entry); + */ +FUNCTION(prot_to_real_to_prot) +pushl %ebp +movl %esp, %ebp +pushl %esi +pushl %edi +pushl %ebx + +movl %ecx, %ebx +movl %eax, %ecx +movl %edx, %eax +andl $0xF, %eax +shrl $4, %edx +shll $16, %edx +addl %eax, %edx + +PROT_TO_REAL +.code16 + +REAL_TO_PROT +.code32 + +movzwl %cx, %eax + +popl %ebx +popl %edi +popl %esi +popl %ebp +ret #include "../int.S" diff --git a/grub-core/net/drivers/i386/pc/pxe.c b/grub-core/net/drivers/i386/pc/pxe.c index e8c0b22..801a34c 100644 --- a/grub-core/net/drivers/i386/pc/pxe.c +++ b/grub-core/net/drivers/i386/pc/pxe.c @@ -180,6 +180,13 @@ grub_pxe_recv (struct grub_net_card *dev __attribute__ ((unused))) { grub_memset (isr, 0, sizeof (*isr)); isr->func_flag = GRUB_PXE_ISR_IN_START; + + const char *debug = grub_env_get ("no_nic_poll"); + if (debug && debug[0] >= '2') + prot_to_real_to_prot (GRUB_PXENV_UNDI_ISR, isr, pxe_rm_entry); + if (debug && debug[0] >= '1') + return NULL; + grub_pxe_call (GRUB_PXENV_UNDI_ISR, isr, pxe_rm_entry); /* Normally according to the specification we should also check that isr->func_flag !=
Bug#741464: grub-pc-bin: hangs after displaying boot menu
Thu, 16 Oct 2014 17:57:20 +0200 Sven Joachim wrote: > On 2014-10-13 16:25 +0200, Colin Watson wrote: > > > On Wed, Mar 12, 2014 at 08:24:31PM +0100, Sven Joachim wrote: > >> After upgrading the grub packages and rebooting my laptop, grub > >> displayed the boot menu and then was hung. The countdown before > >> booting the default kernel was not started and grub did not accept any > >> keyboard input. > >> > >> I had to boot a rescue system from a USB stick, chroot into my > >> installation and downgrade to 2.00-22 to get back to a working system. > > > > Sorry for the delay in replying to this. Could you please post the > > output of: > > > > sudo debconf-show grub-pc > > > > ? Is there anything else interesting about your system, since this is > > not something I can reproduce? > > I have diverted /sbin/update-grub to maintain /boot/grub/grub.cfg by > hand, as you suggested in bug #578576. Therefore the debconf data are > probably not too interesting. > > > Bearing in mind the period of time > > involved, it might also be worth trying with 2.02~beta2-14 now that you > > have rescue media to hand. > > I have managed to install 2.02~beta2-15 on a USB stick which is much > easier to recover, and the offending command which causes grub to freeze > is "terminal_input at_keyboard", which I have been using for obtaining a > German keyboard layout (see #686817 on that matter; I'm sure there was > an even older bug, but cannot find it now). If I remove that statement, > grub works. From the grub command line I can "insmod at_keyboard" > without problems, but "terminal_input at_keyboard" freezes grub. I tried to reproduce this in a virtual machine (using kvm), but under kvm everything seems to work fine including the german keyboard layout. When I tried it on real hardware I could reproduce the problem, but instead of freezing I got garbage input after switching terminal_input to at_keyboard. Kind regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#741464: grub-pc-bin: hangs after displaying boot menu
Control: retitle -1 grub-pc-bin: freezes after "terminal_input at_keyboard" On 2014-10-13 16:25 +0200, Colin Watson wrote: > On Wed, Mar 12, 2014 at 08:24:31PM +0100, Sven Joachim wrote: >> After upgrading the grub packages and rebooting my laptop, grub >> displayed the boot menu and then was hung. The countdown before >> booting the default kernel was not started and grub did not accept any >> keyboard input. >> >> I had to boot a rescue system from a USB stick, chroot into my >> installation and downgrade to 2.00-22 to get back to a working system. > > Sorry for the delay in replying to this. Could you please post the > output of: > > sudo debconf-show grub-pc > > ? Is there anything else interesting about your system, since this is > not something I can reproduce? I have diverted /sbin/update-grub to maintain /boot/grub/grub.cfg by hand, as you suggested in bug #578576. Therefore the debconf data are probably not too interesting. > Bearing in mind the period of time > involved, it might also be worth trying with 2.02~beta2-14 now that you > have rescue media to hand. I have managed to install 2.02~beta2-15 on a USB stick which is much easier to recover, and the offending command which causes grub to freeze is "terminal_input at_keyboard", which I have been using for obtaining a German keyboard layout (see #686817 on that matter; I'm sure there was an even older bug, but cannot find it now). If I remove that statement, grub works. From the grub command line I can "insmod at_keyboard" without problems, but "terminal_input at_keyboard" freezes grub. Cheers, Sven -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#741464: grub-pc-bin: hangs after displaying boot menu
Processing control commands: > retitle -1 grub-pc-bin: freezes after "terminal_input at_keyboard" Bug #741464 [grub-pc-bin] grub-pc-bin: hangs after displaying boot menu Changed Bug title to 'grub-pc-bin: freezes after "terminal_input at_keyboard"' from 'grub-pc-bin: hangs after displaying boot menu' -- 741464: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741464 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#741464: grub-pc-bin: hangs after displaying boot menu
On Wed, Mar 12, 2014 at 08:24:31PM +0100, Sven Joachim wrote: > After upgrading the grub packages and rebooting my laptop, grub > displayed the boot menu and then was hung. The countdown before > booting the default kernel was not started and grub did not accept any > keyboard input. > > I had to boot a rescue system from a USB stick, chroot into my > installation and downgrade to 2.00-22 to get back to a working system. Sorry for the delay in replying to this. Could you please post the output of: sudo debconf-show grub-pc ? Is there anything else interesting about your system, since this is not something I can reproduce? Bearing in mind the period of time involved, it might also be worth trying with 2.02~beta2-14 now that you have rescue media to hand. Thanks, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#741464: grub-pc-bin: hangs after displaying boot menu
Package: grub-pc-bin Version: 2.02~beta2-7 Severity: critical After upgrading the grub packages and rebooting my laptop, grub displayed the boot menu and then was hung. The countdown before booting the default kernel was not started and grub did not accept any keyboard input. I had to boot a rescue system from a USB stick, chroot into my installation and downgrade to 2.00-22 to get back to a working system. -- Package-specific info: *** BEGIN /proc/mounts /dev/sda5 / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 /dev/sda1 /boot ext2 rw,nosuid,nodev,relatime 0 0 *** END /proc/mounts *** BEGIN /boot/grub/device.map (hd0) /dev/disk/by-id/ata-HTS541060G9AT00_MPB3PAXGKN2KZG *** END /boot/grub/device.map *** BEGIN /boot/grub/grub.cfg ### BEGIN /etc/grub.d/00_header ### if [ -s $prefix/grubenv ]; then load_env fi set default="0" 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 { insmod vbe insmod vga insmod video_bochs insmod video_cirrus } terminal_input console terminal_output console set timeout=10 ### END /etc/grub.d/00_header ### set menu_color_normal=cyan/blue set menu_color_highlight=white/blue insmod gzio insmod part_msdos insmod ext2 set root='(hd0,msdos1)' ### BEGIN /etc/grub.d/10_linux ### menuentry 'Debian GNU/Linux (Kernel 3.13.6-kms)' { echo'Loading Linux 3.13.6-kms ...' linux /vmlinuz-3.13.6-kms root=/dev/sda5 ro quiet init=/bin/systemd echo'Loading initial ramdisk ...' initrd /initrd.img-3.13.6-kms } menuentry 'Debian GNU/Linux (Kernel 3.13.6-kms, Sysvinit)' { echo'Loading Linux 3.13.6-kms ...' linux /vmlinuz-3.13.6-kms root=/dev/sda5 ro quiet init 2 echo'Loading initial ramdisk ...' initrd /initrd.img-3.13.6-kms } menuentry 'Debian GNU/Linux (Kernel 3.14.0-rc6-kms)' { echo'Loading Linux 3.14.0-rc6-kms ...' linux /vmlinuz-3.14.0-rc6-kms root=/dev/sda5 ro quiet init=/bin/systemd echo'Loading initial ramdisk ...' initrd /initrd.img-3.14.0-rc6-kms } menuentry 'Debian GNU/Linux (Kernel 3.14.0-rc6-kms, Sysvinit)' { echo'Loading Linux 3.14.0-rc6-kms ...' linux /vmlinuz-3.14.0-rc6-kms root=/dev/sda5 ro quiet init 2 echo'Loading initial ramdisk ...' initrd /initrd.img-3.14.0-rc6-kms } menuentry 'Debian GNU/Linux (Kernel 3.12.14-kms)' { echo'Loading Linux 3.12.14-kms ...' linux /vmlinuz-3.12.14-kms root=/dev/sda5 ro quiet init=/bin/systemd echo'Loading initial ramdisk ...' initrd /initrd.img-3.12.14-kms } menuentry 'Debian GNU/Linux (Kernel 3.12.14-kms, Sysvinit)' { echo'Loading Linux 3.12.14-kms ...' linux /vmlinuz-3.12.14-kms root=/dev/sda5 ro quiet init 2 echo'Loading initial ramdisk ...' initrd /initrd.img-3.12.14-kms } menuentry 'Debian GNU/Linux (Kernel 3.10.33-kms)' { echo'Loading Linux 3.10.33-kms ...' linux /vmlinuz-3.10.33-kms root=/dev/sda5 ro quiet init=/bin/systemd echo'Loading initial ramdisk ...' initrd /initrd.img-3.10.33-kms } menuentry 'Debian GNU/Linux (Kernel 3.10.33-kms, Sysvinit)' { echo'Loading Linux 3.10.33-kms ...' linux /vmlinuz-3.10.33-kms root=/dev/sda5 ro quiet init 2 echo'Loading initial ramdisk ...' initrd /initrd.img-3.10.33-kms } menuentry 'Debian GNU/Linux (Kernel 3.4.83-kms)' { echo'Loading Linux 3.4.83-kms ...' linux /vmlinuz-3.4.83-kms root=/dev/sda5 ro quiet init=/bin/systemd echo'Loading initial ramdisk ...' initrd /initrd.img-3.4.83-kms } menuentry 'Debian GNU/Linux (Kernel 3.4.83-kms, Sysvinit)' { echo'Loading Linux 3.4.83-kms ...' linux /vmlinuz-3.4.83-kms root=/dev/sda5 ro quiet init 2 echo'Loading initial ramdisk ...' initrd /initrd.img-3.4.83-kms } menuentry 'Debian GNU/Linux (Kernel 3.2.55-kms)' { echo'Loading Linux 3.2.55-kms ...' linux /vmlinuz-3.2.55-kms root=/dev/sda5 ro quiet init=/bin/systemd echo'Loading initial ramdisk ...' initrd /initrd.img-3.2.55-kms } menuentry 'Debian GNU/Linux (Kernel 3.2.55-kms, Sysvinit)' { echo'Loading Linux 3.2.55-kms ...' linux /vmlinuz-3.2.55-kms root=/dev/sda5 ro quiet init 2 echo'Loading initial ramdisk ...' initrd /initrd.img-3.2.55-kms } menuentry 'Debian GNU/Linux (Kernel 3.13-1-686-pae)' { echo'Loading Linux 3.13-1-686-pae ...' linux /vmlinuz-3.13-1-686-pae root=/dev/sda5 ro quiet init=/bin/s