Bugzilla – Bug 326942
xfs file system corruption after first stage of installation
Last modified: 2007-09-24 13:40:55 UTC
This may need to be blocker? I cannot install: As soon as phase 1 is done and the first reboot takes place, During boot from disk the screen flashes the install screen then I see a message like Yast.. D bus error. I cannot write it down fast enough and I do not see it in the attached logs. Let me know what file it should be in. This is a biggie, install is not possible.
Created attachment 173760 [details] yast boot msgs etc I tried to reinstall a second and got the same results. No luck. I did see the error message quickly and noticed it also said /usr...yast2 ... line 464 bus error ... OPT.... Then the installed dropped into a login and stopped. No login was possible since root password was never established. To be clear, this happens during first boot from disk right before configuration should start. I took all defaults except added Gnome, file and web server and did my own partitioning. One more thing.. I checked the DVD on 10.1 to make sure it was ok. The 10.3 install no longer checks DVDs.
Also, the summary line has D-bus but it actually is "yast2 line 464 bus error" (no D), this was due to messages going by too quickly. I searched again and still cannot find the message in any file.
Steffen, didn't you report something similiar? What happened with it?
Mariao, it should be possible to grab YaST logs and other files this way: * Boot installation DVD * Switch to console Ctrl+Alt+F2 * mount /dev/$your_device /mnt * Check the end of file /mnt/var/log/YaST2/y2log * Check the end of file /mnt/var/log/YaST2/y2start.log If possible, please, attach these two files also with /mnt/var/log/messages Picture of a failing second stage can be also taken by a camera (faster than eyes when it comes to reading) :) Anything that you do would help us a lot :) Thanks!
You mean bug 326383. That turned out to be an xfs filesystem corruption. According to the log in comment 1, this seems to be the case here, too. I wasn't sure about it in the end as my other machine with xfs updated fine and hadn't time to check it again so far. :-( So, there seems to be an xfs problem for real. Mario, just run 'rpm -aV'; any lines with 'S.5' (md5 checksum error) where they shouldn't be?
*** Bug 326383 has been marked as a duplicate of this bug. ***
I'd like at least an independent confirmation that this is indeed a fs corruption. But in any case, seems safe to move to the kernel.
*** Bug 327061 has been marked as a duplicate of this bug. ***
switching from xfs to ext3 during installation solved the problem.
The installation in VirtualBox also used xfs, however, and there it worked. How comes the same RC1 has both a buggy and a working xfs implementation? In any case: without a fix, we should drop from supported fs list then, shouldn't we.
Didn't happen all the time for me, too (see comment 5). Maybe in some cases the data are not flushed to disk completely before reboot.
Ah, maybe it was caused by ... bug #326478 NTPD was running and "umount" at the end of the installation didn't work --> system partition was corrupted after the reboot from first to second stage. Possible? This appears in the minimal installation...
Oh, let's close it as dup of 326478 quickly then - one issue less ;) I'll do an installation with xfs with the remastered DVD9 then.
At least in the case where I had no problems I'm absolutely sure the fs _was_ unmounted because I had to fix the boot loader config and for that had to mount the fs again.
Just checked and it's indeed bug 326478. After manually killing ntpd & dhcpcd and unmounting the fs, things work out fine. *** This bug has been marked as a duplicate of bug 326478 ***
I reinstalled this morning with EXT3 to test and did not have the problem. However, on my machine XFS is significantly faster which is what I will stay with. Will try XFS again when fix is ready.
*** Bug 327474 has been marked as a duplicate of this bug. ***
*** Bug 327521 has been marked as a duplicate of this bug. ***
*** Bug 327743 has been marked as a duplicate of this bug. ***