Description of problem: smartd service not starting in Fedora Core 15 x86_64 after "preupgrade" from most recent FC14 x86_64 files Version-Release number of selected component (if applicable): Fedora Core 15 x86_64 upgraded from FC14 most recent public kernel using "preupgrade" How reproducible: Unable to reproduce since "downgrade" from FC15 to FC14 is not considered a "supported" function Steps to Reproduce: 0. Use "yum" on FC14 to upgrade all FC14 files to most latest versions 1. Upgrade from most up-to-date FC14 files to most up-to-date FC15 using "preupgrade" 2. Check running services 3. Find "smartd" not running and not "startable" using "systemctl" Actual results: Upgraded from FC14 latest public x86_64 kernel to Fc15 Expected results: "preupgrade" should properly upgrade all packages existing on a platform Additional info: Copied "/etc/rc.d/init.d/smartd" file from FC14 platform to FC15 platform. Set attributes to "755" Run "service smartd start" in FC15 Observe "smartd" start on Console Check /var/log/messages to verify "smartd" found all attached hard disks. It did.
> 3. Find "smartd" not running and not "startable" using "systemctl" What do you mean by this? Could you provide more info? Especially about the "not startable" part? Thanks
I could not find any way in FC15 to check the status of "smartd". Maybe I missed something or just don't understand these new changes. FWIW, the 'old style' "service" command just works every time without issue since it works against scripts located in "init.d". That is just so simple to troubleshoot...even in the early hours of the morning. What I do know about this problem is this: (1) I copied the "smartd" script from the "init.d" folder on a FC14 to the same location on my upgraded FC15 system. (2) Then I ran "service smartd status" like I am used to doing and found the service "stopped". (3) Since I knew the service was working before upgrade, logic dictates the upgrade process caused the service to stop. (4) So I ran "service smartd start" and I saw the service start normally with all the extra "systemctl" verbiage (multiple lines of output) on the Console. I would hate to build a FC14 system just to retest preupgrade to FC15 to prove this problem. Perhaps there is an upgrade log somewhere that captures all the steps that were executed during that "preupgrade" process? I have not yet formatted the FC15 system disk and replaced it with FC14; FC15 is also experiencing strange stability issues in the CLI no less, but FC14 ran flawless on the same hardware. I have not bothered testing the FC15 GUI.
ok, thanks for the info. smartmontools use systemd service files instead of old init scripts, but it should work fine. Just because the trigger that makes smartd start during boot was set to F-14's smartmontools version (which got updated) it did not make smartd start during boot, but it should be working fine with systemd commands OR when using old sysv init compatibility commands (like 'chkconfig' or 'service'). So, how to fix this problem: 1) disable smartd chkconfig smartd off 1) stop smartd service smartd stop 2) remove your file (/etc/init.d/smartd) 3) systemd's file is /lib/systemd/system/smartd.service and this file is installed from smartmontools package. Check this file is present 4) make systemd reload it's configuration systemctl daemon-reload 5) enable smartd chkconfig smartd on you can check the status with: systemctl list-units --all | grep smartd if it outputs anything, smartd is enabled. Maybe there is some better way, but this works for me :) The only missing part from Fedora 14 -> Fedora 15 update was: systemctl enable smartd.service I'll fix it in Fedora 15, so it works for other users. Unfortunately, I can't check whether smartd was enabled or not in Fedora 14 once Fedora 15 is installed, so I'll just prevent it from happening again, but can't fix it. You'll need to fix it manually (for fresh F14->F15 updates only step 5) is required).
Here's what I figured out.... (1) I removed the "smartd" script from "init.d" since I knew it worked. I noticed that "systemctl status smartd.service" would consistently show the service as "dead" (2) To be certain that "smartmontools" was properly installed, I ran "yum reinstall smartmontools" (3) "systemctl status smartd.service" still shows the service as "dead". Now what is the default state for "smartd" when it's installed? In FC14 running "chkconfig --list" would show "smartd" set to "off" for all runlevels. Perhaps the same behavior carries over to FC15? (4) Run "systemctl enable smartd.service" (5) Then I rebooted the system to see what would happen (6) Then I re-ran "systemctl status smartd.service" and saw the service "active" Is it possible that the prior runlevel state of "smartd" is not preserved during the upgrade? I ask because I routinely monitor all of my systems; "smartd" and "lm_sensors" are important tools to me.
(In reply to comment #4) > Here's what I figured out.... > > (1) I removed the "smartd" script from "init.d" since I knew it worked. I > noticed that "systemctl status smartd.service" would consistently show the > service as "dead" this means it's not running. You can start it using: systemctl start smartd.service or service smartd start (which calls systemctl command, this is for backward compatibility) > > (2) To be certain that "smartmontools" was properly installed, I ran "yum > reinstall smartmontools" > > (3) "systemctl status smartd.service" still shows the service as "dead". Now > what is the default state for "smartd" when it's installed? In FC14 running > "chkconfig --list" would show "smartd" set to "off" for all runlevels. Perhaps > the same behavior carries over to FC15? Policy in Fedora says that installed packages should not be running by default (with some strict exceptions), so it's correct. You have to start/enable it manually chkconfig --list does not work for systemd services you can use systemctl list-units --all | grep smartd There is command "systemctl is-enabled", but it does not work right now (bug #699027 ) you can look at : http://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet > > (4) Run "systemctl enable smartd.service" > > (5) Then I rebooted the system to see what would happen > > (6) Then I re-ran "systemctl status smartd.service" and saw the service > "active" > > Is it possible that the prior runlevel state of "smartd" is not preserved > during the upgrade? I ask because I routinely monitor all of my systems; > "smartd" and "lm_sensors" are important tools to me. If you install smartmontools on F-14, F-15 or any other Fedora version, it won't start by default. You have to enable it manually. It's expected that if you have service enabled and update its package (wheter in F14 or during F14->F15 makes no difference) it should stay enabled. Unfortunately, because we've changed init system from sysv init to systemd, some special hacks are required for package to stay enabled. (It needs to check, whether it's enabled and enable it automatically after new package was installed.) For smartmontools, it was working fine with F14 packages that existed when smartmontools was changed to systemd. With updated F14 packages that "stay enabled" script is not triggered, so you have to enable it manually. There are some other services that have problem with F14->F15 update, see https://fedoraproject.org/wiki/Common_F15_bugs#upgrade-disabled-services
smartmontools-5.41-2.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/smartmontools-5.41-2.fc15
Package smartmontools-5.41-2.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing smartmontools-5.41-2.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/smartmontools-5.41-2.fc15 then log in and leave karma (feedback).
Please close. I am unable to test as Fedora Core 15 is proving to be unstable on hardware that runs Fedora Core 14 flawlessly. I have tried updating Fedora Core 15 to resolve the random kernel crashes that I experience with it but it does not help. Also, it is most unfortunate that these kernel crashes do not write any information to Syslog. Taking a picture of the Console screen isn't useful as most of the kernel crashes scroll off the screen. It is a shame that Fedora Core 15 hasn't proven stable like previous releases. It is so bad that it reminds me of Fedora Core 2.
Please do not change bug status, especially not in case if there is any activity in bug report. Bug status should be change only by bug assignee, bugbot or bug zapper. For your kernel issue - a) try to collect as much data as possible and file bug against kernel, b) try to ask on fedora-kernel for help how to get needed information.
Please remove my email from this case. I no longer wish to be notified of it's status.
unfortunately, this can't be done. Only email address of "watching" people can be removed, but reporter, assignee and qa contact can't be removed. Anyway, there should be only 4 emails (update submitted stable, pushed stable, stable and bug close).
smartmontools-5.41-2.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.