IDE Project
Hello, I want to know what a IDE do you all use? I just have download the grub 2 project. Can you advise me how to setting up eclipse to import as a project, how can I debug it? Kindly regards Michael ___ Help-grub mailing list Help-grub@gnu.org https://lists.gnu.org/mailman/listinfo/help-grub
Re: gpg verification issue over tftp
No problem. The patch should be uploaded now. On Nov 17, 2014 1:24 PM, "Andrei Borzenkov" wrote: > В Mon, 17 Nov 2014 12:29:43 -0600 > Robert Kliewer пишет: > > > I don't have a local disk setup to test, but a memdisk test works without > > issue (using code from git master on 11/11). I was able to add some > debug > > logging to isolate the issue to grub_file_close. I attached a screenshot > > and some more info to the bug report (43601). It seems like the gpg > close > > and tftp close may be stepping on each other, but not really knowing the > > code I'm just taking a guess. Removing the grub_device_close call from > > grub_file_close fixes my issue, but I know it's not the right answer. > Hope > > this helps. > > Could you attach your patches with debug output (git diff would be > fine) to the bug report; it makes it easier to follow? > > > On Nov 15, 2014 10:40 AM, "Andrei Borzenkov" > wrote: > > > > > В Tue, 11 Nov 2014 14:06:14 -0600 > > > Robert Kliewer пишет: > > > > > > > I'm seeing an issue in rhel 7 grub 2.02 based on grub 2.02~beta2 > (none of > > > > the rhel patches appear to touch gpg, so it's almost certainly in the > > > main > > > > line as well). If I'm using a gpg public key with check_signatures > > > > enabled, all file operations over tftp break grub (efi x86_64 image > > > running > > > > on vmware 10). For example if I cat a signed grubenv file, the file > > > > displays in its entirety but it is followed with: > > > > > > > > alloc magic is broken at : > > > > Aborted. Press any key to exit. > > > > > > > > > > This sounds like memory corruption. It does not need to have anything > > > to do with gpg, could as well be a tftp/network problem. Useful tests > > > were > > > > > > - test same operation from local disk (to exclude network) > > > - test current upstream master whether problem still exists there > > > > > > > Pressing a key takes me back to the EFI firmware. I can work around > the > > > > issue by disabling check_signatures and manually running > verify_detached > > > on > > > > the file but that leaves me pulling my kernel and initrd twice, once > to > > > > check the signature and once to load. Just wondering if I'm > configured > > > in > > > > a bad way that would cause this behaviour. Also, this does not > appear to > > > > be an issue with signed files in the memdisk (probably not the hdd > > > either, > > > > but I'm only booting over the network). Any help is appreciated. > > > Thanks. > > > > > > > > Rob > > > > > > > > ___ Help-grub mailing list Help-grub@gnu.org https://lists.gnu.org/mailman/listinfo/help-grub
Re: Grub2 plain dm-crypt support
>> > Sorry meant to answer earlier. Yes, apparently it was work in progress > that probably never compiled. Somebody would need to clean it up. If > you manage it, send a patch so branch can be updated. I now have a version that builds. There were very few changes necessary. I can supply a patch. However... I can load the module successfully and use its "devmap" command but it doesn't work for me. I am not sure how much of the solution is in place and I don't know enough about how it should work to be able to progress it without help. I don't think it correctly sets up the cipher. The default value "aes-cbc" doesn't work. I have compared with the luks code and I believe that the cipher needs to be just the cipher name (e.g. "aes") and I have verified that I don't get an error if I explicitly supply this with "devmap -c aes...". What it doesn't do is set up the cipher mode in the way that the luks code does - there needs to be a way to pass it the mode and have it set that up (e.g. "xts-plain64"). Unless anyone can help who is more knowledgeable about this I am going to have to leave it and accept that it doesn't work. But, if there is someone else (perhaps the person who wrote the devmapper.c as it is now) then I am more than happy to help test it. > You realize that hd1 is not guaranteed to always remain hd1 after > reboot? Yes. but in a simple scenario where there is only one device I don't think it'll be an issue. ___ Help-grub mailing list Help-grub@gnu.org https://lists.gnu.org/mailman/listinfo/help-grub
Re: gpg verification issue over tftp
В Mon, 17 Nov 2014 12:29:43 -0600 Robert Kliewer пишет: > I don't have a local disk setup to test, but a memdisk test works without > issue (using code from git master on 11/11). I was able to add some debug > logging to isolate the issue to grub_file_close. I attached a screenshot > and some more info to the bug report (43601). It seems like the gpg close > and tftp close may be stepping on each other, but not really knowing the > code I'm just taking a guess. Removing the grub_device_close call from > grub_file_close fixes my issue, but I know it's not the right answer. Hope > this helps. Could you attach your patches with debug output (git diff would be fine) to the bug report; it makes it easier to follow? > On Nov 15, 2014 10:40 AM, "Andrei Borzenkov" wrote: > > > В Tue, 11 Nov 2014 14:06:14 -0600 > > Robert Kliewer пишет: > > > > > I'm seeing an issue in rhel 7 grub 2.02 based on grub 2.02~beta2 (none of > > > the rhel patches appear to touch gpg, so it's almost certainly in the > > main > > > line as well). If I'm using a gpg public key with check_signatures > > > enabled, all file operations over tftp break grub (efi x86_64 image > > running > > > on vmware 10). For example if I cat a signed grubenv file, the file > > > displays in its entirety but it is followed with: > > > > > > alloc magic is broken at : > > > Aborted. Press any key to exit. > > > > > > > This sounds like memory corruption. It does not need to have anything > > to do with gpg, could as well be a tftp/network problem. Useful tests > > were > > > > - test same operation from local disk (to exclude network) > > - test current upstream master whether problem still exists there > > > > > Pressing a key takes me back to the EFI firmware. I can work around the > > > issue by disabling check_signatures and manually running verify_detached > > on > > > the file but that leaves me pulling my kernel and initrd twice, once to > > > check the signature and once to load. Just wondering if I'm configured > > in > > > a bad way that would cause this behaviour. Also, this does not appear to > > > be an issue with signed files in the memdisk (probably not the hdd > > either, > > > but I'm only booting over the network). Any help is appreciated. > > Thanks. > > > > > > Rob > > > > ___ Help-grub mailing list Help-grub@gnu.org https://lists.gnu.org/mailman/listinfo/help-grub
Re: gpg verification issue over tftp
I don't have a local disk setup to test, but a memdisk test works without issue (using code from git master on 11/11). I was able to add some debug logging to isolate the issue to grub_file_close. I attached a screenshot and some more info to the bug report (43601). It seems like the gpg close and tftp close may be stepping on each other, but not really knowing the code I'm just taking a guess. Removing the grub_device_close call from grub_file_close fixes my issue, but I know it's not the right answer. Hope this helps. On Nov 15, 2014 10:40 AM, "Andrei Borzenkov" wrote: > В Tue, 11 Nov 2014 14:06:14 -0600 > Robert Kliewer пишет: > > > I'm seeing an issue in rhel 7 grub 2.02 based on grub 2.02~beta2 (none of > > the rhel patches appear to touch gpg, so it's almost certainly in the > main > > line as well). If I'm using a gpg public key with check_signatures > > enabled, all file operations over tftp break grub (efi x86_64 image > running > > on vmware 10). For example if I cat a signed grubenv file, the file > > displays in its entirety but it is followed with: > > > > alloc magic is broken at : > > Aborted. Press any key to exit. > > > > This sounds like memory corruption. It does not need to have anything > to do with gpg, could as well be a tftp/network problem. Useful tests > were > > - test same operation from local disk (to exclude network) > - test current upstream master whether problem still exists there > > > Pressing a key takes me back to the EFI firmware. I can work around the > > issue by disabling check_signatures and manually running verify_detached > on > > the file but that leaves me pulling my kernel and initrd twice, once to > > check the signature and once to load. Just wondering if I'm configured > in > > a bad way that would cause this behaviour. Also, this does not appear to > > be an issue with signed files in the memdisk (probably not the hdd > either, > > but I'm only booting over the network). Any help is appreciated. > Thanks. > > > > Rob > > ___ Help-grub mailing list Help-grub@gnu.org https://lists.gnu.org/mailman/listinfo/help-grub
