Bugzilla Bug 216990

This is going to be interesting for me to document properly.  I'll start with
the install scenario:

1) Primary SATA Hard Drive with standard swap (sda1)& root filesystem on a
Reiserfs filesystem (sda2).
2) Secondary Hard Drive with Windows XP NTFS (sdb1), Linux EXT3 where Gentoo
Beta1 2008.1 was installed (labeled as sdb3 according to libsata) and Archive
ReiserFS partition for use by the default o/s on the primary hard
drive(/dev/sdb2).

Grub is installed on sda with stage 2 on /dev/sda2 (root filesystem).

After completely installing, I noticed no option for choosing between grub or
lilo (no biggy) and *no* option for customizing the Grub menu.lst file.  This
was extremely important to see with my listed above layout -- being as unique
as it is, I did not expect most installers to get it correct.

Also noticed, the GTK+ installer had log for viewing, but had the applet button
which complained of no log available -- believe a bug is already filed for
this.

After the install finalized, I could have swore to have properly shutdown the
system.  However, on reboot, I was presented with a blank grub menu.

Rebooted with an recent Gentoo Minimal CD and noticed my root filesystem /boot
was not present!  Not only this, but fsck.reiserfs also required the rebuild
tree option!  Completely shocked at this point as these two drives are not more
then a year old and are Seagate drives!  Never seen anything like this at all
until this install with 2008.0 beta1!



Reproducible: Didn't try

Actual Results:  
I'm still in the process of cleaning things up.  My entire /boot folder is
missing and pushed into lost+found.  Noticed awk was missing on reboot and
init.d/rc scripts are screwed still.


I'm marking this as a blocker.  However, reproducing this bug is going to be
more then likely pending on other testers seeing a similar scenario for now.

Of my 10 years on Linux, this is probably the worst bug I've seen with an
installer so far.  I extremely doubt it's due to bad blocks and somehow more
due to an improper umount of the filesystems.  But even I haven't seen
corruption to this extent on my accidental shutdowns in the past.

I'll do my best to follow-up on this bug when others post here, but my
production box is now down.  This was a pretty darn stable box too!

OK.  I'm production host is back up.

Here's what was missing

 - Entire /boot folder
 - Bin files awk, basename, umount, (depscan.sh?), mktemp, hostname, loadkeys

<shrugs>  All I've got for now.  I could be looking at two separate bugs here. 
One filesystem related or other source.  And another with the Installer with
it's grub install code.  It doesn't look like the Installer touched the boot
folder at all on /dev/sda2 here, I'm also wondering if /dev/sda2 was even
mounted during the install to /dev/sdb3?

Only thing I can think of, if more files are missing, re-emerge world.  Also,
even though unlikely, watch for a failing /dev/sda -- one never knows!

Oh wow!  The partition I installed the 2008.0 beta1 to, I get a trillion of the
following prompts <y>:

--- snip ---
# fsck.ext3 /dev/sdb3
e2fsck 1.40.6 (09-Feb-2008)
Resize inode not valid.  Recreate<y>? yes

/dev/sdb3 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Root inode is not a directory.  Clear<y>? yes

Reserved inode 4 (<The ACL data inode>) has invalid mode.  Clear<y>? yes

Inode 4, i_blocks is 114024, should be 0.  Fix<y>? yes

Reserved inode 6 (<The undelete directory inode>) has invalid mode.  Clear<y>?
yes

Inode 6, i_blocks is 32, should be 0.  Fix<y>? yes

Inode 8, i_blocks is 0, should be 262416.  Fix<y>? 
--- snip ---

Somehow, I seriously doubt I have two failing (~150G/~350G)Seagate drives at
the same time!

fsck is still going using '-y' option.  Somehow I doubt the install of 2008.0
is even usable at this point.

<shakes head> First I've seen a install fail so miserably!

--- snip ---
#mount /dev/sdb3 /mnt/test

#ls /mnt/test/
lost+found

# du -kh --max-depth=1
995M    ./lost+found
--- snip ---

LOL!

Hrm, ok a couple things to note here.
1. We don't support ReiserFS, and never will.
2. The advanced mode of the command-line installer will let you choose which
drive 's MBR to install GRUB to.  I think this is what you want, but I can't
tell for sure.
3. I would recommend reinstalling rather than trying to recover.  You'll save
time.

I think that the grub issue isn't related to some filesystem issue you're
having.  Perhaps you chose the wrong filesystem and that is why you're seeing
funky things?

(In reply to comment #5)
> Hrm, ok a couple things to note here.
> 1. We don't support ReiserFS, and never will.

I don't understand this one. ReiserFS is provided by gentoo-sources and
reiserfs is an option within the installer.

> 2. The advanced mode of the command-line installer will let you choose which
> drive 's MBR to install GRUB to.  I think this is what you want, but I can't
> tell for sure.

More then likely, probably does.  However, a person starting the install
probably isn't going to know whether or not the installer is going to give them
the opportunity to customize the Grub install module of the installer.  (Past
history for popular Linux distro installers shows, do allow customization
whether or not expert mode was initially specified.  Mainly, for non-expert
mode install, the option is there during the grub install to make sure the
menu.lst or lilo.conf file is in order.)

<shrugs>  Bug #208396 demonstrates this.

> 3. I would recommend reinstalling rather than trying to recover.  You'll save
> time.

If you noted within comment #4, that was the root filesystem of the install of
2008.0 beta1, for which, the entire root filesystem was moved to lost+found!    

BTW, I did use ext3 for 2008.0 beta1 install.  Maybe this is what you were
referring to, concerning supported file systems for 2008.0 beta1 -- only ext3
is currently supported?  Still, I vividly recall reiserfs & ext3 both being
options.


> I think that the grub issue isn't related to some filesystem issue you're
> having.  Perhaps you chose the wrong filesystem and that is why you're seeing
> funky things?

no.  fdisk/cfdisk reported the filesystem as ext3.  fsck.ext3 would probably
not have proceeded if it were not an ext3 filesystem.

I *should* mention here, I used the livecd-i686-installer-2008.0_beta1.iso.

My only guess currently is, maybe the kernel segfaulted during or just prior to
umount.  Or the installer grub-install segfaulted.  Even then, this must've
been the biggest segfault hitting just the right G spot on this box!  I've
never seen this massive data corruption.  Another thought is, libsata stability
issue.  Right now, I'm kind of stumped how I can replicate this ... safely. 
Using my spare IDE drives to replicate this is going to loop around using SATA
drivers, etc.

For now, I'll kick-back and relax and hopefully somebody else will encounter
this issue & hopefully provide a tidbit more data.

In the past, I've had to make sure I compiled grub using no optimizations (only
-O2).  Using optimizations on my SMP Pentium3 box, and grub got cranky. 
Usually only refusing/error to install to MBR.

I don't want to speculate any further without specific logged debug data
leading to, libsata/grub could be acting up.

...mmm.. wait a second, I did use an i686 livecd.  (Still need more data to
verify this.  I can't risk installing on this box again. If I get time, I'll
install on my pentium3 laptop.)

The installer does not touch *any* partition that you don't tell it to. If
you've got filesystem corruption all over, something completely unrelated to
the installer happened. We can't help you.

<shrugs>  what help?

Wasn't even asking for help, but to only document a critical/severe bug I
encountered.  (To my knowledge, this is a bug reporting system and not a help
channel.)

A more proper solution for closing this bug, would be to "postpone for more
information needed" (obviously due to the lack of log feature the installer was
unable to pull after install) or pushed to 2008.0 release team for info (as
there could be a bug with libsata/grub).

(... was considering spending a few hours looking at the installer code and
helping.  Leaving as closed due to the inability to attain relevant log data.)