[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#607301: Cannot boot from debian-6.0.1a-i386-DVD Binary-1 20110322-15:11 and sid 29.03.2011 and debian-rescue-cdrom Grub 1.99~rc1-6 Symptom: " error: hd0 cannot get C/H/S values "



To address your kind response to me Miguel;
I read all the links you gave me for my 'Silicon Image 3114'
SATA/Raid controller chip. I also followed and read the sub links.
I shall certainly be on the look out for disk corruptions.
I could not see any mention of my 'NO BOOT' symptom in the links.
including your pointer which eventually lead to "Bug 10480 Summary:
sil3114 yields "ext3_new_block: Allocating block in system zone"

I came across:
https://ata.wiki.kernel.org/index.php/Sata_sil
"Known problems
Some reports of data corruption when paired with NVIDIA chipsets."
McTech; I have an ALADDIN5 chipset. For my clarity, that's a number five.

The great item I learned from your tip, was that I should not depend
searching so much on http:groups.google.com

I do not remember coming across your links in my own searching,
so thank you. I suppose I was using different search arguments.
I thought I had done such a thorough job.
I am indebted to you for expanding my search horizons Miguel.

If I get data corruption errors, such as
 " kernel: EXT3-fs error "
 " kernel: EXT2-fs error "    or some such,
I will know where to look and what to try.
So far, I have had no data corruption errors that I am aware of,
but then I have not been explicitly looking for them.
I have seen no error messages re data corruption, I do get my:-

" Searching for Boot Record from SCSI..Not Found
  Boot Failure "

and that is after a complete installation, of about, I don't know,
15 or 20 various successfull install data transfers.
See my  /sbin/e2fsck -nv /dev/sda1  clean output below.
Of course, I will be looking out in my install logs in future.
" cat lspci -nn.txt "  and   " dmesg -s 1000000 "
Output from " lspci -nn " " lspci -nnvvvxxx "

I will keep a look out for the symptoms described in the following
link :-
https://bugzilla.kernel.org/show_bug.cgi?id=10480
Comment #8 From Jan Kara 2008-04-24
"They (the error messages) generally mean the filesystem is corrupted.
In this particular case, bitmap of used blocks is corrupted as system
blocks (most likely inode table) are marked as freed in the bitmap of
used blocks and then we tried to allocate from there..."

Miguel,
Using grml-daily-sid 110316 codename grml-live-autobuild [2011-03-16]
the following is a disk analysis report from my single disk system :-
root@grml / # mount /dev/sda1
...
/dev/sda1 on /mnt/sda1 type ext3 (rw)
root@grml / # umount /dev/sda1
root@grml / # /sbin/e2fsck -nv /dev/sda1
e2fsck 1.41.12  (17-May-2010)
/dev/sda1 was not cleanly unmounted. check forced    <<McTech??<<
Pass1. Checking inodes, blocks, and sizes
Pass2. Checking directory structure
Pass3. Checking directory connectivity
Pass4. Checking reference counts
Pass5. Checking group summary information
113443 inodes used (1.16%)
954    non-contiguous files (0.8%)
166    non-contiguous directories (0.1%)
       # of inodes with ind/dind/tind blocks: 7293/60/0
1390543 blocks used (3.57%)
0      bad blocks                             <<McTech<<
1      large file

89420 regular files
9396  directories
12    character device files
25    block device files
2     fifos
419   links
14578 symbolic links (13474 fast symbolic links)
1     socket
113853 files

Currently, this disk and controller seems all right to me.

So thank you Miguel.
I am not sure if the following is the correct protocol.
I shall continue my efforts by sending an email
Installation-report with package: grub-rescue-pc-1.99~rc1-6
to help-grub@gnu.org.
   http://lists.gnu.org/archive/html/help-grub/
   http://lists.gnu.org/mailman/listinfo/help-grub  ,

and hopefully temporarily put to sleep this thread,
Bug#607301 Debian Package: installation-reports here at;
http://lists.debian.org/debian-boot/2011/02/msg00320.html

I hope this is the correct procedure. If I am standing on anybody's toes,
my appologies in advance. Correct procedural guidance is always welcome here.

Mucho gracias Miguel F, Melhores cumprimentos.
Thank you for your help and time. Best regards,    McTech



Reply to: