[opensuse-factory] Dirty filesystem after Yast update of RC1 and halt + reboot.
Hi, I told Yast to update all updatables. It downloaded over a gigabit, it took the whole afternoon. It is a nuisance when it screeches over a network failure and doesn't retry till I come by the computer and tell it to retry. In the end, I told it to reboot, or perhaps halt; in any case, it halted. I booted again, and I saw the system running a long filesystem check because the root partition had not been cleanly umounted. I thought this was a known bug with the RC1 DVD, but not with the installed system. -- Cheers, Carlos E. R. (from RC1) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Carlos E. R. wrote:
Hi,
I told Yast to update all updatables. It downloaded over a gigabit, it took the whole afternoon. It is a nuisance when it screeches over a network failure and doesn't retry till I come by the computer and tell it to retry.
Good point, YaST should either try to download automatically (after 60 seconds or so) or should give the opportunity to [ Retry Automatically ]. Anyway, this would need to be configurable: * Try automatically * Max tries (for not to end up in a loop) * Time wait Please, file an Enhancement request.
In the end, I told it to reboot, or perhaps halt; in any case, it halted. I booted again, and I saw the system running a long filesystem check because the root partition had not been cleanly umounted.
I thought this was a known bug with the RC1 DVD, but not with the installed system.
Yes, it was a bug in RC1 when rebooting from First Stage to Second Stage of the installation. Sometimes, there were two processes running under the /mnt path (/mnt == Installation chroot). These processes were: 'ntpd' and 'dhcpcd'. How exactly did you rebooted the system? I'm not sure, but I have a feeling that in a minimal installation I saw something like: reboot: fuser: command not found And 'fuser' is a command that can list or even kill processes running depending on the directory that they have open. Please, write mote details, you can additionally inspect the end of YaST logs: /var/log/YaST2/y2log Have a nice day Lukas -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic
Lukas Ocilka wrote:
Carlos E. R. wrote:
I told Yast to update all updatables. It downloaded over a gigabit, it took the whole afternoon. It is a nuisance when it screeches over a network failure and doesn't retry till I come by the computer and tell it to retry.
Good point, YaST should either try to download automatically (after 60 seconds or so) or should give the opportunity to [ Retry Automatically ].
Anyway, this would need to be configurable: * Try automatically * Max tries (for not to end up in a loop) * Time wait
Please, file an Enhancement request.
I just filed bug #328822 report because this was annoying me, too. Zypper too should try reloading: I updated my RC1 over the command line and had to start the process around 5 times until it finally had all packages. Regards nordi --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
nordi wrote:
Please, file an Enhancement request.
I just filed bug #328822 report because this was annoying me, too. Zypper too should try reloading: I updated my RC1 over the command line and had to start the process around 5 times until it finally had all packages.
A separate enhancement request #328870 has been created as a clone of your bugreport #328822. It always makes sense to file one bugreport/enhancement request for one issue. Such issues are very often solved by different developers. Bye Lukas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2007-09-27 at 09:27 +0200, Lukas Ocilka wrote:
Carlos E. R. wrote:
Hi,
I told Yast to update all updatables. It downloaded over a gigabit, it took the whole afternoon. It is a nuisance when it screeches over a network failure and doesn't retry till I come by the computer and tell it to retry.
Good point, YaST should either try to download automatically (after 60 seconds or so) or should give the opportunity to [ Retry Automatically ].
Anyway, this would need to be configurable: * Try automatically * Max tries (for not to end up in a loop) * Time wait
Another thing is that as it downloads one file, installs it, downloads another, installs it... if it stops midway the system remains in an undefined state: for instance, not RC1, not RC2. There might be inconsistencies, too. It would be better to download everything, then install everything.
Please, file an Enhancement request.
Ok, will do. [...] Huh... er... how do I do that? I can't find a bugzilla option or button for that. Enter new bug, perhaps? Then what? Choose "enhancement" in the "severity" drop list? Sorry, I have never done that, and the FAQ doesn't explain it.
In the end, I told it to reboot, or perhaps halt; in any case, it halted. I booted again, and I saw the system running a long filesystem check because the root partition had not been cleanly umounted.
I thought this was a known bug with the RC1 DVD, but not with the installed system.
Yes, it was a bug in RC1 when rebooting from First Stage to Second Stage of the installation. Sometimes, there were two processes running under the /mnt path (/mnt == Installation chroot). These processes were: 'ntpd' and 'dhcpcd'.
I remember that. But this was not the install system, but the already installed system.
How exactly did you rebooted the system?
- From inside kde user session, choose halt or reboot. My intention was to select reboot, but maybe I miss-clicked and choose halt. In any case, the system halted. Then I powered up again, and saw the fsck messages. Notice that after a large YOU update, like from RC1 to RC2, many libraries and programs have a different version on disk and in memory. Many things could fail.
I'm not sure, but I have a feeling that in a minimal installation I saw something like: reboot: fuser: command not found
And 'fuser' is a command that can list or even kill processes running depending on the directory that they have open. Please, write mote details, you can additionally inspect the end of YaST logs: /var/log/YaST2/y2log
But Yast was not running when I rebooted. The YOU session finished without saying anything, but I knew a reboot was in order, so I did. I don't think there will be anything in the Yast log, nor in any other log, as it will have been a problem with the rc or halt scripts: as the system is not cleanly umounted and flushed, the last entries in the logs, if any, will be in the syslog memory or kernel buffers and lost. What I see in the /var/log/messages is this: Sep 27 01:11:09 minas-morgul smartd[24826]: Device: /dev/hdd, SMART Usage Attribute: 195 Hardware_ECC_Recovered changed from 59 to 60 Sep 27 01:27:56 minas-morgul sudo: cer : pam_authenticate: Conversation error ; TTY=pts/8 ; PWD=/home/cer ; USER=root ; COMMAND=/opt/kde3/bin/kdesu_stub - Sep 27 01:27:58 minas-morgul gconfd (cer-4475): Received signal 15, shutting down cleanly Sep 27 01:27:58 minas-morgul gconfd (cer-4475): Exiting Sep 27 01:28:07 minas-morgul console-kit-daemon[2388]: GLib-CRITICAL: g_queue_push_head: assertion `queue != NULL' failed Sep 27 01:28:08 minas-morgul shutdown[4628]: shutting down for system halt Sep 27 01:28:09 minas-morgul init: Switching to runlevel: 0 Sep 27 01:28:11 minas-morgul ntpd[22031]: ntpd exiting on signal 15 Sep 27 01:28:11 minas-morgul smartd[24826]: smartd received signal 15: Terminated Sep 27 01:28:12 minas-morgul smartd[24826]: smartd is exiting (exit status 0) Sep 27 01:28:12 minas-morgul auditd[17825]: The audit daemon is exiting. Sep 27 01:28:12 minas-morgul audispd[17830]: input read: EOF Sep 27 01:28:13 minas-morgul sshd[21181]: Received signal 15; terminating. Sep 27 01:28:13 minas-morgul syslog-ng[25437]: syslog-ng version 1.6.12 going down Sep 27 01:30:55 minas-morgul syslog-ng[3132]: syslog-ng version 1.6.12 starting Nothing there. The kernel log (verbosity=7) contains: Sep 27 01:28:11 minas-morgul kernel: bootsplash: status on console 0 changed to on Sep 27 01:28:12 minas-morgul kernel: audit(1190849291.979:471): audit_pid=0 old=17825 by auid=1000 Sep 27 01:28:12 minas-morgul kernel: audit(1190849291.979:472): auid=1000 uid=0 gid=0 pid=17830 comm="audispd" sig=6 Sep 27 01:28:13 minas-morgul kernel: pnp: Device 00:0e disabled. Sep 27 01:28:13 minas-morgul kernel: ACPI: PCI interrupt for device 0000:00:1f.5 disabled Sep 27 01:28:13 minas-morgul kernel: Kernel logging (proc) stopped. Sep 27 01:28:13 minas-morgul kernel: Kernel log daemon terminating. Sep 27 01:31:00 minas-morgul kernel: klogd 1.4.1, log source = /proc/kmsg started. The only way to see something would be a "halt" log, but it could not be saved. Perhaps if the halt process stops at the last second so that we can have a peep at the screen... :-? - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFG/PAOtTMYHG2NR9URAgiGAJ4k8bnLMspHoREGlOA198nvdyZG+gCbBXWs COfljd65Y4rhiriaR0275/A= =7LqD -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Carlos E. R. wrote:
Another thing is that as it downloads one file, installs it, downloads another, installs it... if it stops midway the system remains in an undefined state: for instance, not RC1, not RC2. There might be inconsistencies, too. It would be better to download everything, then install everything. Which does not work if you have a small disk (or partition, as in my case).
Please, file an Enhancement request.
Ok, will do.
[...]
Huh... er... how do I do that? I can't find a bugzilla option or button for that. Enter new bug, perhaps? Then what? Choose "enhancement" in the "severity" drop list?
We already have bugs #328870 and #328870. With "enhancement request" he meant you should set the severity of the bug to "Enhancement". Regards nordi --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (3)
-
Carlos E. R. -
Lukas Ocilka -
nordi