gujin-devel Mailing List for gujin boot/system loader
Brought to you by:
etienne_lorrain
Menu
▾
▴
gujin-devel
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
(4) |
Feb
(1) |
Mar
(2) |
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Etienne L. <eti...@gu...> - 2007-09-18 12:52:07
|
> The de-facto stitaution with the LANG environment variable in Linux is: > > * the list of all locales supported by Glibc can be obtained by running > "locale -a", and "en" is not there. > * Glibc ignores case and dashes in the charset specification (e.g., > thinks that en_US.utf8 and en_US.UTF-8 are the same locale). > * some applications (notably, those using libX11) require a certain > spelling of the charset specification (e.g., accept en_US.UTF-8 but not > en_US.utf8). OK, for the next version, I will put in install-*.tar.gz the result of compiling without "LANGAGE" defined in the Makefile, then messages defaults to english and the LANG= is not passed as parameter. If the user compiles with LANGAGE=ENGLISH or LANGAGE=FRENCH, then it will behave as today and the file /etc/locale.alias may need updating by installation script (to add which type of english by default). Note here: http://docs.hp.com/en/B2355-90131/environ.5.html The format of LANG is: LANG=language[_territory][.codeset] saying clearly that _territory is optional, and I used UNIX/Linux systems with LANG=en or LANG=fr few years ago. I still do not have a feedback from: http://sources.redhat.com/ml/libc-alpha/2007-09/msg00067.html > KVM runs only on processors that support Intel or AMD virtualization > extensions. The command line syntax is exactly the same as that of qemu. > Install Gujin, let it boot the kernel and the initrd image, and crask > kvm immediately after that. When crashing there, you may want to try to uncheck the "force bzImage protocol" checkbox in setup, forcing to use the 32 bits entry point. It may work - I cannot really tell why - each times I tried to debug I was calling the Linux kernel real-mode entry point as usual and the crash was hapenning later. Note that this real-mode code has completely changed in the latest Linux version - the best way to debug would probably be to run boot.exe under the old Borland TurboDebugger, modifying the kernel to have an "INT 0x3" at startup and single stepping from there. Etienne. |
|
From: Wit S <wit...@gm...> - 2007-08-22 18:22:29
|
Hello: I am new to bootloaders so forgive me in my ignorance. I stumbled upon Gujin and it has some abilities that I like, specifically things I want to add to me live CD. How does Gujin pass control to the OS? Which C file does it? How does it find the systems in realtime? Is it a linux version or is it always going to be DOS? I tried using the floppy and everytime I tried to boot my NTFS system it would say 0x20 error or if I tried to boot my linux system I would get a kernel panic. If I take out the floppy it will boot fine. ? I appreciate your help. Thanks |
|
From: Etienne L. <eti...@gu...> - 2007-02-01 14:30:42
|
This message has not been archived... ---------------------------- Original Message ---------------------------= - Hi Marco, I copied you as BCC (Blind Carbon Copy) *** Note to other readers: this is following the thread at: http://sourceforge.net/forum/forum.php?thread_id=3D1627499&forum_id=3D491= 28 > Below the log of the unsuccessful attempt (I get Gujin1 Gujin2 > checksum ERROR! in a loop) That is usually happening when you forget to do the: dd if=3D/dev/zero of=3D/dev/sda bs=3D512 count=3D64 to clear the MBR of the pen drive, before each try to install Gujin, because Gujin installer do not like to erase the MBR if it is present and valid. That may also happen when one of the partition is mounted and the Linux kernel refuses to erase the partition table, take care of automount-ers. The two exact commands should be: dd if=3D/dev/zero of=3D/dev/sda bs=3D512 count=3D64 # to erase the begini= ng ./instboot boot.bin /dev/sda --disk=3DBIOS:0x80,auto --cmdline=3D"" \ --mbr-device=3D/dev/sda --partition_index=3D4 --read_retry --usb_hdd For extra safety you could unplug and replug the USB key in between the two commands. At the end of the install you give, you have line: Extra: failed re-reading partition table of /dev/sda Extra: failed re-reading partition table of /dev/sda which is a bad sign. This message can only be ignored when you have installed Gujin in a partition, and this partition is not the one which is mounted (i.e. /dev/hda1 is mounted but you installed Gujin in /dev/hda2 and without the --mbr-device parameter). > So let me summarize the result I achieved so far > USB penDRIVE: OK With or without a partition table? Did you give the "--mbr-device=3D/dev/sda --usb_hdd" parameters? > CD: OK > HDD-USB: I will try soon I have a 30GB one. 1.7 should treath > it as the penDrive.. The real question is not how Gujin treats it, but how your BIOS want it... > Multiboot: > PEN Drive: I was not able to partition it. /sbin/fdisk /dev/sda should do the trick, those nice text tools... > CD: multisessions done, unfortunately some distributions don't > find the path. (which ones will work ?) Can we do anything more ? I told you at the begining, the problem is mounting the root device, and I do not know the solution - excluding modifying one line of the init scripts inside the ISO image. > HDD: to test. HDD USB works for me, without the --usb_hdd parameter. > Hibryd Boot: I copied knoppix DVD to my 30GB USB drive. > Problem: make it booting from the Hdd.. > so still alot to go... Create a partition of type Linux, let's say /dev/hda8, and type: cat /dev/cdrom > /dev/hda8 then boot with Gujin. It needs to be a partition and not the file knoppix.iso in a filesystem. > Other (old) goals: boot an (or more) ISO to be generic and > original boot indipendent... With or without changing the ISO... Etienne. |
|
From: Etienne L. <eti...@gu...> - 2007-01-31 10:54:56
|
Hi Marco, I copied you as BCC (Blind Carbon Copy) *** Note to other readers: this is following the thread at: http://sourceforge.net/forum/forum.php?thread_id=3D1627499&forum_id=3D491= 28 > Below the log of the unsuccessful attempt (I get Gujin1 Gujin2 > checksum ERROR! in a loop) That is usually happening when you forget to do the: dd if=3D/dev/zero of=3D/dev/sda bs=3D512 count=3D64 to clear the MBR of the pen drive, before each try to install Gujin, because Gujin installer do not like to erase the MBR if it is present and valid. That may also happen when one of the partition is mounted and the Linux kernel refuses to erase the partition table, take care of automount-ers. The two exact commands should be: dd if=3D/dev/zero of=3D/dev/sda bs=3D512 count=3D64 # to erase the begini= ng ./instboot boot.bin /dev/sda --disk=3DBIOS:0x80,auto --cmdline=3D"" \ --mbr-device=3D/dev/sda --partition_index=3D4 --read_retry --usb_hdd For extra safety you could unplug and replug the USB key in between the two commands. At the end of the install you give, you have line: Extra: failed re-reading partition table of /dev/sda Extra: failed re-reading partition table of /dev/sda which is a bad sign. This message can only be ignored when you have installed Gujin in a partition, and this partition is not the one which is mounted (i.e. /dev/hda1 is mounted but you installed Gujin in /dev/hda2 and without the --mbr-device parameter). > So let me summarize the result I achieved so far > USB penDRIVE: OK With or without a partition table? Did you give the "--mbr-device=3D/dev/sda --usb_hdd" parameters? > CD: OK > HDD-USB: I will try soon I have a 30GB one. 1.7 should treath > it as the penDrive.. The real question is not how Gujin treats it, but how your BIOS want it... > Multiboot: > PEN Drive: I was not able to partition it. /sbin/fdisk /dev/sda should do the trick, those nice text tools... > CD: multisessions done, unfortunately some distributions don't > find the path. (which ones will work ?) Can we do anything more ? I told you at the begining, the problem is mounting the root device, and I do not know the solution - excluding modifying one line of the init scripts inside the ISO image. > HDD: to test. HDD USB works for me, without the --usb_hdd parameter. > Hibryd Boot: I copied knoppix DVD to my 30GB USB drive. > Problem: make it booting from the Hdd.. > so still alot to go... Create a partition of type Linux, let's say /dev/hda8, and type: cat /dev/cdrom > /dev/hda8 then boot with Gujin. It needs to be a partition and not the file knoppix.iso in a filesystem. > Other (old) goals: boot an (or more) ISO to be generic and > original boot indipendent... With or without changing the ISO... Etienne. |
|
From: Marco B. <be...@em...> - 2007-01-30 22:34:04
|
Here is the answer. Below the log of the unsuccessful attempt (I get Gujin1 Gujin2 checksum ERROR! in a loop) So let me summarize the result I achieved so far USB penDRIVE: OK CD: OK HDD-USB: I will try soon I have a 30GB one. 1.7 should treath it as the penDrive.. Multiboot: PEN Drive: I was not able to partition it. CD: multisessions done, unfortunately some distributions don't find the path. (which ones will work ?) Can we do anything more ? HDD: to test. Hibryd Boot: I copied knoppix DVD to my 30GB USB drive. Problem: make it booting from the Hdd.. so still alot to go... Other (old) goals: boot an (or more) ISO to be generic and original boot indipendent... Benny benny@benny-laptop:~/Desktop/gujin1.7/install/install$ ./instboot boot.bin /dev/sda --disk=BIOS:0x80,auto --cmdline="" --mbr-device=/dev/sda --partition_index=4 --read_retry --usb_hdd -w Proc: initialise cmdline from /proc/cmdline: root=/dev/hda3 ro quiet splash Proc: kept '--cmdline="quiet splash"' Extra: reading parameter '--cmdline=', empty cmdline, clear default. Size: this configuration leaves 3168 bytes for code, Size: and leaves 6528 bytes for xcode, 34592 bytes for xdata segments. Size: this configuration leaves 41992 bytes for stack + heap. Extra: '--geometry=' not given, start .com/.exe/.pic/.bcd/.num/.bios extension recognition: Extra: '--geometry=' not given, look if '/dev/sda' is a device: Yes but does not finish by a digit Extra: set devname to '/dev/sda' to get partition size & offset and disk parameters. Extra: geocmd beginning with '/', begin device geometry analysis. Extra: scandisk /sys/block/*/dev for stat_buf.st_rdev 0x800 Extra: start_sector of MAJOR device '/sys/block/sda/dev' is zero Extra: HDIO_GETGEO ioctl: total_sector: 257805, start_sector: 0, cylinders: 1011, heads: 5, sectpertrack: 51. Extra: something not perfect: total sector * 512 = 131996160, total len 132120576 Extra: device name /dev/sda, len 132120576, total_sector 257805, so sector size 512, pages of 8 sectors Extra: Reporting wholedisk: start_sector = 0, total_sector 257805, partdisk: start_sector = 0, total_sector 258048 Extra: Want a MBR device on a whole disk, create partition 51+257754 inside wholedisk 0+257805 Extra: Reporting install->misc.output_partition_offset 51 Extra: exit setup_geometry with: --geometry=257754,51,5,51,512,257805,0,5,51,512 (cylinder: 1011,1011) Chain: --disk=BIOS:0x80,0x7F Extra: entering setup_fs with fs->NbFsSector == 257754 and '--fs=' Fs: if FatSize 12 and NbSectorPerCluster 4, then NbClusterPerCluster 1365, NbFatSector 189 Fs: NbFsSector 257754, NbReservedSector 1, NbRootSector 8, nbDATandFATsector 257745 Fs: nbDATcluster 64341 >= 4085 == 0xFF5 too big for FAT12 Fs: if FatSize 16 and NbSectorPerCluster 4, then NbClusterPerCluster 1024, NbFatSector 252 Fs: so FAT16, nbSectorPerFAT 252, nbDATcluster 64310 Fs: FAT16 selected Fs: NbRootSector_default_used set, convert 1 trailing sector to root sectors (8 -> 9) Extra: exiting setup_fs with '--fs=FAT:257754,4,9,1,2,16,0x80,0xF8' Extra: Auto disk (disk got at boot in DL register) patch (replace 0xC289==0xC289 by 0xE688) done Extra: read-retry patch done Mbr: jmpinstruction: 0xEB,0x6F, EBIOSaccess 0x90 i.e. BIOS only Mbr: NbHiddensector 51, Head 5, Sector/track 51, i.e. partition size 125 Mb. Mbr: Bytepersector 512, Sectorpercluster 4, Reservedsector 1, NbRootdirentry 144. Mbr: NbFAT 2, NbSectorperFAT 252, NbTotalsector 0, NbTotalsector2 257754, Mediadescriptor 0xF8. Mbr: PhysicaldriveNb 0x80, FATreserved 0, Signaturebyte0x29 0x29, FileSysName 'FAT16 '. Extra: --position=0, so nb_cluster: at_begin 0, in_file 85, at_end 64225. Chain: MBR sector (lba = 0) of disk 0x7F at 0x7C00, chs_chain: lba=566, last_lba=904, 904 - 566 = 338, Chain: BIOS disk 0x80, C/H/S 1011/5/51 Chain[00]: 1 sector at LBA 566, C/H/S: 2/01/06 loaded at 0x07E00, i.e. 0x07C00200..0x07C003FF Chain[01]: 45 sector at LBA 567, C/H/S: 2/01/07 loaded at 0x08000, i.e. 0x07C00400..0x07C05DFF Chain[02]: 19 sector at LBA 612, C/H/S: 2/02/01 loaded at 0x0DA00, i.e. 0x07C05E00..0x07C083FF Chain[03]: 32 sector at LBA 631, C/H/S: 2/02/20 loaded at 0x10000, i.e. 0x07C08400..0x07C0C3FF Chain[04]: 30 sector at LBA 663, C/H/S: 2/03/01 loaded at 0x14000, i.e. 0x07C0C400..0x07C0FFFF Chain[05]: 21 sector at LBA 693, C/H/S: 2/03/31 loaded at 0x17C00, i.e. 0x17C00000..0x17C029FF Chain[06]: 45 sector at LBA 714, C/H/S: 2/04/01 loaded at 0x1A600, i.e. 0x17C02A00..0x17C083FF Chain[07]: 6 sector at LBA 759, C/H/S: 2/04/46 loaded at 0x20000, i.e. 0x17C08400..0x17C08FFF Chain[08]: 51 sector at LBA 765, C/H/S: 3/00/01 loaded at 0x20C00, i.e. 0x17C09000..0x17C0F5FF Chain[09]: 5 sector at LBA 816, C/H/S: 3/01/01 loaded at 0x27200, i.e. 0x17C0F600..0x17C0FFFF Chain[10]: 46 sector at LBA 821, C/H/S: 3/01/06 loaded at 0x27C00, i.e. 0x27C00000..0x27C05BFF Chain[11]: 20 sector at LBA 867, C/H/S: 3/02/01 loaded at 0x2D800, i.e. 0x27C05C00..0x27C083FF Chain[12]: 17 sector at LBA 887, C/H/S: 3/02/21 loaded at 0x30000, i.e. 0x27C08400..0x27C0A5FF Chain: using 12 element (max 35), i.e 312 bytes for bootchain[] (max 910) Chain: will save MBR (for MBR recovery) at lba: 904 Extra: scandisk /sys/block/*/dev for stat_buf.st_rdev 0x800 Extra: start_sector of MAJOR device '/sys/block/sda/dev' is zero Mbr: keep old VolumeserialNb = 0x0 Mbr: FAT16 0x29 signature found on '/dev/sda', keep default C/H/S info block. Mbr: first bytes: 0xEB, 0x6F, 0x90 Mbr: InfoBlock: 512 bytes/sector, 0 short total sectors, 257805 total sector, media descriptor: 0xF8, physical drive nb 0xFF InfoBlock: 51 sectors/track, 5 heads, 0 hidden sectors, volume serial nb 0x0. Mbr: has initialised new MBR up to 0x1B6; WinNT/XP marker 0x0 kept. Extra: scandisk /sys/block/*/dev for stat_buf.st_rdev 0x800 Extra: start_sector of MAJOR device '/sys/block/sda/dev' is zero Extra: output device is the whole disk, do offset every writes by misc->output_partition_offset 51 * 512 = 26112. Location: will lseek64: 0 * 512 + 51 * 512, i.e. 26112 You asked to create a new FAT filesystem on '/dev/sda', and so ERASE completely this partition, confirm [NO/yes]: yes Extra: Begin writing to the device. Extra: writing boot record as first sector. Location: will lseek64: 1 * 512 + 51 * 512, i.e. 26624 Location: lseek64(0, SEEK_CUR): 52 sector, should be 52 sector, after FAT Reserved Sector Fs: write_fat_16 write: FAT uses 128624 bytes and contains 129024 bytes, 400 bytes emptied Fs: write_fat_16 write: FAT uses 128624 bytes and contains 129024 bytes, 400 bytes emptied Location: lseek64(0, SEEK_CUR): 565 sector, should be 565 sector, after FAT(s) + root directory Location: will lseek64: 514 * 512 + 51 * 512, i.e. 289280 Extra: writing copy of MBR. Extra: writing total remaining after (file+BytePerSector). Location: lseek64(0, SEEK_CUR): 904 sector, should be 904 sector, after the complete file Extra: writing the uninstall boot record Location: lseek64(0, SEEK_CUR): 905 sector, should be 905 sector, after the uninstall boot record Finishing write (flushing buffers) and then checking... Extra: scandisk /sys/block/*/dev for stat_buf.st_rdev 0x800 Extra: start_sector of MAJOR device '/sys/block/sda/dev' is zero Extra: output device is the whole disk, do offset every writes by misc->output_partition_offset 51 * 512 = 26112. Location: will lseek64: 0 * 512 + 51 * 512, i.e. 26112 Extra: Begin extensive verification of what has been written. Extra: checking boot record as first sector. Location: will lseek64: 1 * 512 + 51 * 512, i.e. 26624 Location: lseek64(0, SEEK_CUR): 52 sector, should be 52 sector, after FAT Reserved Sector Fs: write_fat_16 check: FAT uses 128624 bytes and contains 129024 bytes, 400 bytes emptied Fs: write_fat_16 check: FAT uses 128624 bytes and contains 129024 bytes, 400 bytes emptied Location: lseek64(0, SEEK_CUR): 565 sector, should be 565 sector, after FAT(s) + root directory Location: will lseek64: 514 * 512 + 51 * 512, i.e. 289280 Extra: checking copy of MBR. Extra: checking total remaining after (file+BytePerSector). Location: lseek64(0, SEEK_CUR): 904 sector, should be 904 sector, after the complete file Extra: checking the uninstall boot record Location: lseek64(0, SEEK_CUR): 905 sector, should be 905 sector, after the uninstall boot record Extra: will write and/or check the MBR on '/dev/sda' Extra: failed re-reading partition table of /dev/sda Extra: failed re-reading partition table of /dev/sda benny@benny-laptop:~/Desktop/gujin1.7/install/install$ ---- BOOTING I get gujin checksum error when booting in a loop... next attempt benny@benny-laptop:~/Desktop/gujin1.7/install/install$ ./instboot boot.bin /dev/sda --disk=BIOS:0x80,auto --cmdline="" --mbr-device=/dev/sda --partition_index=4 --read_retry --usb_hdd -w --single_sector_load Proc: initialise cmdline from /proc/cmdline: root=/dev/hda3 ro quiet splash Proc: kept '--cmdline="quiet splash"' Extra: reading parameter '--cmdline=', empty cmdline, clear default. Size: this configuration leaves 3168 bytes for code, Size: and leaves 6528 bytes for xcode, 34592 bytes for xdata segments. Size: this configuration leaves 41992 bytes for stack + heap. Extra: '--geometry=' not given, start .com/.exe/.pic/.bcd/.num/.bios extension recognition: Extra: '--geometry=' not given, look if '/dev/sda' is a device: Yes but does not finish by a digit Extra: set devname to '/dev/sda' to get partition size & offset and disk parameters. Extra: geocmd beginning with '/', begin device geometry analysis. Extra: scandisk /sys/block/*/dev for stat_buf.st_rdev 0x800 Extra: start_sector of MAJOR device '/sys/block/sda/dev' is zero Extra: HDIO_GETGEO ioctl: total_sector: 257805, start_sector: 0, cylinders: 1011, heads: 5, sectpertrack: 51. Extra: something not perfect: total sector * 512 = 131996160, total len 132120576 Extra: device name /dev/sda, len 132120576, total_sector 257805, so sector size 512, pages of 8 sectors Extra: Reporting wholedisk: start_sector = 0, total_sector 257805, partdisk: start_sector = 0, total_sector 258048 Extra: Want a MBR device on a whole disk, create partition 51+257754 inside wholedisk 0+257805 Extra: Reporting install->misc.output_partition_offset 51 Extra: exit setup_geometry with: --geometry=257754,51,5,51,512,257805,0,5,51,512 (cylinder: 1011,1011) Chain: --disk=BIOS:0x80,0x7F Extra: entering setup_fs with fs->NbFsSector == 257754 and '--fs=' Fs: if FatSize 12 and NbSectorPerCluster 4, then NbClusterPerCluster 1365, NbFatSector 189 Fs: NbFsSector 257754, NbReservedSector 1, NbRootSector 8, nbDATandFATsector 257745 Fs: nbDATcluster 64341 >= 4085 == 0xFF5 too big for FAT12 Fs: if FatSize 16 and NbSectorPerCluster 4, then NbClusterPerCluster 1024, NbFatSector 252 Fs: so FAT16, nbSectorPerFAT 252, nbDATcluster 64310 Fs: FAT16 selected Fs: NbRootSector_default_used set, convert 1 trailing sector to root sectors (8 -> 9) Extra: exiting setup_fs with '--fs=FAT:257754,4,9,1,2,16,0x80,0xF8' Extra: Auto disk (disk got at boot in DL register) patch (replace 0xC289==0xC289 by 0xE688) done Extra: read-retry patch done Extra: single_sector_load patch applied successfully Mbr: jmpinstruction: 0xEB,0x6F, EBIOSaccess 0x90 i.e. BIOS only Mbr: NbHiddensector 51, Head 5, Sector/track 51, i.e. partition size 125 Mb. Mbr: Bytepersector 512, Sectorpercluster 4, Reservedsector 1, NbRootdirentry 144. Mbr: NbFAT 2, NbSectorperFAT 252, NbTotalsector 0, NbTotalsector2 257754, Mediadescriptor 0xF8. Mbr: PhysicaldriveNb 0x80, FATreserved 0, Signaturebyte0x29 0x29, FileSysName 'FAT16 '. Extra: --position=0, so nb_cluster: at_begin 0, in_file 85, at_end 64225. Chain: MBR sector (lba = 0) of disk 0x7F at 0x7C00, chs_chain: lba=566, last_lba=904, 904 - 566 = 338, Chain: BIOS disk 0x80, C/H/S 1011/5/51 Chain[00]: 1 sector at LBA 566, C/H/S: 2/01/06 loaded at 0x07E00, i.e. 0x07C00200..0x07C003FF Chain[01]: 45 sector at LBA 567, C/H/S: 2/01/07 loaded at 0x08000, i.e. 0x07C00400..0x07C05DFF Chain[02]: 19 sector at LBA 612, C/H/S: 2/02/01 loaded at 0x0DA00, i.e. 0x07C05E00..0x07C083FF Chain[03]: 32 sector at LBA 631, C/H/S: 2/02/20 loaded at 0x10000, i.e. 0x07C08400..0x07C0C3FF Chain[04]: 30 sector at LBA 663, C/H/S: 2/03/01 loaded at 0x14000, i.e. 0x07C0C400..0x07C0FFFF Chain[05]: 21 sector at LBA 693, C/H/S: 2/03/31 loaded at 0x17C00, i.e. 0x17C00000..0x17C029FF Chain[06]: 45 sector at LBA 714, C/H/S: 2/04/01 loaded at 0x1A600, i.e. 0x17C02A00..0x17C083FF Chain[07]: 6 sector at LBA 759, C/H/S: 2/04/46 loaded at 0x20000, i.e. 0x17C08400..0x17C08FFF Chain[08]: 51 sector at LBA 765, C/H/S: 3/00/01 loaded at 0x20C00, i.e. 0x17C09000..0x17C0F5FF Chain[09]: 5 sector at LBA 816, C/H/S: 3/01/01 loaded at 0x27200, i.e. 0x17C0F600..0x17C0FFFF Chain[10]: 46 sector at LBA 821, C/H/S: 3/01/06 loaded at 0x27C00, i.e. 0x27C00000..0x27C05BFF Chain[11]: 20 sector at LBA 867, C/H/S: 3/02/01 loaded at 0x2D800, i.e. 0x27C05C00..0x27C083FF Chain[12]: 17 sector at LBA 887, C/H/S: 3/02/21 loaded at 0x30000, i.e. 0x27C08400..0x27C0A5FF Chain: using 12 element (max 35), i.e 312 bytes for bootchain[] (max 910) Chain: will save MBR (for MBR recovery) at lba: 904 Extra: scandisk /sys/block/*/dev for stat_buf.st_rdev 0x800 Extra: start_sector of MAJOR device '/sys/block/sda/dev' is zero Mbr: keep old VolumeserialNb = 0x0 Mbr: FAT16 0x29 signature found on '/dev/sda', keep default C/H/S info block. Mbr: first bytes: 0xEB, 0x6F, 0x90 Mbr: InfoBlock: 512 bytes/sector, 0 short total sectors, 257805 total sector, media descriptor: 0xF8, physical drive nb 0xFF InfoBlock: 51 sectors/track, 5 heads, 0 hidden sectors, volume serial nb 0x0. Mbr: has initialised new MBR up to 0x1B6; WinNT/XP marker 0x0 kept. Extra: scandisk /sys/block/*/dev for stat_buf.st_rdev 0x800 Extra: start_sector of MAJOR device '/sys/block/sda/dev' is zero Extra: output device is the whole disk, do offset every writes by misc->output_partition_offset 51 * 512 = 26112. Location: will lseek64: 0 * 512 + 51 * 512, i.e. 26112 You asked to create a new FAT filesystem on '/dev/sda', and so ERASE completely this partition, confirm [NO/yes]: yes Extra: Begin writing to the device. Extra: writing boot record as first sector. Location: will lseek64: 1 * 512 + 51 * 512, i.e. 26624 Location: lseek64(0, SEEK_CUR): 52 sector, should be 52 sector, after FAT Reserved Sector Fs: write_fat_16 write: FAT uses 128624 bytes and contains 129024 bytes, 400 bytes emptied Fs: write_fat_16 write: FAT uses 128624 bytes and contains 129024 bytes, 400 bytes emptied Location: lseek64(0, SEEK_CUR): 565 sector, should be 565 sector, after FAT(s) + root directory Location: will lseek64: 514 * 512 + 51 * 512, i.e. 289280 Extra: writing copy of MBR. Extra: writing total remaining after (file+BytePerSector). Location: lseek64(0, SEEK_CUR): 904 sector, should be 904 sector, after the complete file Extra: writing the uninstall boot record Location: lseek64(0, SEEK_CUR): 905 sector, should be 905 sector, after the uninstall boot record Finishing write (flushing buffers) and then checking... Extra: scandisk /sys/block/*/dev for stat_buf.st_rdev 0x800 Extra: start_sector of MAJOR device '/sys/block/sda/dev' is zero Extra: output device is the whole disk, do offset every writes by misc->output_partition_offset 51 * 512 = 26112. Location: will lseek64: 0 * 512 + 51 * 512, i.e. 26112 Extra: Begin extensive verification of what has been written. Extra: checking boot record as first sector. Location: will lseek64: 1 * 512 + 51 * 512, i.e. 26624 Location: lseek64(0, SEEK_CUR): 52 sector, should be 52 sector, after FAT Reserved Sector Fs: write_fat_16 check: FAT uses 128624 bytes and contains 129024 bytes, 400 bytes emptied Fs: write_fat_16 check: FAT uses 128624 bytes and contains 129024 bytes, 400 bytes emptied Location: lseek64(0, SEEK_CUR): 565 sector, should be 565 sector, after FAT(s) + root directory Location: will lseek64: 514 * 512 + 51 * 512, i.e. 289280 Extra: checking copy of MBR. Extra: checking total remaining after (file+BytePerSector). Location: lseek64(0, SEEK_CUR): 904 sector, should be 904 sector, after the complete file Extra: checking the uninstall boot record Location: lseek64(0, SEEK_CUR): 905 sector, should be 905 sector, after the uninstall boot record Extra: will write and/or check the MBR on '/dev/sda' Extra: failed re-reading partition table of /dev/sda Extra: failed re-reading partition table of /dev/sda benny@benny-laptop:~/Desktop/gujin1.7/install/install$ SAME AS BEFORE Finishing write (flushing buffers) and then checking... benny@benny-laptop:~/Desktop/gujin1.7/install/install$ ./instboot boot.bin /dev/sda --disk=BIOS:0x80,auto --cmdline="" --mbr-device=/dev/sda --partition_index=4 --read_retry --usb_hdd --head=16 --sectorpertrack=32 -w Proc: initialise cmdline from /proc/cmdline: root=/dev/hda3 ro quiet splash Proc: kept '--cmdline="quiet splash"' Extra: reading parameter '--cmdline=', empty cmdline, clear default. Size: this configuration leaves 3168 bytes for code, Size: and leaves 6528 bytes for xcode, 34592 bytes for xdata segments. Size: this configuration leaves 41992 bytes for stack + heap. Extra: '--geometry=' not given, start .com/.exe/.pic/.bcd/.num/.bios extension recognition: Extra: '--geometry=' not given, look if '/dev/sda' is a device: Yes but does not finish by a digit Extra: set devname to '/dev/sda' to get partition size & offset and disk parameters. Extra: geocmd beginning with '/', begin device geometry analysis. Extra: scandisk /sys/block/*/dev for stat_buf.st_rdev 0x800 Extra: start_sector of MAJOR device '/sys/block/sda/dev' is zero Extra: HDIO_GETGEO ioctl: total_sector: 258048, start_sector: 0, cylinders: 504, heads: 16, sectpertrack: 32. Extra: Overwriting number of heads from 16 to 16. Extra: Overwriting number of sector/track from 32 to 32. Extra: device name /dev/sda, len 132120576, total_sector 258048, so sector size 512, pages of 8 sectors Extra: Reporting wholedisk: start_sector = 0, total_sector 258048, partdisk: start_sector = 0, total_sector 258048 Extra: Want a MBR device on a whole disk, create partition 32+258016 inside wholedisk 0+258048 Extra: Reporting install->misc.output_partition_offset 32 Extra: exit setup_geometry with: --geometry=258016,32,16,32,512,258048,0,16,32,512 (cylinder: 504,504) Chain: --disk=BIOS:0x80,0x7F Extra: entering setup_fs with fs->NbFsSector == 258016 and '--fs=' Fs: if FatSize 12 and NbSectorPerCluster 4, then NbClusterPerCluster 1365, NbFatSector 189 Fs: NbFsSector 258016, NbReservedSector 1, NbRootSector 8, nbDATandFATsector 258007 Fs: nbDATcluster 64407 >= 4085 == 0xFF5 too big for FAT12 Fs: if FatSize 16 and NbSectorPerCluster 4, then NbClusterPerCluster 1024, NbFatSector 252 Fs: so FAT16, nbSectorPerFAT 252, nbDATcluster 64375 Fs: FAT16 selected Fs: NbRootSector_default_used set, convert 3 trailing sector to root sectors (8 -> 11) Extra: exiting setup_fs with '--fs=FAT:258016,4,11,1,2,16,0x80,0xF8' Extra: Auto disk (disk got at boot in DL register) patch (replace 0xC289==0xC289 by 0xE688) done Extra: read-retry patch done Mbr: jmpinstruction: 0xEB,0x6F, EBIOSaccess 0x90 i.e. BIOS only Mbr: NbHiddensector 32, Head 16, Sector/track 32, i.e. partition size 125 Mb. Mbr: Bytepersector 512, Sectorpercluster 4, Reservedsector 1, NbRootdirentry 176. Mbr: NbFAT 2, NbSectorperFAT 252, NbTotalsector 0, NbTotalsector2 258016, Mediadescriptor 0xF8. Mbr: PhysicaldriveNb 0x80, FATreserved 0, Signaturebyte0x29 0x29, FileSysName 'FAT16 '. Extra: --position=0, so nb_cluster: at_begin 0, in_file 85, at_end 64290. Chain: MBR sector (lba = 0) of disk 0x7F at 0x7C00, chs_chain: lba=549, last_lba=887, 887 - 549 = 338, Chain: BIOS disk 0x80, C/H/S 504/16/32 Chain[00]: 1 sector at LBA 549, C/H/S: 1/01/06 loaded at 0x07E00, i.e. 0x07C00200..0x07C003FF Chain[01]: 26 sector at LBA 550, C/H/S: 1/01/07 loaded at 0x08000, i.e. 0x07C00400..0x07C037FF Chain[02]: 32 sector at LBA 576, C/H/S: 1/02/01 loaded at 0x0B400, i.e. 0x07C03800..0x07C077FF Chain[03]: 6 sector at LBA 608, C/H/S: 1/03/01 loaded at 0x0F400, i.e. 0x07C07800..0x07C083FF Chain[04]: 26 sector at LBA 614, C/H/S: 1/03/07 loaded at 0x10000, i.e. 0x07C08400..0x07C0B7FF Chain[05]: 32 sector at LBA 640, C/H/S: 1/04/01 loaded at 0x13400, i.e. 0x07C0B800..0x07C0F7FF Chain[06]: 4 sector at LBA 672, C/H/S: 1/05/01 loaded at 0x17400, i.e. 0x07C0F800..0x07C0FFFF Chain[07]: 28 sector at LBA 676, C/H/S: 1/05/05 loaded at 0x17C00, i.e. 0x17C00000..0x17C037FF Chain[08]: 32 sector at LBA 704, C/H/S: 1/06/01 loaded at 0x1B400, i.e. 0x17C03800..0x17C077FF Chain[09]: 6 sector at LBA 736, C/H/S: 1/07/01 loaded at 0x1F400, i.e. 0x17C07800..0x17C083FF Chain[10]: 26 sector at LBA 742, C/H/S: 1/07/07 loaded at 0x20000, i.e. 0x17C08400..0x17C0B7FF Chain[11]: 32 sector at LBA 768, C/H/S: 1/08/01 loaded at 0x23400, i.e. 0x17C0B800..0x17C0F7FF Chain[12]: 4 sector at LBA 800, C/H/S: 1/09/01 loaded at 0x27400, i.e. 0x17C0F800..0x17C0FFFF Chain[13]: 28 sector at LBA 804, C/H/S: 1/09/05 loaded at 0x27C00, i.e. 0x27C00000..0x27C037FF Chain[14]: 32 sector at LBA 832, C/H/S: 1/10/01 loaded at 0x2B400, i.e. 0x27C03800..0x27C077FF Chain[15]: 6 sector at LBA 864, C/H/S: 1/11/01 loaded at 0x2F400, i.e. 0x27C07800..0x27C083FF Chain[16]: 17 sector at LBA 870, C/H/S: 1/11/07 loaded at 0x30000, i.e. 0x27C08400..0x27C0A5FF Chain: using 16 element (max 35), i.e 416 bytes for bootchain[] (max 910) Chain: will save MBR (for MBR recovery) at lba: 887 Extra: scandisk /sys/block/*/dev for stat_buf.st_rdev 0x800 Extra: start_sector of MAJOR device '/sys/block/sda/dev' is zero Mbr: keep old VolumeserialNb = 0x0 Mbr: FAT16 0x29 signature found on '/dev/sda', keep default C/H/S info block. Mbr: first bytes: 0xEB, 0x6F, 0x90 Mbr: InfoBlock: 512 bytes/sector, 0 short total sectors, 257805 total sector, media descriptor: 0xF8, physical drive nb 0xFF InfoBlock: 32 sectors/track, 16 heads, 0 hidden sectors, volume serial nb 0x0. Mbr: has initialised new MBR up to 0x1B6; WinNT/XP marker 0x0 kept. Extra: scandisk /sys/block/*/dev for stat_buf.st_rdev 0x800 Extra: start_sector of MAJOR device '/sys/block/sda/dev' is zero Extra: output device is the whole disk, do offset every writes by misc->output_partition_offset 32 * 512 = 16384. Location: will lseek64: 0 * 512 + 32 * 512, i.e. 16384 You asked to create a new FAT filesystem on '/dev/sda', and so ERASE completely this partition, confirm [NO/yes]: yes Extra: Begin writing to the device. Extra: writing boot record as first sector. Location: will lseek64: 1 * 512 + 32 * 512, i.e. 16896 Location: lseek64(0, SEEK_CUR): 33 sector, should be 33 sector, after FAT Reserved Sector Fs: write_fat_16 write: FAT uses 128754 bytes and contains 129024 bytes, 270 bytes emptied Fs: write_fat_16 write: FAT uses 128754 bytes and contains 129024 bytes, 270 bytes emptied Location: lseek64(0, SEEK_CUR): 548 sector, should be 548 sector, after FAT(s) + root directory Location: will lseek64: 516 * 512 + 32 * 512, i.e. 280576 Extra: writing copy of MBR. Extra: writing total remaining after (file+BytePerSector). Location: lseek64(0, SEEK_CUR): 887 sector, should be 887 sector, after the complete file Extra: writing the uninstall boot record Location: lseek64(0, SEEK_CUR): 888 sector, should be 888 sector, after the uninstall boot record Finishing write (flushing buffers) and then checking... Extra: scandisk /sys/block/*/dev for stat_buf.st_rdev 0x800 Extra: start_sector of MAJOR device '/sys/block/sda/dev' is zero Extra: output device is the whole disk, do offset every writes by misc->output_partition_offset 32 * 512 = 16384. Location: will lseek64: 0 * 512 + 32 * 512, i.e. 16384 Extra: Begin extensive verification of what has been written. Extra: checking boot record as first sector. Location: will lseek64: 1 * 512 + 32 * 512, i.e. 16896 Location: lseek64(0, SEEK_CUR): 33 sector, should be 33 sector, after FAT Reserved Sector Fs: write_fat_16 check: FAT uses 128754 bytes and contains 129024 bytes, 270 bytes emptied Fs: write_fat_16 check: FAT uses 128754 bytes and contains 129024 bytes, 270 bytes emptied Location: lseek64(0, SEEK_CUR): 548 sector, should be 548 sector, after FAT(s) + root directory Location: will lseek64: 516 * 512 + 32 * 512, i.e. 280576 Extra: checking copy of MBR. Extra: checking total remaining after (file+BytePerSector). Location: lseek64(0, SEEK_CUR): 887 sector, should be 887 sector, after the complete file Extra: checking the uninstall boot record Location: lseek64(0, SEEK_CUR): 888 sector, should be 888 sector, after the uninstall boot record Extra: will write and/or check the MBR on '/dev/sda' Extra: failed re-reading partition table of /dev/sda Extra: failed re-reading partition table of /dev/sda -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Video-Corsi.com : Vuoi scoprire un modo rapido e veloce per imparare? Scopri i nostri VideoCorsi professionali Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=5141&d=30-1 |
|
From: Etienne L. <eti...@ya...> - 2007-01-23 17:50:04
|
Randy Dunlap wrote:=0A=0A> I'd like to test gujin on a spare PC. Well, I h= ave installed=0A> Linux on it, but it's OK if it gets trashed.=0A>=0A> Howe= ver, I didn't create a small partition for gujin.=0A> >From reading the FAQ= , it seems that I need to do that.=0A> Is that correct?=0A=0A I assume that= Gujin is working for you, i.e you have installed it=0Aon a floppy, a USB k= ey or a CDROM and it does what you want;=0Aso (as a next step) you want to = install it on your hard drive.=0A Basically, Gujin just needs the first sec= tor of the disk (MBR) or=0Afirst sector of an active partition, plus some s= pace in a filesystem.=0A The filesystem could be anything but only FAT is i= mplemented=0Aright now (by lack of time), and because I am used to only use= =0Aa B.E.E.R. partition (containing a FAT) to install Gujin.=0A The B.E.E.R= . partition can be very small, some disk partition=0Amanagement systems lea= ve few hundred Kbytes to few Mbytes=0Aat end of the drive by default and th= at is enough for Gujin.=0A Then, you just need to boot Linux and type as ro= ot:=0A./instboot boot.bin /dev/hda0=0A if you want to install on disk /dev/= hda. It will automatically search=0Afor some free space at end of the disk = to create this B.E.E.R.partition,=0Aand if correctly found will ask you to = confirm before writing to the=0Adisk. If you say "yes" the installer will s= et up the end of the disk=0A(creating a small FAT partition there) and the = install finish=0Ausually without any problem.=0A The main advantage of the = B.E.E.R. partition is that it does not=0Atake a slot in the partition table= .=0A My advise is to use the previous system by default, often you just=0An= eed to reduce the last partition by one or two cylinder, easy if that=0Apar= titon is for swap space.=0A=0A Note the "-hx" option of instboot which desc= ribe usual installations.=0A=0A> And then this device (/dev/hda4)=0A> ./ins= tboot boot.img /dev/hda4=0A> ~~~~~~~~~=0A> refers to th= e special gujin partition? Is that right?=0A> (so that I need to go reinst= all Linux and create that partition)=0A=0ANow if you have an empty slot in = your partition table (primary or extended),=0Awith some free space on your = disk, like /dev/hda4, you can use it.=0ANote that it is not a "special guji= n partition", there isn't such a thing,=0Abut the installer create a FAT fi= lesystem, inserting a bootloader;=0Ayou will be able to use that FAT filesy= stem anyway you like after creation.=0A=0A> Q2. Does gujin have scriptable= capabilities? E.g., with=0A> lilo, I can build a new kernel, copy it to /= boot, and tell=0A> lilo to boot the new kernel *one time only* on the next = boot=0A> (-R option). This makes installing & booting a new kernel=0A> ver= y safe, which is important when doing lots of kernel builds=0A> and testing= . I suppose another way to ask this is:=0A> can I tell gujin to boot a spe= cific kernel on the next boot?=0A> and can that be in effect only one time?= =0A=0A To create a one-shoot only boot process, you need write access=0Ato = the hard disk (to store that you have booted once), and Gujin=0Acan be conf= igured to not write at all (by default).=0A In fact, because it is so easy = to select which kernel to boot, I never=0Aneeded this function.=0A I have i= n between 3 and 7 Linux distribution on the same PC, the work=0Apartition h= as up to 10 different kernel version at the same time, so=0AI like to keep = the boot process simple and select which kernel with=0Athe mouse.=0A=0A> Q3= . Does gujin work on x86_64 systems?=0A=0ACannot test, I do not have x86_6= 4.=0A=0A> Q4. What does "hda0" in the FAQ refer to? Linux doesn't use=0A>= that naming scheme.=0A> Oh, that's the BEER partition. Is that required?= =0A> (I could probably answer that by reading the FAQ or install.txt,=0A> b= ut install.txt seems much too rambling IMO.)=0A=0A The B.E.E.R. partition i= s not needed (and you will not use that=0Aon a USB key, a CDROM or a floppy= ) but that is what I use=0Aas default on a hard disk, because it is simpler= - as described=0Apreviously.=0A Either write down better bootloader or mor= e docs, I am more=0Ainterested by better code; moreover people ask me to co= mpare=0Awith Grub or LILO and I did not use any other bootloader than mine= =0Afor the last 5 years - so I can't compare.=0A=0A> Q5. Several examples = in install.txt use "boot.img" as a filename.=0A> Is that supposed to be "bo= ot.bin"?=0A=0A Yes, thanks I will correct. I have changed the extension in = Makefile=0Aaround version 0.6.=0A=0A> Thanks,=0A> ---=0A> ~Randy=0A=0A Than= ks for testing Gujin,=0A Etienne.=0A=0A=0A=09=0A=0A=09=0A=09=09=0A_________= __________________________________________________________________ =0AD=E9c= ouvrez une nouvelle fa=E7on d'obtenir des r=E9ponses =E0 toutes vos questio= ns ! =0AProfitez des connaissances, des opinions et des exp=E9riences des i= nternautes sur Yahoo! Questions/R=E9ponses =0Ahttp://fr.answers.yahoo.com |
|
From: Randy D. <rd...@xe...> - 2007-01-23 01:20:25
|
Hi,
I'd like to test gujin on a spare PC. Well, I have installed
Linux on it, but it's OK if it gets trashed.
However, I didn't create a small partition for gujin.
>From reading the FAQ, it seems that I need to do that.
Is that correct?
And then this device (/dev/hda4)
./instboot boot.img /dev/hda4
~~~~~~~~~
refers to the special gujin partition? Is that right?
(so that I need to go reinstall Linux and create that partition)
Q2. Does gujin have scriptable capabilities? E.g., with
lilo, I can build a new kernel, copy it to /boot, and tell
lilo to boot the new kernel *one time only* on the next boot
(-R option). This makes installing & booting a new kernel
very safe, which is important when doing lots of kernel builds
and testing. I suppose another way to ask this is:
can I tell gujin to boot a specific kernel on the next boot?
and can that be in effect only one time?
Q3. Does gujin work on x86_64 systems?
Q4. What does "hda0" in the FAQ refer to? Linux doesn't use
that naming scheme.
Oh, that's the BEER partition. Is that required?
(I could probably answer that by reading the FAQ or install.txt,
but install.txt seems much too rambling IMO.)
Q5. Several examples in install.txt use "boot.img" as a filename.
Is that supposed to be "boot.bin"?
Thanks,
---
~Randy
|
|
From: <ebi...@xm...> - 2001-08-14 15:55:02
|
Etienne Lorrain <eti...@ya...> writes: > --- "Eric W. Biederman" <ebi...@xm...> a =E9crit=A0: > > Etienne Lorrain <eti...@ya...> writes: > > > If someone wants to change it completely, he will > > > have to rewrite tools which are accessing this structure (rdev) and > > > also the bootloaders which are setting up fields into it already. > > > This will involve re-coding real-mode i8086 assembly, and there is l= ess > > > and less people knowing how to do it. > >=20 > > True. However for the moment I am up for making this kind of change. > > rdev needs to be recoded anyway as it is not portable. We need a rdev > > like tool to attach a command line and a ramdisk to arbitrary linux > > kernels. >=20 > I am from the old Unix school, I like text - so IMHO this could go in > a string, like "root=3D/dev/hda3 initrd=3Dinitrd-3.gz". That is why I pr= oposed > to put that string in the "comment" field of the gzip file (see RFC). > Unfortunately right now there is no tool to set up this field, but all t= he > uncompression tools seems to treat correctly (skip) this field if presen= t. > Is there someone against it? Is there a software (like the "znote" > for pkzip) available on Internet to set the comment field of a gz file? If you are going with gzip. That definentily sounds like a good strategy. =20 > > > My main problem is the order the things are done: First load compres= sed > > > files at defined addresses, then call a kernel function which callba= ck > > > the BIOS, then uncompress files. > >=20 > > How is this a problem. Is it the error handling or something else? >=20 > I hate to destroy random memory content and then ask to the lower > layers to behave correctly. For instance I used a DOS debugger to find > some of my bugs - it is not possible if the memory at 0x100000 has been > overwritten. Even simply my logger/debugger (writing information in a > log file under DOS) can not work. There is sense it that. Having a way to do all reasonable of the error checking up front and then going forward with running the kernel. > > I like the fact that the kernel decompresses itself. This is one less > > thing that the bootloader doesn't have to do. And allows the > > compression scheme to be changed at least theoretically. >=20 > I need the decompressor. People will want icons to clic on for Linux, > and I plan to uncompress them with my gunzip. Maybe one day I will even > compress a part of my bootloader, for instance the different language > messages or even part of the code. Note that this ungzip-er is very smal= l, > 5 Kb for the one in 0.4, 4.5 Kb for the current one - and in some cases > do not even need a 32 Kb memory window, unlike the real zlib. > Keep in mind that this bootloader may one day go to the EEPROM of a > network card (32 Kb max) or in the empty FLASH area of the BIOS... > Also have a look at the memory requirement of bzip2, few Mb... O.k. I'll definentily have to have a look at it then. The gunzip code I have seems to have been larger. =20 > > Why does Gujin need to do the decompression? Is this simply for > > better error checking, and error handling? >=20 > Also, the CRC32 calculation is nearly the only way to guaranty that you > have a real kernel - and did not do any error in loading the file. The > usual problems I am waiting here is to load wrong sectors because I have > a bug in the CHS description of the disk, or I have read a corrupted sec= tor > because the floppy had bad sectors and the ECC correction did a bad job. O.k. That is one area where you are definentily ahead of me. I have been playing with some kind of checksum but I haven't yet. =20 > > > Once Gujin has started, I have a complete C environment so I can load > > > files, treat errors, display messages. I can do this either from cold > > > boot or from DOS (think of the first install of Linux on a system). > >=20 > > This definentily sounds nice. Do you envision the setup code > > returning to the bootloader if a fatal error occurs? >=20 > Even more, I envision running GPL maintenance software - and return to > the bootloader at the end because this software did take care to not > modify memory below 1Mb. > For instance I have corrected a small bug in the bootloader (first stage) > because I had a sector to read on the HD - and this sector cannot be read > at the first time (needs a 0x20 - read with retry - IDE command, > a 0x21 - read without retry - return "uncorrected ECC error") and I was > not waiting enough for the ECC correction to finnish its task. > Because one of the main feature of e2fs is to not fragment files, you > will never run an unfragmenter, so there will (probably) be more and > more sectors which will need ECC correction each time they are read. > What is then needed is a small application displaying the ratio of > block needing ECC correction and maybe just read and rewrite them > to optimise the system. >=20 > > > This interface would still not handle a distribution where there is > > > few kernel files: > > > /boot/Linux-2.4.8-SMP > > > /boot/Linux-2.4.8-UP > > > /boot/Linux-2.4.8-386 > > > /boot/Linux-2.4.8-Pentium > > > And the bootloader should just select automagically the right kernel. > >=20 > > At this port I have linux booting from linux so what I would do is > > load /boot/Linux-2.4.8-i386 and then from linux select the right > > kernel modify the bootloader parameters, and boot the optimal kernel. >=20 > IHMO a bit complex, managing the command line parameters for the two > kernels (like ide addresses, scsi disk order...) Oh it can get complex, but if all you want to do is to invoke another kernel with exactly the same options you were invoked with it is a simple thing to do. > > > Moreover, going from a simple solution (loading the binary image of > > > an ELF file) to a complex one (as described) to solve problem which > > > may appear in the future is not my way of thinking: it is already > > > complex enought to do simple software. > >=20 > > I believe it can be done much more simply. And I think I can make the > > time to get it done, over the long term. I can do with an ELF > > binary, not it's binary ala objdump -O binary I can do what you > > propose to do with concatenated GZIP files. And with that I don't > > need decompression code in the bootloader.=20 >=20 > For me, I choose to load a GZIP because its format is trivial enough > to extract, and a "objdump -O binary" because I do not want to do the > loading part of an ELF file.=20 For purposes of a loading a binary the ELF program header simply says load this chunk of file to this chunk of memory. So while it is a touch more complex then a GZIP header it is simpler than a whole gzip file. With ELF I have so far implemented 3 bootloaders, that can handle it which allows me to boot arbitrary kernels. > GZIP is also used for initrd, so you need > it if you want to check the integrity what you have loaded. > You can try any other method you want, I can't say I never did a > wrong choice. Where I have been focusing is on network booting, and booting in small environments without a BIOS. And for those having the option to package the kernel and ramdisk, and the command line together is important, as is the option to reduce size by using a different compression algorithm. Which is my primary reason for wanting to include the decompressor with the kernel, and require the bootloader to use it. That isn't all of my comments but I need to run off to work now. Later, Eric |
|
From: <eti...@ya...> - 2001-08-14 11:06:29
|
--- "Eric W. Biederman" <ebi...@xm...> a écrit : > Etienne Lorrain <eti...@ya...> writes: > > If someone wants to change it completely, he will > > have to rewrite tools which are accessing this structure (rdev) and > > also the bootloaders which are setting up fields into it already. > > This will involve re-coding real-mode i8086 assembly, and there is less > > and less people knowing how to do it. > > True. However for the moment I am up for making this kind of change. > rdev needs to be recoded anyway as it is not portable. We need a rdev > like tool to attach a command line and a ramdisk to arbitrary linux > kernels. I am from the old Unix school, I like text - so IMHO this could go in a string, like "root=/dev/hda3 initrd=initrd-3.gz". That is why I proposed to put that string in the "comment" field of the gzip file (see RFC). Unfortunately right now there is no tool to set up this field, but all the uncompression tools seems to treat correctly (skip) this field if present. Is there someone against it? Is there a software (like the "znote" for pkzip) available on Internet to set the comment field of a gz file? > > My main problem is the order the things are done: First load compressed > > files at defined addresses, then call a kernel function which callback > > the BIOS, then uncompress files. > > How is this a problem. Is it the error handling or something else? I hate to destroy random memory content and then ask to the lower layers to behave correctly. For instance I used a DOS debugger to find some of my bugs - it is not possible if the memory at 0x100000 has been overwritten. Even simply my logger/debugger (writing information in a log file under DOS) can not work. > I like the fact that the kernel decompresses itself. This is one less > thing that the bootloader doesn't have to do. And allows the > compression scheme to be changed at least theoretically. I need the decompressor. People will want icons to clic on for Linux, and I plan to uncompress them with my gunzip. Maybe one day I will even compress a part of my bootloader, for instance the different language messages or even part of the code. Note that this ungzip-er is very small, 5 Kb for the one in 0.4, 4.5 Kb for the current one - and in some cases do not even need a 32 Kb memory window, unlike the real zlib. Keep in mind that this bootloader may one day go to the EEPROM of a network card (32 Kb max) or in the empty FLASH area of the BIOS... Also have a look at the memory requirement of bzip2, few Mb... > Why does Gujin need to do the decompression? Is this simply for > better error checking, and error handling? Also, the CRC32 calculation is nearly the only way to guaranty that you have a real kernel - and did not do any error in loading the file. The usual problems I am waiting here is to load wrong sectors because I have a bug in the CHS description of the disk, or I have read a corrupted sector because the floppy had bad sectors and the ECC correction did a bad job. > > Once Gujin has started, I have a complete C environment so I can load > > files, treat errors, display messages. I can do this either from cold > > boot or from DOS (think of the first install of Linux on a system). > > This definentily sounds nice. Do you envision the setup code > returning to the bootloader if a fatal error occurs? Even more, I envision running GPL maintenance software - and return to the bootloader at the end because this software did take care to not modify memory below 1Mb. For instance I have corrected a small bug in the bootloader (first stage) because I had a sector to read on the HD - and this sector cannot be read at the first time (needs a 0x20 - read with retry - IDE command, a 0x21 - read without retry - return "uncorrected ECC error") and I was not waiting enough for the ECC correction to finnish its task. Because one of the main feature of e2fs is to not fragment files, you will never run an unfragmenter, so there will (probably) be more and more sectors which will need ECC correction each time they are read. What is then needed is a small application displaying the ratio of block needing ECC correction and maybe just read and rewrite them to optimise the system. > > This interface would still not handle a distribution where there is > > few kernel files: > > /boot/Linux-2.4.8-SMP > > /boot/Linux-2.4.8-UP > > /boot/Linux-2.4.8-386 > > /boot/Linux-2.4.8-Pentium > > And the bootloader should just select automagically the right kernel. > > At this port I have linux booting from linux so what I would do is > load /boot/Linux-2.4.8-i386 and then from linux select the right > kernel modify the bootloader parameters, and boot the optimal kernel. IHMO a bit complex, managing the command line parameters for the two kernels (like ide addresses, scsi disk order...) > > Moreover, going from a simple solution (loading the binary image of > > an ELF file) to a complex one (as described) to solve problem which > > may appear in the future is not my way of thinking: it is already > > complex enought to do simple software. > > I believe it can be done much more simply. And I think I can make the > time to get it done, over the long term. I can do with an ELF > binary, not it's binary ala objdump -O binary I can do what you > propose to do with concatenated GZIP files. And with that I don't > need decompression code in the bootloader. For me, I choose to load a GZIP because its format is trivial enough to extract, and a "objdump -O binary" because I do not want to do the loading part of an ELF file. GZIP is also used for initrd, so you need it if you want to check the integrity what you have loaded. You can try any other method you want, I can't say I never did a wrong choice. Etienne. ___________________________________________________________ Do You Yahoo!? -- Vos albums photos en ligne, Yahoo! Photos : http://fr.photos.yahoo.com |
|
From: <eti...@ya...> - 2001-08-10 14:06:05
|
--- Giacomo Catenazzi <ca...@ma...> a écrit : > Etienne Lorrain wrote: > > These two files in memory have also to be at fixed linear > > addresses in real mode - and if you have a memory manager > > (himem.sys) loaded, these address may not be free. Usually > > you will find at the bottom of the himem memory the smartdrv > > (disk cache) data. It is then impossible to load a file at a random > > memory address and stay in real mode to do futher processing. > > In this case, Gujin is just malloc'ing the memory (using himem.sys), > > loading and decompressing this file (checking its CRC32), and > > only then disable interrupts, switch to protected mode, copy > > the file at its intended linear address and jump to the kernel > > code. > > > > hmm. > > You say: BIOS/hardware can be broken, let use DOS do load Linux! There are ISA/PCI cards which are initialised before the first sector of the HD/FD is loaded (SCSI, network boot ROM or special devices), but it is true that they are not usually using memory at 0x100000. I have just done this relocation thinking that it may be nice to be able to load a kernel over the 16 Mbytes limit - to free a maximum of space to the 16 Mb DMA-able area (if DMA is 16 Mb only) - but that is stuff for the future because the kernel would be linked at another address. I applied this late-relocation in case of himem. > IMHO using DOS (himem.sys and letting DOS to setting our > hardware in ibmbio.com and ibmdos.com) give us more problem > that solution! I am not able to open the A20 gate in all the ways himem.sys can, objdump will be your friend here. Note that Linux has never booted on such a special machine - using I/O ports 0x329 or 0x320 to open A20 - I just leave the door open to run from DOS/win, even for beginner who do not know what is himem/emm386 - or people wanting to remote boot Linux from a DOS/win machine getting vmlinuz from the network. > We should have complete control to hardware, not letting DOS > to hide/modify the BIOS segment 0040:0000 and some other > hardware setting. So Gujin will boot from an IDE HD not supported by the BIOS, on a VGA card without BIOS (or nearly: see VGA_MEMORY compile switch). It can also do what loadlin does - I do not want to maintain two identical software. > Thus we should (if possible) use only BIOS call (or directly hardware), > but forget DOS. (BTW you know what DOS makes before himem.sys ? > Do we have the sources?) Forget DOS/Win - what a dream... Can I join your dream? Etienne. ___________________________________________________________ Do You Yahoo!? -- Vos albums photos en ligne, Yahoo! Photos : http://fr.photos.yahoo.com |
|
From: Giacomo C. <ca...@ma...> - 2001-08-10 13:02:55
|
Etienne Lorrain wrote: > These two files in memory have also to be at fixed linear > addresses in real mode - and if you have a memory manager > (himem.sys) loaded, these address may not be free. Usually > you will find at the bottom of the himem memory the smartdrv > (disk cache) data. It is then impossible to load a file at a random > memory address and stay in real mode to do futher processing. > In this case, Gujin is just malloc'ing the memory (using himem.sys), > loading and decompressing this file (checking its CRC32), and > only then disable interrupts, switch to protected mode, copy > the file at its intended linear address and jump to the kernel > code. > hmm. You say: BIOS/hardware can be broken, let use DOS do load Linux! IMHO using DOS (himem.sys and letting DOS to setting our hardware in ibmbio.com and ibmdos.com) give us more problem that solution! We should have complete control to hardware, not letting DOS to hide/modify the BIOS segment 0040:0000 and some other hardware setting. Thus we should (if possible) use only BIOS call (or directly hardware), but forget DOS. (BTW you know what DOS makes before himem.sys ? Do we have the sources?) giacomo |
|
From: <eti...@ya...> - 2001-08-10 12:31:33
|
hpa wrote: > Etienne wrote: > > - Loads Linux kernel images (zImage and bZimage) without the help > > of LILO, and short-circuit all real-mode code in the kernel to > > start at the first protected mode instruction of the kernel. > > This is a very bad idea. The kernel entry point is in real mode for a > reason: it means that the kernel doesn't have to rely on the boot > loader to provide the services it needs from real mode before > entering protected mode once and for all. The interface to the real > mode entry point is narrow and stable, the protected mode entrypoint > is a kernel internal and doesn't have an interface that is guaranteed > to be stable -- again, for good reason. Thanks for the constructive criticism, now it is time to explain why I did it this way - it is far to be the simplest solution. First, I need to say that the Linux current interface is really stable: if you define "BOOT_KERNEL_BEFORE_2_0" in vmlinuz.[ch], Gujin will be able to boot pre- 1.0 Linux versions. Also, Gujin has always booted kernels this way. Considering the kernel interface to the bootloader, I find it is IMHO a bit complex: you not only have to give parameters in memory (at 0x9000:0000 or at %esi on 2.4.1+) but also provide callbacks (BIOS calls) for quite a lot of things. Alan Cox described it (incompletely) in his message in june, subject "draft BIOS use document for the kernel" at: http://marc.theaimsgroup.com/?l=linux-kernel&m=99322719013363&w=2 You also have to put in memory one or two compressed files (kernel and initrd) without any way to check if those hundred of Kbytes have been correctly read and are not corrupted. There will be no way - if an error is detected by the legacy loader at the decompression stage - to return to the bootloader saying: Fatal error, please select another kernel. These two files in memory have also to be at fixed linear addresses in real mode - and if you have a memory manager (himem.sys) loaded, these address may not be free. Usually you will find at the bottom of the himem memory the smartdrv (disk cache) data. It is then impossible to load a file at a random memory address and stay in real mode to do futher processing. In this case, Gujin is just malloc'ing the memory (using himem.sys), loading and decompressing this file (checking its CRC32), and only then disable interrupts, switch to protected mode, copy the file at its intended linear address and jump to the kernel code. Then, with the "old" method to load the kernel, you have the video selection menu. Well, it is a bit complex a thing to do in a bootloader, and its interface is complex (not speaking of the user interface), considering that you have already written everywhere in memory without knowing if (for instance) a video driver was loaded. All the video selection stuff has be to handled before selecting a kernel to load, IMO. I could probably find other problem, but I do not want to do destructive criticism. What do I propose? Lets put is simply: - The kernel file is a simple binary image to load at 0x100000, so you get it from the linux ELF file by just doing: objcopy -O binary -R .note -R .comment -S /usr/src/linux/vmlinux kernel gzip -9 kernel There is absolutely no limit on its size. - The initrd (if present) is a gzip of a filesystem image. - All information needed by the kernel is set in memory. It is clearly described on a C structure (vmlinuz.h::struct linux_param). This structure contains also (for reference) old fields which are no more used, or fields which were used only by previous bootloader. The is _no_ BIOS callback. - The hardware is setup correctly, for instance for the current video mode - if you are in graphic 8 BPP - the 256 color palette is set up with reasonnable values independant of the video card. Basically, hardware is immediately useable by the kernel. - There is a compatibility mode to load vmlinuz/zImage/bzImage. Note that all this is coded and working (I hope so). I know that with this solution, the bootloader and the kernel are more linked together, but I know also that the bootloader has to be a lot more intelligent (considering the number of related messages in the Linux lists). It should not try to load a Pentium compiled kernel on a 486. It should setup the video card (so be ready to get "invalid instruction exceptions" while executing BIOS calls). It should not try to run a corrupted kernel. It should not crash if a kernel/initrd file has been moved or two hard disks have been exchanged. It should display clear messages on what is wrong. It is up to the bootloader to crash if one BIOS call modify one register which is documented as constant (if it did not take care) - and in DEBUG mode send some informations to a serial/parallel port. When a new buggy BIOS appear, it is up to the bootloader to be upgraded, not to the Linux kernel. In short it is a real and complete software which handle all/most of the (buggy) BIOSes in their natural environment: the i386 real mode. If there is few fields to add to "struct linux_param" (really unusual from history), then Gujin will be upgraded. Anyway it is GPL - and written in C so there is a lot of people around able to change it, unlike assembly code. It is not as clean as described because of the APM / ACPI / PCI configuration BIOS32 calls; but that did not change by the Gujin bootloader. Note also that the SMP tables are passed in memory. One last thing I have to add (for people who have read up to here), is that having removed the "header" of the vmlinuz file, I lack the only important parameter in this header: the root device (rdev command). Right now, I am guessing it in a lot of configurations, but that is not a perfect solution. I think one of the simplest way is to add a "root=/dev/hd**" in the described comment field of the GZIP header; that is still not coded. From the same area, there is no way to know if a kernel will be able to boot in graphic mode (support of VESA framebuffer and which BPP are available). If vesafb is not compiled in and you start the kernel in graphic, the kernel boots but the display is like a crash... Right now the dirty way is the write-protect bit of the vmlinuz file - not a long term solution. Comment anyone? Etienne. ___________________________________________________________ Do You Yahoo!? -- Vos albums photos en ligne, Yahoo! Photos : http://fr.photos.yahoo.com |
9 messages has been excluded from this view by a project administrator.