Mentor for gsoc for parted integration.
Hi, I am interested in parted integration in grub and it is my proposal in gsoc. Any one willing to mentor this project. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] Make the unifont FONT_SOURCE configurable as --with-unifont=FILE
Fonts might be located in different locations, and the default fonts (Unifont and DejaVu Sans) are not available on all systems or other fonts might be preferred. 2012-04-06 Mads Kiilerich m...@kiilerich.com * configure.ac: Make the unifont FONT_SOURCE configurable as --with-unifont=FILE === modified file 'configure.ac' --- configure.ac 2012-04-01 19:54:45 + +++ configure.ac 2012-04-06 17:21:55 + @@ -238,16 +238,23 @@ AC_MSG_ERROR([bison is not found]) fi -FONT_SOURCE= +AC_ARG_WITH([unifont], +AS_HELP_STRING([--with-unifont=FILE], + [set the unifont source [[guessed]]])) -for ext in pcf pcf.gz bdf bdf.gz ttf ttf.gz; do - for dir in . /usr/src /usr/share/fonts/X11/misc /usr/share/fonts/unifont; do -if test -f $dir/unifont.$ext; then - FONT_SOURCE=$dir/unifont.$ext - break 2 -fi +if test x$with_unifont = x; then + FONT_SOURCE= + for ext in pcf pcf.gz bdf bdf.gz ttf ttf.gz; do +for dir in . /usr/src /usr/share/fonts/X11/misc /usr/share/fonts/unifont; do + if test -f $dir/unifont.$ext; then +FONT_SOURCE=$dir/unifont.$ext +break 2 + fi +done done -done +else + FONT_SOURCE=$with_unifont +fi if test x$FONT_SOURCE = x ( test x$platform = xqemu || test x$platform = xloongson || test x$platform = xqemu_mips); then AC_MSG_ERROR([qemu and loongson ports need unifont]) @@ -930,7 +937,7 @@ AC_SUBST([freetype_cflags]) AC_SUBST([freetype_libs]) -DJVU_FONT_SOURCE= +DJVU_FONT_SOURCE=$FONT_SOURCE starfield_excuse= ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Mentor for gsoc for parted integration.
On 06.04.2012 15:53, RAJIV KRISHNA OMAR wrote: Hi, I am interested in parted integration in grub and it is my proposal in gsoc. This is an old idea which was formulated in times when parted manipulated filesystems as well as partition tables and was never really discussed whether it's useful or would qualify for SoC. With the POSIX layer I wrote for brltty it will probably be relatively easy to compile parted into a GRUB module. Also any writing to disk has a danger of data loss, so we restrict the writing to what makes sense to write on boot regularly. So we write only to environment block and few specific msdos partition table manipulations for the OS which make assumptions about partition map layout which prevent multi-booting. I have never seen any OS which makes any such assumptions on any other partition map. The only reasons I see to write in any other way is to reorganise data or to install a new OS. In most cases it makes more sense to integrate parted into installer. In other cases it makes more sense to have a small initramfs/mfsroot/ramdisk/... based OS bootable from GRUB and working from RAM with a data-related set of tools including parted. Also if you want to make any projects you have to prove that you're able to succeed. The best way to prove it is to start with small contributions and it will also help you familiraise with GRUB codebase. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
grub.pxe, ARP-after-boot, DMA, and trouble
I've been recently using grub.pxe (from debian's version 1.99-17)
according to the instructions at [0] to boot memtest86+ [1] (from
debian's version 4.20-1.1) over the network on x86 machines. Due to the
problems described below, i'm using a serial console.
The grub configuration is very simple:
--
serial --speed=115200
terminal_input console serial
terminal_output console serial
menuentry 'memtest86+ serial console' {
set root='(pxe)'
echo 'loading memory tester...'
linux16 /memtest86+.bin console=ttyS0,115200n8
}
--
On some machines i've done this with, memtest86+ reports transient
memory failures very early in the run, and the failures seem to happen
even on brand new sticks of RAM, placed in any combination and order in
the hardware. The errors were transient -- sometimes i'd get as many as
~300 32-bit words of RAM failing, other times memtest could complete a
full pass with no errors.
The failures came during an early test where memtest86+ writes each
address's value to its own memory location, and then re-reads the memory
to verify.
Using the serial line, i was able to record the memory failures from a
run that had 24 words fail. I was able to transcribe them and convert
them to a hexdump format. These are the 24 words that failed (the
memory address indices are in the left-hand column):
*
00095d30 9c c8 e3 71 dc ff 00 65 32 4b a0 29 08 06 00 01
00095d40 08 00 06 04 00 01 00 65 32 4b a0 29 c0 a8 17 54
00095d50 00 00 00 00 00 00 c0 a8 17 86 55 55 55 55 55 55
00095d60 55 55 55 55 55 55 55 55 55 55 55 55 9a a2 8c 53
*
00097590 00 00 00 00 30 5d 09 00 40 00 00 00 04 00 00 00
000975a0 4d 4d 00 00 00 00 00 00 00 00 00 00 10 38 6a 94
*
The first block (of 16 words) appears to be an ARP request packet
From the local network's DHCP server to the failing machine (the MAC
addresses have been obfuscated here, and i didn't bother updating the
checksum to match)
The second block (of 8 words) appears to contain a pointer to the
first block, a size indicator, and some other stuff i don't recognize.
So i think what's happening is something like Matthew Garrett describes
in his recent work with UEFI [2], although i'm using BIOS and not UEFI.
In particular, i suspect that *after* the bootloader has turned over
control to the kernel (memtest in this case), the PXE-driven NIC is
continuing to DMA received packets into active RAM.
This seems pretty dangerous!
Would using pxe_unload before the close of the stanza prevent this
situation from happening (i regret i haven't been able to test it myself
because i haven't had access to the failing hardware since i completed
this diagnosis)? If so, it seems like that should be clearly documented
and strongly recommended in grub.texi.
Or, should grub be marking certain sections of memory as unavailable
somehow before handoff to the kernel?
Or is there some other way to avoid this sort of corruption?
I've seen similar failures now on pretty different hardware (a fairly
old Dell Optiplex GX260 SFF and a new Lenovo ThinkCentre M77).
Any ideas?
--dkg
[0] https://www.gnu.org/software/grub/manual/grub.html#Network
[1] http://www.memtest.org/
[2] http://mjg59.dreamwidth.org/11235.html
pgpfAXFZqs91T.pgp
Description: PGP signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
