2010/10/4 James Laska <jlaska@xxxxxxxxxx>: > Thanks for posting your logs. See comments below. > > On Mon, 2010-10-04 at 16:26 +0200, Michał Piotrowski wrote: >> 2010/10/4 James Laska <jlaska@xxxxxxxxxx>: >> > On Mon, 2010-10-04 at 15:28 +0200, Michał Piotrowski wrote: >> >> 2010/10/4 James Laska <jlaska@xxxxxxxxxx>: >> >> > On Mon, 2010-10-04 at 13:10 +0200, Michał Piotrowski wrote: >> >> >> W dniu 4 października 2010 00:16 użytkownik Michał Piotrowski >> >> >> <mkkp4x4@xxxxxxxxx> napisał: >> >> >> > W dniu 3 października 2010 23:58 użytkownik Bruno Wolff III >> >> >> > <bruno@xxxxxxxx> napisał: >> >> >> >> There >> >> >> >> was some recent security updates that affected pretty much all versions. >> >> >> >> I haven't run into any f14 specific problems recently. >> >> >> >> >> >> >> > >> >> >> > Good to know. I'll try to update system. I will let know if there are >> >> >> > any problems >> >> >> >> >> >> I noticed a problem with preupgrade-cli. I rebooted system, preupgrade >> >> >> updated it, but then the system does not respond to ping - I turned >> >> >> off it by pressing power button. I connected box to the TV to see what >> >> >> happens, but the system started correctly. Strange. Do physical access >> >> >> to the machine is required when using preupgrade? >> >> >> >> >> >> Apart from that it seems that everything went well. >> >> > >> >> > Should not be required, but hard to say without more details. I suspect >> >> > it the installer stopped and was prompting you for some information >> >> > (perhaps language or keymap)? Do you have access to the installer logs >> >> > from the preupgrade attempt? >> >> >> >> Yes, I've got some logs from installation. I can post it - it's about 226 kb. >> > >> > I wouldn't mind seeing the logs (fpaste.org). Can you >> > paste /root/upgrade.log, /root/install.log and /var/log/anaconda.log? >> >> anaconda.log >> http://fpaste.org/FFnR/ > > Nice, this shows that it appears to have booted and completed a > preupgrade install. > > Specifically, you can see it starts the installer with what appears like > a preupgrade scenario > >> 23:21:44,897 INFO loader: kernel command line: >> 23:21:44,897 INFO loader: >> ks=hd:UUID=0a3d18e7-9d53-499a-b572-feda3bafec21:/boot/upgrade/ks.cfg >> 23:21:44,898 INFO loader: repo=hd::/var/cache/yum/preupgrade >> 23:21:44,898 INFO loader: preupgrade >> 23:21:44,898 INFO loader: >> stage2=hd:UUID=0a3d18e7-9d53-499a-b572-feda3bafec21:/boot/upgrade/install.img >> 23:21:44,898 INFO loader: Setting stage2 from hd:UUID=0a3d18e7-9d53-499a-b572-feda3bafec21:/boot/upgrade/install.img >> 23:21:44,899 INFO loader: method hd - UUID=0a3d18e7-9d53-499a-b572-feda3bafec21 | /boot/upgrade/install.img >> 23:21:44,899 DEBUG loader: readNetInfo /tmp/s390net not found, early return > >> 23:21:44,899 INFO loader: anaconda version 14.17.4 on x86_64 starting > > Definitely the F-14-Beta installer version. > >> 23:21:50,671 INFO loader: getting kickstart file >> 23:21:50,671 INFO loader: getting kickstart file from harddrive >> 23:21:50,671 INFO loader: Loading ks from device UUID=0a3d18e7-9d53-499a-b572-feda3bafec21 on path /boot/upgrade/ks.cfg >> 23:21:50,672 INFO loader: getFileFromBlockDevice(UUID=0a3d18e7-9d53-499a-b572-feda3bafec21, /boot/upgrade/ks.cfg) >> 23:21:50,783 INFO loader: Searching for file on path /tmp/mnt//boot/upgrade/ks.cfg >> 23:21:50,822 INFO loader: file copied to /tmp/ks.cfg > > It found and used the kickstart file (ks.cfg) created by preupgrade. > >> 23:21:53,607 INFO loader: got stage2 at url hd:UUID=0a3d18e7-9d53-499a-b572-feda3bafec21://boot/upgrade/install.img > > It finds the install.img file copied to your local disk partition by preupgrade. > >> anaconda.program >> http://fpaste.org/jNYH/ >> >> anaconda.storage >> http://fpaste.org/u5mA/ >> >> anaconda.syslog >> http://fpaste.org/AqTK/ >> >> anaconda.xlog >> http://fpaste.org/gWwP/ >> >> anaconda.yum >> http://fpaste.org/CqmZ/ >> >> upgrade.log >> http://fpaste.org/Lzn4/ > > Shows the *good* version of glibc being installed > (glibc-2.12.90-14.x86_64). So you were *not* impacted by recent glibc > problems. > >> upgrade.log.syslog >> http://fpaste.org/2KtM/ >> >> That's all I have - I deleted install.log one and a half years ago. >> >> > Did the install ever complete? >> >> I don't know - this box is not attached to any display - I was not >> able to verify it. > > I would have expected to see a line in your anaconda.log indicating that > the install completed, and it was rebooting. There are a few remaining > minor steps the installer does before completing, but I don't see a > mention of those. > > I'm sorry to ask, but if still available, I'd love to see > your /boot/upgrade/ks.cfg file as well. Unfortunately I don't have this file. > >> According to this >> http://fpaste.org/Lzn4/ >> packages was installed. >> >> > Or did you force reboot it before it >> > ever started/completed? >> >> I ran preupgrade - it downloaded all packages, then I reboot system. I >> waited for almost two hours before I turned off it manually. System at >> that time did not respond to ping. > > Upgrades can take a *lot* longer than you anticipate. By design, > preupgrade does all the network activity (downloading kernel+initrd, > install.img and packages) from a running system. I've got a self build kernel 2.6.35.6-34.fc13.x86_64. I am almost sure that I have not seen kernel in the list of packages to upgrade. > The upgrade itself is > done without networking. In scenarios where preupgrade doesn't have > sufficient /boot disk space for content, it will perform a network > upgrade. That doesn't seem to be the case from your logs. > > In summary, in your case, I would not expect networking to be active > during the upgrade process. > >> > When preupgrade reboots into the installer, it >> > sets up a boot-next grub target which will boot into the installer >> > *only* for the next reboot. If you reboot multiple times before >> > starting the installer, it will boot back into your previously defined >> > default boot target. >> >> It seems to me that the system is properly upgraded. > > I suspect the upgrade completed and was waiting on user input, It seemed to me that preupgrade process should not require any user interactions. I've used this tool twice on this system and I do not recall that I had to provide any user input. > or was > still in the middle of performing package upgrade %scripts and rebooted. Maybe. However, it seems to me that the update of 420 packages should not take so long. That's why I turned off the box. Unfortunately, on my laptop virtualization is not working too fast, so it'll not check whether preupgrade actually works well. But maybe someone else will find the time to check. Thanks for your analysis. > > Thanks, > James > Regards, Michal -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
