https://bugzilla.novell.com/show_bug.cgi?id=450196 https://bugzilla.novell.com/show_bug.cgi?id=450196#c86 Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- InfoProvider|mrmazda@earthlink.net |werner@suse.com --- Comment #86 from Felix Miata <mrmazda@earthlink.net> 2012-07-04 10:16:16 UTC --- (In reply to comment #85)

No I do not have any idea otherwise this would be fixed, only a broken system setup like wrong CMOS clock not in UTC and/or strange file system setup causing such recovering due wrong timestamps and/or broken unmount chain.

As no one here can reproduce this here on any system it is up on the reporter to provide more informations.

In case it wasn't noticed by reading my recent comments, this has been happening on _many_ systems (and for many years), all of which are multiboot, most of which include every currently supported openSUSE release, usually plus Factory, plus at least one out of support openSUSE release, plus at least one non-openSUSE Linux release from Fedora, Mandriva, Mageia, Knoppix, Debian, CentOS, Gentoo and/or Kubuntu, plus a primary partition with at least one of OS/2 or DOS and/or Windows, and all but one or two of which (the only two running RAID) have ***** CMOS clocks set to local time ***** and NTP configured to start on boot. All Linux partitions are either swap, EXT2 or EXT3. All of EXT2 and EXT3 were formatted with I=128 and most with bs=1024. Most / partitions are 4800MB, with some 4000, some 4400, a few 7200, and the few largest 10400. Most if not all have had tune2fs -c0 -i0 run on them. I configure so that the oldest of installed kernels and bootloaders are able to access every native partition, if not every non-native partition, as well. For purposes of testing for this difficult not to reproduce bug, I usually do not boot other installations besides the openSUSE one being tested against until update cycles with their associated zypper ups or dups are complete, which usually means one openSUSE kernel is having a newer openSUSE kernel added and next booted to with no other kernel being used in between, which means no other kernels are mounting any partitions in between use of first kernel and upgrade kernel. On those systems that include an OS/2 installation, the master bootloader is IBM Boot Manager. Regardless whether IBM BM is installed, the master Grub bootloader is never on the MBR, and always controlled by me manually rather than by any installed OS, mounted either as /disks/boot or /disks/hda/boot, virtually never as /boot. IBM BM writes to disk on every boot, though I can't say whether this includes writing to MBR sector in every or even any case. Most MBRs carry BIOS compatible legacy code written or originally written by Microsoft or IBM. All Linux installations are configured with a non-empty /etc/exports file and installed nfs-kernel-server, to start on boot when I don't forget to change the "off" installation default to "on". Byte counts for fstabs average well in excess of 6000, with more than 11000 typical of late. Most of their sizes are accounted for most of the time by unpowered hosts, as its rather infrequent I have more than 4 running at once. Much more usual during testing is 3 or 4. Not counting Wine, DOSbox or DOSemu, none of my systems use any kind of virtualization. To provide more information I need to be told exactly what additional information is required. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.