Grub v0.97 "Unknown partition table signature"

[DiTBho]

mac-mini/x86, in "PC" compatibie mode (not EFI).

Code: [Select]

# grub-install /dev/sda1
Unknown partition table signature
Unknown partition table signature
Unknown partition table signature
Unknown partition table signature
Unknown partition table signature
Unknown partition table signature
Unknown partition table signature
Unknown partition table signature
Unknown partition table signature
Unknown partition table signature
Unknown partition table signature
Unknown partition table signature
Unknown partition table signature
Unknown partition table signature
Unknown partition table signature
Unknown partition table signature
Unknown partition table signature
Unknown partition table signature
Unknown partition table signature
Unknown partition table signature
Unknown partition table signature
Unknown partition table signature
Unknown partition table signature
Unknown partition table signature
Unknown partition table signature
Unknown partition table signature
Installation finished. No error reported.
This is the contents of the device map /boot/grub/device.map.
Check if this is correct or not. If any of the lines is incorrect,
fix it and re-run the script `grub-install'.

(fd0)   /dev/fd0
(hd0)   /dev/sda
(hd1)   /dev/sdb
(hd2)   /dev/sdc
(hd3)   /dev/sdd

has anyone ever seen this error message? I don't get what is wrong, and how to fix it 

[DiTBho]

Code: [Select]

grub> root (hd0,0)
 Filesystem type is ext2fs, partition type 0x83

grub> setup (hd0)
 Checking if "/boot/grub/stage1" exists... yes
 Checking if "/boot/grub/stage2" exists... yes
 Checking if "/boot/grub/e2fs_stage1_5" exists... yes
 Running "embed /boot/grub/e2fs_stage1_5 (hd0)"...  18 sectors are embedded.
succeeded
 Running "install /boot/grub/stage1 (hd0) (hd0)1+18 p (hd0,0)/boot/grub/stage2 /boot/grub/menu.lst"... succeeded
Done.

grub>

this is ok, but doesn't fix the problem

[DiTBho]

Code: [Select]

boot_drive="hd0"
boot_bpart="0"
menuconfig="menu.lst"
bootconfig="grub.conf"
device_map="./device.map"

echo "-[device map]--------------------------"
cat $device_map
echo "---------------------------------------"

cp $bootconfig $menuconfig

grub --batch --boot-drive="($boot_drive,$boot_bpart)" --config-file="$menuconfig" --device-map="$devicemap" <<EOF
root ($boot_drive,$boot_bpart)
setup ($boot_drive)
quit
EOF


Code: [Select]

-[device map]--------------------------
(hd0)  /dev/sda
---------------------------------------
Probing devices to guess BIOS drives. This may take a long time.
Unknown partition table signature
Unknown partition table signature


    GNU GRUB  version 0.97  (640K lower / 5120K upper memory)

 [ Minimal BASH-like line editing is supported.  For the first word, TAB
   lists possible command completions.  Anywhere else TAB lists the possible
   completions of a device/filename. ]
grub> root (hd0,0)
 Filesystem type is ext2fs, partition type 0x83
grub> setup (hd0)
 Checking if "/boot/grub/stage1" exists... yes
 Checking if "/boot/grub/stage2" exists... yes
 Checking if "/boot/grub/e2fs_stage1_5" exists... yes
 Running "embed /boot/grub/e2fs_stage1_5 (hd0)"...  18 sectors are embedded.
succeeded
 Running "install /boot/grub/stage1 (hd0) (hd0)1+18 p (hd0,0)/boot/grub/stage2 /boot/grub/menu.lst"... succeeded
Done.
grub> quit


[Nominal Animal]

What partition table format are you using?  gpt?
    fdisk -l /dev/sda

What is the partition table signature?
    dd if=/dev/sda bs=1 skip=510 count=2 status=none | od -A none -t x1
If not "55 aa", there you go.  How did you create the partition table in the first place?

[DiTBho]

What partition table format are you using?  gpt?

it's an old PC-partition scheme, older than GPT.

Code: [Select]

# fdisk -l /dev/sda[
fdisk -l /dev/sda
Disk /dev/sda: 111.79 GiB, 120034123776 bytes, 234441648 sectors
Disk model: FUJITSU MHZ2120B
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot   Start       End   Sectors   Size Id
/dev/sda1  *       2048   1959929   1957882   956M 83
/dev/sda2       1959930   3919859   1959930   957M 82
/dev/sda3       3919860 234441647 230521788 109.9G 83


Code: [Select]

# dd if=/dev/sda bs=1 skip=510 count=2 status=none | od -A none -t x1
55 aa


If not "55 aa", there you go.  How did you create the partition table in the first place?

I had already checked with a hex editor, the signature seems ok, as does the MBR (which is the Grub stage1).

The disk is installed inside an old Apple-mini/x86 (intel core2 duo), and was created years ago with fdisk. It worked fine, until I compiled a new linux kernel, moving from v4.9.16 to v6.6.8, and upgraded Grub from Grub-v1 to Grub-v2 since the new gentoo stage4 no longer uses Grub-v1.

Code: [Select]

=sys-boot/grub v2.12-r1

Grub-v2 was compiled with GRUB_PLATFORMS="pc", however "grub-install /dev/sda" with the old grub.conf file didn't work and made the system unbootable.

Code: [Select]

GRUB_PLATFORMS="pc"
# coreboot
# efi-32
# efi-64
# emu
# ieee1275
# loongson
# multiboot
# pc <------------- old PC booting scheme
# qemu
# qemu-mips
# uboot
# xen
# xen-32
# xen-pvh
(grub-v2 profile)

Code: [Select]

# hd0,0 is /dev/sda1
# hd0,1 is /dev/sda2
# hd0,2 is /dev/sda3

# Boot automatically after x secs.
timeout 30

# By default, boot the entry
default 2

# Fallback to the entry.
fallback 1

#-----------------------------------------------------------------------
# ID=0
title   memory test
root    (hd0,0)
kernel  /kernel/memtest86
#-----------------------------------------------------------------------
# ID=1
title   kernel-4.9.16 (stable, for production)
root    (hd0,0)
kernel  /kernel/kernel-4.9.16.bzImage root=/dev/sda3 CONSOLE=/dev/tty1
#-----------------------------------------------------------------------
# ID=2
title   kernel-6.6.8 (new, to be tested)
root    (hd0,0)
kernel  /kernel/kernel-6.6.8.bzImage root=/dev/sda3 CONSOLE=/dev/tty1
(grub.conf)

So, I booted from a USB stick, unmerged Grub-v2, and binary packaged Grub-v1 from another Gentoo x86/32bit machine with same the profile, just >8 years older, and emerged it as binary.

Code: [Select]

boot/grub/stage1
boot/grub/stage2
boot/grub/e2fs_stage1_5
boot/grub/fat_stage1_5
boot/grub/ffs_stage1_5
boot/grub/vstafs_stage1_5
boot/grub/xfs_stage1_5
boot/grub/default
boot/grub/grub.conf
boot/grub/splash.xpm.gz
boot/grub/stage2_eltorito
sbin/grub
sbin/grub-install
sbin/grub-terminfo
sbin/grub-md5-crypt
sbin/grub-set-default
usr/share/info/grub.info.bz2
usr/share/info/multiboot.info.bz2
usr/share/grub/splash.xpm.gz
usr/share/man/man1/mbchk.1.bz2
usr/share/man/man8/grub.8.bz2
usr/share/man/man8/grub-md5-crypt.8.bz2
usr/share/man/man8/grub-install.8.bz2
usr/share/man/man8/grub-terminfo.8.bz2
usr/share/doc/grub-0.97-r10/NEWS.bz2
usr/share/doc/grub-0.97-r10/TODO.bz2
usr/share/doc/grub-0.97-r10/AUTHORS.bz2
usr/share/doc/grub-0.97-r10/grub.conf.gentoo.bz2
usr/share/doc/grub-0.97-r10/grub.conf.sample.bz2
usr/share/doc/grub-0.97-r10/THANKS.bz2
usr/share/doc/grub-0.97-r10/README.bz2
usr/share/doc/grub-0.97-r10/BUGS.bz2
usr/share/doc/grub-0.97-r10/ChangeLog.bz2
lib/grub/i386-pc/ufs2_stage1_5
lib/grub/i386-pc/jfs_stage1_5
lib/grub/i386-pc/minix_stage1_5
lib/grub/i386-pc/stage2
lib/grub/i386-pc/e2fs_stage1_5
lib/grub/i386-pc/vstafs_stage1_5
lib/grub/i386-pc/iso9660_stage1_5
lib/grub/i386-pc/ffs_stage1_5
lib/grub/i386-pc/stage2_eltorito
lib/grub/i386-pc/fat_stage1_5
lib/grub/i386-pc/xfs_stage1_5
lib/grub/i386-pc/reiserfs_stage1_5
lib/grub/i386-pc/stage1
bin/mbchk
(=sys-boot/grub-0.97, binary packaged, content)

Grub-v1 made the system bootable again, but complains about that signature, which makes no sense as the signatures { 0x55 0xaa } seem correct 

[Nominal Animal]

What partition table format are you using?  gpt?

it's an old PC-partition scheme, older than GPT.

Yep, old DOS partition table format, just like on e.g. most USB sticks with more than one partition.  Nothing wrong with that.

Obviously it seems to work, the only thing is the error message, and whether it means anything.

Perhaps the unused fourth partition has some garbage left over?  You could create it, save it, then delete it, and save again (using fdisk /dev/sda).  The old DOS partition table format supports exactly four "primary" partitions, although the last of them can be an "extended" partition containing additional "secondary" partitions.

However, for me, the next step would be to run grub-install --debug /dev/sda using the grub-0.97 grub-install –– it is a shell script, a binary in later versions –– to better see what actually generates the warning.  This way, the bash script runs in set -x mode, displaying each command as it runs them.  After that, run dmesg to check if kernel generated any of the warnings.

[SiliconWizard]

Grub-v1 made the system bootable again, but complains about that signature, which makes no sense as the signatures { 0x55 0xaa } seem correct 

Could this be an endianness issue? Maybe related to an incorrect configuration of the grub build?

[Nominal Animal]

Grub-v1 made the system bootable again, but complains about that signature, which makes no sense as the signatures { 0x55 0xaa } seem correct 

Could this be an endianness issue? Maybe related to an incorrect configuration of the grub build?

It's an x86-based mac mini, with grub-0.97 only supporting x86 (parts written in assembly).  Intel little-endian all the way.  (That's also why the signature constant PC_MBR_SIGNATURE is written as 0xaa55 in grub-0.97/stage2/pc_slice.h.)

In grub-0.97, (stage1/1.5/2), a dos partition table signature mismatch should yield a "Partition table invalid or corrupt".

To overwrite the signature, one could run (Bash or dash)
    sync ; LANG=C LC_ALL=C printf '\xaa\x55' | dd of=/dev/sda bs=1 seek=510 count=2 ; sync
but I think this will just stop booting at stage2 with the "partition table invalid or corrupt" error.  Reverting to the normal one is of course
    sync ; LANG=C LC_ALL=C printf '\x55\xaa' | dd of=/dev/sda bs=1 seek=510 count=2 ; sync

[DiTBho]

the situation here is terrible, and continues to get worse.

grub-v2 ... I have no idea what damage it did but it even damaged the ext3 filesystem as I found the first 13Kbyte of the partition filled with 0xAA, as if it had written to it at low level.

Ext3 isn't too tolerant of this sort of thing, so I made backups before unmount it, and then wiped out the entire disk

Code: [Select]

dd if=/dev/zero of=/dev/sda
(the machine booted from the usb-stick, so I can do it on the disk)

Created a PC partition from scrath (fdisk /dev/sda), formatted /dev/sda4 as ext4, and installed Lilo.

But now the firmware no longer recognizes the disk as bootable and I no longer hear the bootstrap sound, and worse still, it worked (not the past verb), now, without holding down (Option-key on a mac-keyboard) ALT(ALT-key on a PC keyboard) during startup, the Mac seems to go crazy and doesn't even see the USB stick with the EFI installer inside.

Holding on the Option/Alt key at the bootstrap forces the mac to list all the bootable devices.
Surprise, the USB stick is listed, but the harddrive is reported as ... blank

WHAT
THE
FSK!!!

I've already tried everything, including cleaning the stroller area 

The absurd thing, I have a stack of other 8 intel mac-minis - unfortunately they are not mine - none of them behave this way!
And I've already finished installing both Lilo and Stage4 on all 8, cloned via netcat.
They boot perfectly (incremental IP and hostname=node0..7 -> ip=192.168.1.130...137), and they do boot, a clear sign that the procedure followed is correct, and that lilo works!




Why on the why the only unlucky Mac is mine?!?

[madires]

mac-mini/x86, in "PC" compatibie mode (not EFI).

Code: [Select]

# grub-install /dev/sda1
Unknown partition table signature

has anyone ever seen this error message? I don't get what is wrong, and how to fix it 

Usually grub is installed in the MBR, e.g. /dev/sda (disk, not some partiton). It's only installed in a specific partition if there's already some bootloader from another OS in the MBR and you don't want to replace it with grub.

[DiTBho]

Usually grub is installed in the MBR, e.g. /dev/sda (disk, not some partiton). It's only installed in a specific partition if there's already some bootloader from another OS in the MBR and you don't want to replace it with grub.

That was how Grub-v0.97 was installed: on the MBR!
I cleaned the first 448 bytes of /dev/sda, and installed Lilo from scratch on a fresh empty MBR, but it did not help.

Today also I found that "something" "somehow" wrote 13Kbytes of { 0xAA, 0xAA, ... } to the rootfs partition on the ext3 filesystem structure, which seems strange, but that's what I saw.

There should be no malware - yup, GNU/Linux is not safe from them - as that mac has never executed nothing but GNU/Linux and has never been used to surf the net, and all it did was compile both Gentoo and development sources.

I wonder why the other eight Mac-intel-s (exactly the same model) boot Lilo and this bloody Mac does not even recognize the disk as bootable?!?
I cloned exactly *THE SAME* setup, so, at least holding the Option/ALT-key should list the disk in the bootable device list. But again no-dice.
And it's also weird that I don't I hear the "chime sound" from that bloody Mac.  Already tried to "clean the PRAM", but again no-dice.

This sounds
1) Firmware curruption, is the flash degraded? Who knows ...
2) the PRAM battery is goind to die, but it's not exaxtly already died, walking dead. Who knows.
3) ...?!?

umm, I also tested the disk with badblocks && S.M.A.R.T. : all ok

[DiTBho]

opened, thanks to the above video.

[DiTBho]

[DiTBho]

• dead cdrom, labelled Apple, doesn't have a standard sATA connector. Umm, probably custom. It does not read anything, and makes weird noice when you insert a CD. The Linux kernel (v6) gets nuts when you try to read something -> to be replaced? rapaired? mumble ...
• the PRAM battery is a CR2032 and the voltmeter measures 3.1V -> looks good
• the harddisk is labeled "Apple", attached to my HPPA workstation is fully recognized, so it's a standard sATA disk. Installed inside a usb-sATA box, all the other mac-mini-intel-s can see in the of bootable device, just "not EFI", that's correct, as it has a "DOS-partition scheme" and LILO as MBR
• there are two so-dimm ram sticks. Ummm, 2GB each, that's weird as it should be 4GB total, whereas the Linux kernel (64bit) sees 2GB --> is one of them damaged? Was it the RAM that corrupted 13Kbyte on the disk?!? and does it cause all the problems?!? to be checked ...
  

[DiTBho]

Meanwhile, found it in a local market, I went to get it immediately, so I bought a mac-mini/intel-2009 to replace mine.
And I installed 2x4GB on it!

it's based on Intel(R) Core(TM)2 Duo CPU, P7550@2.26GHz, so ~+300Mhz faster than my old gear! That's good!

Code: [Select]

# uname -r
6.1.7-macmini64

# cat /proc/meminfo
MemTotal:        7860856 kB
MemFree:         7772188 kB
MemAvailable:    7737848 kB


Code: [Select]

# lilo
Reading boot sector from /dev/sda
Using TEXT secondary loader
Calling map_insert_data
Mapping message file /boot/lilo-message.txt
Calling map_insert_file
Boot image: /kernel/kernel64-6.1.7.bzImage
Added k6.1.7/64bit  *
Boot image: /kernel/kernel32-6.1.7.bzImage
Added k6.1.7/32bit
Writing boot sector.
it only writes 448 bytes and nothing else on /dev/sda, as expected 

[Nominal Animal]

Before you install it, wipe it (by writing zeros to the first and last megabyte of the storage device), then create a new partition table and partitions using fdisk/sfdisk/etc., and only then install grub/lilo.

As you well know, it is best to keep the /boot partition as ext2, and by default mount it read-only in the OS if possible (it is not possible if you use/need e.g. automated kernel updates).  That way the / partition can use any filesystem the kernel supports.

In theory, some of the issues you're seeing could be due to interactions with LVM2, as in configured to be used with automagic scanning, but doesn't see anything.  Brutally clearing the first and last megabytes of the storage device is the big hammer for that (and all other partition table and partition scanning stuff).

As to the malfunctioning one, I think it has severe hardware issues, possibly in the internal controller of the misbehaving disk.  The replacement of data with 0xAA = 10101010₂ is a tell-tale sign of that, unrelated to the partition table signature.

[DiTBho]

Before you install it, wipe it (by writing zeros to the first and last megabyte of the storage device), then create a new partition table and partitions using fdisk/sfdisk/etc., and only then install grub/lilo.

that's why I dd if=/dev/zero of=/dev/sda, but it didn't help

As to the malfunctioning one, I think it has severe hardware issues, possibly in the internal controller of the misbehaving disk.  The replacement of data with 0xAA = 10101010₂ is a tell-tale sign of that, unrelated to the partition table signature.

the problem is ... which part is malfunctioning
+ hdd?
+ ram?
+ motherboard?

In my spare time, I'll try to understand it, but I have to resolve the issue as soon as possible to finish a project.

Today I spent 80 UKP for a late 2009 Apple Mac Mini Intel Core2 Duo@2.26GHz, 500GB HDD, and 20 ULK for a 2x4GB ram kit
+ 080UKP Mac Mini
+ 020UKP ram kit
= 100UKP total

Tempted to pick up a second late 2009 Apple Mac Mini Intel Core2 Duo, but
+ 2.53Ghz
+ 8GB of ram already installed

listed for 120 euro shipped 

[DiTBho]

It seems the CDROM is a weak components in Intel Mac-Mini. I see that many mid-late 2009 releases have a dead cdrom.
I have never encountered such a high frequency of defects with optical drives used in PowerPC Mac-Mini.

[Nominal Animal]

+ hdd?

My main suspect is the HDD internal controller.  If you can, temporarily swapping it with something else would be informative.

In general, this kind of suspicious and problematic behaviour is not worth the worry if a simple test replacement cannot pinpoint the failure to a specific device one can replace; you'll spend much more time investigating and worrying about it than it is worth spending for, especially if you can get a full replacement device for on the order of 100€ or so.

It seems the CDROM is a weak components in Intel Mac-Mini. I see that many mid-late 2009 releases have a dead cdrom.

Interesting.  I can understand getting the sensor dirty and not being able to reliably read any media anymore (difficult to clean..), but it seems you're seeing electromechanical failures.

Do you happen to have a picture of the connector?  I assume you've already excluded slimline and micro-SATA and mSATA as possibilities?  The mid-2010 models per iFixIt pictures seem to use custom SATA connectors.

[DiTBho]

This tutorial is to show how to fix the optical drive problem in your Mac Mini 2009.
The problem is that if the optical drive is dirty it keep ejecting the DVD movies or audio CDs without playing them. During the years the electronic devices accumulate a lot of dust and when the optical laser gets some of the dust the laser can't read accurate the DVD movies or Audio CDs for example.
I hope that this tutorial can help you to fix your 2009 MacMini.

this video gives some points to this theory: too much dust can cause malfunctions.
It is very dirty because it has never been opened in the last 14 years, it has continued to accumulate dust.
The PowerPC version has a different fan, which probably blows it out.

[DiTBho]

Do you happen to have a picture of the connector?

I will take tomorrow 

[Nominal Animal]

Do you happen to have a picture of the connector?

I will take tomorrow 

Better spend the time with careful use of pressurized clean air and a vacuum cleaner!

("Hot tip": pantyhose fabric stretched over the plastic intake of a vacuum cleaner makes for an excellent filter, stopping small screws and such vanishing inside the vacuum cleaner.  Also useful for finding dropped screws.)

[DiTBho]

it seems there are special "CD caddy" like this, allowing you to install a second HDD.

Like with the Mac-Mini Server? 
(I've never seen one in person, only seen on the internet: so I doubt they really exist)

It just replaces the CDROM unit, so ... it seems the weird "sATA" connector is just a "smaller" version, probably made by Apple.

[DiTBho]

Code: [Select]

Mac-Mini Early 2009  Core2/Duo P7350 2.00GHz  4GB  NVIDIA-GeForce-9400M-128MB <---- mine, dead
Mac-Mini Early 2009  Core2/Duo P8400 2.26GHz  4GB  NVIDIA-GeForce-9400M-256MB
Mac-Mini Late  2009  Core2/Duo P7550 2.26GHz  8GB  NVIDIA-GeForce-9400M-256MB <---- mine, new
Mac-Mini Late  2009  Core2/Duo P8700 2.53GHz  8GB  NVIDIA-GeForce-9400M-256MB <---- my boss's
Mac-Mini Late  2009  Core2/Duo P8800 2.66GHz  8GB  NVIDIA-GeForce-9400M-256MB
Mac-Mini Server      Core2/Duo P8700 2.53GHz  8GB  NVIDIA-GeForce-9400M-256MB (wanted)

I carefully cleaned and removed all the dust, but it seems the firmware is corrupted.
I know the firmware can be updated, but ... I have enough: for me it's dead and it will be replaced with a second faster unit.

R.I.P.

[SiliconWizard]

Damn, using Intel-based Mac minis from 15 years ago, especially when one despises Intel CPUs, is intriguing.

[DiTBho]

Damn, using Intel-based Mac minis from 15 years ago, especially when one despises Intel CPUs, is intriguing.

That's why I won't throw the metal case of the dead Mac-mini in the trash: to be re-used as case for a MIPS board!!!

Mips32R2/be-mini, running Haiku, sweet dreams are made of this 

... unfortunately I have to use those things (which I personally hate) for a lot of different reasons.

Starting from, because I don't have the CAD/CAM skills (and I'm paid for it anyway) to re-design rack cases for mac-mini/Intel (>2010) or Apple Silicon (similar, from the mechanical point of view, rack kits are compatible), and I have to stock up to eighth of those Apple intel Mini 2009 in a kind of cluster in a rack-case, and I have use x86 (intel core2/Duo @ >=2GHz is enough for the specs) because there are commercial applications (including C compilers) with which they are supplied only the binaries, among other things in 32bit ... so I also have to instruct Catalyst to build a "multi library" stage4, hybrid 32 and 64bit, with a 64-bit kernel to be able to address all 8GB of RAM, which is required for two QEMU/x86 VM.

So, if it was for my personal stuff, I would buy an Ampera 128Core workstation and/or a POWER workstation, for sure not that x86 stuff.

[DiTBho]

(
then it must also be said: I have no authority to tell my boss or my clients to throw everything away
which would also make a lot of sense, but these are decisions that are not my responsibility
)

[SiliconWizard]

Damn, using Intel-based Mac minis from 15 years ago, especially when one despises Intel CPUs, is intriguing.

That's why I won't throw the metal case of the dead Mac-mini in the trash: to be re-used as case for a MIPS board!!!

 

So, if it was for my personal stuff, I would buy an Ampera 128Core workstation and/or a POWER workstation, for sure not that x86 stuff.

Ampera stuff is very expensive.