Re: [gentoo-amd64] Amoeba file system
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
[gentoo-amd64] Re: Amoeba file system
Peter Humphrey [EMAIL PROTECTED] posted [EMAIL PROTECTED], 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
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
[gentoo-amd64] chipset temperatures?
Hi, I have an Asus A8N-E motherboard which had a motherboard chipset fan go bad yesterday. After doing some reading I found many folks have had this same problem and switched successfully to Zalman passive heat sinks so I did the same thing today. The machine has been up for about 4 hours with no problems. So far so good My question is how can I monitor chipset temp from my my desktop to watch this for awhile? If I drop into BIOS I see a temperature listed and had to turn off boot time warnings about the chipset fan going to slow so it seems the BIOS knows what's going on. Is there a way for me to do this in Gnome? Thanks in advance, Mark -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] chipset temperatures?
On Sun, 2007-04-08 at 15:42 -0700, Mark Knecht wrote: Hi, I have an Asus A8N-E motherboard which had a motherboard chipset fan go bad yesterday. After doing some reading I found many folks have had this same problem and switched successfully to Zalman passive heat sinks so I did the same thing today. The machine has been up for about 4 hours with no problems. So far so good My question is how can I monitor chipset temp from my my desktop to watch this for awhile? If I drop into BIOS I see a temperature listed and had to turn off boot time warnings about the chipset fan going to slow so it seems the BIOS knows what's going on. Is there a way for me to do this in Gnome? Thanks in advance, Mark emerge lm_sensors ; there's probably some plugin for gdesklets too, dunno if there's something for the panel -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] chipset temperatures?
On 4/8/07, Christoph Mende [EMAIL PROTECTED] wrote: On Sun, 2007-04-08 at 15:42 -0700, Mark Knecht wrote: Hi, I have an Asus A8N-E motherboard which had a motherboard chipset fan go bad yesterday. After doing some reading I found many folks have had this same problem and switched successfully to Zalman passive heat sinks so I did the same thing today. The machine has been up for about 4 hours with no problems. So far so good My question is how can I monitor chipset temp from my my desktop to watch this for awhile? If I drop into BIOS I see a temperature listed and had to turn off boot time warnings about the chipset fan going to slow so it seems the BIOS knows what's going on. Is there a way for me to do this in Gnome? Thanks in advance, Mark emerge lm_sensors ; there's probably some plugin for gdesklets too, dunno if there's something for the panel Thanks. I'll go read about that. ; ??? Again, thanks. - Mark -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Anyone using i965 3D?
On Fri, Apr 06, 2007 at 02:27:46AM -0700, Andrei Slavoiu wrote: Do you have Xorg 7.2? The driver for this card was only included starting from this version, so if you use the current stable xorg you need to switch to the testing version. Yes, Xorg 7.2 with the 1.7.4 driver (actually the modesetting branch matching same, as I'm using an LCD and wanted 1680x1050 resolution support), Mesa 6.5.2 with 2.6.20.3 kernel With DRI off, glxgears/etc work though of course slowly. With them on, anything talking to gl fails, eg: (motoko ~)$ glxinfo name of display: :0.0 glxinfo: bufmgr_fake.c:746: bmGenBufferStatic: Assertion `0' failed. Aborted Backtrace shows the assertion inside i965_dri.so I also tried xorg-server-1.2.99.903.ebuild and xf86-video-i810-1.9.94, which failed entirely (segfault on driver load, trashed the display state and rendered the entire console unusable). Glad to know this is working for someone at least - so hopefully it's just something with my configuration or specific versions, or at the worst a hardware problem. Maybe DRI works under 4:3 screen layouts but not others? I can live with slow 3D, it's not essential to my workflow but it's very frustrating when your hardware doesn't seem to work as it should. -Jack -- gentoo-amd64@gentoo.org mailing list
