Re: BTRFS RAID 1

[Vladimir 'phcoder' Serbinenko]

That looks like correct output

Le dim. 21 juil. 2024, 23:20, Opty  a écrit :

> Hello,
>
> bug #39591 suggests it should work but I got
>
> opty@vodopnik:~$ tmp/grub/grub-2.12/grub-probe --target=device /
> /dev/mapper/lukssda1
> /dev/mapper/lukssdb1
>
> Regards,
> Opty
>
>

Re: Fixing My First Bug

[Vladimir 'phcoder' Serbinenko]

Sorry, I misread your message. Syminfo.lst is autogenerated but extra_deps
is written manually. I'll have a look later

Le ven. 19 juil. 2024, 21:23, Vladimir 'phcoder' Serbinenko <
phco...@gmail.com> a écrit :

> syminfo.lst is generated automatically. You don't need to supply it. Your
> error means 2 things:
> 1) real error is earlier in the log
> 2) most likely you don't have right sed or awk tools
>
> Le ven. 19 juil. 2024, 20:56, Lavelle, William  a
> écrit :
>
>> Hello all! Apologies for any noob behavior, I’m new to this. I’d like to
>> help fix Bug 65065 on the forums
>> <https://savannah.gnu.org/bugs/index.php?65065> after it happened for me
>> too, 7 months after it first posted.
>>
>> When I run make, I get the error:
>>
>> *** No rule to make target ‘../grub-core/extra_deps.lst’, needed by
>> ‘syminfo.lst’.  Stop.
>>
>>
>>
>> It seems simple to fix (famous last words, I know) since it’s just a
>> missing file. The commit message by Oliver Steffen (linked) seems to imply
>> this file “extra_deps.lst” already exists, just wasn’t included in the
>> tarball. My ideas to fix it:
>>
>>1. Use git add to commit the file, adding it to the tarball for
>>everyone
>>2. Grab the file from somewhere else, put it in the source code
>>directory, run make. This only solves it for me, but I could post on the
>>forum bug report “this is solved by going to this public resource to get
>>the file yourself”. But where could I grab a copy of
>>“../grub-core/extra_deps.lst”? I’m worried about how do I know if the
>>version I grab for use is outdated. I tried download the most recent
>>snapshot with “git clone https://git.savannah.gnu.org/git/grub.git”
>>but couldn’t find any file named “extra_deps.lst” inside.
>>
>>
>>
>> Thank you all!
>>
>

Re: Fixing My First Bug

[Vladimir 'phcoder' Serbinenko]

syminfo.lst is generated automatically. You don't need to supply it. Your
error means 2 things:
1) real error is earlier in the log
2) most likely you don't have right sed or awk tools

Le ven. 19 juil. 2024, 20:56, Lavelle, William  a écrit :

> Hello all! Apologies for any noob behavior, I’m new to this. I’d like to
> help fix Bug 65065 on the forums
>  after it happened for me
> too, 7 months after it first posted.
>
> When I run make, I get the error:
>
> *** No rule to make target ‘../grub-core/extra_deps.lst’, needed by
> ‘syminfo.lst’.  Stop.
>
>
>
> It seems simple to fix (famous last words, I know) since it’s just a
> missing file. The commit message by Oliver Steffen (linked) seems to imply
> this file “extra_deps.lst” already exists, just wasn’t included in the
> tarball. My ideas to fix it:
>
>1. Use git add to commit the file, adding it to the tarball for
>everyone
>2. Grab the file from somewhere else, put it in the source code
>directory, run make. This only solves it for me, but I could post on the
>forum bug report “this is solved by going to this public resource to get
>the file yourself”. But where could I grab a copy of
>“../grub-core/extra_deps.lst”? I’m worried about how do I know if the
>version I grab for use is outdated. I tried download the most recent
>snapshot with “git clone https://git.savannah.gnu.org/git/grub.git”
>but couldn’t find any file named “extra_deps.lst” inside.
>
>
>
> Thank you all!
>

Re: os-prober slow, grub-mount results in very slow file transfers

[Vladimir 'phcoder' Serbinenko]

We don't maintain os-prober. As for grub-mount it was never meant to be
fast and certainly isn't

Le lun. 13 mai 2024, 22:47, stratus--- via Bug reports for the GRand
Unified Bootloader  a écrit :

> Dear Grub maintainers, myself and others on the Artix forum have
> experienced problems with os-prober running very slowly. The issue seems to
> occur in other distros as well, and the same subject has come up before in
> the past:
> https://forum.artixlinux.org/index.php/topic,6818.msg41493
> It appears that grub-mount uses a FUSE mount which requires a specific
> implementation for different filesystems. When the partitions are mounted
> with grub-mount, file reading operations are vastly slower than when
> mounted by the normal mount command. This is even worse on BTRFS than with
> EXT4, and it looks like NTFS is probably very slow too. This can be easily
> tested by using grub-mount to mount a partition then seeing how long it
> takes to copy some files over compared with a normal mount. And to further
> obscure the issue, it also appears to depend on how much searching
> os-prober has to do before  finding out the information it needs, some
> distros like Devuan seem to yield this quickly so there still isn't any
> real delay, but Arch takes much longer and probably Windows too it appears.
> I sometimes use gvfs-gphoto2 to transfer pictures and videos (some of
> which may be several GB in size) from my camera which uses a FUSE
> implementation and that doesn't have especially slow transfer speeds.
> I wonder if you might be able to fix this sometime, or if you think the
> issue lies outside of grub, provide advice on who to "bug" about this
> instead.
> Best wishes!
>
>

Re: Error in text

[Vladimir 'phcoder' Serbinenko]

Translations are not handled by GRUB team but by translation project.
Please take any translation problem with them

Le mar. 6 déc. 2022, 15:52, ric ric  a écrit :

> Hello.
> I found a typo in GRUB. The system is configured in Spanish language. I'm
> in the GRUB command line/CLI. The error is in the text of the command
> description (the descriptions are in Spanish on my system).
> The command is: help legacy_check_password
> When it says "Simulate GRUB1 <> command in menu entry mode".
> There is "password" for "pasword".
>

Re: [PATCH v2] fat: Allow out-of-range FAT modification timestamps

[Vladimir 'phcoder' Serbinenko]

LGTM. Also you can skip dprintf. It's not very useful.

Le dim. 23 mai 2021 à 02:56, Tomasz Kramkowski  a écrit :

> 20def1a3c introduced support for file modification times to allow
> comparison of file ages on EFI systems. This patch used
> grub_datetime2unixtime which uses a 32 bit unix timestamp and as a
> result did not allow the full range of times that FAT timestamps do.
>
> In some situations a file with a timestamp of 1970-01-01 gets
> transferred to a FAT partition, the timestamp ends up as 2098-01-01
> because of FAT's use of the 1980-01-01 DOS epoch and lack of negative
> timestamps.
>
> Since 2098 is after 2038, this date cannot fit in a 32 bit timestamp.
>
> Ideally grub should use 64 bit timestamps but I have not investigated
> what kind of work would be required to support this.
>
> This fixes bug #60565.
>
> Reported-by: Naïm Favier 
> Tested-by: Naïm Favier 
> Signed-off-by: Tomasz Kramkowski 
> ---
>  grub-core/fs/fat.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> v2: grub_dprintf needs an explicit \n unlike grub_error
>
> diff --git a/grub-core/fs/fat.c b/grub-core/fs/fat.c
> index 7f775a170..7ed20d627 100644
> --- a/grub-core/fs/fat.c
> +++ b/grub-core/fs/fat.c
> @@ -1020,16 +1020,17 @@ grub_fat_dir (grub_device_t device, const char
> *path, grub_fs_dir_hook_t hook,
>info.mtimeset = grub_exfat_timestamp (grub_le_to_cpu32
> (ctxt.entry.type_specific.file.m_time),
>
> ctxt.entry.type_specific.file.m_time_tenth,
> );
> +  if (info.mtimeset == 0)
> +   grub_dprintf("exfat", "invalid modification timestamp for %s\n",
> path);
>  #else
>if (ctxt.dir.attr & GRUB_FAT_ATTR_VOLUME_ID)
> continue;
>info.mtimeset = grub_fat_timestamp (grub_le_to_cpu16
> (ctxt.dir.w_time),
>   grub_le_to_cpu16
> (ctxt.dir.w_date),
>   );
> -#endif
>if (info.mtimeset == 0)
> -   grub_error (GRUB_ERR_OUT_OF_RANGE,
> -   "invalid modification timestamp for %s", path);
> +   grub_dprintf("fat", "invalid modification timestamp for %s\n",
> path);
> +#endif
>
>if (hook (ctxt.filename, , hook_data))
> break;
> --
> 2.31.1
>
>
>

Re: grub-mkstandalone Error

[Vladimir 'phcoder' Serbinenko]

On Mon, Sep 21, 2020 at 10:53 AM Wasim Khan  wrote:
>
> Hi,
>
> I am facing below error while generating standalone image if I use Linaro GCC 
> 7.4-2019.02 toolchain.
>
> $ grub-mkstandalone --directory=./grub-core -O arm64-efi -o grub.efi 
> --modules "tftp net efinet gzio linux efifwsetup part_gpt part_msdos font 
> gfxterm all_video" /boot/grub/grub.cfg=./grub.cfg
> grub-mkstandalone: error: relocation 0x113 is not implemented yet.
This is relocation R_AARCH64_ADR_PREL_PG_HI21
The weird part is that I implemented it back in 2016. Can you retest
with official source?
>
> Above command works fine if I use linaro-5.4.1 toolchain.
> Can somebody please help to know why the issues is coming with newer 
> toolchain (like GCC 7.4-2019.02) and any fix for that ?
>
>
> Regards,
> Wasim
>


-- 
Regards
Vladimir 'phcoder' Serbinenko

Re: bug in grub2-install

[Vladimir 'phcoder' Serbinenko]

/boot needs to be readadble by grub on boot. Failing that your system won't
boot and hence such install is not implemented.
Skip-fs -probe  controls the check of the device that will hold bootsector,
not of /boot

On Tue, Jul 7, 2020, 16:36 Audun  wrote:

> Grub-install is not installing due to unknown filesystem *even when
> using skip-fs-probe*
>
> This is absolutely maddening.
>
> # grub2-install --skip-fs-probe /dev/sdb
> Installing for i386-pc platform.
> grub2-install: error: unknown filesystem.
>
> --
> Best Regards,
>
> Audun Gangsto
>
>

Re: Cannot install grub

[Vladimir 'phcoder' Serbinenko]

On Thu, Jun 11, 2020 at 10:29 AM mcpain  wrote:
>
> Hi. I was unable to install grub on my PC with following error:
>
> # grub-install /dev/sda
> unable to identify a filesystem at hostdisk//dev/sda; safety check can't be
> performed
>
> using grub-2.02
> There's a single volume on disk without partition table and it's encrypted
> with LUKS.
This can't work as boot sector and LUKS structure would occupy the
same place. You're lucky that I have written this check as otherwise
it would have killed your LUKS
>
> When I install on unencrypted volume, grub successfully installs on disk.



-- 
Regards
Vladimir 'phcoder' Serbinenko

Re: Re: grub does not detect partition 5 on new USB-WD My Passport 1TB

[Vladimir 'phcoder' Serbinenko]

On Thu, Jul 18, 2019 at 6:17 PM Peter Littmann  wrote:
>
> You mean doing "ls -l" in a booted Linux?
> Accessing the disk from within Linux is not the problem.
> I installed Linux(Ubuntu/Manjaro/Arch) some times to this disk and all wents 
> good.  But at boot time grub2 is not be able to detect/connect to the 
> installed system.
>
> Grub2 itself does not provide "ls -l", right?
It does
>
> Your guess goes in the direction of a problem with 48Bit-LBA it seems, but 
> this was included in the BIOSes around the year 2002, I think?
For internal, yes. For USB the problem persisted for many more years
> This AMI BIOS is from the year 2010(Build-date).
>
> In case of (hd0,msdos1)(Ubuntu) it helped to install it in the first 
> partition.
> But the rest of the HDD should be adressable by the BIOS and Grub2, too, I 
> expect.
>
> Booting by SuperGrub2Disk 2.04rc1 even does not show (hd0,msdos5).
>
> Only when I load the additional drivers(experimental) I can show 
> (usb5a,msdos5) and list its contents.
> But I can not boot it, but this may be a other problem cause at first it 
> detects a device hd111 and then can not find it.
>
> Regards
>
> Peter Littmann
>
> Gesendet: Donnerstag, 18. Juli 2019 um 14:42 Uhr
> Von: "Vladimir 'phcoder' Serbinenko" 
> An: "Peter Littmann" 
> Cc: bug-grub@gnu.org
> Betreff: Re: grub does not detect partition 4 and 5 on new USB-WD My Passport 
> 1TB
> try "ls -l" to see how much of disk BIOS sees. My guess is that it
> cuts it at 128GiB. I'd recommend putting everything need for boot at
> the beginning of the disk
>
> On Mon, Jul 15, 2019 at 6:32 PM Peter Littmann  wrote:
> > I have a old BIOS (build date 04/01/2010) and connected a new USB-WD 
> > Passport 1TB harddisk.
> > Grub 2.02 does only detect: (hd0,msdos1), (hd0,msdos2) and (hd0,msdos3)
> > But not (hd0,msdos4) (Extended) and (hd0,msdos5) (ext4 with 
> > Arch-Installation).
> > The addressing should be handled by 48Bit-LBA.
> >
> > What can be the reason and how to solve this?
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: grub does not detect partition 4 and 5 on new USB-WD My Passport 1TB

[Vladimir 'phcoder' Serbinenko]

try "ls -l" to see how much of disk BIOS sees. My guess is that it
cuts it at 128GiB. I'd recommend putting everything need for boot at
the beginning of the disk

On Mon, Jul 15, 2019 at 6:32 PM Peter Littmann  wrote:
>
> Hey,
>
> I have a old BIOS (build date 04/01/2010) and connected a new USB-WD Passport 
> 1TB harddisk.
> Grub 2.02 does only detect: (hd0,msdos1), (hd0,msdos2) and (hd0,msdos3)
> But not (hd0,msdos4) (Extended) and (hd0,msdos5) (ext4 with 
> Arch-Installation).
> The addressing should be handled by 48Bit-LBA.
>
> What can be the reason and how to solve this?
>
> TIA
>
> Peter
>
>
>
> ___
> Bug-grub mailing list
> Bug-grub@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-grub



-- 
Regards
Vladimir 'phcoder' Serbinenko

___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: Bug with GRUB2 installation in UEFI mode on HP 250 G6 Notebook

[Vladimir 'phcoder' Serbinenko]

This doesn't even contain output of grub-install, at least nothing I
could find immediately

On Tue, Jul 16, 2019 at 10:41 PM Artyom Pozharov
 wrote:
>
> Hello, GRUB2 Developers. I noticed the critical error with GRUB-installer
> package. Please, take attention to it. I can't install GNU/Linux
> distributions in UEFI, because this error appears. There are no problems
> with BIOS-compability mode. Thanks in advance! Details here:
> https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1835664
> Yours sincerely, Artyom!
>
> ___
> Bug-grub mailing list
> Bug-grub@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-grub



-- 
Regards
Vladimir 'phcoder' Serbinenko

___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: 100% CPU usage while waiting for LUKS password

[Vladimir 'phcoder' Serbinenko]

On Thu, Jul 11, 2019 at 4:57 AM James Harvey  wrote:
>
> On Wed, Jun 26, 2019 at 8:10 PM James Harvey  wrote:
> >
> > While waiting for the user to type a LUKS password, grub 2.0.2 causes
> > 100% CPU usage.
> >
> > This is perhaps most problematic within a virtual machine, taking up
> > an entire virtual core on the host.  Especially bad for VM providers
> > who don't have control over this.
> >
> > This is certainly a lesser problem on bare metal, although it's never
> > a great idea to put undue stress on hardware.
>
> Found what's causing the 100% CPU usage.  12 years ago, 0149ab7c6
> disabled the 'hlt' instruction in
> include/grub/i386/time.h::grub_cpu_idle(), noting "this can't work
> until we handle interrupts."  This later made its way into
> include/grub/x86_64/time.h as well.
>
> Has the missing interrupt support been added in the last 12 years, at
> this stage in the boot process?

no

>
> ___
> Bug-grub mailing list
> Bug-grub@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-grub



-- 
Regards
Vladimir 'phcoder' Serbinenko

___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: Fix incorrect mask for ppc64

[Vladimir 'phcoder' Serbinenko]

Why is swap_bytes right solution? It feels like if anything we just need to
remove le_to_cpu32

On Tue, Dec 5, 2017, 13:23  wrote:

> From: Masahiro Matsuya 
>
> The netmask configured in firmware is not respected on ppc64 (big endian).
> When 255.255.252.0 is set as netmask in firmware, the following is the
> value of bootpath string in grub_ieee1275_parse_bootpath().
>
>  /vdevice/l-lan@3002
> :speed=auto,duplex=auto,192.168.88.10,,192.168.89.113,192.168.88.1,5,5,255.255.252.0,512
>
> The netmask in this bootpath is no problem, since it's a value specified
> in firmware. But,
> The value of 'subnet_mask.ipv4' was set with 0xfc00, and __builtin_ctz
> (~grub_le_to_cpu32 (subnet_mask.ipv4)) returned 16 (not 22).
> As a result, 16 was used for netmask wrongly.
>
>      1100   # subnet_mask.ipv4 (=0xfc00)
>    1100     # grub_le_to_cpu32
> (subnet_mask.ipv4)
>    0011     # ~grub_le_to_cpu32
> (subnet_mask.ipv4)
>
> And, the count of zero with __builtin_ctz can be 16.
> This patch changes it as below.
>
>      1100   # subnet_mask.ipv4 (=0xfc00)
>    1100     # grub_le_to_cpu32
> (subnet_mask.ipv4)
>      1100   #
> grub_swap_bytes32(grub_le_to_cpu32 (subnet_mask.ipv4))
>      0011   #
> ~grub_swap_bytes32(grub_le_to_cpu32 (subnet_mask.ipv4))
>
> The count of zero with __builtin_clz can be 22. (clz counts the number of
> one bits preceding the most significant zero bit)
> ---
>  grub-core/net/drivers/ieee1275/ofnet.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/grub-core/net/drivers/ieee1275/ofnet.c
> b/grub-core/net/drivers/ieee1275/ofnet.c
> index 002446be1..3df75357a 100644
> --- a/grub-core/net/drivers/ieee1275/ofnet.c
> +++ b/grub-core/net/drivers/ieee1275/ofnet.c
> @@ -220,8 +220,7 @@ grub_ieee1275_parse_bootpath (const char *devpath,
> char *bootpath,
>   flags);
>inter->vlantag = vlantag;
>grub_net_add_ipv4_local (inter,
> -  __builtin_ctz (~grub_le_to_cpu32
> (subnet_mask.ipv4)));
> -
> +  __builtin_clz
> (~grub_swap_bytes32(grub_le_to_cpu32 (subnet_mask.ipv4;
>  }
>
>if (gateway_addr.ipv4 != 0)
> --
> 2.13.5
>
>
> ___
> Bug-grub mailing list
> Bug-grub@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-grub
>
___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: grub-mkstandalone: error: `/usr/lib/grub/i386-pc/kernel.img' is miscompiled: its start address is 0x9000 instead of 0x8200: ld.gold bug?.

[Vladimir 'phcoder' Serbinenko]

This is not an upstream problem. It's distros using a buggy linker. However
I moved link address to 0x9000 to avoid this problem in the future
Le Thu, Aug 17, 2017 à 3:39 PM, Julian Brost  a écrit :

> The command
>
> grub-mkstandalone \
>   --format=i386-multiboot \
>   --directory=/usr/lib/grub/i386-pc \
>   --output=/dev/null
>
> results in the error message
>
> grub-mkstandalone: error: `/usr/lib/grub/i386-pc/kernel.img' is
> miscompiled: its start address is 0x9000 instead of 0x8200: ld.gold
> bug?.
>
> The problem can be reproduced with version 2.02 on Arch Linux and Debian
> sid, as well as on Debian stretch with version 2.02beta3.
>
> ___
> Bug-grub mailing list
> Bug-grub@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-grub
>
___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: Tag-alignment in multiboot2 image headers

[Vladimir 'phcoder' Serbinenko]

On Wed, Mar 8, 2017, 22:28 Andrei Borzenkov  wrote:

> On Thu, Mar 9, 2017 at 1:17 AM, Ahmed, Safayet (GE Global Research,
> US)  wrote:
> > Hello,
> >
> > I'm seeing an inconsistency in the multiboot2 specification and the
> implementation of the multiboot2 loader code in GRUB. It may be my
> understanding that's incorrect. A clarification would be appreciated.
> >
> > This concerns the alignment requirements for tags in OS image headers.
> The specification states 4 bytes, but the code uses 8 bytes.
> >
> > The specification states (Section 3.1.3) that "Tags constitutes a buffer
> of structures following each other padded on 'u32' size."
> >
>
> This is ambiguous and needs better wording as well (it is not clear
> whether "padded" here applies to individual tag or all tags block).
>
> > The "for" loop for parsing tags uses the following "increment" statement
> (grub/grub_core/loader/multiboot_mbi2.c: line 148):
> > tag = (struct multiboot_header_tag *) ((grub_uint32_t *) tag +
> ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN) / 4))
> >
> > The macro MULTIBOOT_TAG_ALIGN is defined in (include/multiboot2.h) as 8.
> This alignment value is consistent with the specification for tags in the
> multiboot2 information structure, but not for tags in an OS image header.
> >
>
> Yes, it sure looks wrong. Thanks for making us aware!
>
> @Vladimir, @Daniel - I think this is 2.02 material, we do not want
> release with such inconsistency. The question is what needs fixing
> though - about half of all tags are not multiple of 8 bytes, so I
> expect people to hit it in real life. What is current implementation
> in MB2 compliant kernels?
>
The intention was 8, so that we can have u64 naturally aligned in the
header even on non-x86. I believe all current kernels are compatible with
grub, so I think we should update the docs. Daniel, your opinion?

>
___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: [PATCH] squash4: fix handling of fragments and sparse files

[Vladimir 'phcoder' Serbinenko]

On Sat, Feb 18, 2017, 10:17 Andrei Borzenkov  wrote:

> 1. Do not assume block list and fragment are mutually exclusive. Squash
> can pack file tail as fragment (unless -no-fragments is specified); so
> check read offset and read either from block list or from fragments as
> appropriate.
>
> 2. Support sparse files with zero blocks.
>
> 3. Fix fragment read - frag.offset is absolute fragment position,
> not offset relative to ino.chunk.
>
Go ahead.

>
> Reported and tested by Carlo Caione 
>
> ---
>
> @Vladimir: we need regression tests for both of these cases. We could real
> small
> files only by accident - block list was zero, so it appeared to work.
>
How do you create those files reliably? Feel free to add any files to
grub-fs-tester. Feel free to commit without tests, we can add tests later.

>
> @Carlo, please test. I'm surprised it worked for you even without
> fragments as
> your file is sparse and grub immediately choked on the first zero block.
>
>  grub-core/fs/squash4.c | 55
> +-
>  1 file changed, 36 insertions(+), 19 deletions(-)
>
> diff --git a/grub-core/fs/squash4.c b/grub-core/fs/squash4.c
> index b97b344..deee71a 100644
> --- a/grub-core/fs/squash4.c
> +++ b/grub-core/fs/squash4.c
> @@ -823,7 +823,12 @@ direct_read (struct grub_squash_data *data,
>curread = data->blksz - boff;
>if (curread > len)
> curread = len;
> -  if (!(ino->block_sizes[i]
> +  if (!ino->block_sizes[i])
> +   {
> + /* Sparse block */
> + grub_memset (buf, '\0', curread);
> +   }
> +  else if (!(ino->block_sizes[i]
> & grub_cpu_to_le32_compile_time (SQUASH_BLOCK_UNCOMPRESSED)))
> {
>   char *block;
> @@ -873,36 +878,57 @@ direct_read (struct grub_squash_data *data,
>
>
>  static grub_ssize_t
> -grub_squash_read_data (struct grub_squash_data *data,
> -  struct grub_squash_cache_inode *ino,
> -  grub_off_t off, char *buf, grub_size_t len)
> +grub_squash_read (grub_file_t file, char *buf, grub_size_t len)
>  {
> +  struct grub_squash_data *data = file->data;
> +  struct grub_squash_cache_inode *ino = >ino;
> +  grub_off_t off = file->offset;
>grub_err_t err;
>grub_uint64_t a = 0, b;
>grub_uint32_t fragment = 0;
>int compressed = 0;
>struct grub_squash_frag_desc frag;
> +  grub_off_t blk_len;
> +  grub_uint64_t mask = grub_le_to_cpu32 (data->sb.block_size) - 1;
> +  grub_size_t orig_len = len;
>
>switch (ino->ino.type)
>  {
>  case grub_cpu_to_le16_compile_time (SQUASH_TYPE_LONG_REGULAR):
> -  a = grub_le_to_cpu64 (ino->ino.long_file.chunk);
>fragment = grub_le_to_cpu32 (ino->ino.long_file.fragment);
>break;
>  case grub_cpu_to_le16_compile_time (SQUASH_TYPE_REGULAR):
> -  a = grub_le_to_cpu32 (ino->ino.file.chunk);
>fragment = grub_le_to_cpu32 (ino->ino.file.fragment);
>break;
>  }
>
> -  if (fragment == 0x)
> -return direct_read (data, ino, off, buf, len);
> +  /* Squash may pack file tail as fragment. So read initial part directly
> and
> + get tail from fragments */
> +  blk_len  = fragment == 0x ? file->size : file->size & ~mask;
> +  if (off < blk_len)
> +{
> +  grub_size_t read_len = blk_len - off;
> +  grub_ssize_t res;
> +
> +  if (read_len > len)
> +   read_len = len;
> +  res = direct_read (data, ino, off, buf, read_len);
> +  if ((grub_size_t) res != read_len)
> +   return -1; /* FIXME: is short read possible here? */
> +  len -= read_len;
> +  if (!len)
> +   return read_len;
> +  buf += read_len;
> +  off = 0;
> +}
> +  else
> +off -= blk_len;
>
>err = read_chunk (data, , sizeof (frag),
> data->fragments, sizeof (frag) * fragment);
>if (err)
>  return -1;
> -  a += grub_le_to_cpu64 (frag.offset);
> +  a = grub_le_to_cpu64 (frag.offset);
>compressed = !(frag.size & grub_cpu_to_le32_compile_time
> (SQUASH_BLOCK_UNCOMPRESSED));
>if (ino->ino.type == grub_cpu_to_le16_compile_time
> (SQUASH_TYPE_LONG_REGULAR))
>  b = grub_le_to_cpu32 (ino->ino.long_file.offset) + off;
> @@ -943,16 +969,7 @@ grub_squash_read_data (struct grub_squash_data *data,
>if (err)
> return -1;
>  }
> -  return len;
> -}
> -
> -static grub_ssize_t
> -grub_squash_read (grub_file_t file, char *buf, grub_size_t len)
> -{
> -  struct grub_squash_data *data = file->data;
> -
> -  return grub_squash_read_data (data, >ino,
> -   file->offset, buf, len);
> +  return orig_len;
>  }
>
>  static grub_err_t
> --
> tg: (2fb8cd2..) u/squash-tail-fragment (depends on: master)
>
> ___
> Bug-grub mailing list
> Bug-grub@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-grub
>
___
Bug-grub mailing list

Re: Problem with ISO9660 and files stored on multiple extents

[Vladimir 'phcoder' Serbinenko]

On Thu, Feb 16, 2017, 16:56 Carlo Caione <ca...@endlessm.com> wrote:

> On Thu, Feb 16, 2017 at 4:54 PM, Vladimir 'phcoder' Serbinenko
> <phco...@gmail.com> wrote:
> >
> >
> > On Thu, Feb 16, 2017, 14:14 Carlo Caione <ca...@endlessm.com> wrote:
> >>
> >> On Thu, Feb 16, 2017 at 2:09 PM, Vladimir 'phcoder' Serbinenko
> >> <phco...@gmail.com> wrote:
> >> >
> >> >
> >> > On Thu, Feb 16, 2017, 14:04 Carlo Caione <ca...@endlessm.com> wrote:
> >> >>
> >> >> On Thu, Feb 16, 2017 at 12:37 PM, Carlo Caione <ca...@endlessm.com>
> >> >> wrote:
> >> >> > On Thu, Feb 16, 2017 at 12:32 PM, Thomas Schmitt <
> scdbac...@gmx.net>
> >> >> > wrote:
> >> >> >> Hi,
> >> >> >>
> >> >> >> Carlo Caione wrote:
> >> >> >>> > I think that the problem
> >> >> >>> > here is that endless.squash has been stored in two extents in
> the
> >> >> >>> > ISO9660 and GRUB doesn't deal fine with that (also according to
> >> >> >>> > this
> >> >> >>> > comment
> >> >> >>> >
> >> >> >>> >
> >> >> >>> >
> http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/fs/iso9660.c#n960
> >> >> >>
> >> >> >> Andrei Borzenkov wrote:
> >> >> >>> This comment could be stale and misleading.
> >> >> >>
> >> >> >> The code of read_node() in iso9660.c looks ready for multi-extent
> >> >> >> (aka
> >> >> >> ISO
> >> >> >> level 3).
> >> >> >>
> >> >> >> I have a very densely compressed test ISO for large file support
> >> >> >>http://scdbackup.webframe.org/large.iso.bz2
> >> >> >> which bunzip2 inflates from 4.5 KiB to 4+ GiB.
> >> >> >
> >> >> > Yeah, I made some more tests and apparently the problem is not in
> the
> >> >> > ISO9660 module but in the SQUASH4 module.
> >> >> > To be perfectly honest I have already a patch that solves my
> problem
> >> >> > but I'm having a hard time to understand WHY it solves the issue
> >> >> > since
> >> >> > I'm still not really familiar with squashfs (I casually found it
> >> >> > during my debugging).
> >> >> > Of course probably it is only masking a problem somewhere else.
> Still
> >> >> > digging.
> >> >> >
> >> >> > diff --git a/grub-core/fs/squash4.c b/grub-core/fs/squash4.c
> >> >> > index b97b344..4fef813 100644
> >> >> > --- a/grub-core/fs/squash4.c
> >> >> > +++ b/grub-core/fs/squash4.c
> >> >> > @@ -895,7 +895,7 @@ grub_squash_read_data (struct grub_squash_data
> >> >> > *data,
> >> >> >break;
> >> >> >  }
> >> >> >
> >> >> > -  if (fragment == 0x)
> >> >> > +  if (fragment == 0x || fragment == 0)
> >> >> >  return direct_read (data, ino, off, buf, len);
> >> >> >
> >> >> >err = read_chunk (data, , sizeof (frag),
> >> >>
> >> >> Hey Vladimir,
> >> >> Any idea about this?
> >> >
> >> > How big is the file in question? What is the squash tools version?
> >>
> >> The squash image is 4564504576
> >
> > I mean the size of file you try to access
>
> In the squashfs image there is one single file of size 1147128
>
Then it's possible that your patch is correct. I don't know why the format
changes or what the 0 means in this field

>
> --
> Carlo Caione  |  +39.340.80.30.096  |  Endless
>
___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: Problem with ISO9660 and files stored on multiple extents

[Vladimir 'phcoder' Serbinenko]

On Thu, Feb 16, 2017, 14:14 Carlo Caione <ca...@endlessm.com> wrote:

> On Thu, Feb 16, 2017 at 2:09 PM, Vladimir 'phcoder' Serbinenko
> <phco...@gmail.com> wrote:
> >
> >
> > On Thu, Feb 16, 2017, 14:04 Carlo Caione <ca...@endlessm.com> wrote:
> >>
> >> On Thu, Feb 16, 2017 at 12:37 PM, Carlo Caione <ca...@endlessm.com>
> wrote:
> >> > On Thu, Feb 16, 2017 at 12:32 PM, Thomas Schmitt <scdbac...@gmx.net>
> >> > wrote:
> >> >> Hi,
> >> >>
> >> >> Carlo Caione wrote:
> >> >>> > I think that the problem
> >> >>> > here is that endless.squash has been stored in two extents in the
> >> >>> > ISO9660 and GRUB doesn't deal fine with that (also according to
> this
> >> >>> > comment
> >> >>> >
> >> >>> >
> http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/fs/iso9660.c#n960
> >> >>
> >> >> Andrei Borzenkov wrote:
> >> >>> This comment could be stale and misleading.
> >> >>
> >> >> The code of read_node() in iso9660.c looks ready for multi-extent
> (aka
> >> >> ISO
> >> >> level 3).
> >> >>
> >> >> I have a very densely compressed test ISO for large file support
> >> >>http://scdbackup.webframe.org/large.iso.bz2
> >> >> which bunzip2 inflates from 4.5 KiB to 4+ GiB.
> >> >
> >> > Yeah, I made some more tests and apparently the problem is not in the
> >> > ISO9660 module but in the SQUASH4 module.
> >> > To be perfectly honest I have already a patch that solves my problem
> >> > but I'm having a hard time to understand WHY it solves the issue since
> >> > I'm still not really familiar with squashfs (I casually found it
> >> > during my debugging).
> >> > Of course probably it is only masking a problem somewhere else. Still
> >> > digging.
> >> >
> >> > diff --git a/grub-core/fs/squash4.c b/grub-core/fs/squash4.c
> >> > index b97b344..4fef813 100644
> >> > --- a/grub-core/fs/squash4.c
> >> > +++ b/grub-core/fs/squash4.c
> >> > @@ -895,7 +895,7 @@ grub_squash_read_data (struct grub_squash_data
> >> > *data,
> >> >break;
> >> >  }
> >> >
> >> > -  if (fragment == 0x)
> >> > +  if (fragment == 0x || fragment == 0)
> >> >  return direct_read (data, ino, off, buf, len);
> >> >
> >> >err = read_chunk (data, , sizeof (frag),
> >>
> >> Hey Vladimir,
> >> Any idea about this?
> >
> > How big is the file in question? What is the squash tools version?
>
> The squash image is 4564504576
>
I mean the size of file you try to access

>
> mksquashfs version 4.3-git (2014/06/09)
>
> No options are passed to mksquashfs when creating the image.
>
> --
> Carlo Caione  |  +39.340.80.30.096  |  Endless
>
___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: Problem with ISO9660 and files stored on multiple extents

[Vladimir 'phcoder' Serbinenko]

On Thu, Feb 16, 2017, 14:04 Carlo Caione  wrote:

> On Thu, Feb 16, 2017 at 12:37 PM, Carlo Caione  wrote:
> > On Thu, Feb 16, 2017 at 12:32 PM, Thomas Schmitt 
> wrote:
> >> Hi,
> >>
> >> Carlo Caione wrote:
> >>> > I think that the problem
> >>> > here is that endless.squash has been stored in two extents in the
> >>> > ISO9660 and GRUB doesn't deal fine with that (also according to this
> >>> > comment
> >>> >
> http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/fs/iso9660.c#n960
> >>
> >> Andrei Borzenkov wrote:
> >>> This comment could be stale and misleading.
> >>
> >> The code of read_node() in iso9660.c looks ready for multi-extent (aka
> ISO
> >> level 3).
> >>
> >> I have a very densely compressed test ISO for large file support
> >>http://scdbackup.webframe.org/large.iso.bz2
> >> which bunzip2 inflates from 4.5 KiB to 4+ GiB.
> >
> > Yeah, I made some more tests and apparently the problem is not in the
> > ISO9660 module but in the SQUASH4 module.
> > To be perfectly honest I have already a patch that solves my problem
> > but I'm having a hard time to understand WHY it solves the issue since
> > I'm still not really familiar with squashfs (I casually found it
> > during my debugging).
> > Of course probably it is only masking a problem somewhere else. Still
> digging.
> >
> > diff --git a/grub-core/fs/squash4.c b/grub-core/fs/squash4.c
> > index b97b344..4fef813 100644
> > --- a/grub-core/fs/squash4.c
> > +++ b/grub-core/fs/squash4.c
> > @@ -895,7 +895,7 @@ grub_squash_read_data (struct grub_squash_data *data,
> >break;
> >  }
> >
> > -  if (fragment == 0x)
> > +  if (fragment == 0x || fragment == 0)
> >  return direct_read (data, ino, off, buf, len);
> >
> >err = read_chunk (data, , sizeof (frag),
>
> Hey Vladimir,
> Any idea about this?
>
How big is the file in question? What is the squash tools version?

>
>
> --
> Carlo Caione  |  +39.340.80.30.096  |  Endless
>
___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: flexnet etc

[Vladimir 'phcoder' Serbinenko]

Please upgrade your grub

On Tue, Oct 25, 2016, 19:50 WJ  wrote:

> Hallo,
>
> For years I use a dual boot PC Linux and Windows.
>
> Recently I installed an upgrade of Powerpdf from Nuance. This new
> edition uses flexnet.
> Thus repetively  Ubuntu became inaccessible. Everytime flexnet damaged
> Grub and only windows stayed accessible. Only an extensive procedure
> with live Ubuntu and bootrepair allowed me to use Ubuntu again.
>
> On the net I hear this is a normal problem, as both Grub and flexnet
> use the same area, maybe sector 37. Is it possible to get Grub
> installed in another area?
>
> Maybe you can help,
>
> Thank you very much,
>
> Best Wishes,
>
> Wicher Jansen
>
> ___
> Bug-grub mailing list
> Bug-grub@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-grub
>
___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: [bug #47569] GRUB 2.02~beta2 "fatal error: token too large, exceeds YYLMAX"

[Vladimir 'phcoder' Serbinenko]

We can add longjmp/setjmp to recover from such errors more gracefully

Le mer. 30 mars 2016 15:06, Andrei Borzenkov  a
écrit :

> Follow-up Comment #1, bug #47569 (project grub):
>
> Well, grub-mkconfig and /etc/default/grub are just shell scripts at the
> end.
> Not sure what we can do here. If shell does not complain, how should we
> know
> something went wrong?
>
>
> ___
>
> Reply to this item at:
>
>   
>
> ___
>   Message sent via/by Savannah
>   http://savannah.gnu.org/
>
>
> ___
> Bug-grub mailing list
> Bug-grub@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-grub
>
___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: [openbsd] 2.02-beta3: build fails - getroot.c:(.text+0x2b): undefined reference to `getrawpartition'

[Vladimir 'phcoder' Serbinenko]

If it solves the problem, go ahead

Le ven. 18 mars 2016 17:53, Andrei Borzenkov  a écrit :

> 18.03.2016 16:01, Jiri B пишет:
> > On Fri, Mar 18, 2016 at 06:26:47AM +0300, Andrei Borzenkov wrote:
> >>> [...]
> >>>   CFLAGS=-ftrampolines -fno-stack-protector -fno-pie -nopie
> >>>
> >>> So I gave it a try and it seems better (?)
> >>>
> >>> $ ls -l
> /home/jirib/openbsd/pobj/grub-2.02-beta3/fake-amd64/usr/local/lib/grub/i386-pc/
> lzma_decompress.im*
> >>> -rwxr-xr-x  1 jirib  wheel  3068 Mar 17 21:45
> /home/jirib/openbsd/pobj/grub-2.02-beta3/fake-amd64/usr/local/lib/grub/i386-pc/lzma_decompress.image*
> >>> -rw-r--r--  1 jirib  wheel  2832 Mar 17 21:45
> /home/jirib/openbsd/pobj/grub-2.02-beta3/fake-amd64/usr/local/lib/grub/i386-pc/lzma_decompress.img
> >>>
> >>> $ objdump -f
> /home/jirib/openbsd/pobj/grub-2.02-beta3/fake-amd64/usr/local/lib/grub/i386-pc/lzma_decompress.image
> >>>
> >>>
> /home/jirib/openbsd/pobj/grub-2.02-beta3/fake-amd64/usr/local/lib/grub/i386-pc/lzma_decompress.image:
>file format elf32-i386
> >>> architecture: i386, flags 0x0002:
> >>> EXEC_P
> >>> start address 0x8200
> >>>
> >>> It is OK?
> >>>
> >>
> >> It certainly looks better than before. Does it actually work?
> >>
> >> We aready use -fno-PIE, looks like we need to explicitly check for
> >> -fno-pie as well.
> >
> > I just booted OpenBSD from "native OpenBSD" grub2:
> >
>
> Good. Please test attached patch.
>
> @Vladimir: I was unsure whether to add explicit -fpie test, but at the
> end I do not see what it buys us. Both options have been introduced at
> the same time and we want neither enabled. Current test covers both.
>
> Is it OK to commit?
>
___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: [openbsd] 2.02-beta3: build fails - getroot.c:(.text+0x2b): undefined reference to `getrawpartition'

[Vladimir 'phcoder' Serbinenko]

The real problem is .hash section. We need to strip it

Le jeu. 17 mars 2016 16:54, Andrei Borzenkov  a écrit :

> 17.03.2016 13:12, Jiri B пишет:
> > On Mon, Mar 14, 2016 at 09:46:20PM +0300, Andrei Borzenkov wrote:
> > $ tar tzvf
> /home/jirib/openbsd/packages/amd64/all/grub-2.02-beta3.tgz | grep
> lzma_decompress
> > -r-xr-xr-x  1 root bin   3904 Jan  1  1970
> lib/grub/i386-pc/lzma_decompress.image
> > -r--r--r--  1 root bin  134480024 Jan  1  1970
> lib/grub/i386-pc/lzma_decompress.img
>  [...]
>  No. Something went wrong with section addresses/offsets. Please test
>  2.02~beta2 - do you observe the same problem? Please upload
> >>
> >> Did you test beta2?
> >
> > Hi, sorry for delay. Yes I tried beta2, same result.
> >
>  lzma_decompress.image. Where obcopy comes from (obcopy --version)?
> What
>  assembler is used?
> >>>
> >>> $ objcopy -V
> >>> GNU objcopy 2.17
> >>> Copyright 2005 Free Software Foundation, Inc.
> >>> This program is free software; you may redistribute it under the terms
> of
> >>> the GNU General Public License.  This program has absolutely no
> warranty.
> >>> [...]
> >>
> >> I asked lzma_decompress.image, not img. img is too late.
> >
> > I apologize, I missed valid filename. So here as lzma_decompress.image
> from beta3
> > (as beta2 got same huge img file).
> >
> > http://afterboot.cz/pub/lzma_decompress.image
> > SHA256 (lzma_decompress.image) =
> 3968a35c3fc2570cf1a888179433f23a7319d104c8622c71e501f4ba6ca38308
> >
>
> Well, your compiler managed to create shared library instead of
> executable file:
>
> bor@bor-Latitude-E5450:~$ LANG=C objdump -f Загрузки/lzma_decompress.image
>
> Загрузки/lzma_decompress.image: file format elf32-i386
> architecture: i386, flags 0x0050:
> HAS_SYMS, DYNAMIC
> start address 0x8200
>
> I get the same if I explicitly add -shared to linker flags.
>
> Could you test with
>
> ./configure TARGET_LDFLAGS=-static
>
> ___
> Bug-grub mailing list
> Bug-grub@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-grub
>
___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: grub bug

[Vladimir 'phcoder' Serbinenko]

Update your GRUB

Le mer. 2 mars 2016 15:17, Gruenwald, Bernhard 
a écrit :

> /usr/sbin/grub-probe --device-map=/boot/grub/device.map --target=fs -v
> /boot/grub
> /usr/sbin/grub-probe: info: changing current directory to /dev.
> /usr/sbin/grub-probe: info: changing current directory to cpu.
> /usr/sbin/grub-probe: info: changing current directory to shm.
> /usr/sbin/grub-probe: info: opening md/0.
> /usr/sbin/grub-probe: error: no such disk.
>
>
>
> Mit freundlichen Grüßen / Best Regards
>
> Bernhard Grünwald
> Technik
>
> arados GmbH
> Eisenhämmerstr. 36
> 92237 Sulzbach-Rosenberg
>
>
> Telefon:
> Mobil:
> Fax:
> e-mail: +49 9661 17399-13
> +49 172 8290913
> +49 9661 1789994
> bernhard.gruenw...@arados.de
>
>
> http://www.arados.de/
>
> Ust.-ID-Nr.: DE131832904
> HR Amtsgericht Amberg HRB1060
> Geschäftsführer Gerhard Egelseer
>
>
> ___
> Bug-grub mailing list
> Bug-grub@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-grub
>
___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: [bug #27695] parser.sh ignores the closing quote when preceeded by a variable

[Vladimir 'phcoder' Serbinenko]

Andreas Born wrote:
 URL:
   http://savannah.gnu.org/bugs/?27695

  Summary: parser.sh ignores the closing quote when preceeded
 by a variable
   
Attached patch should fix this bug
  Project: GNU GRUB
 Submitted by: shador
 Submitted on: Di 13 Okt 2009 21:11:16 GMT
 Category: Terminal
 Severity: Major
 Priority: 5 - Normal
   Item Group: Software Error
   Status: None
  Privacy: Public
  Assigned to: None
  Originator Name: 
 Originator Email: 
  Open/Closed: Open
  Discussion Lock: Any
  Release: 
  Release: SVN
  Reproducibility: Every Time
  Planned Release: None

 ___

 Details:

 The problem is reproducible with this example:
   
 set blub=blob
 echo $blub
 
 blob
   
 echo ${blub}
 
 blob
   
 echo $blub

 
 = fails, the closing quote is ignored
   
 echo $blub
 
 blob
 = works as workaround

 The real trouble starts with strings containing spaces. But it can be fixed,
 as shown, by adding another quote at the end or using ${...}.

 This was tested with beta~4.




 ___

 Reply to this item at:

   http://savannah.gnu.org/bugs/?27695

 ___
   Nachricht geschickt von/durch Savannah
   http://savannah.gnu.org/



 ___
 Bug-grub mailing list
 Bug-grub@gnu.org
 http://lists.gnu.org/mailman/listinfo/bug-grub

   


-- 
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git 

diff --git a/ChangeLog b/ChangeLog
index b0864a9..db30e9f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,10 @@
 2009-10-15  Vladimir Serbinenko  phco...@gmail.com
 
+	* script/sh/lexer.c (grub_script_yylex): Prevent character from changing
+	state twice.
+
+2009-10-15  Vladimir Serbinenko  phco...@gmail.com
+
 	* loader/i386/pc/xnu.c (grub_xnu_set_video): Fix loading splash image.
 
 2009-10-15  Vladimir Serbinenko  phco...@gmail.com
diff --git a/script/sh/lexer.c b/script/sh/lexer.c
index a30e3c0..0c71dae 100644
--- a/script/sh/lexer.c
+++ b/script/sh/lexer.c
@@ -350,9 +350,11 @@ grub_script_yylex (union YYSTYPE *yylval, struct grub_parser_param *parsestate)
 	  if (! (check_varstate (newstate)))
 		{
 		  if (state-state == GRUB_PARSER_STATE_VARNAME2
-		  || state-state == GRUB_PARSER_STATE_QVARNAME2)
-		nextchar (state);
-		  state-state = newstate;
+		  || state-state == GRUB_PARSER_STATE_QVARNAME2)
+		{
+		  nextchar (state);
+		  state-state = newstate;
+		}
 		  break;
 		}
 
@@ -378,7 +380,6 @@ grub_script_yylex (union YYSTYPE *yylval, struct grub_parser_param *parsestate)
 
 	  buffer[bufpos++] = 0;
 
-	  state-state = newstate;
 	  yylval-arg = grub_script_arg_add (parsestate, yylval-arg,
 	 GRUB_SCRIPT_ARG_TYPE_VAR, buffer);
 	  grub_dprintf (scripting, vartoken=`%s'\n, buffer);
___
Bug-grub mailing list
Bug-grub@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-grub

Re: Can Grub 0.97 load an x86_64 OS image?

[Vladimir 'phcoder' Serbinenko]

Dr. Dov Bulka wrote:
 I downloaded the sources and built a grub executable. The code has
 many references to ELF32 structures and, not surprisingly, I'm unable
 to load an OS image whose format is x86_64.

 The machine is running Linux 2.6.18-8.el5.
 Grub version is 0.97

Grub Legacy is abandonded project. We switched to grub2 now and code in
grub2 is more readable than in legacy
 uname -a tells me that this is an x86_64 architecture.

 Looking at the source code for load_image in stage2/boot.c I find
 code like:

  /* ELF loading supported if multiboot, FreeBSD and NetBSD.  */
   if ((type == KERNEL_TYPE_MULTIBOOT
|| pu.elf-e_ident[EI_OSABI] == ELFOSABI_FREEBSD
|| grub_strcmp (pu.elf-e_ident + EI_BRAND, FreeBSD) == 0
|| suggested_type == KERNEL_TYPE_NETBSD)
len  sizeof (Elf32_Ehdr)
BOOTABLE_I386_ELF ((*((Elf32_Ehdr *) buffer
 {

 Which tells me that this code is meant for i386 (32-bit).

 What have I done wrong?

GRUB Legacy unlike GRUB2 supports only 32-bit *BSD
On i386 linux isn't loaded as ELF but as own image format (compressed
ELF with some startup code and own headers).

 Did I download an old version of Grub not capable of handling x86_64
 (64-bit)? Or...
 Did I configure it wrong? What am I missing?

 Thanks,
 Dov

 http://www.DoveRealEstate.biz

 

 ___
 Bug-grub mailing list
 Bug-grub@gnu.org
 http://lists.gnu.org/mailman/listinfo/bug-grub
   


-- 
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git 



___
Bug-grub mailing list
Bug-grub@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-grub

Re: [bug #27621] Unable to load simple boot manager (SBM) with Grub 2

[Vladimir 'phcoder' Serbinenko]

Michael37 wrote:
 URL:
   http://savannah.gnu.org/bugs/?27621

  Summary: Unable to load simple boot manager (SBM) with Grub
 2
  Project: GNU GRUB
 Submitted by: michael37
 Submitted on: Wed 07 Oct 2009 01:06:23 AM GMT
 Category: Booting
 Severity: Major
 Priority: 5 - Normal
   Item Group: Software Error
   Status: None
  Privacy: Public
  Assigned to: None
  Originator Name: Michael37
 Originator Email: 
  Open/Closed: Open
  Discussion Lock: Any
  Release: 
  Release: SVN
  Reproducibility: Every Time
  Planned Release: None

 ___

 Details:

 SBM is a nice handy tool which allows booting from devices that BIOS doesn't
 properly support, for example, from some USB CD-ROMs or from diagnostics dell
 partition.
   
diagnostic and recovery partitions should be bootable by grub2  as well.
Perhaps you need Robert's ntldr patch
 In Jaunty and earlier releases with Grub 1, using SBM was trivial (inspired
 by http://www.gentoo-wiki.info/GRUB/Chainloaded_CD-ROM, but no downloads
 required). Simply install package syslinux, copy file
 /usr/lib/syslinux/memdisk to /boot; then copy file /install/sbm.bin from any
 Ubuntu install CD to /boot (reference:
 https://help.ubuntu.com/community/SmartBootManager). Finally, set up grub 1
 entry

 title SBM
 root (hd0,1)
 kernel /boot/memdisk
 initrd /boot/sbm.bin

 The same strategy doesn't work for Karmic with grub 2 (version 1.97 beta 3).
 I added the following entry to /boot/grub/grub.cfg using
 /etc/grub.d/40_custom:

 menuentry SBM {
   insmod ext2
   set root=(hd0,1)
   search --no-floppy --fs-uuid --set 1017bb9e-ad12-494f-a580-6f94b015891d
   linux /boot/memdisk 
   initrd /boot/sbm.bin
 }

 When I try to choose this entry in grub2 menu, I get one line of text as if
 kernel is trying to boot, then screen blanks and computer hangs.

 I tried using memdisk and sbm.bin from both Jaunty and Karmic under Karmic
 and neither work.  Looks like grub problem by elimination.



   
memdisk incorrectly claims 32-bit linux boot protocol support. Not our
bug. Use linux16.
 ___

 Reply to this item at:

   http://savannah.gnu.org/bugs/?27621

 ___
   Message sent via/by Savannah
   http://savannah.gnu.org/



 ___
 Bug-grub mailing list
 Bug-grub@gnu.org
 http://lists.gnu.org/mailman/listinfo/bug-grub

   


-- 
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git 




___
Bug-grub mailing list
Bug-grub@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-grub

Re: PIO only CF card boot

[Vladimir 'phcoder' Serbinenko]

Felix Zielcke wrote:
 Am Dienstag, den 06.10.2009, 18:08 -0600 schrieb Christopher Brooks:
   
 Hi,

  

 I’m booting off of a CF card (Kingston 32gig elite pro).  The card
 reader I’m using doesn’t support DMA, and won’t boot off of this card.
 Grub fails in stage 2 with error 25 (disk read error).  I think (not
 sure) grub is trying to use dma mode to load menu.lst in stage 2, and
 the device is timing out.  I would like to build/configure grub such
 that it doesn’t try and load menu.lst using dma mode, but instead just
 defaults to pio mode.

  

 Tips on how to accomplish this?  Does it seem like a reasonable
 explanation for what is happening?
 

 GRUB Legacy isn't anymore supported by us.
 Use GRUB 2.
 But it also relies on the BIOS to read data from it.
 Maybe you have luck and it works with it.
 But maybe your BIOS is broken and that could only be avoided if we would
 write a drvier for your card reader.
 If it's USB you could try 
 insmod uhci (or ohci depends on your USB controller)
 insmod usbms
 ls might show it

   
Compact Flash is likely to be ATA. Try ata.mod


-- 
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git 



___
Bug-grub mailing list
Bug-grub@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-grub

Re: GRUB-1.97~beta3 configure problems on freebsd

[Vladimir 'phcoder' Serbinenko]

Brian R. Jones wrote:
 It appears that grub-mkconfig_lib has an explicit dependence on GNU
 coreutils.  This is ok, but it requires the GNU versions of 'stat' and
 'readlink' come before the native BSD versions in the path.  I would
 argue that this is a bad thing.

 I could not find a ./configure option that would allow we to set a
 specific path for GNU coreutils so that grub-mkconfig_lib could
 explicitly use the GNU versions rather than the native ones.  All I
 can say is that it would be a nice addition.

 Of course the problem can be worked around, but I generally think it's
 a bad idea to put foreign tools ahead of native ones in the path.  To
 much chance of breaking native scripts.


We're aware of the problem but the patch by Felix Zielcke is deemed too
intrusive during pre-release phase.


___
Bug-grub mailing list
Bug-grub@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-grub

Re: how to post fixes/suggestions for GRUB

[Vladimir 'phcoder' Serbinenko]

Brian R. Jones wrote:
 Let me start by saying that I am obviously late to the game and have a
 lot of catching up to do.  I have an urgent need to get GRUB working
 well on FreeBSD.  I have searched the archives and the bugs database
 (and yet managed to not read the INSTALL document at first) and have
 found answers to some of my questions, but not all.

You're always welcome to come to IRC. We welcome testers. But you should
be aware that not always there is someone available for tech support.
Except readlink/stat problem I was able to use freebsd with GRUB
successfully (BIOS,GPT, ZFS).
 I do not want to waste time of the people on this list, so the way I
 figure it I can.

 1) just fix what I need and not bother to tell y'all
IRC (irc.freenode.net) is the best way to discuss something relating to
your configuration unless you hit a bug.
 2) fix what I need and post my changes/issues here

Use grub-de...@gnu.org. All patches should go there.
 3) look into becomeing a GRUB contributor.

Subscribe to grub-de...@gnu.org. Voice your opinion on the matters that
concern you, submit patches there too. You may create a personal
repository to make tester's life easier. When you contribute something
important the maintainer will contact you to sign few papers stating
that you wrote the code yourself, own it and give FSF the power to
protect it. This results in a delay before big patch can be applied but
in most of cases it's resolved quickly.
 At the moment, I would prefer doing 2) if that's ok.





___
Bug-grub mailing list
Bug-grub@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-grub

[Fwd: Re: [bug #27493] ./configure fails to prduce valid makefile on freebsd 7.2 i386]

[Vladimir 'phcoder' Serbinenko]

 Original Message 
Subject:Re: [bug #27493] ./configure fails to prduce valid makefile on
freebsd 7.2 i386
Date:   Tue, 22 Sep 2009 08:12:47 +0200
From:   Vladimir 'phcoder' Serbinenko phco...@gmail.com
To: Brian R Jones invalid.nore...@gnu.org
References: 20090922-002129.sv75361.18...@savannah.gnu.org



Brian R Jones wrote:
 URL:
   http://savannah.gnu.org/bugs/?27493

  Summary: ./configure fails to prduce valid makefile on
 freebsd 7.2 i386
  Project: GNU GRUB
 Submitted by: babel17
 Submitted on: Tue 22 Sep 2009 12:21:29 AM GMT
 Category: Compilation
 Severity: Major
 Priority: 5 - Normal
   Item Group: Software Error
   Status: None
  Privacy: Public
  Assigned to: None
  Originator Name: Brian R Jones
 Originator Email: bjo...@castlejones.net
  Open/Closed: Open
  Discussion Lock: Any
  Release: 
  Release: 1.96
  Reproducibility: Every Time
  Planned Release: None

 ___

 Details:

 [csl011]grub-1.96# uname -a
 FreeBSD csl011 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May  1 08:49:13 UTC
 2009 r...@walker.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
 [csl011]grub-1.96# export LDFLAGS=-L/usr/local/lib; # for liblzo2
 [csl011]grub-1.96# ./configure
 ...
 completes with no errors
 ...
 [csl011]grub-1.96# make
 ./conf/i386-pc.mk, line 30: Need an operator
 ./conf/i386-pc.mk, line 48: Need an operator
 ./conf/i386-pc.mk, line 66: Need an operator
 ./conf/i386-pc.mk, line 84: Need an operator
 ...
 ./conf/common.mk, line 27: Need an operator
 ./conf/common.mk, line 31: Need an operator
 ./conf/common.mk, line 35: Need an operator
 ./conf/common.mk, line 39: Need an operator
 ./conf/common.mk, line 43: Need an operator
 ...
 Makefile, line 130: Missing dependency operator
 Makefile, line 131: Need an operator
 Makefile, line 138: Need an operator
 make: fatal errors encountered -- cannot continue



   
You have to use GNU make. On FreeBSD it's available as gmake



 ___

 File Attachments:


 ---
 Date: Tue 22 Sep 2009 12:21:29 AM GMT  Name: Makefile  Size: 10kB   By:
 babel17

 http://savannah.gnu.org/bugs/download.php?file_id=18751
 ---
 Date: Tue 22 Sep 2009 12:21:29 AM GMT  Name: common.mk  Size: 103kB   By:
 babel17

 http://savannah.gnu.org/bugs/download.php?file_id=18750
 ---
 Date: Tue 22 Sep 2009 12:21:29 AM GMT  Name: config.log  Size: 34kB   By:
 babel17

 http://savannah.gnu.org/bugs/download.php?file_id=18748
 ---
 Date: Tue 22 Sep 2009 12:21:29 AM GMT  Name: i386-pc.mk  Size: 137kB   By:
 babel17

 http://savannah.gnu.org/bugs/download.php?file_id=18749

 ___

 Reply to this item at:

   http://savannah.gnu.org/bugs/?27493

 ___
   Message sent via/by Savannah
   http://savannah.gnu.org/



 ___
 Bug-grub mailing list
 Bug-grub@gnu.org
 http://lists.gnu.org/mailman/listinfo/bug-grub

   





___
Bug-grub mailing list
Bug-grub@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-grub

Re: (no subject)

[Vladimir 'phcoder' Serbinenko]

On Thu, Aug 20, 2009 at 7:58 PM, landon kelseylandonmkel...@hotmail.com wrote:
 First: Here is what lead up to the problem

First of all. Big font is a disrespect and egomania. Supporting users
isn't our priority. We do it only when we're nice. If you want help
gently ask it and hope someone responds it. Or pay someone to respond
it.
Furthermore grub1 isn't supported (but if you pay me I can provide
grub1 support)

-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git


___
Bug-grub mailing list
Bug-grub@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-grub

Re: [bug #27203] Sometimes after reboot grub doesn't response to keyboard

[Vladimir 'phcoder' Serbinenko]

On Fri, Aug 7, 2009 at 7:53 PM, Pauliinvalid.nore...@gnu.org wrote:

 URL:
  http://savannah.gnu.org/bugs/?27203

                 Summary: Sometimes after reboot grub doesn't response to
 keyboard
                 Project: GNU GRUB
            Submitted by: suokkos
            Submitted on: Fri 07 Aug 2009 05:53:40 PM GMT
                Category: User Interface
                Severity: Major
                Priority: 5 - Normal
              Item Group: Software Error
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name:
        Originator Email:
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 1.96
         Reproducibility: Intermittent
         Planned Release:

    ___

 Details:

 Sometimes (25%) after reboot keyboard doesn't respond in grub but when linux
 is loaded keyboard works again.

 Hardware is Acer aspire 1350 laptop.

Looks like bug in bios. Use at_keyboard (add insmod at_keyboard to
your grub.cfg)



    ___

 File Attachments:


 ---
 Date: Fri 07 Aug 2009 05:53:40 PM GMT  Name: lspci  Size: 9kB   By: suokkos

 http://savannah.gnu.org/bugs/download.php?file_id=18538

    ___

 Reply to this item at:

  http://savannah.gnu.org/bugs/?27203

 ___
  Message sent via/by Savannah
  http://savannah.gnu.org/



 ___
 Bug-grub mailing list
 Bug-grub@gnu.org
 http://lists.gnu.org/mailman/listinfo/bug-grub




-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git


___
Bug-grub mailing list
Bug-grub@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-grub

Re: GRUB overwriting partition tables

[Vladimir 'phcoder' Serbinenko]

   Device Boot    Start       End   #sectors  Id  System
 /dev/sda1             1 692272486  692272486  85  Linux extended
 /dev/sda2     692272487 976773167  284500681   7  HPFS/NTFS
 /dev/sda3             0         -          0   0  Empty
 /dev/sda4             0         -          0   0  Empty
 /dev/sda5             2  16777217   16777216  82  Linux swap
 /dev/sda6      16777219  33554434   16777216  83  Linux
 /dev/sda7      33554436  50331651   16777216  83  Linux
 /dev/sda8      50331653  67108868   16777216  83  Linux
 /dev/sda9      67108870 379690677  312581808  83  Linux
 /dev/sda10    379690679 692272486  312581808  83  Linux

In this configuration there is simply no way where to put GRUB2 -
there is no MBR gap. While GRUB shouldn't have destroyed your
partition table this configuration will never be supported. I've
looked into the code and now know where the bug is and thinking about
the way to make grub safely abort in such configuration

--
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git


___
Bug-grub mailing list
Bug-grub@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-grub

Re: [bug #27100] [REGRESSION] multiboot can't load freeldr.sys

[Vladimir 'phcoder' Serbinenko]

On Fri, Jul 24, 2009 at 7:13 PM, Robert Millaninvalid.nore...@gnu.org wrote:

 URL:
  http://savannah.gnu.org/bugs/?27100

                 Summary: [REGRESSION] multiboot can't load freeldr.sys
                 Project: GNU GRUB
            Submitted by: robertmh
            Submitted on: Fri Jul 24 19:13:29 2009
                Category: Booting
                Severity: Major
                Priority: 5 - Normal
              Item Group: Software Error
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name:
        Originator Email:
             Open/Closed: Open
         Discussion Lock: Any
                 Release: trunk
         Reproducibility: Every Time
         Planned Release:

    ___

 Details:

 Starting with r1760 (the commit that introduced payload relocation), the
 multiboot loader fails to load freeldr.sys (a Multiboot-aout bootloader
 included with ReactOS).

 This could be an indication that Multiboot-aout in general is not working, or
 a bug in freeldr.sys (assumption about MBI location).





    ___

 Reply to this item at:

  http://savannah.gnu.org/bugs/?27100

 ___
  Message sent via/by Savannah
  http://savannah.gnu.org/



 ___
 Bug-grub mailing list
 Bug-grub@gnu.org
 http://lists.gnu.org/mailman/listinfo/bug-grub




-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
diff --git a/ChangeLog b/ChangeLog
index 752bde8..bb8aff3 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2009-07-27  Vladimir Serbinenko  phco...@gmail.com
+
+   * loader/i386/multiboot_helper.S (grub_multiboot_backward_relocator):
+   Clear direction flag before jumping to OS.
+   (grub_multiboot2_real_boot): Likewise.
+
 2009-07-25  Felix Zielcke  fziel...@z-51.de
 
* kern/file.c (grub_file_open): Revert to previous check with
diff --git a/loader/i386/multiboot_helper.S b/loader/i386/multiboot_helper.S
index d7539f1..d109458 100644
--- a/loader/i386/multiboot_helper.S
+++ b/loader/i386/multiboot_helper.S
@@ -71,6 +71,7 @@ VARIABLE(grub_multiboot_backward_relocator)
rep
movsb
 
+   cld
jmp *%edx
 VARIABLE(grub_multiboot_backward_relocator_end)
 
@@ -112,4 +113,6 @@ FUNCTION(grub_multiboot2_real_boot)
 /* Move the magic value into eax and jump to the kernel.  */
 movl$MULTIBOOT2_BOOTLOADER_MAGIC,%eax
 popl%ecx
+
+cld
 jmp *%ecx
___
Bug-grub mailing list
Bug-grub@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-grub

Re: [bug #26966] building in separate directory fails

[Vladimir 'phcoder' Serbinenko]

I regularly build grub2 externally with no problem but have to retest
with recent trunk. Check that your build system is correct and recent.
We don't support old or broken build systems

On Mon, Jul 6, 2009 at 12:40 AM, Peterinvalid.nore...@gnu.org wrote:

 URL:
  http://savannah.gnu.org/bugs/?26966

                 Summary: building in separate directory fails
                 Project: GNU GRUB
            Submitted by: peterius
            Submitted on: Sun 05 Jul 2009 10:40:33 PM GMT
                Category: Compilation
                Severity: Major
                Priority: 5 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: peterius
        Originator Email:
             Open/Closed: Open
         Discussion Lock: Any
                 Release: svn
         Reproducibility: None
         Planned Release:

    ___

 Details:

 Several files need -I$(srcdir) in addition to -I$(srcdir)/include in order to
 compile.  Running ./configure from a separate directory keeps things much
 cleaner.




    ___

 Reply to this item at:

  http://savannah.gnu.org/bugs/?26966

 ___
  Message sent via/by Savannah
  http://savannah.gnu.org/



 ___
 Bug-grub mailing list
 Bug-grub@gnu.org
 http://lists.gnu.org/mailman/listinfo/bug-grub




-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git


___
Bug-grub mailing list
Bug-grub@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-grub

Re: GRUB

[Vladimir 'phcoder' Serbinenko]

Losiento para escribir con español muy primitivo y incorecto pero
ahóra estoy en el RMLL y no tiengo mucho tiempo. Esto listo es
exlusivamente para grub2, y no grub-legacy. Si quierreis un suport
viene al irc.freenode.net#grub. Puedo decir qué tu problema es
probablemente qué tu menu.lst no es corecto. La entrada corecto para
tu probablimente configuratión serei
title Windows
root (hd0,3)
makeactive
chainloader +1

ó si teneis windows en el partiticion del FAT:
title Windows
root (hd0,2)
makeactive
chainloader +1

For people not reading Spanish: he just has a bad menu.lst and I
noticed that this channel ist English and grub2-only


2009/7/1 Ricardo Cuestas Martinez rcm.f...@hotmail.com:
 Para empezar, tenía instalados Windows XP y Ubuntu. El GRUB me funcionaba
 perfectamente y podía iniciar con los dos fácilmente. Tuve problemas con
 Windows XP y lo reinstalé. Entonces GRUB se borró y yo lo volvi a instalar
 con el programa Super Disk Grub. Ubuntu me inicia sin problemas, pero
 Windows me da el error:

 Error 13:Invalid or unsupported executable format.
 Press any key to continue...

 En Ubuntu al poner el comando sudo fdisk -l me ponen la siguiente
 distribución:

 Disposit.   Inicio   Comienzo   Fin   Bloques    Id    Sistema
 /dev/sda1    1   698956139111    5Extendida
 /dev/sda2   *    6990 7113   99603082   Linux swap / Solaris
 /dev/sda3 71141306847833537+  b    W95 FAT32
 /dev/sda413069    19457   51319642+  7HPFS/NTFS
 /dev/sda51 36    289107    83   Linux
 /dev/sda6   37   6989    55849941   83   Linux

 ¿Me podría decir cómo arreglar lo del error? Si necesita más información
 dígamelo.
 
 Diferentes formas de estar en contacto con amigos y familiares. Descúbrelas.
 Descúbrelas.
 ___
 Bug-grub mailing list
 Bug-grub@gnu.org
 http://lists.gnu.org/mailman/listinfo/bug-grub





--
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git


___
Bug-grub mailing list
Bug-grub@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-grub

Re: grub wont find files on new partition with linux install

[Vladimir 'phcoder' Serbinenko]

I am using grub v-0.97 to boot multiple os's. computer is set up: hda1-winxp,
hda2-vfat which has grub folder, hda3-ubuntu, hda5-swap, hda6-some linux
distro, hda7-some linux distro, hda8-vfat data, hda9-vfat data, hda10-ext2
/home. I set the partition flag on hda2 active so the bios will read that
partition to boot. I install grub to hda2. recently formated (to make
available) hda6 and hda7. Then installed Slackware to hda6. I modified
menu.lst to ad Slackware but it wont boot (wont find kernel or files on
hda6). When I turn on computer I get my menu.lst, go to grub prompt and type
find /sbin/init and the only results are for hd3 (hd0,2). If I boot to
ubuntu, run grub find /sbin/init the results are for hda3 (ubuntu, hda6
(slackware), and hda7 (os before I formated hda7). The grub folder that is
on hda2 is copied from ubuntu after which I run grub root (hd0,1) then
grub setup (hd0,1). It completes successfully. I have done the install to
hda2 with setup from ubuntu and the grub prompt at the boot screen. Since
grub from ubuntu can see hda6 and hda7 I dont think problem is fault of
BIOS. What do I do to fix this?
Your new install probably uses extents (ext4). It's not supported by
grub-legacy and we don't recieve feature requests for it anymore. Use
grub2

-- 
Regards
Vladimir 'phcoder' Serbinenko


___
Bug-grub mailing list
Bug-grub@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-grub