[gentoo-amd64] Amoeba file system

[gentoo-amd64] Amoeba file system

[Peter Humphrey]

For quite a while now, every time I've reinstalled a large batch of 
packages, such as in an emerge -e system, I've finished up with an 
unbootable system. I have /boot on /dev/hda1 and grub is also installed on 
that partition (I use Partition Magic to choose the partition to boot 
from).

The problem is that, having found problems with the 64-bit grub, I long ago 
got used to installing the 32-bit version, with "emerge --usepkg 
grub-static". That works fine, but because grub is in the world file it 
gets included in the wholesale reinstallation - but without the --usepkg 
parameter.

Today I finally traced the problem to emerging grub-static without 
the --usepkg parameter to emerge. Is this a bug worth reporting? I've fixed 
it pro tem (I hope) by deleting grub from /var/lib/portage/world.

-- 
Rgds
Peter Humphrey
Linux Counter 5290, Aug 93
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Amoeba file system

[Peter Humphrey]

On Saturday 07 April 2007 17:27:55 Peter Humphrey wrote:

> The problem is that, having found problems with the 64-bit grub, I long
> ago got used to installing the 32-bit version, with "emerge --usepkg
> grub-static". That works fine, but because grub is in the world file it
> gets included in the wholesale reinstallation - but without the --usepkg
> parameter.

What I should have finished by saying is that, after emerge grub-static, 
fdisk shows the boot partition /dev/hda1 as of type 0x92, Amoeba (whatever 
that is), and that Boot Magic can't recognise it and refuses to boot 
through it.

-- 
Rgds
Peter Humphrey
Linux Counter 5290, Aug 93
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Amoeba file system

[dustin]

On Sat, Apr 07, 2007 at 09:58:53PM +0100, Peter Humphrey wrote:
> What I should have finished by saying is that, after emerge grub-static, 
> fdisk shows the boot partition /dev/hda1 as of type 0x92, Amoeba (whatever 
> that is), and that Boot Magic can't recognise it and refuses to boot 
> through it.

Wait, you're saying that *emerging* grub-static is repartitioning your
drive?  I'm going to go out on a limb, without actually looking at the
grub ebuild, and say: no, no it's not.

I'm not familiar with why you'd need the grub-static package, instead of
just 'USE="static" grub', so I can't further answer your questions,
except to say that you should duplicate the conditions under which your
grub-static package was initially built by using /etc/portage/package.*,
and then put grub-static (and not grub) in your 'world'.

Dustin
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Amoeba file system

[Jean-Marc Hengen]

Hello,

a few comments on this topic:

You can simply emerge grub - as far as I know, grub is always build as
32bit-application! The kernel will change, while he is booting to the
64bit modus. This is how I have done it:

* sys-boot/grub
      Installed versions:  Version: 0.97-r3
                           Date:    15:03:53 01/16/07
                           USE:     -custom-cflags -netboot -static

You may see, I haven't enabled any use-flag. (Note, the processor does 
not start in 64bit modus, the application has to put it into this mode. 
This is done by the kernel.)

Is there any reason, why you need partion magic - I needed only cfdisk 
and that only once, when I created the different partitions. I also have 
a Windows XP installed. Everthings works fine. After update I do the 
following:
#grub
root (hd1,0) #Because linux doesn't really care, everything is on the
              #second drive. Windows has it's own drive, hd0, which help
              #to assure, that Windows is always installed on c - the
              #windows installation always thought, that my ext2 boot
              #partition is c, when Linux and Windows where installed on
              #the same drive.
setup (hd0) #bios will still look on hd0 for MBR, so grub-MBR-piece
             #goes there.
quit #and new grub will be used.

I'm only curious, you wrote about 64bit grub and 32bit grub - I hope you 
didn't install sys-boot/grub and sys-boot/grub-static at the same time. 
This would be a bad idea in my eyes. I hope, portage prevents someone 
from doing this. If you had installed both, that may be the source of 
your problem.

Jean-Marc
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Amoeba file system

[Peter Humphrey]

On Saturday 07 April 2007 22:27:08 dustin@v.igoro.us wrote:

> Wait, you're saying that *emerging* grub-static is repartitioning your
> drive?  I'm going to go out on a limb, without actually looking at the
> grub ebuild, and say: no, no it's not.

Watch this:

# fdisk -l /dev/hda
[...]
   Device Boot      Start         End      Blocks   Id  System
/dev/hda1   *           1           7       56196   83  Linux
[...]

# emerge grub-static
Calculating dependencies  ..... ..... ..... .... done!
>>> Verifying ebuild Manifests...

>>> Emerging (1 of 1) sys-boot/grub-static-0.97 to /
[...]
>>> sys-boot/grub-static-0.97 merged.
[...]
# fdisk -l /dev/hda

Disk /dev/hda: 80.0 GB, 80026361856 bytes
[...]
   Device Boot      Start         End      Blocks   Id  System
/dev/hda1               1           7       56196   93  Amoeba
[...]

Now I'm going to have to boot a CD and run fdisk to delete and 
re-create /dev/hda1, then chroot to the root partition and run grub to 
reinstall itself.

> I'm not familiar with why you'd need the grub-static package, instead of
> just 'USE="static" grub',

I haven't thought of doing that; perhaps I should try it. I used to use 
grub-static a few years ago when 64-bit grub had not yet been developed, in 
accordance with the standard installation instructions of the time; I 
suppose I've just stuck with it.

> ... you should duplicate the conditions under which your grub-static
> package was initially built by using /etc/portage/package.*, 
> and then put grub-static (and not grub) in your 'world'.

It turns out that 'world' does have grub-static, not grub. Sorry I was 
unclear about that. How would I arrange package.* to pass --usepkg to 
emerge? Maybe I won't have to if your suggestion works (USE=static emerge 
grub).

-- 
Rgds
Peter Humphrey
Linux Counter 5290, Aug 93
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Amoeba file system

[Duncan]

Peter Humphrey <prh@gotadsl.co.uk> posted
200704072158.54016.prh@gotadsl.co.uk, excerpted below, on  Sat, 07 Apr
2007 21:58:53 +0100:

>> The problem is that, having found problems with the 64-bit grub, I long
>> ago got used to installing the 32-bit version, with "emerge --usepkg
>> grub-static". That works fine, but because grub is in the world file it
>> gets included in the wholesale reinstallation - but without the
>> --usepkg parameter.
> 
> What I should have finished by saying is that, after emerge grub-static,
> fdisk shows the boot partition /dev/hda1 as of type 0x92, Amoeba
> (whatever that is), and that Boot Magic can't recognise it and refuses
> to boot through it.

OK, to get some things straight.

1)  There is no such thing as 64-bit grub.  It's 32-bit (or rather, 16-
bit, but compiled with 32-bit gcc, which handles 16-bit real-mode apps 
like grub too).  To compile grub on amd64, you need either a multilib 
system, or a 32-bit chroot with a 32-bit toolchain.  If you are running 
64-bit only, you can't compile grub because it needs either a 32-bit gcc 
or a multilib gcc to compile.

2)  The package called grub-static is a 32-bit pre-compiled binary.  
Nothing is compiled merging it, it just merges the pre-compiled binary.  
Thus, --use-package in theory has little effect on it because it's pre-
compiled in any case.  (The exception would be if the ebuild has changed 
without changing the version, or if a different version would be merged 
without --use-package.)

It would appear that loading a current grub into the boot-sector on that 
partition causes it to be detected as amoebafs for whatever reason.  Your 
existing package apparently doesn't have that reason, and you can boot 
thru it.

For the time being, I believe your fix (taking grub out of world so it 
doesn't try to merge) should work.

However, as Jean-Marc suggests, there's little reason to chain grub thru 
partition-magic's boot-manager, when grub should handle booting virtually 
anything (including but not limited to Linux, BSD, and the various MS-DOS 
and MSWormOS platforms) you need to boot directly.  Thus, why not install 
grub into the main hard drive boot sector directly, and do away with the 
Partition-Magic boot-manager?  Then you'd be able to clear it out of the 
partition's boot-sector, and not need to worry about it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Amoeba file system

[dustin]

On Sun, Apr 08, 2007 at 11:17:47AM +0100, Peter Humphrey wrote:
> Watch this:
> 
> # fdisk -l /dev/hda
> [...]
>    Device Boot      Start         End      Blocks   Id  System
> /dev/hda1   *           1           7       56196   83  Linux
> [...]
> 
> # emerge grub-static
> Calculating dependencies  ..... ..... ..... .... done!
> >>> Verifying ebuild Manifests...
> 
> >>> Emerging (1 of 1) sys-boot/grub-static-0.97 to /
> [...]
> >>> sys-boot/grub-static-0.97 merged.
> [...]
> # fdisk -l /dev/hda
> 
> Disk /dev/hda: 80.0 GB, 80026361856 bytes
> [...]
>    Device Boot      Start         End      Blocks   Id  System
> /dev/hda1               1           7       56196   93  Amoeba
> [...]

ok.. that's insane.  Looking at the ebuild, the only thing I see that
could do that is the call to grub itself, and it's probably a serious
bug, possibly writing a bit or byte to the wrong block of the drive.
This looks similar:
  http://www.computing.net/linux/wwwboard/forum/28589.html
I would suggest narrowing it down by running 'fsdisk' in the ebuild
directly before and after the grub invocation:
      
      fdisk -l /dev/hda; sleep 3
      /sbin/grub --batch \
            --device-map="${dir}"/grub/device.map \
            > /dev/null
      fdisk -l /dev/hda; sleep 3

and if that does, indeed, change the partition table, then file a bug
with the grub:
  http://www.gnu.org/software/grub/grub-legacy-bugs.en.html

> Now I'm going to have to boot a CD and run fdisk to delete and 
> re-create /dev/hda1, then chroot to the root partition and run grub to 
> reinstall itself.

So long as you don't restart, just running 'fdisk' and resetting the
type should do the trick.  The kernel won't recognize the change
immediately, but that's ok -- it will be written to disk (for better or
worse, this is exactly what grub's doing).  So you should be able to
test this without having to restart.

> I haven't thought of doing that; perhaps I should try it. I used to use 
> grub-static a few years ago when 64-bit grub had not yet been developed, in 
> accordance with the standard installation instructions of the time; I 
> suppose I've just stuck with it.

>From the look of the ebuild, there is no 64-bit version -- it builds a
32-bit version unconditionally.  I may be misreading that, though.

> It turns out that 'world' does have grub-static, not grub. Sorry I was 
> unclear about that. How would I arrange package.* to pass --usepkg to 
> emerge? Maybe I won't have to if your suggestion works (USE=static emerge 
> grub).

--usepkg just uses a previously compiled package somewhere on your
system.  My point was not to cause portage to automatically use that
package, but to cause it to recompile the package with exactly the same
parameters as those used to create the package.  You may have to
mask/unmask versions to lock into the right one.

Dustin
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Amoeba file system

[Peter Humphrey]

On Sunday 08 April 2007 10:40:56 Jean-Marc Hengen wrote:

> Is there any reason why you need Partition Magic?

1.	I have never yet found a way to tell grub to boot Win XP - it
	always either reboots endlessly, or stops after complaining
	that it can't find its boot loader.
2.	It's much easier to install other distros if they have their
	own boot partition to play in. SuSE, for instance, seems 
	to be unable to combine its own image with all the
	existing ones, so I have to go grubbing around the disks
	looking for images to make grub.conf entries.

> I'm only curious, you wrote about 64bit grub and 32bit grub - I hope you
> didn't install sys-boot/grub and sys-boot/grub-static at the same time.

No, I didn't fall into that trap. And you're right, the grub-static ebuild 
says:
DEPEND="!sys-boot/grub"

-- 
Rgds
Peter Humphrey
Linux Counter 5290, Aug 93
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Amoeba file system

[Peter Humphrey]

On Sunday 08 April 2007 15:53:32 dustin@v.igoro.us wrote:

> Looking at the ebuild, the only thing I see that could do that is the call
> to grub itself, and it's probably a serious bug, possibly writing a bit or
> byte to the wrong block of the drive. 

It's changing the file-system field from 0x83 to 0x93. Perhaps an XOR with 
0xC0. (My 1974 assembler days are showing!)

> This looks similar:
>   http://www.computing.net/linux/wwwboard/forum/28589.html

Hm. Perhaps, though I'd say it wasn't quite the same.

> I would suggest narrowing it down by running 'fsdisk' in the ebuild
> directly before and after the grub invocation:
>
>       fdisk -l /dev/hda; sleep 3

Actually, I used "fdisk -l /dev/hda; sleep 3 | \"; otherwise the script hung 
at that point.

>       /sbin/grub --batch \
>             --device-map="${dir}"/grub/device.map \
>
>             > /dev/null
>
>       fdisk -l /dev/hda; sleep 3

Ok, I tried that and the partition table was left untouched - the behaviour 
had changed by instrumenting it. So I deleted the first call to fdisk, 
remerged grub-static and got my problem back. Looks like we have (someone 
has) a timing problem.

> and if that does, indeed, change the partition table, then file a bug
> with the grub:
>   http://www.gnu.org/software/grub/grub-legacy-bugs.en.html

You don't think I should file a bug on gentoo first?

> > Now I'm going to have to boot a CD and run fdisk to delete and
> > re-create /dev/hda1, then chroot to the root partition and run grub to
> > reinstall itself.
>
> So long as you don't restart, just running 'fdisk' and resetting the
> type should do the trick.  The kernel won't recognize the change
> immediately, but that's ok -- it will be written to disk (for better or
> worse, this is exactly what grub's doing).  So you should be able to
> test this without having to restart.

A useful short-cut - thanks! What's more, it works.

> From the look of the ebuild, there is no 64-bit version -- it builds a
> 32-bit version unconditionally.  I may be misreading that, though.

I suppose what I meant was "the standard version that can be compiled on a 
multi-lib system that's mostly 64-bit", rather than a precompiled version 
(which is 32-bit).

Thanks for the help, Justin, Duncan and Jean-Marc.

-- 
Rgds
Peter Humphrey
Linux Counter 5290, Aug 93
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Amoeba file system

[Duncan]

Peter Humphrey <prh@gotadsl.co.uk> posted
200704091202.47469.prh@gotadsl.co.uk, excerpted below, on  Mon, 09 Apr
2007 12:02:47 +0100:

> I suppose what I meant was "the standard version that can be compiled on
> a multi-lib system that's mostly 64-bit", rather than a precompiled
> version (which is 32-bit).

Ahh... That makes more sense.  =8^)

That the issue seems to be a timing/race condition of some sort is 
interesting, but would explain why the issue seems so unusual.  No 
/wonder/ you can't find much else on what seemed like it should be a 
perfectly reproducible bug! Your system just falls in the wrong timing 
slot, it would seem. =8^(  I'm still wondering what the mechanism is, but 
this is a strange one, all right.  You should feel privileged that the 
fates favored you with something so unusual. =8^)  (Yeah, I know, about 
like those folks with the one in a million birth defect...  At least the 
computer isn't a part of your body you have to live with...)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Amoeba file system

[Wil Reichert]

On 4/9/07, Peter Humphrey <prh@gotadsl.co.uk> wrote:
> On Sunday 08 April 2007 10:40:56 Jean-Marc Hengen wrote:
>
> > Is there any reason why you need Partition Magic?
>
> 1.      I have never yet found a way to tell grub to boot Win XP - it
>         always either reboots endlessly, or stops after complaining
>         that it can't find its boot loader.

I've always just used the example provided by grub with no problems.
Going to guess here that your XP install isn't on the first partition
of the drive its on?  Seem to recall problems with that and grub
before.

Wil
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Amoeba file system

[Bob Sanders]

Peter Humphrey, mused, then expounded:

> 2.	It's much easier to install other distros if they have their
> 	own boot partition to play in. SuSE, for instance, seems 
> 	to be unable to combine its own image with all the
> 	existing ones, so I have to go grubbing around the disks
> 	looking for images to make grub.conf entries.
>

We do the following to boot multiple os':

   create a small partition on dev/sda1 that contains just

   /boot/grub/*
   in /boot/grub/menu.lst (or grub.conf):

# Imaging Environment grub configuration file
# Installs in to MBR of first disk, and allows
# chaning to the other boot options.
default 8
timeout 15
#serial --unit=1 --speed=38400 --word=8 --parity=no --stop=1
#terminal --timeout=10 --dumb serial console

title disk 1 slot 1 root /dev/sda2 image likely x86_64-rhel4u4
   # OS root device /dev/sda2
   root (hd0,1)
   rootnoverify (hd0,1)
   chainloader +1

title disk 1 slot 2 root /dev/sda3 image likely x86_64-rhel5-ga
   # OS root device /dev/sda3
   root (hd0,2)
   rootnoverify (hd0,2)
   chainloader +1

title disk 1 slot 3 root /dev/sda5 image likely x86_64-sles10-gmc
   # OS root device /dev/sda5
   root (hd0,4)
   rootnoverify (hd0,4)
   chainloader (hd0,0)/boot/grub/bootsect-xfs-sda5

title disk 1 slot 4 root /dev/sda6 image likely x86_64-sles9sp3-e1000
   # OS root device /dev/sda6
   root (hd0,5)
   rootnoverify (hd0,5)
   chainloader (hd0,0)/boot/grub/bootsect-xfs-sda6

etc...

Then install each dist in it's own partition with no individual /boot partition.
The chainloader then picks up the grub entry from that partition.  I do the same
with WinXP on my laptop for the few times I boot into that partition.

Typically, though, we only use parted to setup our partitions.  And a lot of the
time we set up our systems as GPT disks with labels.

Bob
-  
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Amoeba file system

[Peter Humphrey]

On Monday 09 April 2007 12:41:45 Duncan wrote:

> At least the computer isn't a part of your body you have to live with...)

It does no harm to remind myself of that occasionally :)

-- 
Rgds
Peter Humphrey
Linux Counter 5290, Aug 93
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Amoeba file system

[Peter Humphrey]

On Monday 09 April 2007 14:49:18 Wil Reichert wrote:

> Going to guess here that your XP install isn't on the first partition
> of the drive its on?  Seem to recall problems with that and grub
> before.

It's on /dev/hda3.

So anyway, that's why I stick with Boot Magic.

-- 
Rgds
Peter Humphrey
Linux Counter 5290, Aug 93
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Amoeba file system

[Peter Humphrey]

On Sunday 08 April 2007 15:53:32 dustin@v.igoro.us wrote:

> So long as you don't restart, just running 'fdisk' and resetting the
> type should do the trick.  The kernel won't recognize the change
> immediately, but that's ok -- it will be written to disk (for better or
> worse, this is exactly what grub's doing).  So you should be able to
> test this without having to restart.

In fact that didn't work at all well. At the time I was running fdisk it did 
appear to be doing as expected, but this morning when I came to start the 
system, grub's character set had been corrupted (or a pointer to it). I got 
just "GRUB " followed by half a line of graphics characters. So clearly, 
rather more than just the partition-type field is being overwritten.

I had to boot a CD, delete then re-create /dev/hda1, chroot to the installed 
system and run grub again to reinstall itself, just as I had been doing.

Before raising a bug report, I'm going to recompile the entire system 
with -O2 in place of the -Os that I have at the moment. I can't see how 
that could be causing this problem, but I want to be sure.

-- 
Rgds
Peter Humphrey
Linux Counter 5290, Aug 93
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Amoeba file system

[Peter Hoff]

[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]

It might actually be a Windows issue rather than a grub issue. Historically Windows has been really picky about being on /dev/hda1. I've heard rumors that newer versions are less picky about it, but then again I recall hearing rumors that you never needed to defrag ntfs, so...

I'd probably repartition and reinstall (maybe using disk images to minimize the pain). I also recall seeing somewhere bootloader settings that would trick Windows into thinking it was on /dev/hda1, but I can't recall where. It may have been back in the lilo days. tldp.org is never a bad place to look.


----- Original Message ----
From: Peter Humphrey <prh@gotadsl.co.uk>
To: gentoo-amd64@lists.gentoo.org
Sent: Monday, April 9, 2007 7:14:45 AM
Subject: Re: [gentoo-amd64] Amoeba file system


On Monday 09 April 2007 14:49:18 Wil Reichert wrote:

> Going to guess here that your XP install isn't on the first partition
> of the drive its on?  Seem to recall problems with that and grub
> before.

It's on /dev/hda3.

So anyway, that's why I stick with Boot Magic.

-- 
Rgds
Peter Humphrey
Linux Counter 5290, Aug 93
-- 
gentoo-amd64@gentoo.org mailing list

[-- Attachment #2: Type: text/html, Size: 1881 bytes --]