Bug 326478

Created attachment 173436 [details]
yast-logs.tar.gz

what makes you think so?

Well, I stopped the "going down for reboot in X sec" process and called mount. It lists the /mnt/ and /mnt/dev mounts. Then I pressed okay -> machine reboots and a fsck was running and found some failures on boot.

reseting forgotten needinfo...

Thanks :) 

I'll check again what was the problem but as far as I remember, the problem was that calling

umount /mnt/dev
umount /mnt

returned "still busy"...

So installer tries to umount them but it is not successful :(

Christopher, just curious: Did you by any chance work in the shell running on console 2 and "cd /mnt" ? In that case, umount is bound to fail.

I tought about it, too. So I did a new install on my private notebook last night and could reproduce it without touching a console. When the machine reboots at the end of stage1 I saw messages like: umount /mnt/ - is still bussy. Sadly, I forgot to run a lsof /mnt. I guess you can reproduce this as well on your machine.

Might be also because of some process still having some files open in the /mnt (target) directory :( I'll check it, hopefully with Jkupec.

As for libzypp, it seem it correctly releases installation media after finishing the installation:

2007-09-19 21:35:20 <1> 10.10.100.17(4108) [zypp] ZYppImpl.cc(commit):285 Commit (CommitPolicy( )) returned: CommitResult 606 (errors 0, remaining 0, srcremaining 0)
2007-09-19 21:35:20 <1> 10.10.100.17(4108) [wfm] Source.cc(SourceReleaseAll):593 Releasing all sources...

No problems related to SourceReleaseAll reported afterwards.

I was unable to reproduce this bug in RC1 -- minimal installation + online repos.

Moreover this is hard to debug using your logs because those logs don't contain the umount_finish call -- logs are copied to the installed system before the umount is called :) Otherwise there would be NO logs at all.

Please, try to duplicate:
- When installation is going to reboot the system, press [Stop]
- Attach the y2log file
- Continue (reboot)

Ah, found it :)

there is a
/usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -u ntp
running :)))

fuser /mnt
returns 13010rce
(which is that mentioned process)

Could this be another side-effect of #326490 / #287539?

It is more likely a side effect of ntp configuration during installation. Ntp client is set to be started during boot by default (see bug #302389). Thus, calling NtpClient::Write() to write configuration at the end of installation starts ntp daemon.
I'll set ntp-client to 'write only' mode during 1st stage and we'll see if it helps (yast2-ntp-client 2.15.11)

why is ntpd in the inst sys anyway?

Because it's in /mnt (on the target) during the inst_finish (finalizing installation). NtpClient needs to write its data (configuration) after RPM of xntp is installed.

I have a prepared fix for inst_finish / inst_umount to try
    * mount -o remount,ro /...
    * umount --force /...
when normal umount fails

This will help with other running processes that will definitely appear later in GM :) (it's just an extension of the current solution)

Needs to be tested tomorrow morning
(affected package yast2-installation.rpm)

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

the actual bug is submitted though

- When normal umount at the end of the installation fails, try
  at least: sync, remount read-only, umount --force.
- Report all services running in the installation directory
  (both #326478).
- yast2-installation-2.15.52

This actually only *helps* to avoid problems, the *real* problem is that there might be several process running and all of them should be shut-down or killed but it's uneasy to determine which process should be left (whitelist).

In my opinion, Linuxrc should work as a fallback and try to shut-down (and then shoot-down, if it doesn't help) all processes (and umount, of course) before rebooting. -- Will be solved as a feature for openSUSE 11.0

I've just had a look and there is not only ntpd but also dhcpcd running.

Please make sure that's killed as well.

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

dhcpcd? Ah, I see ... hmm, but it doesn't need to be killed because it doesn't use /mnt or does it?

I mean the dhcpcd started by yast, not the one linuxrc runs. It sits below
/mnt.

Yes, I know, but it shouldn't use /mnt at all ... We'll check it.

Proposed patch to the installation:

.local.bash_output

instead of

.target.bash_output

Index: inst_network_setup.ycp
===================================================================
--- inst_network_setup.ycp      (revision 41018)
+++ inst_network_setup.ycp      (working copy)
@@ -754,7 +754,7 @@
        FlushAllIPSettings();
 
        string cmd = sformat ("/sbin/dhcpcd '%1'", String::Quote (network_settings["network_device"]:""));
-       map run_cmd = (map) SCR::Execute (.target.bash_output, cmd);
+       map run_cmd = (map) WFM::Execute (.local.bash_output, cmd);
        y2milestone ("Running %1 returned %2", cmd, run_cmd);
 
        if (run_cmd["exit"]:-1 != 0) {

- Start dhcpcd using WFM instead of SCR.
- Kill dhcpcd at the end of the installation (both #326342).
- yast2-installation-2.15.53

Would it be possible to get a delta.iso soon up on the repositories for this so we can install RC1 to search for other bugs/issues?  This bug is preventing further troubleshooting of other issues and some people do not have the greatest luck doing net installs with the repositories often timing out.

the bug is easy to work around. Just halt the reboot and do the unmount manually

Note: This will be fixed in the final Goldmaster.  You will get a delta.iso from RC1 to the final goldmaster once we release the final version.

Just did an installation with XFS using RC2 - no more problems with XFS, so I hope this bug is fixed for good.

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

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

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