Comparison between lilo and grub

[Steve]

Hello all,

I'm not subscribed to this list, so will view through the archives.

I've been asked to do a comparison between the two. Although I realize 
probably that Grub is better for larger hard-drives I don't really have 
any ammuntion to prove that's it has better features.

This is for my boss btw.

Any pros and cons would be appreciated.

Thanks.

-- 
Stephen - Toronto


___
Bug-grub mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-grub

grub vs lilo

[Steve]

Hello,

I asked this question before and didn't receive any response.

Can the learned folks here provide me with a comparison between the two?


-- 
Steve


___
Bug-grub mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-grub

Re: grub vs lilo

[Steve]

On Mon, 29 Jan 2001, Shaun Savage wrote:

> HI
>
> I am not an expert BUT I will try to answer your question with what I
> have found.
>
> The big difference is LILO uses a sector map while grub uses filesystem
> access.  This means that grub is self  configuring.  Every time you make
> changes to lilo you have to run the command 'lilo', grub does it at boot
> time.
>
> Grub supports network booting, lilo does not.
>
> lilo has a better user interface, it can support splash screens, quiet
> boot,...  Grub has command line or ncurses menu.  The caveat, it grub is
> more flexible. you can change things at boot time lilo you can not.
>
> The are other issues that I have not thought of or don't know, but I
> hope it helps.
>
> Conclusion:
> Grub is more powerful and flexible, but for non-users users lilo is
> simpler and looks better.

Great - thanks Shaun.

-- 
Steve


___
Bug-grub mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-grub

Re: grub vs lilo

[Steve]

On Thu, 1 Feb 2001, Dave Cinege wrote:

> Kuno Woudt wrote:
> >
> > Dave Cinege <[EMAIL PROTECTED]> writes:
> >
> > > I completly disagree. Grub's conf file is simple and initutive and I've never
> > > seen any type of boot menu for lilo. (No I don't mean holding the
> > > tab key.)
> > The boot menu for grub is nice for new users, but rather annoying if
> > you reboot a lot -
>
> The timeout is adjustable...
>
> > selecting an os using cursor keys is fairly slow
> > compared to typing the name of the OS to boot (well, when you use two
> > letter acronyms for all boot options ;) or is there a hotkey command
> > for menu.lst I overlooked ?
>
> Entry numbers would be a nice addition.

Appreciate all the information from everyone who replied to this thread.

-- 
Steve


___
Bug-grub mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-grub

How do I try out, and then possibly install, new kernels?

[steve]

Good day, my friends :)
    I have a question, and because I 
genuinely want to learn, please have mercy on me if it sounds stupid :)  I 
have installed the version of GRUB that ships with Red Hat Linux 7.2 and I was 
wondering, are there different instructions I must follow if I want to 
experiment with new kernels, or do I just use the Kernel How-To?  I tried 
to find the information before I wrote this, please either E-Mail me the answer, 
or just send me a link to the answer.
 
Thank you very much for your help :)
Steven P. Ulrick

bug with mandrake - 9.1RC2

[steve]

Hi,

I have an issue with the last RC release of mandrake (with their rescue 
mode), I got this:
/dev/ram3 doesn't have any corresponding BIOS drive

I think, this should be hidden (maybe it is a grub problem?)

Hope that helps,

Steve 



___
Bug-grub mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-grub

[bug #64376] error: file '/grub/x86_64-efi/normal.mod' not found.

[Steve]

Follow-up Comment #2, bug #64376 (project grub):

I have this issue as well on latest grub 2:2.06.r591.g6425c12cd-1 and I do not
have encryption enabled .. It happens every time I run grub-install command..
Error image attached...

(file #54910)

___

Additional Item Attachment:

File name: GrubError.png  Size:124 KB




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64376] error: file '/grub/x86_64-efi/normal.mod' not found.

[Steve]

Follow-up Comment #3, bug #64376 (project grub):

Sorry forgot to mention OS..

OS: Arch Linux latest
Link: https://archlinux.org/packages/core/x86_64/grub/


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64376] error: file '/grub/x86_64-efi/normal.mod' not found.

[Steve]

Follow-up Comment #4, bug #64376 (project grub):

Here to report issue is still present on grub 2:2.12rc1-1


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64376] error: file '/grub/x86_64-efi/normal.mod' not found.

[Steve]

Follow-up Comment #5, bug #64376 (project grub):

I found a strange issue with XFS filesystem when used for `/boot`. Out of
<100%> it fails to install grub with the Calamares installer. However when the
commit ef7850c757fb3dd2462a512cfa0ff19c89fcc0b1 (fs/xfs: Fix issues found
while fuzzing the XFS filesystem) gets reverted installing on XFS `/boot`
works. You can reproduce it 100% with this ISO and a positive result is
possible with that ISO. Also not that installing it locally sometimes fails
also but not so often

Here are the ISOs same exact ISO only difference is one is using modded Grub
with commit reverted and the other unmodded grub from upstream...

Unmodded original
https://xerolinux.xyz/iso/dev/xerolinux-oem.iso

Modded ISO :
https://xerolinux.xyz/iso/dev/xerolinux-modded.iso


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64376] error: file '/grub/x86_64-efi/normal.mod' not found.

[Steve]

Follow-up Comment #6, bug #64376 (project grub):

Hello,

Due to a formatting error am posting again.. 

I found a strange issue with XFS filesystem when used for `/boot`. Out of
<100%> it fails to install grub with the Calamares installer. However when the
commit ef7850c757fb3dd2462a512cfa0ff19c89fcc0b1 (fs/xfs: Fix issues found
while fuzzing the XFS filesystem) gets reverted installing on XFS `/boot`
works. You can reproduce it 100% with this ISO and a positive result is
possible with that ISO. Also not that installing it locally sometimes fails
also but not so often

Here are the ISOs same exact ISO only difference is one is using modded Grub
with commit reverted and the other unmodded grub from upstream...

Unmodded original
https://xerolinux.xyz/iso/dev/xerolinux-oem.iso

Modded ISO :
https://xerolinux.xyz/iso/dev/xerolinux-modded.iso

Distro Base : ArchLinux


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Grub XFS normal.mod not found error

[Steve]

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 a result of this, not really ideal now is it ?


Kindly update us on the situation and ETA for fix.. 


--

Best Regards.

---
N: Steve, Chaanine
P: Hardware specialist / IT support

[bug #64821] grub-install reports "error: unknown filesystem."

[Steve]

URL:
  <https://savannah.gnu.org/bugs/?64821>

 Summary: grub-install reports  "error: unknown filesystem."
   Group: GNU GRUB
   Submitter: greatsun
   Submitted: Thu 26 Oct 2023 03:57:08 PM UTC
Category: Installation
Severity: Major
Priority: 5 - Normal
  Item Group: Software Error
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Release: other
 Release: 
 Discussion Lock: Any
 Reproducibility: Every Time
 Planned Release: None


___

Follow-up Comments:


---
Date: Thu 26 Oct 2023 03:57:08 PM UTC By: Steve 
Hi all,

following base of the issue was found:

Basic setup/situation:
1. A computer installed with Windows 11 Pro before, UEFI boot
2. Booting from Debian 12 and running installation
3. When getting to grub-installation the error occured

Error source:
For me it looks like it tries to look into the other "registered" items in the
EFI BOOT and looks into the boot/configured devices for those somehow. As it
is not able to find the proper devices/partitions with the defined
filesystems, it errors as described.

Solution (for me):
Delete the Windows files from EFI directory.
Afterwards everything runs smoothly.

Fix Suggestion (could also be done differently for sure):
If probing for other OSs and issues found, don't stop execution and if
possible name a proper error.


Hope this helps.







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64821>

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64821] grub-install reports "error: unknown filesystem."

[Steve]

Follow-up Comment #1, bug #64821 (project grub):

Forgot to mention the actual version: grub-install (GRUB) 2.06-13


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

1024 cylinder bios limit fix

[Bovy, Steve]

Is it possible for a boot loader to fix/patch the pc-bios
to get rid of stupid 1024 cylinder bios limit once and
for all !!! 

How to add append statements

[Steve Davis]

Have a PC that requires the mem= append statement in lilo to recognize
it's ram.  Is there a way to do this in Grub?

Thx

Config problem

[Steve Sutton]

I've had a quick look through the archives, but I haven't seen this
mentioned before (although there was a recent reference to printf - not
the same thing I think).   Anyway, FYI:-

I have discovered that as supplied in the tarball, grub 0.5.96.1 is
incorrectly configured (by the configure script) on my system.  ncurses.h
is reported as missing by the script (and other curses files), because the
test compilation performed by the script with my ncurses results in
errors:-

In file included from configure:2361:
/usr/include/curses.h:360:9: warning: "GCC_PRINTF" is not defined
/usr/include/curses.h:366:9: warning: "GCC_SCANF" is not defined

I don't know if this is a problem with my version of ncurses, or if
ncurses is supposed to behave like that.  I'm using ncurses as installed
by default by RedHat Linux 7, id string:-

/* $Id: curses.h.in,v 1.94 2000/07/29 16:25:05 tom Exp $ */
#define NCURSES_VERSION_MAJOR 5
#define NCURSES_VERSION_MINOR 1
#define NCURSES_VERSION_PATCH 2730

gcc version: 2.96
binutils version (as reported by ld) 2.10.90

Having manually fixed up the config.h, grub seems to compile ok (although
the above compiler warnings appear frequently).  Also, I frequently get
the following message:-
../stage2/shared.h:247:43: warning: nothing can be pasted after this token

Having said all that, I did get grub to compile ok, and installed and
running :)

Please let me know if you need any more information, or there is anything
else that I can do to help.
-- 
Steve


___
Bug-grub mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-grub

GRUB Hassles

[Steve Porter]

Hi All,

Serious help required if poss.

We have an IBM Netfinity 5000 RH7.2 Linux box with a RAID5 subsystem.
Walked in Monday morning with no access i.e. one drive (of three) was
defunct and the logical drive was critical.  

Reinstalled a new drive, RAID5 rebuilt and now Grub cannot load.  It comes
up with Error 25: Disk Read Error - have done some searches and have tried
command lining Grub to no avail.  Any pointers or suggestions?

I have typed as per the grub.conf:
root (hd0,0)
kernel /boot/vmlinuz-2.4.9-31 ro root=/dev/sda1

However, as soon as I try to access /boot it gives me the Error 25: Disk
Read Error - I can however see other parts of the filesystem through grub
i.e. confgifile /

Any help would be appreciated

Thanks

Steve

___
Bug-grub mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-grub

GRUB Manual

[Steve Holmes]

Where should I send a suggestion for the GRUB manual?

The only address I can find in the manual is this one.

Thanks


___
Bug-grub mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-grub

Suggestion for addition to GRUB Manual

[Steve Holmes]

ts of the
manual to find other sections that you may need, such Error Messages, the
FAQ, etc.
= = = end = = =


I hope the above is technically correct, but I'm not 100% sure about the
procedure for building a new sytem or bootable floppy - is there anything
more to it? - I haven't tested that part. Please correct my mistakes or
omissions.
I have tested this procedure to get my Red Hat system disk images to be
bootable. I use PowerQuest Drive Image 5 which can resize ext2 partitions,
enabling images to non-identical disks, but when imaging to a destination
disk (eg:hd1/hdb) with a different geometry from the source (eg: hd0/hda), I
have to reinstall GRUB to the MBR of the image to make it bootable.

First I tried running: '/sbin/grub; root (hd1,0); setup (hd1); quit' (from
my original/source sys disk hd0) while the image disk was still installed as
hd1 (where the image was made to it). But then when I made the image disk
the primary master hd0, it wouldn't run GRUB.
I eventually discovered that I must install GRUB with the image disk
installed as hd0, so of course it had to be installed from a GRUB floppy.
Now I know that, the process is very simple.
Its probably obvious to you, and maybe its somewhere in the manual, but I
didn't find it.

Hope this is of some use.

Regards
Steve Holmes


___
Bug-grub mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-grub

Problem with pxegrub installation

[Steve Johnson]

Hi,

We are currently trying to do pxegrub installation for our whitebox4 systems. 
I have installed the latest diskless patches to incorporate the latest e1000 
and tg3 network card drivers.

The DHCP and TFTP servers properly send the pxegrub and grub.conf file to the 
PXE client, but the problem is that when we try to send the kernel, the TFTP 
server gets connection refused error messages from the clients.

Here is the output from the logs:
=
Jun 13 14:23:55 nc dhcpd: DHCPDISCOVER from 00:11:43:de:76:3e via eth0
Jun 13 14:23:55 nc dhcpd: DHCPOFFER on 10.160.1.195 to 00:11:43:de:76:3e via 
eth0
Jun 13 14:23:57 nc dhcpd: DHCPREQUEST for 10.160.1.195 (10.160.1.10) from 
00:11:43:de:76:3e via eth0
Jun 13 14:23:57 nc dhcpd: DHCPACK on 10.160.1.195 to 00:11:43:de:76:3e via 
eth0
Jun 13 14:23:57 nc atftpd[498]: Serving /tftpboot/pxegrub to 10.160.1.195:2070
Jun 13 14:23:57 nc atftpd[498]: Serving /tftpboot/pxegrub to 10.160.1.195:2071
Jun 13 14:25:09 nc dhcpd: DHCPDISCOVER from 00:11:43:de:76:3e via eth0
Jun 13 14:25:09 nc dhcpd: DHCPOFFER on 10.160.1.195 to 00:11:43:de:76:3e via 
eth0
Jun 13 14:25:09 nc dhcpd: DHCPREQUEST for 10.160.1.195 (10.160.1.10) from 
00:11:43:de:76:3e via eth0
Jun 13 14:25:09 nc dhcpd: DHCPACK on 10.160.1.195 to 00:11:43:de:76:3e via 
eth0
Jun 13 14:25:09 nc atftpd[498]: Serving /boot/grub/grub.conf to 
10.160.1.195:2001
Jun 13 14:25:12 nc atftpd[498]: Serving /tftpboot/whitebox4/vmlinuz to 
10.160.1.195:2002
Jun 13 14:25:17 nc atftpd[498]: timeout: retrying...
Jun 13 14:25:17 nc atftpd[498]: recvmsg: Connection refused
Jun 13 14:25:17 nc atftpd[498]: tftpd_file.c: 926: recvfrom: Connection 
refused
Jun 13 14:25:22 nc atftpd[498]: Serving /tftpboot/whitebox4/vmlinuz to 
10.160.1.195:2003
Jun 13 14:25:22 nc atftpd[498]: recvmsg: Connection refused
Jun 13 14:25:22 nc atftpd[498]: tftpd_file.c: 926: recvfrom: Connection 
refused
Jun 13 14:25:43 nc atftpd[498]: Serving /tftpboot/whitebox4/vmlinuz to 
10.160.1.195:2004
Jun 13 14:25:43 nc atftpd[498]: recvmsg: Connection refused
Jun 13 14:25:43 nc atftpd[498]: tftpd_file.c: 926: recvfrom: Connection 
refused
Jun 13 14:26:23 nc atftpd[498]: Serving /tftpboot/whitebox4/vmlinuz to 
10.160.1.195:2005
Jun 13 14:26:23 nc atftpd[498]: recvmsg: Connection refused
Jun 13 14:26:23 nc atftpd[498]: tftpd_file.c: 926: recvfrom: Connection 
refused
Jun 13 14:27:43 nc atftpd[498]: Serving /tftpboot/whitebox4/vmlinuz to 
10.160.1.195:2006
Jun 13 14:27:43 nc atftpd[498]: recvmsg: Connection refused
Jun 13 14:27:43 nc atftpd[498]: tftpd_file.c: 926: recvfrom: Connection 
refused
Jun 13 14:30:21 nc atftpd[498]: Serving /tftpboot/whitebox4/vmlinuz to 
10.160.1.195:2007
Jun 13 14:30:21 nc atftpd[498]: recvmsg: Connection refused
Jun 13 14:30:21 nc atftpd[498]: tftpd_file.c: 926: recvfrom: Connection 
refused
Jun 13 14:35:38 nc atftpd[498]: Serving /tftpboot/whitebox4/vmlinuz to 
10.160.1.195:2008
Jun 13 14:35:38 nc atftpd[498]: recvmsg: Connection refused
Jun 13 14:35:38 nc atftpd[498]: tftpd_file.c: 926: recvfrom: Connection 
refused
===

Does anyone have any idea as to what could be causing this, or how this could 
be solved? Any hint is appreciated.

Thanks,
Steve Johnson


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

FreeBSD network install using PXEGrub

[Steve Finkelstein]

Hi all,

I have successfully implemented a solution to install FreeBSD over the
network using pxeboot and Alfred's guide on;

http://people.freebsd.org/~alfred/pxe/en_US.ISO8859-1/articles/pxe/article.html

I'm trying to take this further one step by allowing the installation
of various supported operating systems over the network using pxegrub.
 I was wondering if anyone was successful using
dhcp+tftp+pxegrub/nbgrub to successfully bootstrap a FreeBSD system?

My issue originally declares itself once trying to chainload another bootloader,

  Booting 'FreeBSD 4.11 PXE'  
  
kernel
/tftpboot/boot/loader 
  
 Error 24: Attempt to
access block outside partition
  
   Press any key to continue...

my dhcp options look okay,

##For PXE BSD 4.11 get it from pxe1
next-server x.x.x.x ;
option root-path "x.x.x.x:/usr/local/export/pxe";
filename "grub/pxegrub";
}

My apologies ahead of time if this is better suited on a Grub mailing
list;  I was hoping some of the experts here have also simulated a
similar solution.

Thanks again and happy holidays!

Best,

--
Steve Finkelstein
[EMAIL PROTECTED]


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

Fw: "partnew" Command Writes Wrong Ending Cylinder in MPT

[Steve Burtchin]

- Original Message - 
From: "adrian15" <[EMAIL PROTECTED]>
To: "sburtchin" <[EMAIL PROTECTED]>
Sent: Saturday, December 23, 2006 10:03 AM
Subject: Re: "partnew" Command Writes Wrong Ending Cylinder in MPT


> sburtchin escribió:
>
> > I would like to propose the following code change to allow blanking of a
> > partition table entry
> > with a command like "partnew (hd0,3) 0x00 0 0".  New/Changed code is in
> > bold.
> >
> >/* Convert a LBA address to a CHS address in the INT 13 format.  */
> >auto void lba_to_chs (int lba, int *cl, int *ch, int *dh);
> >void lba_to_chs (int lba, int *cl, int *ch, int *dh)
> >  {
> >int cylinder, head, sector;
> >
> >if (lba <= 0)
> >{
> >  *cl = 0;
> >  *ch = 0;
> >  *dh = 0;
> > }
> > else
> > {
> >  sector = lba % buf_geom.sectors + 1;
> >  head = (lba / buf_geom.sectors) % buf_geom.heads;
> >  cylinder = lba / (buf_geom.sectors * buf_geom.heads);
> >
> >  if (cylinder >= buf_geom.cylinders)
> >   cylinder = buf_geom.cylinders - 1;
> >
> >  *cl = sector | ((cylinder & 0x300) >> 2);
> >  *ch = cylinder & 0xFF;
> >  *dh = head;
> >}
> >  }
>
> Hi sburtchin,
>
> Sorry about the late answer I've been very busy with Super Grub Disk and
> university lately.
>
> Currently grub legacy source code is frozen. Developers only work on
> grub2 which promises to be smarter and better than grub legacy.
>
> I am however working on a kind of grub legacy fork named Super Grub Disk.
>
> You have proposed us a source code change. Have you tried it yourself or
> were not you able to build a grub floppy or cdrom with the changes?
>
> I can build a SGD cdrom with the changes if you want to and you can try
> yourself to see if it works ok or not.
>
> About the bug do you think that if we write:
>
>if (cylinder >= buf_geom.cylinders)
>  cylinder = buf_geom.cylinders - 1;
>
> like this:
> // cylinders correction
> buf_geom.cylinders+=2;
> if (cylinder >= buf_geom.cylinders)
>  cylinder = buf_geom.cylinders - 1;
>
> we will fix the bug?
>
>
>
>
>
> adrian15



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

Fw: "partnew" Command Writes Wrong Ending Cylinder in MPT

[Steve Burtchin]

- Original Message - 
From: "adrian15" <[EMAIL PROTECTED]>
To: "sburtchin" <[EMAIL PROTECTED]>
Sent: Sunday, January 21, 2007 7:07 AM
Subject: Re: "partnew" Command Writes Wrong Ending Cylinder in MPT


> Did you receive this email?
>
> adrian15
>
> sburtchin escribió:
>
> > I would like to propose the following code change to allow blanking of a
> > partition table entry
> > with a command like "partnew (hd0,3) 0x00 0 0".  New/Changed code is in
> > bold.
> >
> >/* Convert a LBA address to a CHS address in the INT 13 format.  */
> >auto void lba_to_chs (int lba, int *cl, int *ch, int *dh);
> >void lba_to_chs (int lba, int *cl, int *ch, int *dh)
> >  {
> >int cylinder, head, sector;
> >
> >if (lba <= 0)
> >{
> >  *cl = 0;
> >  *ch = 0;
> >  *dh = 0;
> > }
> > else
> > {
> >  sector = lba % buf_geom.sectors + 1;
> >  head = (lba / buf_geom.sectors) % buf_geom.heads;
> >  cylinder = lba / (buf_geom.sectors * buf_geom.heads);
> >
> >  if (cylinder >= buf_geom.cylinders)
> >   cylinder = buf_geom.cylinders - 1;
> >
> >  *cl = sector | ((cylinder & 0x300) >> 2);
> >  *ch = cylinder & 0xFF;
> >  *dh = head;
> >}
> >  }
>
> Hi sburtchin,
>
> Sorry about the late answer I've been very busy with Super Grub Disk and
> university lately.
>
> Currently grub legacy source code is frozen. Developers only work on
> grub2 which promises to be smarter and better than grub legacy.
>
> I am however working on a kind of grub legacy fork named Super Grub Disk.
>
> You have proposed us a source code change. Have you tried it yourself or
> were not you able to build a grub floppy or cdrom with the changes?
>
> I can build a SGD cdrom with the changes if you want to and you can try
> yourself to see if it works ok or not.
>
> About the bug do you think that if we write:
>
>if (cylinder >= buf_geom.cylinders)
>  cylinder = buf_geom.cylinders - 1;
>
> like this:
> // cylinders correction
> buf_geom.cylinders+=2;
> if (cylinder >= buf_geom.cylinders)
>  cylinder = buf_geom.cylinders - 1;
>
> we will fix the bug?
>
>
>
>
>
> adrian15
>



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

Fw: I've Coded a New GRUB Function - What Do I Do Next?

[Steve Burtchin]

- Original Message - 
From: "adrian15" <[EMAIL PROTECTED]>
To: "sburtchin" <[EMAIL PROTECTED]>
Sent: Sunday, January 21, 2007 7:14 AM
Subject: Re: I've Coded a New GRUB Function - What Do I Do Next?


> sburtchin wrote:
> > I have created a new GRUB command line function (eptedit) and written a
patch
> > to an existing GRUB function (partnew).  What's the next step?  How do I
get
> > these compiled and linked so I can start using them?  What do I need to
do
> > to get these into the official GRUB distribution?
> >
> > The new code can be found in the following threads on this forum:
> >
> > How To Write Extended Partition Tables from GRUB?
> >
> > "partnew" Command Writes Wrong Ending Cylinder in MPT
> >
> > Please help me with the details so I can start using my new functions.
> > Thank you!
>
> Humm...
>
>  From the source code folder root type make
>
> This should give you some files on stage2/ which are:
> stage2, stage1, stage1_5_e2fs
>
> and
>
> then you can install grub with these files manually to test it.
> I think it is explained on grub faq. It consists on copying the files on
> a /boot/grub/ folder and issuing root and setup commands so that they
> get installed.
>
> Do not hesitate to ask me for more details.
>
> You might be interested on Super Grub Disk source code that automatises
> the compilation for the creation of a cdrom or a floppy and once you see
> it works on a cdrom... you build the final stage2 and stage1_5 for hard
> disks.
>
> adrian15



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

Fw: "partnew" Command Writes Wrong Ending Cylinder in MPT

[Steve Burtchin]

- Original Message - 
From: "Steve Burtchin" <[EMAIL PROTECTED]>
To: "adrian15" <[EMAIL PROTECTED]>
Sent: Thursday, January 25, 2007 4:14 PM
Subject: Re: "partnew" Command Writes Wrong Ending Cylinder in MPT


>
> - Original Message - 
> From: "adrian15" <[EMAIL PROTECTED]>
> To: "sburtchin" <[EMAIL PROTECTED]>
> Sent: Sunday, January 21, 2007 7:07 AM
> Subject: Re: "partnew" Command Writes Wrong Ending Cylinder in MPT
>
>
> > Did you receive this email?
> Yes.
>
> >
> > adrian15
> >
> > sburtchin escribió:
> >
> > > I would like to propose the following code change to allow blanking of
a
> > > partition table entry
> > > with a command like "partnew (hd0,3) 0x00 0 0".  New/Changed code is
in
> > > bold.
> > >
> > >/* Convert a LBA address to a CHS address in the INT 13 format.  */
> > >auto void lba_to_chs (int lba, int *cl, int *ch, int *dh);
> > >void lba_to_chs (int lba, int *cl, int *ch, int *dh)
> > >  {
> > >int cylinder, head, sector;
> > >
> > >if (lba <= 0)
> > >{
> > >  *cl = 0;
> > >  *ch = 0;
> > >  *dh = 0;
> > > }
> > > else
> > > {
> > >  sector = lba % buf_geom.sectors + 1;
> > >  head = (lba / buf_geom.sectors) % buf_geom.heads;
> > >  cylinder = lba / (buf_geom.sectors * buf_geom.heads);
> > >
> > >  if (cylinder >= buf_geom.cylinders)
> > >   cylinder = buf_geom.cylinders - 1;
> > >
> > >  *cl = sector | ((cylinder & 0x300) >> 2);
> > >  *ch = cylinder & 0xFF;
> > >  *dh = head;
> > >}
> > >  }
> >
> > Hi sburtchin,
> >
> > Sorry about the late answer I've been very busy with Super Grub Disk and
> > university lately.
> >
> > Currently grub legacy source code is frozen. Developers only work on
> > grub2 which promises to be smarter and better than grub legacy.
> >
> > I am however working on a kind of grub legacy fork named Super Grub
Disk.
> >
> > You have proposed us a source code change. Have you tried it yourself or
> > were not you able to build a grub floppy or cdrom with the changes?
> I did'nt know how.  I will have to read up on that.
>
> > I can build a SGD cdrom with the changes if you want to and you can try
> > yourself to see if it works ok or not.
> That would be ideal!
>
> > About the bug do you think that if we write:
> >
> >if (cylinder >= buf_geom.cylinders)
> >  cylinder = buf_geom.cylinders - 1;
> >
> > like this:
> > // cylinders correction
> > buf_geom.cylinders+=2;
> > if (cylinder >= buf_geom.cylinders)
> >  cylinder = buf_geom.cylinders - 1;
> >
> > we will fix the bug?
> >
> > adrian15
> >
> That would definitely provide a workaround to the bug on MY COMPUTER  (for
> the "partnew" command) provided "buf_geom.cylinders" is not used anywhere
> else (I don't think that it is, but its value may be).  "Fix" is a
stronger
> word implying that "buf_geom.cylinders" would be assigned the correct
value
> to begin with.  I still have'nt figured out how that gets assigned, or if
> its value gets used anywhere else that matters.  The data in the
"buf_geom"
> structure seems to get passed around quite a bit (eg. the "geometry"
> function reports 1021 cylinders also [here its the value of
> "geom.cylinders"], if that matters?).
>
> I suspect the source of the bug was a 'dirty' fix to some earlier bug.  A
> safer approach might be:
>
>
> int cylinder, head, sector, bufgeomcylinders;
>
>  bufgeomcylinders = buf_geom.cylinders
>  bufgeomcylinders+=2;
>  if (cylinder >= bufgeomcylinders)
>   cylinder = bufgeomcylinders - 1;
>
>
> leaving the "buf_geom" structure unchanged, and avoiding the potential of
> awakening that earlier bug.
>
> There are far too many global identifiers in GRUB legacy, adding greatly
to
> the risk that one bug fix will cause disastrous consequences somewhere
else.
> I am hoping that GRUB2 development will place a strong emphasis on
> identifier scope so that future bug fixes won't need a 'Band-Aid' solution
> or discussions about what is safe.  The other BIG advantage of keeping
> things local is that novices like me could contribute with a much quicker
> learning curve.  I hope I'm not being too critical, but the more well
> structured the code, the more people like me who want to contribute, can.
>



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

Fw: I've Coded a New GRUB Function - What Do I Do Next?

[Steve Burtchin]

- Original Message - 
From: "Steve Burtchin" <[EMAIL PROTECTED]>
To: "adrian15" <[EMAIL PROTECTED]>
Sent: Thursday, January 25, 2007 4:28 PM
Subject: Re: I've Coded a New GRUB Function - What Do I Do Next?


>
> - Original Message - 
> From: "adrian15" <[EMAIL PROTECTED]>
> To: "sburtchin" <[EMAIL PROTECTED]>
> Sent: Sunday, January 21, 2007 7:14 AM
> Subject: Re: I've Coded a New GRUB Function - What Do I Do Next?
>
>
> > sburtchin wrote:
> > > I have created a new GRUB command line function (eptedit) and written
a
> patch
> > > to an existing GRUB function (partnew).  What's the next step?  How do
I
> get
> > > these compiled and linked so I can start using them?  What do I need
to
> do
> > > to get these into the official GRUB distribution?
> > >
> > > The new code can be found in the following threads on this forum:
> > >
> > > How To Write Extended Partition Tables from GRUB?
> > >
> > > "partnew" Command Writes Wrong Ending Cylinder in MPT
> > >
> > > Please help me with the details so I can start using my new functions.
> > > Thank you!
> >
> > Humm...
> >
> >  From the source code folder root type make
> >
> > This should give you some files on stage2/ which are:
> > stage2, stage1, stage1_5_e2fs
> >
> > and
> >
> > then you can install grub with these files manually to test it.
> > I think it is explained on grub faq. It consists on copying the files on
> > a /boot/grub/ folder and issuing root and setup commands so that they
> > get installed.
> >
> > Do not hesitate to ask me for more details.
> OK - that's what I need to patch code to an existing function, but if I
want
> to create an entirely new function, there seems to be changes required in
a
> lot of places.  Details are in the thread "How To Write Extended Partition
> Tables from GRUB?".  That's where I really don't know how it all works
> together - (ie. to create a new function).
>
> >
> > You might be interested on Super Grub Disk source code that automatises
> > the compilation for the creation of a cdrom or a floppy and once you see
> > it works on a cdrom... you build the final stage2 and stage1_5 for hard
> > disks.
> I will read up on that.
>
> >
> > adrian15
>



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

Fw: I've Coded a New GRUB Function - What Do I Do Next?

[Steve Burtchin]

- Original Message - 
From: "adrian15" <[EMAIL PROTECTED]>
To: "Steve Burtchin" <[EMAIL PROTECTED]>
Sent: Friday, January 26, 2007 1:44 PM
Subject: Re: I've Coded a New GRUB Function - What Do I Do Next?


> Steve Burtchin wrote:
> > OK - that's what I need to patch code to an existing function, but if I
want
> > to create an entirely new function, there seems to be changes required
in a
> > lot of places.  Details are in the thread "How To Write Extended
Partition
> > Tables from GRUB?".  That's where I really don't know how it all works
> > together - (ie. to create a new function).
>
> Create a new function means making a new grub command?
>
> It is not so difficult, adding a line at the bottom of the builtins.c
> like &builtin_command in alphabetical order.
>
> And copying pasteing an existing one and changing its name on the two
> functions that define a grub command.
>
> Check find and findf grub commands in source code to see the difference.
>
> >>adrian15
>
> adrian15



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

Fw: How To Write Extended Partition Tables from GRUB?

[Steve Burtchin]

- Original Message - 
From: "Steve Burtchin" <[EMAIL PROTECTED]>
To: "adrian15" <[EMAIL PROTECTED]>
Sent: Thursday, February 01, 2007 11:51 PM
Subject: Re: How To Write Extended Partition Tables from GRUB?


>
> - Original Message - 
> From: "adrian15" <[EMAIL PROTECTED]>
> To: "sburtchin" <[EMAIL PROTECTED]>
> Cc: 
> Sent: Thursday, February 01, 2007 12:52 PM
> Subject: Re: How To Write Extended Partition Tables from GRUB?
>
>
> > sburtchin escribió:
> > > Another situation deals with data recovery.  If the partition tables
> happen
> > > to become corrupted, fixing these errors can be the first and best
step
> to
> > > data recovery.  There are tools for doing this, but a much quicker
> approach
> > > would be to add a "Restore All Partition Tables" selection to the GRUB
> menu.
> > > This is easily scripted in "menu.lst" using a combination of "partnew"
> and
> > > "eptedit" commands.
> > >
> > This restore All Partition Tables selection how would it be
implemented...
> >
> You would first have to get the information about your partitions.
> PowerQuest's PARTINFO will create a text file for you.  I created a
> spreadsheet because I have a lot of partitions (see attached image - the
> highlighted primary partitions are for the standard MPT, the rest can be
> swapped for the standard ones to boot other os's).  Then copy the data
into
> menu.lst and insert "partnew" and "eptedit" at the appropriate places (I
> would suggest converting partinfo.txt to a spreadsheet.  Then you can
select
> just the columns you need to put into menu.lst --- saving yourself a lot
of
> unnecessary editing).
>
> After a minimal amount of editing, my "Restore All Partition Tables"
section
> of menu.lst would be as in the attached text file.  Starting with the
> information from the spreadsheet, this took me about 15 minutes to create
> (first time), but now that I know how to do it, I could probably do it in
5.
>
> Selecting this boot item in the GRUB menu would do exactly what it says!
>
> > on the running system you run an script that saves all your partition
> > data into a menu.lst that uses that eptedit command and then...
> >
> You run a free (or other) program like PARTINFO and then you edit the
> information as explained above to create the boot item in menu.lst.
>
> > you can burn this menu.lst into a grub cdrom so that you can use
> >
> Yes!!! - if you can't access the menu.lst on the HDD.
>
> > FOR ONLY your computer in a future ?
> >
> Not exactly - Suppose you are managing an IT department and you want to
roll
> out 200 new computers all with identical HDD's.  You could partition all
of
> them in the time it takes to boot to CD and hit enter!  I know there are
> other ways of doing this (multicasting), but if later - any one of these
200
> computers would have its partition tables corrupted, you could restore all
> the partition tables just as fast.  I'm not aware of any other tools that
> would do it this fast.
>
> > Is that your idea ?
> >
> >
> > adrian15
> >
> That was not my idea at all originally, but I am excited to see that my
new
> function has a purpose that would interest others.  I actually only
thought
> of using it this way as an afterthought while I was explaining what I
wanted
> it for back on November 18.  Serendipity at work!
>
> I would definitely want to use it as in the attached text file if my
> partition tables were ever corrupted, but I originally wanted it so I
could
> define extended partitions with the same starting cylinder, but with
> different ending cylinders (because some older os's can only see the first
> 1024 cylinders - ref. my November 18 reply).
>


GRUB_demo_playstuff.png
Description: PNG image
title Restore All Standard Partition Tables & Boot Floppy0
partnew (hd0,0) 0x06 63 514017
partnew (hd0,1) 0xBB 5110560 6153840
partnew (hd0,2) 0x0F 11264400 137108160
partnew (hd0,3) 0xBF 148372560 40960080
eptedit (hd0,4) c 0x07 745 1 1 880 239 63 63 2056257
eptedit (hd0,4) n 0x05 881 0 1 1023 239 63 2056320 2162160
eptedit (hd0,5) c 0x07 881 1 1 1023 239 63 63 2162097
eptedit (hd0,5) n 0x05 1023 0 1 1023 239 63 4218480 4717440
eptedit (hd0,6) c 0x07 1023 1 1 1023 239 63 63 4717377
eptedit (hd0,6) n 0x05 1023 0 1 1023 239 63 8935920 1028160
eptedit (hd0,7) c 0x07 1023 1 1 1023 239 63 63 1028097
eptedit (hd0,7) n 0x05 1023 0 1 1023 239 63 9964080 6153840
eptedit (hd0,8) c 0x07 1023 1 1 1023 239 63 63 6153777
eptedit (hd0,8) n 0x05 1023 0 1 1023 239 63 16117920 5337360
eptedit (hd0,9) c 0x07 10

Fw: "partnew" Command Writes Wrong Ending Cylinder in MPT

[Steve Burtchin]

- Original Message - 
From: "Steve Burtchin" <[EMAIL PROTECTED]>
To: "adrian15" <[EMAIL PROTECTED]>
Sent: Friday, February 02, 2007 6:45 AM
Subject: Re: "partnew" Command Writes Wrong Ending Cylinder in MPT


>
> - Original Message - 
> From: "adrian15" <[EMAIL PROTECTED]>
> To: "Steve Burtchin" <[EMAIL PROTECTED]>
> Sent: Thursday, February 01, 2007 6:30 AM
> Subject: Re: "partnew" Command Writes Wrong Ending Cylinder in MPT
>
>
> > See the attached cdrom once in English cdrom press 'c' key and you'll
> > get a grub console from which you can run the new command:
> >
> > partnewbeta
> >
> Thanks, this worked great!
>
>
> > I've also attached the builtins.c file so that you search for the
> > partnewbeta string and see what you need to add a new command.
> >
> So I put my "epteditbeta" function code in the body of builtins.c and also
> add an entry for it in the "builtin" structure at the end of the file.
That
> is very straightforward.  The stuff I am unsure about is what has to be
put
> into "ChangeLog", "grub.texi ", "grub.info",  or other file and how it
gets
> there (see the attachment).  Some of this looks like it's needed.
>
> The only other question I had was the use of "entry" (see attached source
> code).
> In the lines:
>   /* Adjust for "current" or "next" slot.  */
>   if (ept_slot == 'n') entry++;
> Have I made the right assumption of how "entry" is used?
>
>
> > > The data in the "buf_geom"
> > > structure seems to get passed around quite a bit (eg. the "geometry"
> > > function reports 1021 cylinders also [here its the value of
> > > "geom.cylinders"], if that matters?).
> >
> > Do you mean geom.cylinders instead of buf_geom.cylinders ...
interesting.
> >
> Exactly.  It gets displayed here:
>
>   grub_printf ("drive 0x%x: C/H/S = %d/%d/%d, "
> "The number of sectors = %d, %s\n",
> current_drive,
> geom.cylinders, geom.heads, geom.sectors,
> geom.total_sectors, msg);
>
> I would bet that "&geom.cylinders" is the same as "&buf_geom.cylinders".
>
> > >  bufgeomcylinders = buf_geom.cylinders
> > >  bufgeomcylinders+=2;
> > >  if (cylinder >= bufgeomcylinders)
> > >   cylinder = bufgeomcylinders - 1;
> >
> > That's the patch that I have applied.
> > >
> > >
> > > leaving the "buf_geom" structure unchanged, and avoiding the potential
> of
> > > awakening that earlier bug.
> >
> > I do not agree with you but you may be right so I've applied your patch.
> >
> You would know better than me.  This is safest though, to leave the global
> "buf_geom.cylinders" alone.  Even if no earlier bug, at least there is no
> risk of creating a new bug.  It might have always maxed out at 1021 and
> never caused problem for anyone.  Possibly only a serious risk for a
> partition beginning or ending at cylinder 1022 or 1023 with the os using
CHS
> addressing.
>
>
> > You'll tell me if you have any problem.
> >
> > adrian15
> >
> I have tested thoroughly and the patched code always writes the correct
> starting/ending cylinder IMO.  I tested for all start/end cylinder values
> from 1019 thru 1024.
>
> There was another patch I had suggested for this function that you left
out
> of this beta.  This lets you zero out a whole slot in the MPT with a
command
> like: "partnew (hd0,3) 0x00 0 0".
>
>/* Convert a LBA address to a CHS address in the INT 13 format.  */
>auto void lba_to_chs (int lba, int *cl, int *ch, int *dh);
>void lba_to_chs (int lba, int *cl, int *ch, int *dh)
>  {
>int cylinder, head, sector;
>
> /* begin patch */
>   if (lba <= 0)
>{
>  *cl = 0;
>  *ch = 0;
>  *dh = 0;
> }
> else
> {
>
> /* end patch */
>  sector = lba % buf_geom.sectors + 1;
>  head = (lba / buf_geom.sectors) % buf_geom.heads;
>  cylinder = lba / (buf_geom.sectors * buf_geom.heads);
>
>  if (cylinder >= buf_geom.cylinders)
>   cylinder = buf_geom.cylinders - 1;
>
>  *cl = sector | ((cylinder & 0x300) >> 2);
>  *ch = cylinder & 0xFF;
>  *dh = head;
>
> /* begin patch */
>}
>
> /* end 

Re: How To Write Extended Partition Tables from GRUB?

[Steve Burtchin]

- Original Message - 
From: "Steve Burtchin" <[EMAIL PROTECTED]>
To: "adrian15" <[EMAIL PROTECTED]>
Sent: Thursday, February 01, 2007 11:51 PM
Subject: Re: How To Write Extended Partition Tables from GRUB?
.
.
.
.

> > FOR ONLY your computer in a future ?
> >
> Not exactly - Suppose you are managing an IT department and you want to
roll
> out 200 new computers all with identical HDD's.  You could partition all
of
> them in the time it takes to boot to CD and hit enter!  I know there are
> other ways of doing this (multicasting), but if later - any one of these
200
> computers would have its partition tables corrupted, you could restore all
> the partition tables just as fast.  I'm not aware of any other tools that
> would do it this fast.
>
> > Is that your idea ?
> >
> >
> > adrian15
> >
> That was not my idea at all originally, but I am excited to see that my
new
> function has a purpose that would interest others.  I actually only
thought
> of using it this way as an afterthought while I was explaining what I
wanted
> it for back on November 18.  Serendipity at work!
>
> I would definitely want to use it as in the attached text file if my
> partition tables were ever corrupted, but I originally wanted it so I
could
> define extended partitions with the same starting cylinder, but with
> different ending cylinders (because some older os's can only see the first
> 1024 cylinders - ref. my November 18 reply).
>
I am happy to report that eptedit now appears to be bug-free!

I will send the patch as soon as I complete some more extensive testing.

How do I get an official Bug-grub request number assigned?  I noticed that
many other topics have them, even when they are not bugs at all (eg. "bug
#17472: grub install on hd(0,0) permanently damages Windows bootloader".
This one is clearly user error and is easily recovered from, as admitted by
at least two of those involved in that topic.

The other question that has been nagging me is that most of our
correspondence is not getting into the Bug-grub forum.  Is there something
else I need to be doing, for example putting Bug-grub@gnu.org into the CC
list.  I use "Reply to All" in Outlook Express, but that does not happen
automatically.  I am forwarding all our previous correspondence there now
(just the ones without Bug-grub on the CC list).  I hope that helps.

sburtchin



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

[bug #19389] "partnew" Command Writes Unexpected/Errant CHS Values

[Steve Burtchin]

URL:
  <http://savannah.gnu.org/bugs/?19389>

 Summary: "partnew" Command Writes Unexpected/Errant CHS
Values
 Project: GNU GRUB
Submitted by: sburtchin
Submitted on: Friday 03/23/2007 at 05:46
Category: Disk & Partition
Severity: Major
Priority: 5 - Normal
  Item Group: Software Error
  Status: None
 Privacy: Public
 Assigned to: None
     Originator Name: Steve Burtchin
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Discussion Lock: Any
 Release: 0.97
 Reproducibility: Every Time
 Planned Release: 

___

Details:

*Firstly:* All problems described in this bug report have been solved and
thoroughly tested by me on my Compaq Deskpro EN.  For reference see "partnew"
Command Writes Wrong Ending Cylinder in MPT
<http://www.nabble.com/%22partnew%22-Command-Writes-Wrong-Ending-Cylinder-in-MPT-tf2599372.html>.
 I also want to thank *adrian15* for his help to get me started debugging
GRUB.

*Secondly:* Though seemingly related on the surface, I actually found two
entirely unrelated bugs in the "partnew" code.  Both have been solved by
changes to only the code within the "partnew" function.

= The Bugs =

0 The first problem has to do with the calculation of cylinder values for
large disks, *and* for partitions near the end of any size disk.  If a
partition begins or ends on the last or next-to-last cylinder, or past
cylinder 1021 on a large disk, "partnew" incorrectly calculates the cylinder
value to be the largest allowed value for the disk minus two.

For example, on my small disk with CHS 833/240/63:


partnew (hd1,1) 0x05 2071440 10508400


writes C/H/S 137/0/1 thru 830/239/63 (ending cylinder should be 831)

Another example, on my large disk with CHS 10587/240/63:


partnew (hd0,2) 0x0C 116575200 36136800


writes C/H/S 1021/0/1 thru 1021/239/63 (beginning and ending cylinder should
both be 1023)

This is actually a manifestation of another problem external to the "partnew"
function (I was not able to find it).  This is evident when I ask for
"geometry" from the GRUB command line:


>geometry (hd0) 
drive 0x80: C/H/S 1022/240/63, sectors=160086528, LBA 
Partition 0 -- fat - 0xb 
. 
. 

>geometry (hd1) 
drive 0x81: C/H/S 831/240/63, sectors=12594960, LBA 
Partition 0 -- fat - 0xb 
. 
. 


0 The second problem is that "partnew" does not properly handle parameters
equal to zero.  This situation arises when I want to create an 'Undefined'
partition to thoroughly hide it from aggressive operating system installers
(such as the NT os's which recognize filesystems regardless of what
filesystem type is assigned).

For example:


partnew (hd0,3) 0x00 0 0


writes C/H/S 0/0/1 thru 1021/164/4 (I expected C/H/S 0/0/0 thru 0/0/0)

= The Patches =

The complete patches to both problems can be found in the attached
"builtins.c" file.  This has been thoroughly validated by me on my Compaq
Deskpro EN.

0 The fix to the first problem is actually a 'dirty fix' in the sense that it
only covers up a more basic problem (see above).  This patch is a modification
to code suggested by *adrian15*:

Replace:

  /* beg old code
  if (cylinder >= buf_geom.cylinders)
cylinder = buf_geom.cylinders - 1;
  end old code */
  
  /* begin third part of sburtchin partnew patch (replace lines) */
  bufgeomcylinders = buf_geom.cylinders;
  bufgeomcylinders += 2;
  if (cylinder >= bufgeomcylinders)
cylinder = bufgeomcylinders - 1;
  /* end third part of sburtchin partnew patch */


0 The patch to correct the second problem is also only a minor change to the
code within the "partnew" function:


  /* begin second part of sburtchin partnew patch (add lines) */
  if (lba <= 0) 
  { 
*cl = 0; 
*ch = 0; 
*dh = 0; 
  } 
  else 
  { 
  /* end second part of sburtchin partnew patch */

  sector = lba % buf_geom.sectors + 1;
  head = (lba / buf_geom.sectors) % buf_geom.heads;
  cylinder = lba / (buf_geom.sectors * buf_geom.heads);

  bufgeomcylinders = buf_geom.cylinders;
  bufgeomcylinders += 2;
  if (cylinder >= bufgeomcylinders)
cylinder = bufgeomcylinders - 1;

  *cl = sector | ((cylinder & 0x300) >> 2);
  *ch = cylinder & 0xFF;
  *dh = head;

  /* begin fourth part of sburtchin partnew patch (add lines) */
  } 
  /* end fourth part of sburtchin partnew patch */


= What Next? =

I will do whatever I can to help get these changes into the GRUB Legacy code.
 Can someone help me get started writing *ChangeLog*?  Is there a template or
stand

[bug #19410] Unable to Create Logical Partition with "partnew" Command

[Steve Burtchin]

URL:
  <http://savannah.gnu.org/bugs/?19410>

 Summary: Unable to Create Logical Partition with "partnew"
Command
 Project: GNU GRUB
Submitted by: sburtchin
Submitted on: Sunday 03/25/2007 at 09:27
Category: Disk & Partition
Severity: Major
Priority: 5 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
     Originator Name: Steve Burtchin
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Discussion Lock: Any
 Release: 0.97
 Reproducibility: Every Time
 Planned Release: 

___

Details:

*First:* The problem described in this bug report has been solved (by
creating the "eptedit" function) and thoroughly tested by me on my Compaq
Deskpro EN. For reference see How To Write Extended Partition Tables from
GRUB?
<http://www.nabble.com/How-To-Write-Extended-Partition-Tables-from-GRUB--tf2594470.html>.

*Second:* I would have thought this to be a feature request, but . . . from
the GRUB Legacy Patch Submission Policy:

_"If your system is technically impossible to be booted only with existing
features and your patch addresses that problem, it is a bugfix."_

So maybe this is a bugfix - ??? - I'll let someone else decide that.

*Third:* If GRUB Legacy maintainers want to classify this as a new feature, I
will gladly volunteer my time to become a maintainer for the "eptedit"
function.

= Why I Need to Create Logical Partitions =

The attached files "PriMastr.png" and "SecMastr.png" show the partition
layouts for the three HDD's used in my flexible multiboot system.  What is
obvious is that there are much more than four Primary partitions defined for
each of the internal HDD's.  The highlighted Primary partitions are standard.
 The others can be swapped for the standard ones to address specific boot
situations.  Note also, that this multiboot includes at least two 'non-LBA
aware' operating systems, and that the standard Extended partition continues
past the 1024th cylinder.  The Extended partition on the second HDD also
contains three Logical partitions dedicated as 'scratchpads' for sharing data
between all operating systems, so it is essential that these three Logical
partitions are visible to all of them.  The only way this is possible without
risking the potential for data corruption, is to define a smaller Extended
partition for the 'non-LBA aware' operating systems.  I also want to have the
DOS5 and Win3.1 partitions contained within the Extended partition, rather
than defined as Primary partitions, because this makes it much more
convenient for making image backups (as opposed to creating a custom boot
configuration to image each OS partition).

= How It Will Be Used (Mostly, but see "Other Potential Uses") =

The attached file "mbr2std.png" shows what the MPT of the second HDD should
look like when booting most of the 'LBA aware' OS's.  In this situation, the
file "b15_std.png" shows the EPT that should be found at LBA 7680960.

The attached file "mbr2dos5.png" shows what the MPT of the second HDD should
look like when booting MS-DOS 5.0, and the file "mbr2Win3.png" shows what the
MPT of the second HDD should look like when booting Windows 3.1.  In these
situations, the file "b15_old.png" shows the EPT that should be found at LBA
7680960.  Note that the DOS5 and Windows 3.1 partitions are defined as both
Primary and Logical partitions in this configuration.  I could have redefined
the start of the Extended partition for these two OS's, but the documentation
was made simpler by just hiding the Logical definitions (this seems to have
no ill effects).

The most significance differences between these two situations is the size of
the Extended partition, and the EPT at LBA 7680960.  The "partnew" command is
used to fix the MPT.  The "eptedit" command is used to zero out the second
slot of the EPT at LBA 7680960 for booting MS-DOS 5.0 and Windows 3.1, and to
put the data back into this EPT for booting the 'LBA aware' OS's.  See the
file "MenuItms.txt" for excerpts from my "menu.lst".

You may be wondering why the "geometry" function is called within my
"menu.lst" file.  In the process of testing this new function, I discovered
another bug: GRUB apparently forgets at least some of the geometry
information.  When the "eptedit" function performs validation checks on some
of the input parameters, a check against invalid information in memory
results in "Error 18".  Issuing the "geometry" command refreshe

[bug #19410] Unable to Create Logical Partition with "partnew" Command

[Steve Burtchin]

Additional Item Attachment, bug #19410 (project grub):

File name: mbr2dos5.png   Size:3 KB
File name: mbr2Win3.png   Size:3 KB
File name: b15_old.pngSize:3 KB
File name: MenuItms.txt   Size:2 KB


___

Reply to this item at:

  

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



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

[bug #19410] Unable to Create Logical Partition with "partnew" Command

[Steve Burtchin]

Additional Item Attachment, bug #19410 (project grub):

File name: builtins.c Size:121 KB


___

Reply to this item at:

  

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



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

[bug #19389] "partnew" Command Writes Unexpected/Errant CHS Values

[Steve Burtchin]

Follow-up Comment #1, bug #19389 (project grub):

Added *ChangeLog* and attached patches in Unified Diff format for
_ChangeLog_, _/stage2/builtins.c_ and _/docs/grub.texi_.  

ChangeLog is repeated here for reference:

2007-04-11  Steve Burtchin  <[EMAIL PROTECTED]>

* stage2/builtins.c (partnew_func): Added new variable
"bufgeomcylinders" set equal to "buf_geom.cylinders" plus 2;
allows for correct calculation of cylinder value when near CHS
limit or near end of disk (for small disks).
* stage2/builtins.c (partnew_func): Added test "if (lba <= 0)...
...else" and new code to handle input values (relative and total
sectors) equal to zero; allows resetting a MPT slot to all zeroes.
* docs/grub.texi (partnew): Added instructions to zero slot in MPT.


*Is there anything else I need to do?*

NOTE: See bug #19410: Unable to Create Logical Partition with "partnew"
Command <https://savannah.gnu.org/bugs/?19410> for diff files containing both
patches combined.

(file #12488, file #12489, file #12490)
___

Additional Item Attachment:

File name: grub.texi.pn.diff  Size:0 KB
File name: ChangeLog.pn.diff  Size:1 KB
File name: builtins.c.pn.diff Size:1 KB


___

Reply to this item at:

  <http://savannah.gnu.org/bugs/?19389>

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



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

[bug #19410] Unable to Create Logical Partition with "partnew" Command

[Steve Burtchin]

Follow-up Comment #1, bug #19410 (project grub):

FOR REFERENCE: Attaching diff files containing patches for both of my changes
combined (see also bug #19389: "partnew" Command Writes Unexpected/Errant CHS
Values ) if anyone wants to look at
both together --- because they do compliment eachother.

(file #12492, file #12493, file #12494)
___

Additional Item Attachment:

File name: ChangeLog.both.diffSize:1 KB
File name: grub.texi.both.diffSize:2 KB
File name: builtins.c.both.diff   Size:8 KB


___

Reply to this item at:

  

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



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

[bug #19410] Unable to Create Logical Partition with "partnew" Command

[Steve Burtchin]

Follow-up Comment #2, bug #19410 (project grub):

Added *ChangeLog* and attached patches in Unified Diff format for
_ChangeLog_, _/stage2/builtins.c_ and _/docs/grub.texi_.

ChangeLog is repeated here for reference:

2007-04-11  Steve Burtchin  <[EMAIL PROTECTED]>

* stage2/builtins.c (eptedit_func): New function based mostly on
code derived from functions PARTNEW_FUNC and PARTTYPE_FUNC.
* stage2/builtins.c (builtin_eptedit): New variable.
* stage2/builtins.c (builtin_table): Added pointer to
BUILTIN_EPTEDIT
* docs/grub.texi (eptedit): Added entry to "Commands usable anywhere"
index, and added node for eptedit.


This function has been exhaustively tested.  I have been using it without
ever a problem on my 100GB Maxtor HDD for several months now.  All of the
"_Other Potential Uses for "eptedit"_" in my original post are practical with
possible exception of the last one (even that can be done with a few caveats
-- see following).

As promised, here are the results of my "partitioning a HDD" testing: The
attach file _LogicalCreationTest.lst_ was used to test partitioning a disk
from scratch.  The test HDD is a Fujitsu 6GB with 833 cylinders.  It was zero
filled with [EMAIL PROTECTED] prior to testing.  I found that *eptedit* will
write information to the 'Current' slot of any EPT as long as the sector
signature is present and any valid filesystem type is already there (it only
needs the sector signature to create the first logical partition).  *eptedit*
will write information to the 'Next' slot of any EPT as long as the sector
signature is present and any valid filesystem type is present in the
'Current' slot.  While testing on my small disk, it was *NOT* necessary to
reset the BIOS information with _geometry_ prior to writing a 'Next' slot (I
think this applies only to disks > 1024 cylinders).  In conclusion, *eptedit*
always found the correct sector for writing EPT data.  There are other ways to
partition disks, so I don't have any immediate plans to persue this further,
but if anyone is interested, it should be very easy to make it work.

*Is there anything else I need to do?*

What do I have to do to get the "eptedit" function into GRUB 2. Is it stable
enough yet that I can test it on my working computer? How do I get involved
with GRUB 2 development?

(file #12495, file #12496, file #12497, file #12498)
___

Additional Item Attachment:

File name: ChangeLog.ee.diff  Size:1 KB
File name: grub.texi.ee.diff  Size:2 KB
File name: builtins.c.ee.diff Size:6 KB
File name: LogicalCreationTest.lstSize:2 KB


___

Reply to this item at:

  <http://savannah.gnu.org/bugs/?19410>

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



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

[bug #19591] GRUB dual-boot configuration fails with Fedora Core 6

[Steve Burtchin]

Follow-up Comment #2, bug #19591 (project grub):

QOUTE:
_The same problem was observed with FC6 (kernel 2.6.20-1.2933.fc6) installed
on a new HDD with grub-0.97-13 and on an older PC where FC6 was installed on
the same HDD with grub-0.95-3 and FC3 (kernel 2.6.12-1.1381_FC3)._
ENDQUOTE

In my experience on my Compaq Deskpro EN the *map* command definitely did not
perform as described in the GRUB manual.  I found it to be very buggy.  The
disks were swapped or not swapped depending on how they were looked at.  With
some Microsoft operating systems, disks formatted when they were remapped were
only accessible when booted with the disks remapped.  Likewise when disks were
not remapped.  When swapped, Windows 98 would assign drive letters as
expected, then assign drive letters again to the same partitions as if the
disks had not been swapped (but applications still percieved the disks as
being swapped).

I have only ever used GRUB 0.97, but I am wondering if when you installed FC6
here, the grub-0.95-3 was possibly overwritten with 0.97.  From the
description of your problem, it sounds like upgrading to the latest version
of GRUB is what caused the problem to surface.  If this is the case, then I
suspect a bug was introduced into *map* since the version of GRUB supplied
with FC3.

Rather than use the *map* command to swap disks in BIOS, I have found it to
be much simpler and more reliable to boot Microsoft operating systems on
whatever BIOS device they are physically located without attempting to fool
them.  This is easily accomplished by changing the "Drive ID" in the boot
sector to the actual BIOS number for that disk.

At least on my computer, use of *makeactive* has been entirely
inconsequential for all Microsoft operating systems from DOS 5.0 thru Windows
2000.  Is it ever needed?  For what?

QUOTE
This system would dual boot until I performed a Microsoft Update
and a NAV LiveUpdate last week and rebooted (something I've done for months
and never had a problem with).
ENDQUOTE

I think you are referring to Norton Anti-Virus.  AV software may write
checksums, etc. anywhere on the HDD not normally used by a filesystem.  The
62 sectors following partition tables are usually free for proprietary uses
like this.  GRUB uses some of these sectors too.  Could be your AV has
overwritten part of the GRUB code.  Have you tried reinstalling GRUB?  From a
GRUB command line:


grub> root (hd#,#) --- ie. where the GRUB binaries are ("/boot/grub")
grub> setup (hd0)  --- assuming you want GRUB in the MBR


I'm not sure if this will install with your menu.lst.  You will have to read
up on that, or install from Linux.

___

Reply to this item at:

  

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



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

Re: [bug #19410] Unable to Create Logical Partition with "partnew" Command

[Steve Burtchin]

- Original Message - 
From: "Robert Millan" 
To: "Robert Millan" ; "Steve Burtchin"
; 
Sent: Saturday, December 15, 2007 5:47 PM
Subject: [bug #19410] Unable to Create Logical Partition with "partnew"
Command


>
> Update of bug #19410 (project grub):
>
>  Open/Closed:Open => Closed
>
> ___
>
> Follow-up Comment #3:
>
> We've moved to GRUB 2 as a development platform. Please can you check if
this
> bug still applies there, and if it does, reopen it?
>
> Thanks
>
> ___
>
> Reply to this item at:
>
>   <http://savannah.gnu.org/bugs/?19410>
>
> ___
>   Message sent via/by Savannah
>   http://savannah.gnu.org/


I was not able to reopen this bug report.  I was not able to post a comment
either.  Do I need to become a member of the GNU GRUB group?  Also, I think
the 'Item Group' should be "Feature Request".  I have already contacted
grub-devel with my intent to add new featues to GRUB2.

Please advise.  Thank you,

Steve Burtchin


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

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

[Steve McIntyre]

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. Let's revert it.
>> 
>> Everywhere or on a specific machines?
>
>I observed the issue on a TinkerBoard (Rockchip RK3288 CPU) and on
>qemu-arm-system -machine virt with the current Debian Buster GRUB.

Nod. I've seen similar in a qemu VM and on a Beaglebone Black. Leif's
aware and promised me he'd look when he's back from his travels.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"This dress doesn't reverse." -- Alden Spiess


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

[bug #57705] CHS partition parameters incorrect in grub2

[Steve Si]

URL:
  

 Summary: CHS partition parameters incorrect in grub2
 Project: GNU GRUB
Submitted by: stevesi
Submitted on: Fri 31 Jan 2020 09:07:19 AM UTC
Category: None
Severity: Major
Priority: 5 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 
 Release: 2.02
 Reproducibility: None
 Planned Release: None

___

Details:

see

https://github.com/a1ive/grub/commit/a645fede717ac2c48d12a23bfc6284b161101517#commitcomment-37038354

for details.

CHS values in the MBR partition table are incorrect.
Should be FE FF FF, not FF FF FF.






___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/