Re: Fixing My First Bug

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

Re: Fixing My First Bug

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

Re: [bug #65880] heap-buffer-overflow in grub-mkrescue.c

Hi, Vladimir Serbinenko wrote: > Thomas, savannah just butchers the patch. Looking in my mailbox ... that line break before "argument" is not by me. > Can you send it to ML? I have it ready for grub-devel (git format-patch) and plan to post it by "git send-email" this evening unless Victoriia

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

Thank you, I shall ask the os-prober maintainers instead, it sounds like regular mount (or something else) would be better to use for that purpose after perhaps testing it's available, I'd guess grub-mount might have been designed to use in the minimal early boot environment with the limited

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

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

Re: Cant chainload UKI Image with enabled Secureboot

> I can boot the UKI EFI File without Secureboot directly from USB Drive or the > ESP, so the UKI is fine. > With Secureboot enabled i can Boot the UKI from USB or ESP and no Problem > arises. > > UKI is also totally fine, this is a GRUB Bug. > How to debug this > > -- Sent with Tuta; enjoy

Re: [bug #64297] snapshotting a zfs-based boot pool renders it unreadable by grub

Dear Sir or Madam, I am receiving messages regarding this bug, but have no idea why. Any idea how to get off the list of recipients? (The "savannah" links do not help because you need to know your login name, which I don't remember. The e-mail address raises an "Invalid User" error.) Kind

Re: Grub XFS normal.mod not found error

Hello, Jon DeVree upstream posted a new patch which may fix your issue. Maybe you can give it a try? [PATCH] Fix XFS directory extent parsing

Re: Grub XFS normal.mod not found error

Vacation time, sorry for late reply... Adding Lidong... On Fri, Jul 28, 2023 at 09:27:33AM +, Steve wrote: > Hello, > > Last reply from you guys was on the 13th, and we have yet to see issue > addressed. I, as a Distro maintainer, had to create a new repo where I held > grub back to r499 as

Re: [bug #55093] Add LUKS2 support

Agreed. Especially given the fact that many out there embed keys in their initramfs, this effectively nullifies the security benefits of a LUKS2 setup. On Wed, Aug 2, 2023, 08:42 dllud wrote: > Follow-up Comment #14, bug #55093 (project grub): > > Unfortunately I (as original submitter) am

Re: Grub XFS normal.mod not found error

Hi, I will take a look at the issue. Lidong > On Jul 13, 2023, at 11:03 AM, Daniel Kiper wrote: > > Hi, > > Adding Lidong and Marta... > > Steve, thank you for the report. > > On Wed, Jul 12, 2023 at 03:05:34PM +0300, TechXero wrote: >> Hello >> >> Sorry for posting this again there was a

Re: Grub XFS normal.mod not found error

Hi, Adding Lidong and Marta... Steve, thank you for the report. On Wed, Jul 12, 2023 at 03:05:34PM +0300, TechXero wrote: > Hello > > Sorry for posting this again there was a formatting issue (Whitext/White bg) > > I found a strange issue with XFS filesystem when used for `/boot`. Out of Could

Re: Error in text

OK gracias. El vie, 9 dic 2022 a las 3:43, Vladimir 'phcoder' Serbinenko (< phco...@gmail.com>) escribió: > 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

Re: Error in text

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

Re: Error in text

Hello! You said (via Google Translate "Hello. I saw these errors while I was studying, they are not programming errors, but writing errors or lack of translation in some text that describe the use and syntax of the command. I use settings in Spanish. It is so because I installed Ubuntu and chose

Re: Error in text

Hola. Vi estos errores mientras estudio, no son errores de programación más bien de escritura o falta de traducción en algún texto que describen el uso y sintaxis del comando. Utilizo configuración en español. Es así porque instalé Ubuntu y elegí la opción en español. Saludos. GNU GRUB version

Re: Error in text

The observation corresponds to GNU GRUB 2.06 El mar, 6 dic 2022 a las 11:35, ric ric () escribió: > 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

Re: Testsuite summary for GRUB 2.04-20

J did some changes in grub2-2,04/obj/grub-pc/grub-fs-tester now j got only 2 tests failed. Il 17/05/22 16:49, salvatore cardinale ha scritto: j did apt-src -k -n -t -b grub2 on Debian 11.2 (stable) j got E: Building failed j report to you. Thanks grub-fs-tester.diff.gz Description:

Re: Grub 2.06 Fails To Run Themes At Native Resolution

Hello, I have resolved this issue, and wanted to reply, in case anyone else runs into this. I just had to simple uncomment the font line; GRUB_FONT=/usr/share/grub/dejavusansmono.pf2 It works great now! --- Original Message --- On Wednesday, March 16th, 2022 at 12:44 AM, royal.post

Re: Major Bug in Grub

On 30/01/2022 13:16, Anatoly Pugachev wrote: On Sun, Jan 30, 2022 at 3:52 PM Abby Love wrote: Hi there, that was fat! PS: have you ever created any piece of "software", that is the same way (or even more) popular as a grub? Have you visited your doctor and express your filings about grub

Re: Major Bug in Grub

This is the last line of my original email: > An uneducated hobbyist who was just trying to compute for fun before getting sucked into the nightmare vortex of grub, and this is the most relevant part of your response: > have you ever created any piece of "software", that is the same way (or

Re: Major Bug in Grub

On Sun, Jan 30, 2022 at 3:52 PM Abby Love wrote: > > Hi there, that was fat! PS: have you ever created any piece of "software", that is the same way (or even more) popular as a grub? Have you visited your doctor and express your filings about grub with him?

Re: Can't list Windows 11

Hello! You'll need to provide us with more information. Part of the problem is that when NT was created, they started claiming the boot blocks. And since we are largely using EFI as a boot method things get even more complicated. As I said, we need more information to help you. - Gregg C

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

On Sun, May 23, 2021 at 03:45:42PM +0200, Vladimir 'phcoder' Serbinenko wrote: > LGTM. Also you can skip dprintf. It's not very useful. > > Le dim. 23 mai 2021 à 02:56, Tomasz Kramkowski a écrit : Just to clarify then, you're suggesting I remove the grub_error entirely without replacing it for

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

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

Re: i386/biosdisk - int 13h/service 48h response buffer issue?

Hi GRUB community, do we have any news about this one? Appreciate any advice. Cheers, Guilherme

Re: Regression: uefi tftp+http network boot broken in master (bisected)

On 2021-03-05 21:28, Thomas Frauendorfer wrote: On Wed, Mar 3, 2021 at 10:29 PM asavah wrote: printf changes in grub git seem to have broken uefi network boot. last good commit 968de8c23c1cba0f18230f778ebcf6c412ec8ec5 first bad commit 83603bea6ce8fdff5ab3fbc4c9e592a8c71a8706 I did not test

Re: Regression: uefi tftp+http network boot broken in master (bisected)

On Wed, Mar 3, 2021 at 10:29 PM asavah wrote: > > printf changes in grub git seem to have broken uefi network boot. > > last good commit 968de8c23c1cba0f18230f778ebcf6c412ec8ec5 > first bad commit 83603bea6ce8fdff5ab3fbc4c9e592a8c71a8706 > > I did not test commits in between as they seem to be

Re: grub-mkconfig doesn't change /boot/grub/grub.cfg

Anatoly, Thanks for reply. I miss-stated the issue. It should NOT to change kernel config CONFIG_PSI_DEFAULT_DISABLED. It is to enable PSI by customizing grub-reboot following the steps in https://nanxiao.me/en/enable-pressure-stall-information-psi-on-void-linux/ It did not work! PSI

Re: grub-mkconfig doesn't change /boot/grub/grub.cfg

On Thu, Jan 28, 2021 at 1:22 PM Xu, Bo wrote: > > Hi, > > I am trying to enable PSI by changing the kernel config: > > CONFIG_PSI_DEFAULT_DISABLED=y > > to CONFIG_PSI_DEFAULT_DISABLED=n > > > > Here are the steps I did: > > Added line GRUB_CMDLINE_LINUX_DEFAULT="psi=1” in file

Re: grub-mkstandalone Error

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

Re: GRUB build failure

On Wed, 19 Aug 2020 10:30:34 + Naveen Chaudhary wrote: > Hi, > > I figured out that I should add "--disable-werror" to the configure. > > After this I was able to build successfully. Hmm, interesting. I also compile on ubuntu (upgrade to 20.04) with no added CFLAGS and do not have this

Re: GRUB build failure

Hi, I figured out that I should add "--disable-werror" to the configure. After this I was able to build successfully. Thanks, Naveen From: Naveen Chaudhary Sent: Wednesday, August 19, 2020 3:54 PM To: bug-grub@gnu.org ; grub-de...@gnu.org Subject: GRUB build

Re: bug#41982: [PATCH v2] grub-core: Build fixes for i386

Ludovic Courtès writes: Hi! > Jan Nieuwenhuizen skribis: > >> Jan Nieuwenhuizen writes: >> >> lib/i386/relocator64.S:97: Error: bad register name `%rsp' >> >> The attached v2 fixes that. > > On the Guix side I guess you can go ahead and apply it. > > Well done! Thanks! Ah, I already done

Re: bug#41982: [PATCH v2] grub-core: Build fixes for i386

Hi! Jan Nieuwenhuizen skribis: > Jan Nieuwenhuizen writes: > > Hello! > >> When cross-compiling Grub-2.04 from i386-linux-gnu to i586-pc-hurd on >> GNU Guix, I got this error > > Today, we found* that my patch introduced a regression: a native, EFI > build on i686-linux-gnu failed with > >

Re: bug in grub2-install

Thank you so much! -- Best Regards, Audun Gangsto On Tue, 7 Jul 2020 at 16:51, Vladimir 'phcoder' Serbinenko wrote: > > /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

Re: bug in grub2-install

/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

Re: UEFI and BROKEN Parameter Issue : Ref. Fedora-31

On Mon, Jun 15, 2020 at 05:52:29PM +0530, Bimal Kumar wrote: > Dear Madam / Sir, Sorry, but cond...@kernel.org is not the correct address for kernel support questions, especially ones about a specific Linux distribution. Please contact that distribution for help. good luck! greg k-h

Re: Cannot install grub

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

Re: Hi There

And to say, I could get started on the task, and I would ask support in finding "FREE" blank slate mobile device hardware, as I simply do not know how to find what has which binaries in it, and I am a bit stronger on the feature side, I would say. My proposition is in parallel: to the GRUB

Re: got a little further

Hi! 03.03.2020 6:28, Aneesa Parker пишет: > hello > > I did the following but still stuck > > set prefix=(hd0,msdos5)/boot/grub > set root=hd0,msdos5 > insmod normal > this gave "error file '/boot/grub/i386-pc/normal.mod' not found > You probably have BIOS-style  stage bootloader as it seeks at

Re: request

Thank you. My friend knows nothing about computers. He will be very upset. I have Ubuntu 18.04LTS on a USB. Please can you tell me the command to boot from the USB from grub-repair ? I will deeply appreciate that. On Monday, 2 March 2020, 11:41:03 am AEDT, Carl Karsten wrote:

Re: request

Hello Aneesa, first, relax. It is likely an easy fix, and if not it is likely easy to reinstall everything from the ground up, and likely your friend that lent you their laptop won't mind any of this. I would start by asking your friend for help. it may be embarrassing, but I assure you I

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

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 &qu

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

, 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&q

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

    Gesendet: Donnerstag, 18. Juli 2019 um 18:19 Uhr Von: "Vladimir 'phcoder' Serbinenko" An: "Peter Littmann" Cc: bug-grub@gnu.org Betreff: Re: Re: grub does not detect partition 5 on new USB-WD My Passport 1TB On Thu, Jul 18, 2019 at 6:17 PM Peter Littmann wrote:

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

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 pa

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

oot 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

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: > > Hey, > > I have a old BIOS (build date 04/01/2010) and connected a new

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

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 >

Re: 100% CPU usage while waiting for LUKS password

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

Re: 100% CPU usage while waiting for LUKS password

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

Re: [RFC 1/1] mkimage: revert "Align efi sections on 4k boundary"

On Fri, Apr 19, 2019 at 09:11:50PM +0200, Jesús Diéguez Fernández wrote: > El 19/4/19 a las 17:32, Julien ROBIN escribió: > > Thanks Heinrich, so I tested with your approach and u-boot.bin. > > > > [...] > > > > > > > /PS : may be making a summary of all architectures/configurations tests > >

Re: [PATCH] grub-mkrescue: Allow users to specify a FAT serial number

Hello, "Vladimir 'phcoder' Serbinenko" skribis: > We already have code for iso9660 datetime that we use as UUID. Why not > derive FAT ID from it as well? E.g. by using truncated SHA-2 of iso9660 > datetime? In practice that’s what I did on the Guix side:

Re: [RFC 1/1] mkimage: revert "Align efi sections on 4k boundary"

El 19/4/19 a las 17:32, Julien ROBIN escribió: > Thanks Heinrich, so I tested with your approach and u-boot.bin. > [...] > > > /PS : may be making a summary of all architectures/configurations tests > tutorials would be useful ? Even if it's just QEMU (it would even be a > lot of work), and

Re: [RFC 1/1] mkimage: revert "Align efi sections on 4k boundary"

Thanks Heinrich, so I tested with your approach and u-boot.bin. The reason why I had no version of arm-efi grub working was because I had to add _/--with-platform=efi/_ while playing "./configure [...]" On arm64-efi it's fine to forgot it but not in arm-efi builds. Now I can confirm the same

Re: [RFC 1/1] mkimage: revert "Align efi sections on 4k boundary"

On Thu, Apr 18, 2019 at 05:14:58PM +0200, Heinrich Schuchardt wrote: > On 4/18/19 12:41 PM, Daniel Kiper wrote: > > On Wed, Apr 17, 2019 at 07:50:09AM +0200, Heinrich Schuchardt wrote: > > > Since this commit a51f953f4ee8 ("mkimage: Align efi sections on 4k > > > boundary") grubarm.efi crashes.

Re: [RFC 1/1] mkimage: revert "Align efi sections on 4k boundary"

On 4/19/19 12:02 AM, Julien ROBIN wrote: Hi, I don't know if others folks are easily able to test and reproduce the issue and test suggested patch, so I did some builds, and tests based on the EFI file produced by grub-mkstandalone using -O arm-efi : it's a trivial way to test what code version

Re: [RFC 1/1] mkimage: revert "Align efi sections on 4k boundary"

Hi, I don't know if others folks are easily able to test and reproduce the issue and test suggested patch, so I did some builds, and tests based on the EFI file produced by grub-mkstandalone using -O arm-efi : it's a trivial way to test what code version is working or not with qemu-system-arm

Re: [RFC 1/1] mkimage: revert "Align efi sections on 4k boundary"

On 4/18/19 12:41 PM, Daniel Kiper wrote: On Wed, Apr 17, 2019 at 07:50:09AM +0200, Heinrich Schuchardt wrote: Since this commit a51f953f4ee8 ("mkimage: Align efi sections on 4k boundary") grubarm.efi crashes. Let's revert it. Everywhere or on a specific machines? I observed the issue on a

Re: [PATCH 1/1] efi: avoid NULL dereference if FilePath is NULL

On Wed, Apr 17, 2019 at 07:12:56AM +0200, Heinrich Schuchardt wrote: > The UEFI specification allows LoadImage() to be called with a memory > location only and without a device path. In this case FilePath will not be > set in the EFI_LOADED_IMAGE_PROTOCOL. > > So in function

Re: [RFC 1/1] mkimage: revert "Align efi sections on 4k boundary"

On Wed, Apr 17, 2019 at 07:50:09AM +0200, Heinrich Schuchardt wrote: > Since this commit a51f953f4ee8 ("mkimage: Align efi sections on 4k > boundary") grubarm.efi crashes. Let's revert it. Everywhere or on a specific machines? Daniel ___ Bug-grub

Re: [RFC 1/1] mkimage: revert "Align efi sections on 4k boundary"

On Wed, Apr 17, 2019 at 07:50:09AM +0200, Heinrich Schuchardt wrote: > Since this commit a51f953f4ee8 ("mkimage: Align efi sections on 4k > boundary") grubarm.efi crashes. Let's revert it. > > a51f953f4ee8 ("mkimage: Align efi sections on 4k boundary") > Signed-off-by: Heinrich Schuchardt > ---

Re: [PATCH 1/1] efi: avoid NULL dereference if FilePath is NULL

On Tue, Apr 16, 2019 at 08:01:10PM +0200, Heinrich Schuchardt wrote: > The UEFI specification allows LoadImage() to be called with a memory > location only and without a device path. In this case FilePath will not be > set in the EFI_LOADED_IMAGE_PROTOCOL. > > So in function

Re: grub make error

On Wed, Mar 20, 2019 at 01:19:30AM +, Chen, Farrah wrote: > Thank you for great help! You are welcome! Patch has been pushed. Daniel ___ Bug-grub mailing list Bug-grub@gnu.org https://lists.gnu.org/mailman/listinfo/bug-grub

RE: grub make error

Thank you for great help! Thanks, Fan -Original Message- From: Daniel Kiper [mailto:daniel.ki...@oracle.com] Sent: Tuesday, March 19, 2019 5:56 PM To: Colin Watson Cc: Chen, Farrah ; bug-grub@gnu.org; Hao, Xudong Subject: Re: grub make error On Tue, Mar 19, 2019 at 09:51:20AM

Re: grub make error

On Tue, Mar 19, 2019 at 09:51:20AM +, Colin Watson wrote: > On Tue, Mar 19, 2019 at 01:21:02AM +, Chen, Farrah wrote: > >Thank you for your advice, but I think my environment has met the minimal > >build requirements. > >And I tried again, there’s no issue with commit: > >

Re: grub make error

On Tue, Mar 19, 2019 at 01:21:02AM +, Chen, Farrah wrote: > Hi, > > Thank you for your advice, but I think my environment has met the minimal > build requirements. > And I tried again, there's no issue with commit: > f8f35acb5b05d40e3707a9d2db9ede60023e4cac, this error just happened from >

RE: grub make error

: Daniel Kiper [mailto:daniel.ki...@oracle.com] Sent: Tuesday, March 19, 2019 5:22 AM To: Chen, Farrah Cc: Colin Watson ; bug-grub@gnu.org; Hao, Xudong Subject: Re: grub make error On Mon, Mar 18, 2019 at 02:53:10PM +, Chen, Farrah wrote: > Sorry, I attached wrong log just now, if you recei

Re: grub make error

On Mon, Mar 18, 2019 at 02:53:10PM +, Chen, Farrah wrote: > Sorry, I attached wrong log just now, if you received the email, please > ignore. > > Yes, I am using git://git.savannah.gnu.org/grub. > I attached all the log, can you help to check? It's strange, before this > commit, I never met

Re: grub make error

On Mon, Mar 18, 2019 at 09:29:13AM +, Colin Watson wrote: > On Mon, Mar 18, 2019 at 01:45:23AM +, Chen, Farrah wrote: > >Then the following error occurred: > > > >.. > > > >In file included from ../grub-core/lib/gnulib/libc-config.h:150:0, > > > >from

Re: grub make error

On Mon, Mar 18, 2019 at 01:45:23AM +, Chen, Farrah wrote: >Then the following error occurred: > >.. > >In file included from ../grub-core/lib/gnulib/libc-config.h:150:0, > >from lib/gnulib/regex.c:21: > >lib/gnulib/regexec.c: In function ‘re_search_2_stub’: > >

Re: Make grub error "too few arguments" with xen

On Tue, Dec 04, 2018 at 05:49:24AM +, Chen, Farrah wrote: > Hi all, > > When I make grub, I met error " too few arguments to function > 'grub_create_loader_cmdline'" with xen. > I used git bisect and found the error occurred from commit: > 4d4a8c96e3593d76fe7b025665ccdecc70a53c1f. > Do you

RE: Make grub error "too few arguments" with xen

Hi all, I used git bisect and found the following error occurred from commit: 4d4a8c96e3593d76fe7b025665ccdecc70a53c1f. Such error in loader/arm64/xen_boot.c has been fixed, bur the error in loader/i386/xen.c hasn't been fixed, do you have any idea? Thanks a lot! ... loader/i386/xen.c: In

Re: Fix incorrect subnet mask for ppc64

On 2018-03-14 15:05, diegodo wrote: On 2018-03-13 12:09, diegodo 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

Re: Fix incorrect subnet mask for ppc64

On 2018-03-13 12:09, diegodo 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().

Re: [PATCH] arm64: fix build regression in of_path_of_nvme

On Tue, Feb 27, 2018 at 09:19:23AM -0700, Eric Snowberg wrote: > > On Feb 27, 2018, at 5:06 AM, Daniel Kiper wrote: > > On Mon, Feb 26, 2018 at 10:59:24AM +0100, Joakim Bech wrote: > >> On Mon, Feb 26, 2018 at 10:45:46AM +0100, Daniel Kiper wrote: > >>> On Mon, Feb 26,

Re: [PATCH] arm64: fix build regression in of_path_of_nvme

> On Feb 27, 2018, at 5:06 AM, Daniel Kiper wrote: > > On Mon, Feb 26, 2018 at 10:59:24AM +0100, Joakim Bech wrote: >> On Mon, Feb 26, 2018 at 10:45:46AM +0100, Daniel Kiper wrote: >>> On Mon, Feb 26, 2018 at 09:57:34AM +0100, Joakim Bech wrote: The of_path_of_nvme

Re: [PATCH] arm64: fix build regression in of_path_of_nvme

On Mon, Feb 26, 2018 at 10:59:24AM +0100, Joakim Bech wrote: > On Mon, Feb 26, 2018 at 10:45:46AM +0100, Daniel Kiper wrote: > > On Mon, Feb 26, 2018 at 09:57:34AM +0100, Joakim Bech wrote: > > > The of_path_of_nvme function introduced a build regression: > > >

Re: [PATCH] arm64: fix build regression in of_path_of_nvme

On Mon, Feb 26, 2018 at 10:45:46AM +0100, Daniel Kiper wrote: > On Mon, Feb 26, 2018 at 09:57:34AM +0100, Joakim Bech wrote: > > The of_path_of_nvme function introduced a build regression: > > grub-core/osdep/linux/ofpath.c:365:21: error: comparison between pointer > > and zero character

Re: [PATCH] arm64: fix build regression in of_path_of_nvme

On Mon, Feb 26, 2018 at 09:57:34AM +0100, Joakim Bech wrote: > The of_path_of_nvme function introduced a build regression: > grub-core/osdep/linux/ofpath.c:365:21: error: comparison between pointer > and zero character constant [-Werror=pointer-compare] >if ((digit_string != '\0')

Re: HP ProBook x360 11 G1 EE incompatible with grub

Hi, Le 15/12/2017 à 12:43, Thomas Schmitt a écrit : > I am out of guesses. Everything points to something being missing or going > wrong in GRUB. > (I think the theory of intentionally blocking GRUB is fewly plausible > given the experiment results with SYSLINUX.) I just made one test that

Re: HP ProBook x360 11 G1 EE incompatible with grub

Hi, Michel Bouissou wrote: > Well, Knoppix *DOES BOOT OK* on said machine, > [...] no error message is displayed, and in the end, it runs. So the presence of ISO 9660 on the same medium is not the problem. I am out of guesses. Everything points to something being missing or going wrong in GRUB.

Re: HP ProBook x360 11 G1 EE incompatible with grub

Hi again, Le 11/12/2017 à 23:20, Thomas Schmitt a écrit : > - Try Knoppix 8.1 dd'ed flatly onto stick. It is an ISO 9660 but brings > SYSLINUX EFI boot stuff which is reported to work from USB stick (but > not from DVD): >

Re: Re.: HP ProBook x360 11 G1 EE incompatible with grub

Le 11/12/2017 à 20:10, fernandogai...@pcclinic.pt a écrit : > In my experience fedora, opensuse and mageia secure boot > implementation are more compatible. Can you try with of those? You can > use efi folder from OSS repository of opensuse. I haven't personally tried, but another student's

Re: HP ProBook x360 11 G1 EE incompatible with grub

Hi, Michel Bouissou wrote: > The process was to boot on the original key (or CDROM) that would be a > "temporary" Tails ISO dd'ed, and from there use the “tails installation > program" to create a second key, > [...] > # file -s /dev/sdb > /dev/sdb: DOS/MBR boot sector; partition 1 : ID=0xee,

Re: HP ProBook x360 11 G1 EE incompatible with grub

Hi Thomas, Le 11/12/2017 à 21:30, Thomas Schmitt a écrit : >> *** Keys booting OK out of the box : >> - Tails : tails-amd64-3.2.iso (created by Tails USB installer from >> another same version Tails key) >> - tails-amd64-3.3.iso : Made by an auto-upgrade of the previous one > How are they

Re: HP ProBook x360 11 G1 EE incompatible with grub

Hi, Michel Bouissou wrote: > I'm not in a situation of testing new USB keys right now, If this ever changes, then i advise to test a grub-mkrescue made ISO. I assume that it has the best chances to get the attention of GRUB developers. > *** Keys booting OK out of the box : > - Tails :

Re: HP ProBook x360 11 G1 EE incompatible with grub

Hi again, Le 11/12/2017 à 19:43, Thomas Schmitt a écrit : > To give tangible examples, these don't work after being dd'ed onto > an USB stick device (not a partition) ? When it comes to dd, I'm always talking about dd'ing to a full USB stick, not a partition. I'm not in a situation of testing

Re: Re.: HP ProBook x360 11 G1 EE incompatible with grub

Hi, Le 11/12/2017 à 20:10, fernandogai...@pcclinic.pt a écrit : > In my experience fedora, opensuse and mageia secure boot implementation > are more compatible. Can you try with of those? You can use efi folder > from OSS repository of opensuse. Well, the issue is definitely *not* with secure

Re.: HP ProBook x360 11 G1 EE incompatible with grub

In my experience fedora, opensuse and mageia secure boot implementation are more compatible. Can you try with of those? You can use efi folder from OSS repository of opensuse. Enviado do meu telefone Huawei. Mensagem original Assunto: Re: HP ProBook x360 11 G1 EE incompatible

Re: HP ProBook x360 11 G1 EE incompatible with grub

Hi, Michel Bouissou wrote: > After having disabled Secure boot, I have discovered that none of the > usual (curent, latest versions as of 2017/12) Linux live USB sticks > (among : Ubuntu, Mint, Debian, Manjaro, PartedMagic) was able to boot on > this machine. I assume the boot success depends

Re: Fix incorrect mask for ppc64

Hello, I agree with just removing le_to_cpu32. I wrote the patch one year ago, and I don't remember the intent. But maybe, I had some wrong assumption at that time. For now, I think it looks better to remove le_to_cpu32 without swap_bytes for both LE and BE environment. Thanks, Masahiro Matsuya

Re: Fix incorrect mask for ppc64

Sending the thread to the author (sorry, I missed his email). On 2017-12-05 11:26, Vladimir 'phcoder' Serbinenko wrote: 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

Re: Fix incorrect mask for ppc64

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

Re: Incorrect values in APM cseg_len and cseg_16_len fields

Hello! It seems this bug nobody care. If I had write access to grub repo I would fix it by myself. 25.11.2017, 22:44, "Владимир Андреев" : > Hello! > > GRUB provides ability to pass APM BIOS data to payload as well as to show it > to user via "lsapm" command. > Pointed

Re: grub2 is http protocol known to be slow?

Hi, guys. Is this mailing list a right place for such questions or should I ask somewhere else? -- Peter. On Sun, Sep 10, 2017 at 11:29 AM, Peter Volkov wrote: > Hi! We've tried to use network boot loading kernel and initramfs with http > but we found this to be

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

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 \ >

Re: Build fails with flex 2.6.4 and -Werror

Andrei Borzenkov [2017-06-04 20:47+0300]: > flex bug fixed in flex git. > > https://github.com/westes/flex/issues/162 I don’t think this is the same problem. Using the latest master for both GRUB and flex I get this error (but not with flex 2.6.3): grub_script.yy.c: In

Re: Build fails with flex 2.6.4 and -Werror

04.06.2017 20:05, Timotej Lazar пишет: > Hi, > > Building GRUB using the default configuration (-Werror -Wunused-value) > fails with flex >2.6.3. > flex bug fixed in flex git. https://github.com/westes/flex/issues/162 > The problem is with the script lexer, which defines fprintf to 0. The >

  1   2   3   4   5   6   7   8   9   10   >