> 1-install on existing system
You mean an update?

Please attach /var/log/YaST2 as tarball, `fdisk -l' and /etc/fstab as well as `dump2fs /dev/<root partition>'.

Created attachment 77825 [details]
fdisk -l output

Created attachment 77826 [details]
/etc/fstab

(In reply to comment #1)
> > 1-install on existing system
> You mean an update?

No. I mean do not touch the partition tables, format the existing /, and preserve all other partitions. 

> Please attach /var/log/YaST2 as tarball, `fdisk -l' and /etc/fstab as well as
> `dump2fs /dev/<root partition>'.

Are you sure? /var/log/YaST2 is 47,550K as tarball, 2,558,024 as tar.gz.

-bash: dump2fs: command not found

You can find the command in the package `e2fsprogs'. About the YaST logs: Yes, I'm sure.

# rpm -qa | grep e2fs
e2fsprogs-1.38-20
# dump2fs /dev/hda7
-bash: dump2fs: command not found

I get the same on my 10.0 system, except the version is 1.38-4. Also, a full / partition search for dump2fs comes up blank.

Just to be clear before I attempt to attach anything so large, is the ungzipped 47,550k tar of /var/log/YaST2 what you want? I'm used to mozilla.bugzilla.com, where file attachments are limited to about 300,000 bytes.

sorry, I made a typo: use `dumpe2fs -h /dev/hda7', which will show the superblock information on that filesystem.
You can add 5M per attachment here. We always ask for the whole set of YaST logs for YaST related bugs.

Created attachment 78146 [details]
dumpe2fs -h /dev/hda7 output

Created attachment 78147 [details]
tar.gz of /var/log/YaST2

Thomas, please have a look at this.

I have nothing to do with system startup.
I see nothing related to yast2-storage in this problem. Probably unmounting 
of root fs at end of installation failed for some reason but this umounting
is not done by yast2-storage.

Jiri, can you help?

snwint, ms: 'umount' finishing the installation maybe failed ;)

YaST has to unmount everything it mounts, of course.

$["detected_fs":`ext3, "device":"/dev/hda7", "fsid":131, "fstype":"Linux native", "name":"hda7", "nr":7, "region":[83, 612], "size_k":4915858, "type":`logical, "udev_id":["edd-int13_dev80-part7", "ata-ST360015A_5KB0MASE-part7"], "udev_path":"pci-0000:00:07.1-ide-0:0-part7", "used_fs":`ext3, "uuid":"dc8ad8fc-44f1-45ae-8ead-39df1369ea66"]
INSTALL INFO:Formatting partition /dev/hda7 (4.6 GB) with ext3
Volume.cc(checkDevice):894 checkDevice:/dev/hda7 ret:0
...
Line 15 "Creating journal (32768 blocks): "
"Writing superblocks and filesystem accounting information: "
"This filesystem will be automatically checked every 24 mounts or"
"180 days, whichever comes first.  Use tune2fs -c or -i to override."
SystemCmd Executing:"/sbin/tune2fs -c 500 -i 2m /dev/hda7"
"tune2fs 1.38 (30-Jun-2005)"
"Setting maximal mount count to 500"
"Setting interval between checks to 5184000 seconds"
...
INSTALL INFO:Mounting /dev/hda7 to /
SystemCmd Executing:"modprobe ext3"
SystemCmd Executing:"mount -t ext3 /dev/hda7 /mnt"
device:/dev/hda7 mp:/ options:acl,user_xattr ignore_fstab:0

The partition was recognized, correctly formatted, tuned and mounted.
Then it reported a strange error that it wasn't checked for a long time.
e2fsprogs -> Hendrik Vogelsang <hvogel@suse.de>

The fs was last mounted in the future. 

FS was created at 2006-04-07 11:31:26
FS was first mounted at 2006-04-07 11:31:41
Then the installation ended at 2006-04-07 16:36:43
                               -------------------
And continued 2006-04-07 13:07:29
              -------------------

Which means by the time init mounted hda7 it was last mounted in the future. So a check was forced. This is sane and expected behaviour.

Nothing i can do about that...

This has happened on every factory install I've done, which IIRC is 4 times. I'm not changing the clock during the install, so if the reported time of the process seems to be in the future, there's something wrong in the install process that makes it possible for the an incorrect time to be logged.

It's obvious in comment 16 that the so-called "future" time at issue must be installation end at 16:36:43, when the very first umount would have occurred. This is the actual installation time of approximately one hour and five minutes, plus the four hour UTC offset. The initial mount on first reboot must be happening before the UTC offset is taken into account, creating the illusion in the log and superblock of the future time of last mount.

Going back as many years as I can remember, there's something wrong with init or the kernel that time shifts in the amount of UTC offset occur in logs when the OS has been told to use local time instead of UTC. Maybe it's now time to stop playing clock games when local time is preferred.

This cant be the case because the time when yast starts logging again is also earlier than the time it stoppped logging. 

Please provide

hwclock --show --debug
date

And the content of the files

/etc/adjtime
/etc/sysconfig/clock
/etc/ntp.conf

# hwclock --show --debug
hwclock from util-linux-2.12r
Using /dev/rtc interface to clock.
Last drift adjustment done at 1145974973 seconds after 1969
Last calibration done at 1145974973 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2006/04/26 11:48:03
Hw clock time : 2006/04/26 11:48:03 = 1146066483 seconds since 1969
Wed Apr 26 11:48:03 2006  -0.393089 seconds

# date
Wed Apr 26 11:48:05 EDT 2006

# cat /etc/adjtime
-0.445256 1145974973 0.000000
1145974973
LOCAL

Created attachment 80322 [details]
/etc/sysconfig/clock

Created attachment 80323 [details]
/etc/ntp.conf

Looks alright. Did you boot anything in between the installation steps? Like windows or some other OS that would change the clock?

IIRC, I did nothing that should have touched any clock. It's been a while, so I can't precisely remember details, but I do remember that the time of day details (and thus procedural details, like breaking to sleep) were different on each of the last several installs, and yet this same behavior occurred each time. There were unlikely to have been any intervening boots to doze. There could have been intervening boots to OS/2, which is also in active beta on this system, but AFAIK, neither OS/2 nor doze touch the clock without being told to on a normal boot. IIRC, both have been told not to mess with the clock the two times of year that the clocks change between standard and daylight time, in order to prevent unwarranted clock adjustments among OS switches. I do remember intervening boots of Knoppix 4.02 from /dev/hda14 on the two most recent installs, but I don't think I did it on any before. Knoppix shouldn't be doing anything different with the superblock or PC clock than SuSE does, and it too is set to use local time.

My normal procedure for any "new" install of any Linux is to set the PC clock to midnight immediately before starting the installer, so as to enable tracking of UTC offset effects in the installation logs, config files, and directories. I forgot to do that on this most recent install. :-(

In linux you wont have any daylight saving because your clock runs on localtime.

YaST peepz did anything change regarding clock handling in 10.1? Im lost...

jsuchome: please, check the time/timezone changes if there are any.
I'd suspect a hardware error or ...?

Timezone seems correct to me.

Felix, on such computer, I'm afraid, we are unable to track the issue.
If the annoying fsck, running before the second stage of the installation starts, is the only issue, I'd propose taking is as it comes :)

I'd really suggest to run some hardware tests but... that's the only thing I can do, well, _we_ can do. Sorry about that.

What hardware tests? Besides Factory, the following are all installed, and apparently properly functioning on this system:

eComStation 1.14
eComStation 2.0b1
Knoppix 4.0.2
Mandriva Cooker
WinXP

Motherboard: http://www.tyan.com/products/html/tsunamiatx.html

Same problem in 10.3Beta1

It is very unlikely that this is YaST issue. The only place where YaST may change the time (if user wants to do so) is timezone configuration and it happens at the very beginning of installation, before any volumes are mounted. Moreover, it doesn't touch the time at all during the update.

Screening team, please read esp. comment #17 and reassign to init script or kernel maintainers.

*** Bug 305532 has been marked as a duplicate of this bug. ***

I have also noticed that when I perform an install, Yast always assumes my machine is in UTC time not local time.  I always change the option to local time and after that screen, the screen goes blank (like the screensaver kicked in).  This could be related maybe?

It was already stated in comment #16 that the filesystem was last mounted in the future:

from y2log-1:
File system creation:
2006-04-07 11:31:25,013 INFO  libstorage - SystemCmd.cc(execute):160 SystemCmd Executing:"/sbin/mke2fs -j -v /dev/hda7"

First mounted:
2006-04-07 11:31:41,324 INFO  libstorage - SystemCmd.cc(execute):160 SystemCmd Executing:"mount -t ext3 /dev/hda7 /mnt"

But then in the end something bogus happens:
2006-04-07 12:36:42 <1> 192.168.0.146(3236) [YCP] installation/misc.ycp:29 InjectFile: </var/log/YaST2/y2log>
2006-04-07 16:36:43 <1> 192.168.0.146(9615) [liby2] genericfrontend.cc(main):497 Finished YaST2 component 'scr'
2006-04-07 16:36:43 <1> 192.168.0.146(9615) [Y2Perl] YPerl.cc(destroy):163 Shutting down embedded Perl interpreter.

The time switched from 12:36 to 16:36.
Then the installation continues at 13:07:29
I have no idea why the time switched in the end of the installation. I guess this is happening in one of the related yast modules (scr?).
We need some clue about at which location of yast this time change is triggered.

Reassigning back to yast maintainers.

There is no magic time switch: Those log lines stem from different
precesses where one is running in the inst-sys and the other one
is running in the installed system. We can have different timezone
settings there, just to demonstrate:

inst-sys:~ # date
Wed Dec 19 07:00:23 EST 2007
inst-sys:~ # date --utc
Wed Dec 19 12:00:28 UTC 2007
inst-sys:~ # chroot /mnt/
inst-sys:/ # date
Wed Dec 19 12:00:36 UTC 2007
inst-sys:/ # date --utc
Wed Dec 19 12:00:42 UTC 2007

And YaST logs localtime.

Does this still happen on openSUSE 11.0?

I don't remember seeing it in a long time, but I've mostly just been doing Factory upgrades, not fresh installs. In addition, I usually preformat in order to have 1024 block size on ext3 /, so I might not be able to see it anyway. What I really need to do is a fresh install without preformatting the way I did back when I filed this bug just to see what happens.

I just saw it, but not during install. I created a new /dev/hda21 using DFSee while booted to Factory, then rebooted into 10.3. I did 'mkfs.ext3 -b 1024 /dev/hda21', then 'tune2fs -L S12A-21suse110 -c0 -i6m /dev/hda21', then mounted hda21 and used mc to copy everything from the /dev/hda10 Factory partition to hda21. On next boot, to hda21, boot included fsck on hda21 due to "49710 days without being checked".

Might be that the hwclock setup is too late in 10.3.
This is one of the things that has changed in 11.0 (thats why I asked to check if this happens on 11.0)
boot.clock runs now before boot.localfs. In 10.3 boot.clock ran after boot.localfs which could lead to problems.

You could check if it helps to change the boot order sequence in /etc/init.d/boot.clock:
Remove the line
# Should-Start:      boot.localfs
and replace it with the line
# X-Start-Before:    boot.localfs

then run insserv boot.clock again.

The requested information has not been provided for more than 4 weeks.
The bug gets therefore closed as NORESPONSE.

Please reopen the bug if the bug still exists in the current beta4 and
you can supply the requested information.

I haven't done any fresh installs since NEEDINFO was set. Not likely the problem disappeared on its own just because I didn't have useful information to respond with. Moreover, even when I do install "fresh", I format in advance, and don't let the installer do any formatting.

OTOH, probably the very same problem exists when Factory is installed in multiboot with Mandriva. Mandriva & Factory must do their mounting and clock syncing at different times during startup. When I boot one for a short time, then boot the other, and mount each other's partitions as well, the same message and forced fsck happens, even though shutdown/restart was supposedly clean. Maybe the reported problem can be eliminated by attacking it from that angle.

When I can remember which system that last happened on, I need to try the comment 39 suggestion on it. I have Factory in beta 4 state on about 7 machines, so I should have no problem to reproduce the multiboot induced problem in coming weeks or days.

Felix, recent distros (from 11.0) have the suggestion from comment 39 implemented which should fix the problem you observe. So I think we can close this bug (I don't see much point in trying to fix this in 10.3 which is almost at end-of-life). OK?

I think I should follow up with a couple of fresh installs after one of the next milestones is announced, to confirm the problem's absence in Factory. It's been some time since I've done anything other than zypper dup to bump up versions.

Did you have any time to try the installs?

I keep forgetting about this and doing zypper dups instead. :-( Maybe next week or two I can both find the time and remember.

I just did a an M6 install to a previously unformatted ext3 / partition without seeing this occur. :-)

OK, thanks for testing. So finally after more than 4 years we can close this ;)