Hello,
Damien Zammit, le dim. 16 juil. 2023 10:40:29 +, a ecrit:
> This adds a new grub module called hurdhelper.
That's both simple to implement and interesting for use, thanks!
> This module simplifies the loading of hurd multiboot modules
> by allowing them to be loaded i
This adds a new grub module called hurdhelper.
This module simplifies the loading of hurd multiboot modules
by allowing them to be loaded in one line (in order of loading).
A typical use case would be:
grub> insmod hurdhelper
grub> multiboot /boot/gnumach-1.8-486-dbg.gz root=part:2:devi
Applied, thanks!
Flavio Cruz, le ven. 06 janv. 2023 00:24:38 -0500, a ecrit:
> mbchk is not part of grub2 and only available on grub-legacy.
> ---
> tests/Makefrag.am | 2 +-
> tests/configfrag.ac| 2 +-
> tests/{test-mbchk.in =>
mbchk is not part of grub2 and only available on grub-legacy.
---
tests/Makefrag.am | 2 +-
tests/configfrag.ac| 2 +-
tests/{test-mbchk.in => test-multiboot.in} | 8
3 files changed, 6 insertions(+), 6 deletions(-)
rename tests/{t
Hello,
Damien Zammit, le ven. 30 sept. 2022 12:53:27 +, a ecrit:
> This adds a new grub module called hurdhelper.
That's nice, but be should be submitted to the grub mailing list :)
> +#define ACPI_TASK"acpi"
> +#define PCI_TASK "pci-
This adds a new grub module called hurdhelper.
This module simplifies the loading of hurd multiboot modules
by allowing them to be loaded in one line (in order of loading).
A typical use case would be:
insmod multiboot
insmod hurdhelper
multiboot /boot/gnumach-1.8-486
Luca, le dim. 28 août 2022 09:54:43 +0200, a ecrit:
> Il 27 agosto 2022 20:02:40 UTC, Samuel Thibault ha
> scritto:
> > Samuel Thibault, le sam. 27 août 2022 21:41:57 +0200, a ecrit:
> > > Mmm, on the set_cr3() in i386at_init call, it reboots...
> >
> > Ah, reducing the memory size to 2G fixed it
Il 27 agosto 2022 20:02:40 UTC, Samuel Thibault
ha scritto:
Samuel Thibault, le sam. 27 août 2022 21:41:57 +0200, a ecrit:
Mmm, on the set_cr3() in i386at_init call, it reboots...
Ah, reducing the memory size to 2G fixed it. The kernel_pmap->l4base
address was at 0xFFFD3000, apparently that w
Samuel Thibault, le sam. 27 août 2022 21:41:57 +0200, a ecrit:
> Mmm, on the set_cr3() in i386at_init call, it reboots...
Ah, reducing the memory size to 2G fixed it. The kernel_pmap->l4base
address was at 0xFFFD3000, apparently that was going up the roof :)
It'd be useful to test with larger memo
Mmm, on the set_cr3() in i386at_init call, it reboots...
Samuel
Luca Dariz, le sam. 05 févr. 2022 18:51:24 +0100, a ecrit:
> * configure: compile for native x86_64 by default instead of xen
> * x86_64/Makefrag.am: introduce KERNEL_MAP_BASE to reuse the constant
> in both code and linker script
> * x86_64/ldscript: use a .boot section for the very first operat
have
> > tried with --host=x86_64-gnu, in all cases after pressing enter at the
> > grub menu it loads the kernel but just reboots immediately after that,
> > even if I have put a jmp boot_entry at boot_entry, i.e. it's really the
> > load that is a problem and not any
Samuel Thibault, le sam. 27 août 2022 20:26:10 +0200, a ecrit:
> I can't manage to make this boot at all. Is there a particular configure
> option to pass? I have let it just use the linux 64bit compiler, I have
> tried with --host=x86_64-gnu, in all cases after pressing enter at t
Hello,
I can't manage to make this boot at all. Is there a particular configure
option to pass? I have let it just use the linux 64bit compiler, I have
tried with --host=x86_64-gnu, in all cases after pressing enter at the
grub menu it loads the kernel but just reboots immediately after
* configure: compile for native x86_64 by default instead of xen
* x86_64/Makefrag.am: introduce KERNEL_MAP_BASE to reuse the constant
in both code and linker script
* x86_64/ldscript: use a .boot section for the very first operations,
until we reach long mode. This section is not really alloca
support for booting from grub with x86_64
cleanup multiboot
fix register corruption in irq on qemu
fix console setting from cmdline
enable user access
fix Task State Segment layout for 64 bit
Makefrag.am| 1 -
configure.ac | 3
Il 28/01/22 20:56, Samuel Thibault ha scritto:
Hello,
Luca Dariz, le ven. 28 janv. 2022 19:24:04 +0100, a ecrit:
* link kernel at 0x400 as the xen version, higher values causes
linker errors.
* we can't use full segmentation in long mode, so we need to create a
temporary mapping durin
Hello,
Luca Dariz, le ven. 28 janv. 2022 19:24:04 +0100, a ecrit:
> * link kernel at 0x400 as the xen version, higher values causes
> linker errors.
> * we can't use full segmentation in long mode, so we need to create a
> temporary mapping during early boot to be able to jump to high
>
* link kernel at 0x400 as the xen version, higher values causes
linker errors.
* we can't use full segmentation in long mode, so we need to create a
temporary mapping during early boot to be able to jump to high
addresses
* build direct map for first 4G in boothdr (seems required by Linux
ound.
Luca Dariz (6):
add support for booting from grub with x86_64
cleanup multiboot
fix register corruption in irq on qemu
fix console setting from cmdline
enable user access
fix Task State Segment layout for 64 bit
Makefrag.am| 1 -
configure.ac
> Sure enough, the crash is gone, but I still get the error messages:
Good.
> ext2fs: /dev/hd0s2: panic: main: device too small for superblock (1024
> bytes)
> /hurd/fatfs: Invalid number of bytes per sector
> /hurd/iso9660fs: Could not find valid superblock
>
> Are you sugges
in: device too small for superblock (1024
bytes)
/hurd/fatfs: Invalid number of bytes per sector
/hurd/iso9660fs: Could not find valid superblock
Are you suggesting that these are to be expected? Is this a bug in
update-grub? These messages seem awfully severe for a standard system
operation.
agape
brent
Update of bug #48685 (project hurd):
Status:None => Fixed
Open/Closed:Open => Closed
___
Follow-up Comment #1:
The isofs crash is fix
URL:
<http://savannah.gnu.org/bugs/?48685>
Summary: update-grub triggers filesystem server panics
Project: The GNU Hurd
Submitted by: baccala
Submitted on: Wed 03 Aug 2016 07:01:57 AM GMT
Category
Hi,
Samuel Thibault wrote:
Did you try to put a linux partition on this box too? The idea would be
to check whether its grub has the same kind of issue.
no, not yet. Btw, they are two boxes now! The HDD is not big enough. But
I could try on another HDD temporarily, perhaps the best bet would
Hello,
Did you try to put a linux partition on this box too? The idea would be
to check whether its grub has the same kind of issue.
Samuel
the disk in my original box, it just keeps rebooting,
> > I don't even get the grub screen. Thus I suppose it is grub that
> > forces this continuous reboot cycle?
> >
> > Are there "options" when configuring grub? Something architecture
> > dependent
Hi,
Riccardo Mottola wrote:
Hi,
I installed everything on a "host" machine (same architecture as my
target box, just more ram and more Mhz). I end up with something
bootable!
However if I put the disk in my original box, it just keeps rebooting,
I don't even get the grub
Hi,
I installed everything on a "host" machine (same architecture as my
target box, just more ram and more Mhz). I end up with something bootable!
However if I put the disk in my original box, it just keeps rebooting, I
don't even get the grub screen. Thus I suppose it is g
orked! thanks Samuel! The
new kernel made it possible for the installation to complete, it also
installed Grub correctly and now my machines boots 100% from Hard Disk
without the need of a floppy :) Very good.
Now I will get back updating all my gnustep sources and see how they
fare and report
On Thu, 2013-05-02 at 23:52 +0200, Samuel Thibault wrote:
> Svante Signell, le Thu 02 May 2013 12:14:46 +0200, a écrit :
> > On Thu, 2013-05-02 at 01:47 +0200, Samuel Thibault wrote:
> But I guess you were still running the old kernel while doing this?
>
> You need to reboot with the new kernel t
was for me one of the last bits to fix before making a Debian
> > GNU/Hurd release, does anybody have something else?
>
> Well, the gnumach solution does not seem to work for me:
> Setting up gnumach-image-1.3.99-486 (2:1.3.99.dfsg.git20130501-1) ...
> run-parts: executin
y have something else?
Well, the gnumach solution does not seem to work for me:
Setting up gnumach-image-1.3.99-486 (2:1.3.99.dfsg.git20130501-1) ...
run-parts: executing /etc/kernel/postinst.d/zz-update-grub
1.3.99-486 /boot/gnumach-1.3.99-486.gz
Generating grub.cfg ...
grub-probe: mall
y have something else?
Well, the gnumach solution does not seem to work for me:
Setting up gnumach-image-1.3.99-486 (2:1.3.99.dfsg.git20130501-1) ...
run-parts: executing /etc/kernel/postinst.d/zz-update-grub
1.3.99-486 /boot/gnumach-1.3.99-486.gz
Generating grub.cfg ...
grub-probe: mall
Hello,
The latest commit in gnumach should be fixing the disasters that some
people have been seeing in their hurd system. This was due to an
improper handling of non-block-aligned reads in the gnumach linux block
glue, which happens only if partitions are not block-aligned, leading to
putting dis
Samuel Thibault wrote:
Riccardo Mottola, le Sat 19 May 2012 16:13:19 +0200, a écrit :
while configuring/installing grub-pc from debian, the kernel panics in the
way attached in the screenshot.
I don't see anything obvious, from the source code the assertion should
never trigger, so it
Riccardo Mottola, le Sat 19 May 2012 16:13:19 +0200, a écrit :
> while configuring/installing grub-pc from debian, the kernel panics in the
> way attached in the screenshot.
I don't see anything obvious, from the source code the assertion should
never trigger, so it might just be so
Hi,
while configuring/installing grub-pc from debian, the kernel panics in
the way attached in the screenshot.
Riccardo
<>
Riccardo Mottola, le Sat 19 May 2012 16:13:19 +0200, a écrit :
> while configuring/installing grub-pc from debian, the kernel panics in the
> way attached in the screenshot.
which version of the kernel are you running exactly?
Samuel
Hi,
while configuring/installing grub-pc from debian, the kernel panics in
the way attached in the screenshot.
Riccardo
<>
fo() on them too.
> We would compare the result with that of the file being looked up, and
> use the grub-detected partition information to deteremine on which
> _grub_ device the file resides.
This was NACKED by grub maintainer. Not only because he does not want
to involve GRUB here, but a
Hi,
On Sat, Aug 07, 2010 at 05:28:57PM +0200, Carl Fredrik Hammar wrote:
> On Tue, Jul 27, 2010 at 08:22:14PM +0200, olafbuddenha...@gmx.net wrote:
> > GRUB effectively needs a three-way mapping between filesystems, device
> > node names, and GRUB device names. The mapping betwe
ar, would be
> > > to enumerate the _grub_ devices, and use get_storage_info() on
> > > them too.
> >
> > Not sure what you mean by using get_storage_info() on GRUB
> > devices?...
>
> I mean we enumerate the "whole disk" devices from the devi
gt; file_get_underlying_storage_info(), which returns the backing store
> > used by the filesystem. (I'm not sure if this should be in fs.defs or
> > fsys.defs though.) This would be a hurdish analogy to st_dev thin is
> > returned by stat(), except that it returns a stor
info() on them too.
>
> Not sure what you mean by using get_storage_info() on GRUB devices?...
I mean we enumerate the "whole disk" devices from the devices.map, use
get_storage_info() on them and compare the result with the storage
information for the looked up file.
If both use the sam
be a hurdish analogy to st_dev thin is
> returned by stat(), except that it returns a store instead of a device
> number. IIRC grub-probe on other systems matches st_dev with the
> st_rdev of device files, but this doesn't work on Hurd because having
> stable device numbers in a
Hi,
On Tue, Jul 13, 2010 at 08:00:24PM +0200, Jérémie Koenig wrote:
> On Mon, Jul 12, 2010 at 11:19 PM, wrote:
> Summary: grub-probe, used by grub-install, needs to deteremine which
> device node a given file (say, /boot/grub) is stored on.
[...]
> There are three
> approches
IBSTORE)
CC = @CC@
CFLAGS = @CFLAGS@
Index: configure.ac
===
--- configure.ac.orig 2010-07-16 13:08:11.0 +
+++ configure.ac 2010-07-16 13:09:45.00000 +
@@ -31,7 +31,7 @@
dnl type.
-AC_INIT([GRUB],[0],[bug-g...@gnu.org]) dnl version is filled by debian/r
age_info(),
which returns the backing store used by the filesystem. (I'm not sure if
this should be in fs.defs or fsys.defs though.) This would be a hurdish
analogy to st_dev thin is returned by stat(), except that it returns
a store instead of a device number. IIRC grub-probe on other systems
On Mon, Jul 12, 2010 at 11:19 PM, wrote:
> I already talked to Jeremie
> about handling of partitions in grub-probe. As this is a rather
> fundamental issue, I hope he will start an extra thread on this.
Summary: grub-probe, used by grub-install, needs to deteremine which
device nod
Jakub Daniel, le Tue 01 Dec 2009 02:32:32 +0100, a écrit :
> update-grub throws segfault
Yes, it should get fixed by the latest 20091130 upload.
Samuel
Hello
update-grub throws segfault
I searched for the cause and this is what I got
update-grub
grub-mkconfig
00_header
prepare_grub_to_access_device
grub-probe
this is how grub-probe is called here: /usr/sbin/grub-probe --device
/dev/hd0s1 --target=fs
is
olafbuddenha...@gmx.net, le Wed 11 Nov 2009 00:23:17 +0100, a écrit :
> On Mon, Nov 09, 2009 at 10:47:08PM +0100, Samuel Thibault wrote:
>
> > - Either we align more on POSIX to manage to get the st_dev (aka fsid)
> > of filesystems equal to the the st_rdev of their underlying /dev
> > entries. A
Hi,
On Mon, Nov 09, 2009 at 10:47:08PM +0100, Samuel Thibault wrote:
> - Either we align more on POSIX to manage to get the st_dev (aka fsid)
> of filesystems equal to the the st_rdev of their underlying /dev
> entries. An easy way is to have storeios expose their own pid as
> st_rdev, and have
On Tue, Nov 10, 2009 at 02:01:19PM +0100, Samuel Thibault wrote:
> > I assumed that was the case for the ones that are interesting for grub.
>
> Yes, but then to realize unicity it's more difficult, as you have
> several sources of IDs. You can of course use a prefix to ident
ge_info and use the store directly,
> after this it doesn't need storeio. This is what ext2fs does.
Ah, I didn't know that. Mmf.
> > > The ideal would be to derive it from the underlying Mach device somehow.
> >
> > Not all storage are Mach devices.
>
&
es.
> > The ideal would be to derive it from the underlying Mach device somehow.
>
> Not all storage are Mach devices.
I assumed that was the case for the ones that are interesting for grub.
> > > - Or we make grub use a more hurdish interface, i.e.
> > > file_ge
.
Not all storage are Mach devices.
> The question is how to derive it if there's some sort of transformation
> involved, e.g. gzip stores, concatinated stores, unionfs, etc. We'd need
> to find some stable algorithm that can produce fairly unique numbers
ores, concatinated stores, unionfs, etc. We'd need
to find some stable algorithm that can produce fairly unique numbers.
> - Or we make grub use a more hurdish interface, i.e.
> file_get_storage_info, e.g. storeinfo -n / .
> I have however observed a disturbing behavior:
&g
Hello,
Currently, grub has no way to know which /dev/ entries corresponds to
/boot and /. Its detection mechanism is to run stat /, which on Linux
notably gives
Device: 306h/774d Inode: 2 Links: 29
i.e. st_dev is (3,6), and it also runs stats on /dev/*, notably
/dev/hda6
char = -1
serial_device = 0x0
serial_fd = -1
apm_bios_info = {version = 0, cseg = 0, offset = 0, cseg_16 = 0,
dseg_16 = 0, cseg_len = 0, cseg_16_len = 0, dseg_16_len = 0}
grub_scratch_mem = 0x1244000 ""
install_partition = 131072
linux_text_len = 0
ascii_key_map = {0 }
linux_data_tmp_add
Barry deFreese, le Sun 31 May 2009 10:03:32 -0400, a écrit :
> Even if I run the unmodified version I get segfaults with the
> following error on the console:
>
> end_request: I/O error, dev 02:00, sector 0
>
> Any clue on what could be causing that?
Doesn't gdb give you a backtrace?
Samuel
Hi folks,
I was playing with grub to see if I could find out where it is dying.
It was working OK but now it is core dumping. Even if I run the
unmodified version I get segfaults with the following error on the console:
end_request: I/O error, dev 02:00, sector 0
Any clue on what could be
On Wed, Mar 21, 2007 at 08:15:53PM +0100, [EMAIL PROTECTED] wrote:
> So, why doesn't it install a boot loader?
I think this probably because it uses an obsolete code base which never
did install Grub when installing GNU/Linux, either.
Adding this feature would still be welcome, but prob
On Wed, Mar 21, 2007 at 07:57:06PM +0100, Samuel Thibault wrote:
> You then need to explain that to your mailer for properly setting the
> Mail-Followup-To: header.
Indeed.
> > > Correct, you can't install GRUB from within a GNU/Hurd system,
> > But the resc
e
Mail-Followup-To: header.
> > Correct, you can't install GRUB from within a GNU/Hurd system,
> But the rescue CD is running GNU/Linux...?
Yes.
Samuel
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
On Wed, Mar 21, 2007 at 03:37:16PM +0100, Thomas Schwinge wrote:
> [Taking this to .]
No need to CC me, I happen to be subscribed :)
> Correct, you can't install GRUB from within a GNU/Hurd system,
But the rescue CD is running GNU/Linux...?
Leslie
--
NEW home
Thomas Schwinge, le Wed 21 Mar 2007 15:37:16 +0100, a écrit :
> It's probably no longer worthwhile to do that for GRUB legacy,
Maybe as a debian patch at least.
Samuel
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/
[Taking this to .]
Hello!
On Wed, Mar 21, 2007 at 08:43:43AM +0100, Leslie P. Polzer wrote:
> Da wir gerade beim Thema Hurd waren... ist es richtig und ggf.
> beabsichtigt, da? die Debian GNU/Hurd Rescue-CD keinen Bootloader
> installiert?
Correct, you can't install GRUB from wit
Hello Gnu/Hurders:
Super Grub Disk (Boot rescue cdrom, if you want it in floppy, just ask
me) now it is supposed to boot Gnu/Hurd as a normal thing or as a superuser.
Options you should issue to boot it are:
Your Language -> Advanced -> Other Oses -> Hurd -> Auto Boot -> Same
Hi,
Ian C. Blenke, le Mon 08 Jan 2007 13:56:32 -0500, a écrit :
> Xen PV domUs can boot from "pygrub". This is the method used by JailTime
> and rPath to encapsulate kernels and initrd inside the disk images.
>
> So there is already such a "port". Just specify a bootloader in your xen
> config:
Samuel Thibault wrote:
Thomas Schwinge, le Wed 03 Jan 2007 13:09:25 +0100, a écrit :
Is there a consensus that GRUB (or rather GRUB2) should be ported to
allow them to run in a Xen environment?
I'm not sure grub on Xen would be so useful, since people usually choose
their oper
Hi,
Thomas Schwinge, le Wed 03 Jan 2007 13:09:25 +0100, a écrit :
> Is there a consensus that GRUB (or rather GRUB2) should be ported to
> allow them to run in a Xen environment?
I'm not sure grub on Xen would be so useful, since people usually choose
their operating system and
[Cced to .]
Hello!
This is about porting GRUB to Xen to allow booting a GNU/Hurd system as a
Xen domU.
GNU/Hurd systems use GNU Mach as a microkernel and have a GRUB
configuration like the following one, which is currently not translatable
to a Xen configuration:
#v+
title Debian GNU/Hurd
[Cced to bug-hurd as it might also be of interest there.]
Hello!
On Tue, Oct 03, 2006 at 07:10:29PM +0200, Luca Capello wrote:
> On Sun, 01 Oct 2006 14:46:22 +0200, Samuel Thibault wrote:
> > Luca Capello, le Sun 01 Oct 2006 11:48:58 +0200, a ??crit :
> >> Well, here what a
I'm happy to announce the release of GRUB 1.91. This is the second of
our prereleases leading up to GRUB 2.0. We encourage you to try it, as
we have done a significant amount of work towards GRUB 2. Note that this
release is mainly for developers who are willing to contribute to our
projec
At Wed, 23 Feb 2005 00:23:53 +0100,
Alfred M Szmidt wrote:
>
> The following is needed so that one can boot of a CD, many thanks to
> Marcus.
>
> Ok to commit?
Yes.
> isofs/ChangeLog
> 2005-02-23 Alfred M. Szmidt <[EMAIL PROTECTED]>
>
> * Makefile (iso9660fs.static): New target.
Than
Commited.
2005-02-23 Alfred M. Szmidt <[EMAIL PROTECTED]>
* Makefile (iso9660fs.static): New target.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
The following is needed so that one can boot of a CD, many thanks to
Marcus.
Ok to commit?
isofs/ChangeLog
2005-02-23 Alfred M. Szmidt <[EMAIL PROTECTED]>
* Makefile (iso9660fs.static): New target.
Index: isofs/Makefile
configfile (nd)/boot/hurd-l4/menu.lst
Problem with that is that you can't share that file with `boot', which
is quite a nice thing IMHO.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
> Have you tried that? I'm not sure it actually works, but I'm not sure it
> doesn't. I think I tried it and it wasn't the right thing, but I don't
> really recall at the moment.
From my understanding of what your patch is supposed to do, yes and it
works quite well for me. Specifically, I have
> > With this, we put the canonical script into /boot/servers.boot and instead
> > of everyone's grub config file copying the magic command lines, they just
> > use:
> >
> > kernel /boot/gnumach
> > modulelist /boot/servers.boot
>
> Why can'y
Shakthi Kannan wrote:
Hi!
--- Shakthi Kannan <[EMAIL PROTECTED]> wrote:
grub>boot
The system just hangs here. I don't get any output
at
all. I would really appreciate in getting gnu/hurd
installed on my laptop
Thanks to araujo and bddebian at ##hurd, I got this
working. I ha
Hi!
--- Shakthi Kannan <[EMAIL PROTECTED]> wrote:
> grub>boot
>
> The system just hangs here. I don't get any output
> at
> all. I would really appreciate in getting gnu/hurd
> installed on my laptop
Thanks to araujo and bddebian at ##hurd, I got this
work
On reboot, I enter grub (version 0.94, which is
installed to hdd) and go to the prompt. I do the
following:
grub>kernel (hd0,3)/boot/gnumach.gz root=device:hd0s4
-s
[Multiboot ...]
grub>module (hd0,3)/hurd/ext2fs.static
--multiboot-command-line=${kernel-command-line}
--host-priv-port={hos
> With this, we put the canonical script into /boot/servers.boot and instead
> of everyone's grub config file copying the magic command lines, they just
> use:
>
> kernel /boot/gnumach
> modulelist /boot/servers.boot
Why can'y you use the configfile directive? Wou
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>> Has anyone used grub2? Is it usable yet?
>
>It is not usable yet.
>
> When we spoke sometime ago you said the exact opposite. Has something
> changed in the GRUB 2 code base?
*sigh*, if someone would
> Has anyone used grub2? Is it usable yet?
It is not usable yet.
When we spoke sometime ago you said the exact opposite. Has something
changed in the GRUB 2 code base?
We planned scripting support for GRUB 2. What I had in mind was
just a GRUB 2 script for the Hurd. The scr
> It is not usable yet.
>
> We planned scripting support for GRUB 2. What I had in mind was just
> a GRUB 2 script for the Hurd.
That sounds great. But since it is not a reality for users who are not
themselves hacking on GRUB 2, I would still like to make things easier on
people
Roland McGrath <[EMAIL PROTECTED]> writes:
> Has anyone used grub2? Is it usable yet?
It is not usable yet.
We planned scripting support for GRUB 2. What I had in mind was just
a GRUB 2 script for the Hurd. The script accepts the root device as
argument and loads the right kernel an
2004-09-15 Roland McGrath <[EMAIL PROTECTED]>
You just couldn't sit and suck on this lollipop any longer huh?
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
Has anyone used grub2? Is it usable yet?
I ask because I sent in patches for some useful features for grub, and
Okuji refused to put them in. He says only grub2 will get new features.
That seems like a bad decision to me, since everyone is using grub 0.96 and
adding simple features there can be
Many Specials running this week
THE RE.AL THING
not like the other sites that
imitate these products.
No hidd.en char.ges - Fast Delivery
Vic.odin Val.ium Xan.ax
Via.gra Diaz.epam Alpra.zolam
So.ma Fior.icet Amb.ien
Stil.nox Ult.ram Zo.loft
Clon.azepam At.ivan Tr.amadol
Xeni.cal Cele.brex V
> > I only changed the behaviour of savedefault when executed within the
> > GRUB-util shell (ie. not GRUB menu mode). I can't think of a scenario
> > where the '--once' semantics would be useful to access from the GRUB
> > menu, so I'm reluctant to
On Tue, Nov 11, 2003 at 06:44:21PM +, Keir Fraser wrote:
>
> I only changed the behaviour of savedefault when executed within the
> GRUB-util shell (ie. not GRUB menu mode). I can't think of a scenario
> where the '--once' semantics would be useful to access f
> I only changed the behaviour of savedefault when executed within the
> GRUB-util shell (ie. not GRUB menu mode). I can't think of a scenario
> where the '--once' semantics would be useful to access from the GRUB
> menu, so I'm reluctant to 'fix' thi
> I gave a try to your patch for 'lilo -R' functionality in GRUB:
>
> http://mail.gnu.org/archive/html/bug-grub/2002-02/msg00151.html
>
> it seems to basicaly work, but the --once flag is not honored when running
> the real grub (I don't know if the problem i
Hi!
I gave a try to your patch for 'lilo -R' functionality in GRUB:
http://mail.gnu.org/archive/html/bug-grub/2002-02/msg00151.html
it seems to basicaly work, but the --once flag is not honored when running
the real grub (I don't know if the problem is in savedefault or in t
I'm happy to announce the release of GRUB 0.93. This is the fourth of
our prereleases leading up to GRUB 1.0. We encourage you to try it, as
we have done a lot of bugfixes and feature enhancement since the
previous release.
The source and binary distributions are available fro
I'm happy to announce the release of GRUB 0.92. This is the third of
our prereleases leading up to GRUB 1.0. We encourage you to try it, as
we have done a lot of bugfixes and feature enhancement since the
previous release.
The source and binary distributions are available fro
1 - 100 of 107 matches
Mail list logo
