Bug 537542

Summary: Rebooting into Live-System after installation corrupts installed system
Product: [openSUSE] openSUSE 11.2 Reporter: Stephan Binner <binner>
Component: Live MediumAssignee: Stephan Kulow <coolo>
Status: RESOLVED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Critical    
Priority: P2 - High CC: coolo, jsrain, ms
Version: Factory   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: Screenshot

Description Stephan Binner 2009-09-08 22:06:07 UTC
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.2) Gecko/20090730 SUSE/3.5.2-2.1 Firefox/3.5.2

This is reproducible with KDE i586 Live Build #0266 and leads to corrupted/non-booting 2nd stage of installed live system (see screenshot). 

This is not reproducible with Live-CD Build #0249.

Reproducible: Always

Steps to Reproduce:
1. Boot openSUSE-KDE4-LiveCD-i686-Build0266-Media.iso, choose/wait for "Live System" to start
2. Run live-installer with choosing a different timezone (here Germany)
3. At end of live-installer choose "Reboot Later"
4. Leave CD in drive
5. Choose "Restart Computer" from desktop
6. Wait that "forgotten" CD "accidentally" boots its default "Start Live-System" again
7. Wait that desktop has fully loaded and choose "Restart Computer" again
8. This time choose at boot prompt "Boot from Hard Disk"
9. Watch the error as seen in screenshot
Comment 1 Stephan Binner 2009-09-08 22:06:43 UTC
Created attachment 317306 [details]
Screenshot
Comment 2 Stephan Binner 2009-09-09 13:01:39 UTC
Addendum 2) One has to select a time zone which is East of UTC time zone (like Germany) and one has to keep "Hardware Clock Set to UTC" option unchecked. 

Failure to follow this addendum will result in a working system. :-)
Comment 3 Stephan Kulow 2009-09-09 13:10:50 UTC
first measure I think is fixing the clock setup, e.g. fix /etc/sysconfig/clock to be UTC and a timezone depending on the language. Still, the live installer needs to set the correct timezone _before_ mounting the target. I'm sure this is done for DVD install, but not for live install.
Comment 4 Jiri Srain 2009-09-09 14:04:44 UTC
Stephan, I fail to follow you. IMO it is perfectly correct that the system last-mount time is far in the future - I personally don't care about the system (BIOS) time and use NTP, but at the point of time the filesystem gets mounted, NTP can hardly be running.

Also, think of moving the system time into the past via firmware/BIOS.

Another point: Stefan did one more run of the live CD after the installation (I guess it is also related). Since the live CD mounts the system (well, I'm not sure here how the automounter is configured), the last mount time may come from this run of the live system - when YaST is not involved and the system time may be any kind of strange.
Comment 5 Stephan Kulow 2009-09-09 14:21:17 UTC
I don't think it's perfectly correct for the clock to jump backward unless the system time is wrong. The NTP time is written into the hardware clock and on boot reset. I don't say the file system should be discarded if the clock jumps, but we shouldn't enforce it either.

So I think just as we set the keyboard layout once you go through the live installer, we should change the timezone of the live system _before_ we format and mount.
Comment 6 Jiri Srain 2009-09-09 14:30:28 UTC
What corrupts the filesystem is rebooting to the live system (according to the summary). Since changes in the live system are not persistent, how shall I enforce the timezone in the live system when it boots up? I don't see any way...
Comment 7 Stephan Kulow 2009-09-09 14:32:19 UTC
oh my. I failed to notice that step. So it's indeed something automounting. Sorry for the noise.
Comment 8 Jiri Srain 2009-09-09 14:40:22 UTC
Anyway, I still think that filesystem needs to survive having been mounted in the future.
Comment 9 Stephan Kulow 2009-09-09 14:51:49 UTC
it should survive it very fine if the journal was correctly synced - e.g. the file system was unmounted.
Comment 10 Stephan Kulow 2009-09-09 15:20:38 UTC
there doesn't seem to be any desktop level automount, but kiwi mounting all file systems ;(
Comment 11 Stephan Kulow 2009-09-10 12:59:38 UTC
Reported upstream, there is really nothing we can do:
http://marc.info/?l=linux-ext4&m=125258734308549&w=2
Comment 12 Stephan Kulow 2009-09-10 13:19:46 UTC
rq20314 - sent the patch also upstream