[bug #65856] Add matchers to initrd image filenames not add ending with or containing .img

URL: <https://savannah.gnu.org/bugs/?65856> Summary: Add matchers to initrd image filenames not add ending with or containing .img Group: GNU GRUB Submitter: konsolebox Submitted: Sun 09 Jun 2024 08:27:03

[bug #64475] grub failed to initrd /boot/amd-ucode.img in btrfs partition with bees

Follow-up Comment #6, bug #64475 (project grub): It happened to me too and I'd like to receive notifications on this bug (I didn't figure out another way besides leaving a comment). ___ Reply to this item at:

[bug #64475] grub failed to initrd /boot/amd-ucode.img in btrfs partition with bees

Follow-up Comment #5, bug #64475 (project grub): Hello, I used "qemu-img create -f raw example.img 200M" to created a 200Mb image file, and "losetup /dev/loop0 example.img", mounting example.img as a loop device. Then I formatted the /dev/loop0 by mkfs.btrfs with default options, "mount

[bug #64475] grub failed to initrd /boot/amd-ucode.img in btrfs partition with bees

Follow-up Comment #4, bug #64475 (project grub): [comment #2 comment #2:] > Can you recreate this with a small image and send it to me? You can use grub-fstest IMAGE cmp PATHINIMAGE PATHEXTERNAL to check if GRUB sees your files correctly When I try to create a 16Mb raw img file and mkfs.btrfs

[bug #64475] grub failed to initrd /boot/amd-ucode.img in btrfs partition with bees

Follow-up Comment #3, bug #64475 (project grub): Here is the output of grub-fstest: $ sudo grub-fstest /dev/nvme0n1p5 cmp /boot/amd-ucode.img linux-firmware/src/amd-ucode.img grub-fstest: error: unexpected end of file. $ sha512sum /boot/amd-ucode.img

[bug #64475] grub failed to initrd /boot/amd-ucode.img in btrfs partition with bees

Follow-up Comment #2, bug #64475 (project grub): [(Erreur - Introuvable)] Can you recreate this with a small image and send it to me? You can use grub-fstest IMAGE cmp PATHINIMAGE PATHEXTERNAL to check if GRUB sees your files correctly ___

[bug #64475] grub failed to initrd /boot/amd-ucode.img in btrfs partition with bees

Follow-up Comment #1, bug #64475 (project grub): I mean, something wrong with grub btrfs module, sorry for my mistyping! ___ Reply to this item at: ___

[bug #64475] grub failed to initrd /boot/amd-ucode.img in btrfs partition with bees

URL: <https://savannah.gnu.org/bugs/?64475> Summary: grub failed to initrd /boot/amd-ucode.img in btrfs partition with bees Group: GNU GRUB Submitter: watermelonrei Submitted: Wed 26 Jul 2023 12:17:14

os-prober fails when multiple initrd images

OS prober fails when the target OS has a separate boot partition and multiple initrd images. I have both Debian and Manjaro installed on my laptop. When using Debian's update-grub, I get a grub.cfg with a wrong path for Manjaro's initramfs. It should be: linux /vmlinuz ... initrd /intel

[bug #64448] os-prober fails when initrd contains multiple images

URL: <https://savannah.gnu.org/bugs/?64448> Summary: os-prober fails when initrd contains multiple images Group: GNU GRUB Submitter: drax Submitted: Wed 19 Jul 2023 10:46:25 AM UTC Category

[bug #63784] grub-mkconfig generates invalid code that passes grub-script-check when / is ZFS and there is no initrd

URL: <https://savannah.gnu.org/bugs/?63784> Summary: grub-mkconfig generates invalid code that passes grub-script-check when / is ZFS and there is no initrd Project: GNU GRUB Submitter: arsen Submitted: Fri 10 Feb 2023 09:33

[bug #61058] out of memory error on HP 250 G7 and HP 450 G8 laptop loading large initrd (500Mb)

Follow-up Comment #4, bug #61058 (project grub): I confirmed that jak mentioned, by getting grub2 (2.06-2ubuntu16) from ubuntu-lunar-proposed and it can boot up to 453M on a real machine. In the meantime, I proposed a patch https://www.mail-archive.com/grub-devel@gnu.org/msg35526.html which hope

[bug #61058] out of memory error on HP 250 G7 and HP 450 G8 laptop loading large initrd (500Mb)

Follow-up Comment #3, bug #61058 (project grub): After applying the 2.12 memory management changes I was able to load files up to 1.1GB in a qemu. I could not fit larger initrds on the /boot. This of course doesn't solve the problem entirely - 4GB is still the memory map limit on x86 due to

[bug #61058] out of memory error on HP 250 G7 and HP 450 G8 laptop loading large initrd (500Mb)

Follow-up Comment #2, bug #61058 (project grub): [comment #1 comment #1:] > The same issue here. > > The issue is not highly related to initramfs but more likely grub memory management. > > If the higher memory usage (e.g. GFXMODE=3840x2560) then grub will not able to read 100MB file somethings

[bug #61058] out of memory error on HP 250 G7 and HP 450 G8 laptop loading large initrd (500Mb)

Follow-up Comment #1, bug #61058 (project grub): The same issue here. The issue is not highly related to initramfs but more likely grub memory management. If the higher memory usage (e.g. GFXMODE=3840x2560) then grub will not able to read 100MB file somethings but if I set GFXMODE=640x480, then

[bug #47681] 30_os-prober doesn't handle multiple initrd paths

Follow-up Comment #3, bug #47681 (project grub): [comment #2 comment #2:] > Please update this bug report when os-prober is fixed. Suggested solution is OK. It appears that the issue on os-prober's end is fixed with

[bug #61058] out of memory error on HP 250 G7 and HP 450 G8 laptop loading large initrd (500Mb)

Additional Item Attachment, bug #61058 (project grub): File name: grub-debug-bsb-boot (2).jpgSize:724 KB ___ Reply to this item at:

Can the grub2.02 improve the limit of initrd size in 64-bit system?

Hi All, environment : X86-64 , kernel 3.16.0(64-bit support),grub2.02 I compile the grub2.02 by default. And the grub boots the linux kernel with 32-bit boot protocol.(Documents/X86/boot.txt) I want to use the initrd as big as possible, but it is limited as follows. But when I make

[bug #56546] Allow root=PARTUUID when no initrd is provided

URL: <https://savannah.gnu.org/bugs/?56546> Summary: Allow root=PARTUUID when no initrd is provided Project: GNU GRUB Submitted by: fireburn Submitted on: Tue 25 Jun 2019 03:37:46 PM UTC Category: B

10_linux does not account for common initrd name

Currently, here is the relevant code in 10_linux for detecting initrds: initrd_real= for i in "initrd.img-${version}" "initrd-${version}.img" "initrd-${version}.gz" \ "initrd-${version}" "initramfs-${version}.img" \

[bug #50954] unaligned pointer 0x8 if initrd before linux is not clear enough message

Follow-up Comment #2, bug #50954 (project grub): Are you using Ubuntu grub? Can you reproduce the problem using upstream? ___ Reply to this item at: ___

[bug #50954] unaligned pointer 0x8 if initrd before linux is not clear enough message

Additional Item Attachment, bug #50954 (project grub): File name: unaligned_pointer_0x8_v3.jpg Size:25 KB ___ Reply to this item at: ___ Message

[bug #50954] unaligned pointer 0x8 if initrd before linux is not clear enough message

Follow-up Comment #1, bug #50954 (project grub): Where have you get this message? GRUB does complain when initrd was used without corresponding linux command. Please attach your grub.cfg and photo of error message. ___ Reply to this item

[bug #50954] unaligned pointer 0x8 if initrd before linux is not clear enough message

URL: <http://savannah.gnu.org/bugs/?50954> Summary: unaligned pointer 0x8 if initrd before linux is not clear enough message Project: GNU GRUB Submitted by: pauld Submitted on: Thu 04 May 2017 11:05:27 PM UTC Ca

[bug #47681] 30_os-prober doesn't handle multiple initrd paths

Update of bug #47681 (project grub): Category:None => Configuration ___ Follow-up Comment #2: Please update this bug report when os-prober is fixed. Suggested solution is OK.

[bug #47681] 30_os-prober doesn't handle multiple initrd paths

Follow-up Comment #1, bug #47681 (project grub): Debian bug report for linux-boot-prober (in package os-prober): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820838 ___ Reply to this item at:

[bug #47681] 30_os-prober doesn't handle multiple initrd paths

URL: <http://savannah.gnu.org/bugs/?47681> Summary: 30_os-prober doesn't handle multiple initrd paths Project: GNU GRUB Submitted by: general_chaos Submitted on: Tue 12 Apr 2016 10:28:52 PM GMT Category

[bug #45858] linux16 and initrd16 generated instead of linux and initrd

Update of bug #45858 (project grub): Status:None => Invalid Open/Closed:Open => Closed ___ Follow-up Comment #1: Upstream does not

[bug #45858] linux16 and initrd16 generated instead of linux and initrd

URL: <http://savannah.gnu.org/bugs/?45858> Summary: linux16 and initrd16 generated instead of linux and initrd Project: GNU GRUB Submitted by: fry_kun Submitted on: Tue 01 Sep 2015 08:09:20 PM GMT Category: Configu

[bug #44239] Behavior of syslinux_parse differs from SYSLINUX for initrd= option

Update of bug #44239 (project grub): Status:None = Fixed Open/Closed:Open = Closed ___ Reply to this item at:

[bug #44239] Behavior of syslinux_parse differs from SYSLINUX for initrd= option

URL: http://savannah.gnu.org/bugs/?44239 Summary: Behavior of syslinux_parse differs from SYSLINUX for initrd= option Project: GNU GRUB Submitted by: lunar Submitted on: Fri 13 Feb 2015 04:36:45 PM GMT Category

[bug #44239] Behavior of syslinux_parse differs from SYSLINUX for initrd= option

Follow-up Comment #1, bug #44239 (project grub): Can't comment about behavior itself. Re. patch + cmdline = grub_strdup(curentry-append); Error check missing. + grub_free(cmdline); You need to delete free(cmdline) later. Again, can you post updated version to grub-devel for easier

[bug #40363] TFTP: Files bigger than 63 MB generate error: timeout reading `/boot/initrd'.

Update of bug #40363 (project grub): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #6: comitted modification

[bug #40363] TFTP: Files bigger than 63 MB generate error: timeout reading `/boot/initrd'.

Follow-up Comment #5, bug #40363 (project grub): When the block number gets over 0x the last packet gets ack'ed twice and grub shows this error: error: not an IP. (Due to an tcpdump at the tftp server; the tftp server itself is logging that the file was sent successfully.) (With the patch

[bug #40363] TFTP: Files bigger than 63 MB generate error: timeout reading `/boot/initrd'.

Follow-up Comment #2, bug #40363 (project grub): This patch worked only by chance that the priority queue was empty at the moment of wraparound. ___ Reply to this item at: http://savannah.gnu.org/bugs/?40363

[bug #40363] TFTP: Files bigger than 63 MB generate error: timeout reading `/boot/initrd'.

Follow-up Comment #3, bug #40363 (project grub): Then if the datatype change is removed the sorting in the priority queue is still correct and only when comparing with the network data using only the lowest 2 bytes? (new adjusted patch) (file #29470)

[bug #40363] TFTP: Files bigger than 63 MB generate error: timeout reading `/boot/initrd'.

Follow-up Comment #4, bug #40363 (project grub): If packet for 1 reaches GRUB before packet then packet 1 would be considered to come before and will be processed as delayed retransmission and GRUB will discard it but (re)send ack for , then it will take packet for and

[bug #40363] TFTP: Files bigger than 63 MB generate error: timeout reading `/boot/initrd'.

URL: http://savannah.gnu.org/bugs/?40363 Summary: TFTP: Files bigger than 63 MB generate error: timeout reading `/boot/initrd'. Project: GNU GRUB Submitted by: bernhardu Submitted on: Do 24 Okt 2013 15:10:34 GMT Category

[bug #40363] TFTP: Files bigger than 63 MB generate error: timeout reading `/boot/initrd'.

Additional Item Attachment, bug #40363 (project grub): File name: 0001-TFTP-Handle-overflow-in-blocknumber-fixes-bug-40363.patch Size:1 KB ___ Reply to this item at: http://savannah.gnu.org/bugs/?40363

[bug #35651] reopen bug #35238 - multiple initrd alignment bug

Update of bug #35651 (project grub): Status:None = Fixed Open/Closed:Open = Closed ___ Reply to this item at:

[bug #35651] reopen bug #35238 - multiple initrd alignment bug

URL: http://savannah.gnu.org/bugs/?35651 Summary: reopen bug #35238 - multiple initrd alignment bug Project: GNU GRUB Submitted by: nky Submitted on: Втр 28 Фев 2012 05:34:59 Category: Booting Severity

Grub2 hangs at initrd on Asus machine with UEFI

When booting an Asus UX31E using Grub2 and UEFI the boot hangs during the initrd stage. With debug=all it ends with the following: Lib/relocator.c:1223: min_addr = 0x0, max_addr = 0x, target = 0x88800 Lib/relocator.c:433: trying to allocate in 0x0-0x aligned 0x1

[bug #35238] Support for multiple initrd images like grub-legacy has

Follow-up Comment #3, bug #35238 (project grub): Current implementation fails when mixing .gz and .cpio initrd images. Test case: initrd img1.cpio.gz img2.cpio leads to wrong result. .cpio header must be aligned on 4-byte boundary, while .gz size is not required to be multiple of 4. Please

[bug #35238] Support for multiple initrd images like grub-legacy has

Update of bug #35238 (project grub): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #2: Fixed in bzr

Re: [bug #35238] Support for multiple initrd images like grub-legacy has

I encountered that a long time ago. I just assumed that Grub2 didn't support multiple initrd images. I learned that I could install chntpw into Linux with a persistence file on my thumb drive, and that was my work-around. Gee, I didn't know Grub Legacy supported more than one initrd. That would

[bug #35238] Support for multiple initrd images like grub-legacy has

URL: http://savannah.gnu.org/bugs/?35238 Summary: Support for multiple initrd images like grub-legacy has Project: GNU GRUB Submitted by: rbeede Submitted on: Wed 04 Jan 2012 04:22:13 PM GMT Category: Configuration

[bug #33382] Grub won't load initrd on M787CL (VIA C3) board, memory size misdetected?

URL: http://savannah.gnu.org/bugs/?33382 Summary: Grub won't load initrd on M787CL (VIA C3) board, memory size misdetected? Project: GNU GRUB Submitted by: rainbow Submitted on: Mon 23 May 2011 09:29:12 PM GMT Category

[bug #33382] Grub won't load initrd on M787CL (VIA C3) board, memory size misdetected?

Update of bug #33382 (project grub): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #1: This (memory hole

grub2 fails to read big initrd files

The setup of new linux kernels compiled with [m] option on most modules results in dramatically big initrd files (65-145MB). Grub2 fails to read such a big files from at least ext3 partitions and linux kernel panics because of lack of modules. Quick analysis and debug of grub2 code has shown

grub2 fails to read big initrd files

The setup of new linux kernels compiled with [m] option on most modules results in dramatically big initrd files (65-145MB). Grub2 fails to read such a big files from at least ext3 partitions and linux kernel panics because of lack of modules. Quick analysis and debug of grub2 code has shown

Re: grub2 fails to read big initrd files

On 01/28/2011 04:21 PM, scal...@scyld.sky wrote: The setup of new linux kernels compiled with [m] option on most modules results in dramatically big initrd files (65-145MB). Grub2 fails to read such a big files from at least ext3 partitions and linux kernel panics because of lack of modules

[bug #28587] update-grub doesn't find lzma compressed initrd images

Follow-up Comment #3, bug #28587 (project grub): You seem to be blind Vladimir as I'm explictly mentioned in this report as submitter with my name. ___ Reply to this item at: http://savannah.gnu.org/bugs/?28587

[bug #28587] update-grub doesn't find lzma compressed initrd images

Follow-up Comment #1, bug #28587 (project grub): grub-mkconfig doestn't care about the compression scheme used. It only cares about the filename. So how is it named on your system? On Debian at least they don't have any .gz extension even though they're gzip compressed.

[bug #28587] update-grub doesn't find lzma compressed initrd images

URL: http://savannah.gnu.org/bugs/?28587 Summary: update-grub doesn't find lzma compressed initrd images Project: GNU GRUB Submitted by: arekm Submitted on: Wed 13 Jan 2010 08:29:43 AM CET Category: Configuration

[bug #18471] [PATCH] Grub overwrites reserved memory region when reading initrd file

Update of bug #18471 (project grub): Open/Closed:Open = Closed ___ Follow-up Comment #2: We've moved to GRUB 2 as a development platform. Please can you check if this bug still applies

[bug #12271] Grub loads linux initrd past available memory if vmalloc boot arg is used

Update of bug #12271 (project grub): Open/Closed:Open = Closed ___ Follow-up Comment #1: We've moved to GRUB 2 as a development platform. Please can you check if this bug still applies

[bug #18471] [PATCH] Grub overwrites reserved memory region when reading initrd file

Additional Item Attachment, bug #18471 (project grub): File name: grub-0.93-initrd-smallcopy.patch Size:2 KB ___ Reply to this item at: http://savannah.gnu.org/bugs/?18471 ___ Message

[bug #18471] [PATCH] Grub overwrites reserved memory region when reading initrd file

Follow-up Comment #1, bug #18471 (project grub): It was brought to my attention that the nocopy patch may not work on some systems. This patch supercedes that one. It loads the initrd in 1MB increments. This way it will avoid trashing BIOS reserved memory and also will not pose a problem

Re: which kernel and initrd for rescue boot purposes?

/hda2 or boot: linux root=/dev/hda2 ro from a knoppix or a redhat installation cd? sure, or from a gentoo, or I think debian, or just about any bootable linux CD. That's the isolinux prompt, I believe. I want to add a kernel and an initrd so that I can add a similar feature to Super

which kernel and initrd for rescue boot purposes?

Hello, I need some help of you if you do not mind. Do you remember ever having boot your system like this: boot: knoppix root=/dev/hda2 or boot: linux root=/dev/hda2 ro from a knoppix or a redhat installation cd? I want to add a kernel and an initrd so that I can add a similar feature

[bug #18471] [PATCH] Grub overwrites reserved memory region when reading initrd file

URL: http://savannah.gnu.org/bugs/?18471 Summary: [PATCH] Grub overwrites reserved memory region when reading initrd file Project: GNU GRUB Submitted by: bbrown_gnu Submitted on: Wednesday 12/06/2006 at 16:14 Category

grub hangs on initrd

hangs at the initrd command, withount any error messages. If I try to boot grub in console (shell-like) mode and give the commands to grub manually, I obtain: grub root (hd0,0) Filesystem type is ext2fs, partition type 0x83 grub kernel /vmlinuz-2.6 [Linux-bzImage, setup=0x1400, size=0x14d2a0

initrd hang with 2.6

I'm having a problem when grub executes the boot under the 2.6 kernel (menu or command-line). 1) Falling back to a 2.4 kernel (Redhat Psyche) resolves booting issue. 2) The lock: initrd /boot/initrd-2.6.5-1.358smp.img [Linux-initrd at 0x37fa1000,0x4ed71 bytes] The machine

Re: grub can't read large initrd on flash hdc1

on the initrd perhaps ? Can you show the results of dumpe2fs? Okuji ___ Bug-grub mailing list Bug-grub@gnu.org http://lists.gnu.org/mailman/listinfo/bug-grub

RE: grub can't read large initrd on flash hdc1

www.connexionbyboeing.com -Original Message- From: Yoshinori K. Okuji [mailto:[EMAIL PROTECTED] Sent: Thursday, July 07, 2005 10:27 PM To: bug-grub@gnu.org Cc: Skahan, Vince Subject: Re: grub can't read large initrd on flash hdc1 On Friday 08 July 2005 01:05, Skahan, Vince wrote

RE: grub can't read large initrd on flash hdc1

Think I have it solved. The problem is definitely related to how mke2fs automagically set the various filesystem settings. If the partition is 512 MB or smaller, mke2fs picks 1k block and fragment size, and 8k blocks and fragments per group. The 130MB initrd takes 'forever' to read

Re: grub can't read large initrd on flash hdc1

Well, as far as I test the same ext2 parameters, it is working well, and just slow. Using a larger block size always has a better performance for big files on any kind of disk, because it decreases random access. Maybe this is the only reason. Usually, compact flash disks are much slower than

RE: grub can't read large initrd on flash hdc1

, since there are very few (under 100) files on this partition, would manually setting the block size increase grub's read performance on the initrd perhaps ? -- [EMAIL PROTECTED] -- Cabin Network -- connexion by Boeing sm www.connexionbyboeing.com -Original Message

RE: grub can't read large initrd on flash hdc1

More info - it's actually not hanging infinitely, the read of the initrd completes in 25+ minutes (not about one minute) and the o/s does eventually boot. I've tried to compress the initrd with gzip to lower the compute needs to uncompress (was using gzip -9) to no avail. Anybody have any

RE: grub can't read large initrd on flash hdc1

there is a limit nears 90-100Mo for initrd FC ___ Bug-grub mailing list Bug-grub@gnu.org http://lists.gnu.org/mailman/listinfo/bug-grub

grub can't read large initrd on flash hdc1

I have a ramdisk-based o/s based on a stripped down redhat9 which I built into a initrd image that runs in a 384MB ramdisk. I've identified the problem down to the point that I can see that grub is not completing the grub_read( ) of the initrd, if the initrd is located on (hd0,0) which is hdc1

Re: initrd breaks if VMALLOC_RESERVE is increased - Linux

Jan 2004 14:05:28 - @@ -332,10 +332,8 @@ switch (errnum) { case ERR_NUMBER_OVERFLOW: - /* If an overflow occurs, use the maximum address for - initrd instead. This is good, because MAXINT

Re: initrd breaks if VMALLOC_RESERVE is increased - Linux

Mar 2003 21:07:35 - 1.44 +++ stage2/boot.c 9 Jan 2004 14:05:28 - @@ -332,10 +332,8 @@ switch (errnum) { case ERR_NUMBER_OVERFLOW: - /* If an overflow occurs, use the maximum address for - initrd instead. This is good, because MAXINT is - greater than

Re: initrd breaks if VMALLOC_RESERVE is increased - Linux

than GRUB. If you need to change the location of an initrd, you can set it in a kernel header. See Documentation/i386/boot.txt in your Linux source tree for more info. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman

initrd breaks if VMALLOC_RESERVE is increased - Linux

Hello. I have run into an interesting problem with grub 0.93. This occurs with the Linux 2.4.23 kernel from kernel.org running on an i386 platform with SCSI disks and 2GB of memory. I found that if I change VMALLOC_RESERVE in /usr/src/linux/include/asm/page.h from: #define VMALLOC_RESERVE

Grub, Linux, initrd, and virtual memory layout

, the kernel dies with the message: initrd extends beyond end of memory ... disabling initrd If I create a kernel that does not use an initrd, it works just fine. This is a production machine, and I cannot take it down for any tests. With lilo it worked out of the box. regards, chm

Re: [PATCH] Parse mem= on Linux kernel command line to change initrd load address (resend)

have to be able to handle unsigned long long, because Pentium Pro and later processors can use up to 64GB. So, if you want to make GRUB complete theoretically, simple_strtoul is not enough, either. But, as initrd cannot be put above 0x3C00 anyway, GRUB doesn't have to support such a large value

Re: [PATCH] Parse mem= on Linux kernel command line to change initrd load address (resend)

At 08 Mar 2002 16:50:57 -0500, Jeremy Katz wrote: The attached patch lets GRUB parse a Linux kernel command line for mem= to use as the upper memory location for an initrd as opposed to the maximum detected memory amount per the Linux/I386 boot protocol. Is it really necessary to use

initrd getting overwritten with 1G memory and grub

Hi, I am new to grub and I am facing a problem. With 512MB RAM on my system, I can boot linux using grub without any problems. We use a compact flash based linux system that fits in a 8M flash, and we use an initrd based ramdisk which in principle usually occupies half the memory on the system

Re: Bug#111315: grub: problem with DAC960, kernel 2.4 and initrd]

Gordon ``48, 1'' is 0x3001, not 0x4801. Of course, you are right ! I'll try that next week and let you know... Gordon Maybe try that, but I can't say that I know what your problem Gordon is. My problem is that I've done too much hex lately and I have a tendancy to interpret everything I see

Re: [Laurent.Bonnaud@inpg.fr: Bug#111315: grub: problem with DAC960, kernel 2.4 and initrd]

- Forwarded message from Laurent Bonnaud [EMAIL PROTECTED] - - I also tried passing the root= option as an hex value. I used: title Debian GNU/Linux, kernel 2.4.12-686 root(hd0,0) kernel /boot/vmlinuz-2.4.12-686 root=0x4801 ro initrd

Re: [Laurent.Bonnaud@inpg.fr: Bug#111315: grub: problem with DAC960, kernel 2.4 and initrd]

sorry here is a link to the original mail and followups: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=111315repeatmerged=yes On Wed, Nov 14, 2001 at 09:01:57PM -0600, Gordon Matzigkeit wrote: Maybe try that, but I can't say that I know what your problem is. msg04606/pgp0.pgp

Re: [Laurent.Bonnaud@inpg.fr: Bug#111315: grub: problem with DAC960, kernel 2.4 and initrd]

Jason == Jason Thomas [EMAIL PROTECTED] writes: Jason sorry here is a link to the original mail and followups: Jason http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=111315repeatmerged=yes Well, as he said and as I've seen, it works with 2.2 but not with some or all 2.4. Does grub do

Re: initrd

At Fri, 9 Nov 2001 09:26:39 +1100, Jason Thomas wrote: hi all, its been brought to my attention that if the initrd image is bigger than the 4meg then the usual defaul ramdisk size of 4meg will not do. so to make this work you need something like. ramdisk_size=16384 on the kernel command

initrd

hi all, its been brought to my attention that if the initrd image is bigger than the 4meg then the usual defaul ramdisk size of 4meg will not do. so to make this work you need something like. ramdisk_size=16384 on the kernel command line. should we maybe document this in the grub doco. Thanks

Re: [bonnaud@iut2.upmf-grenoble.fr: Bug#111315: grub: problem with DAC960, kernel 2.4 and initrd]

/vmlinuz-2.4.9-686 root=/dev/rd/c0d0p1 ro initrd /boot/initrd-2.4.9-686 Umm, this is more than likely an initrd problem then if it works with 2.2.19. I'd suggest setting up the 2.4 kernel with the same setup as the 2.2.19 kernel first before trying initrd. I do not think this is a bug

[bonnaud@iut2.upmf-grenoble.fr: Bug#111315: grub: problem with DAC960, kernel 2.4 and initrd]

with DAC960, kernel 2.4 and initrd Package: grub Version: 0.90-9 Severity: normal Hi, I'm trying to use grub to boot the standard Debian kernel 2.4.9 on a machine where the root partition is on a DAC960 controler. Here is what happens during the boot procedure: - grub loads

Re: [bonnaud@iut2.upmf-grenoble.fr: Bug#111315: grub: problem with DAC960, kernel 2.4 and initrd]

I think I may have some helpful information regarding this. On Thu, Sep 06, 2001 at 08:25:16AM +1000, Jason Thomas wrote: | - Forwarded message from Laurent Bonnaud [EMAIL PROTECTED] - ... [ kernel 2.4.x ] ... | - partitions are detected correctly (including the root partition) | -

Re: [Bug-grub] Re: [bonnaud@iut2.upmf-grenoble.fr: Bug#111315: grub: problem with DAC960, kernel 2.4 and initrd]

On Wed, Sep 05, 2001 at 08:10:56PM -0400, dman wrote: | kernel /boot/vmlinuz-2.4.9-686 root=/dev/rd/c0d0p1 ro no its a DAC960 raid controller. your problem could be because your fstab was wrong? or you didn't have devfs mounted, which can be setup to do so automatically when you

Re: [Bug-grub] Re: [bonnaud@iut2.upmf-grenoble.fr: Bug#111315: grub:problem with DAC960, kernel 2.4 and initrd]

On Thu, 6 Sep 2001, Jason Thomas wrote: no its a DAC960 raid controller. Yes, but if you're using devfs, the paths may be different. your problem could be because your fstab was wrong? or you didn't have devfs mounted, which can be setup to do so automatically when you compile the kernel

Re: PATCH: Fix for multiple initrd files

You need to consider compatibility. GRUB must _replace_ an initrd image when one executes the command initrd more than once, by default. So one way would be to add an option to instruct initrd to change the behavior so that it concatenates multiple images. Another way would be to add another

Re: PATCH: Fix for multiple initrd files

OKUJI Yoshinori wrote: You need to consider compatibility. GRUB must _replace_ an initrd image when one executes the command initrd more than once, by default. Why? I can think of no reason why a person would place more then one initrd call per entry, except as a mistake

Re: PATCH: Fix for multiple initrd files

From: Dave Cinege [EMAIL PROTECTED] Subject: Re: PATCH: Fix for multiple initrd files Date: Fri, 29 Jun 2001 18:50:15 -0400 You need to consider compatibility. GRUB must _replace_ an initrd image when one executes the command initrd more than once, by default. Why? I can think

Re: PATCH: Fix for multiple initrd files

OKUJI Yoshinori wrote: From: Dave Cinege [EMAIL PROTECTED] Subject: Re: PATCH: Fix for multiple initrd files Date: Fri, 29 Jun 2001 18:50:15 -0400 You need to consider compatibility. GRUB must _replace_ an initrd image when one executes the command initrd more than once

PATCH: Fix for multiple initrd files

Okuji, Back in January I wrote a patch that basically did this, and you replied with a better version. I've finally gotten around to testing, fixing, and making ready your patch. This patch fixes GRUB's initrd loading behavior. Each 'initrd' call is now loaded 'inline' instead of replacing

Re: Initrd unzipped ?

On Mon, Jun 25, 2001 at 07:36:04PM +0200, Thierry Laronde wrote: Hello, It seems that when one uses an initrd with Linux, the initrd is unzipped. If I'm right, since Linux is able to unzip the initrd too, and since it first moves the initrd to a ramdisk, this is not practical (one waste

Initrd unzipped ?

Hello, It seems that when one uses an initrd with Linux, the initrd is unzipped. If I'm right, since Linux is able to unzip the initrd too, and since it first moves the initrd to a ramdisk, this is not practical (one waste memory). If I'm right about the unzipping, where in the sources

Re: Initrd unzipped ?

From: Thierry Laronde [EMAIL PROTECTED] Subject: Initrd unzipped ? Date: Mon, 25 Jun 2001 19:36:04 +0200 It seems that when one uses an initrd with Linux, the initrd is unzipped. If I'm right, since Linux is able to unzip the initrd too, and since it first moves the initrd to a ramdisk

Re: Initrd unzipped ?

OKUJI Yoshinori wrote: From: Thierry Laronde [EMAIL PROTECTED] Subject: Initrd unzipped ? Date: Mon, 25 Jun 2001 19:36:04 +0200 It seems that when one uses an initrd with Linux, the initrd is unzipped. If I'm right, since Linux is able to unzip the initrd too, and since it first

Re: Initrd unzipped ?

On Tue, Jun 26, 2001 at 07:08:19AM +0900, OKUJI Yoshinori wrote: From: Thierry Laronde [EMAIL PROTECTED] Subject: Re: Initrd unzipped ? Date: Mon, 25 Jun 2001 19:43:19 +0200 OK, found : in disk_io, this is called via grub_read, and one can disable it via configure. Normally, you don't

  1   2   >