Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-amd64
Navigation:
Lists: gentoo-amd64: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-amd64@g.o
From: dustin@...
Subject: Re: Amoeba file system
Date: Sun, 8 Apr 2007 09:53:32 -0500
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@g.o mailing list


Replies:
Re: Amoeba file system
-- Peter Humphrey
Re: Amoeba file system
-- Peter Humphrey
References:
Amoeba file system
-- Peter Humphrey
Re: Amoeba file system
-- Peter Humphrey
Re: Amoeba file system
-- dustin
Re: Amoeba file system
-- Peter Humphrey
Navigation:
Lists: gentoo-amd64: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Amoeba file system
Next by thread:
Re: Amoeba file system
Previous by date:
Re: Amoeba file system
Next by date:
chipset temperatures?


Updated Jun 17, 2009

Summary: Archive of the gentoo-amd64 mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.