You are here
Please note I have also posted this on the Ubuntu forums where I have added a bit more info.
Basically I have just done a fresh install of TKL-Core-Lucid in a KVM VM (under ProxmoxVE) and all went well. I have done some minor customisations (disabled byobu, added my custom sources.list which uses my local mirror and added 01proxy file for my LAN apt-cacher) and still all seemed well. FYI my custom sources.list has lucid-updates uncommented (not sure if that deviates from default).
Then I ran apt-get update && apt-get upgrade and all seemed to go fine until installing udev. It froze (using 0% CPU according to Proxmox). I waited about 20 mins and rebooted the VM. Now in the (Proxmox) VNC window it doesn't complete the boot and seems to hang, although I can log in fine via SSH. But when I try to run any apt related stuff it complains that udev not installed properly (as you'd expect). Rerunning the install just results in the same freeze. Grrr!
So where to now? I know I could probably quite easily work around this (by reinstalling and simply not running apt-get upgrade) but I'd rather work it out and lodge a bug with the relevant party (assuming its not something stupid I've done).
Tried again, slightly different but still errors...
Did a clean install from ISO to a new VM. This time I commented out my local mirror, just leaving lucid-updates from archive.ubuntu.com and cleared my apt-cacher of the other version of udev (to make sure it downloaded a clean copy). I did the same 3 customisations (disabled byobu, added my custom sources.list which uses my local mirror and added 01proxy file for my LAN apt-cacher) but this time only did apt-get install udev (after apt-get update). It didn't freeze/hang this time but it still took way longer than I think it should and this time it threw up a few errors. Here's what happened:
But it seems to reboot ok and when I tried to reinstall it said the udev was at the latest version (so obviously TKL thinks its installed ok).
To double check, I installed again to another clean VM on my PVE host. This time I made no changes at all, just a clean default install. I got exactly the same result as above. Neither of these installs had any other modifications or packages installed exept from the ISO (first boot auto updates didn't run due to no DHCP server available).
Are these errors a problem? Do you think the hanging of the first is related to the errors on the second and third attempts? Or was it perhaps just a dodgey file on my local mirror (it has happened before). Should I try downloading the ISO again?
I think there's a bug somewhere
I've seen reports of this kind on other forums. But I don't have a clue what can be happening.
Thanks for your input Adrian
I haven't had a lot of success over on the Ubuntu forums, but that's ok.
I just didn't worry about it tonight and carried on with my KnowledgeTree investigstions and it didn't seem to cause any issues so obvioulsy its non-fatal.
Perhaps in my initial trial there was another package that upgraded that added to the issue, or perhaps as I mentioned it was a(n extra) dodgey udev from my local mirror? I guess I'll just ignore it.
I've just had exactly the same problem as JedMeister
I did a clean install of TKL-Lucid-Core in ProxmoxVE, SFTP'ed cntlm over & configured it, did apt-get update then apt-get upgrade which stops at "setting up udev (151-12.1)".
Is there a way of doing apt-get upgrade in TKL-Lucid-Core for everything except udev?
Upgrading udev on its own works - but I'd just wait for now...
So if you upgrade udev first (apt-get install udev) then run apt-get upgrade it will work (at least it did for me). But I wouldn't yet because not only is there the udev bug, there is also a bug in the Webmin package. Webmin stops working after apt-get upgrade! FYI the bug reports I filed are here (udev) and here (webmin).
For now just upgrade the packages that you need to upgrade. Don't worry about packages with security issues as they are automatically handled daily by cron (ie auto security updates).
Hang tight for now. I'm sure there will be some resolution to this soon as the TKL devs are looking to re-release all the current appliances on top of Core-Lucid. That will mean will some sort fix or workaround cause they are like that! :)
TurnKey Lucid beta builds are around the corner
Hey folks. I haven't had a chance to look into the above stated issues, and not sure I will. The beta Lucid builds are almost complete, and are up to date with the latest available packages. We never came across any udev/webmin issues during the builds, so all seems well.
As you know, we don't like to commit to exact time frames, but we are pushing for release in a week or two, and are currently on schedule.
Awesome
If the new images include all the latest packages and everything works then the bugs I filed will be irrelevant and all will be well in my world. Nice :)
No Solution on Turnkey (11.3-lucid-x86)
Hi Alon, all,
Turnkey is brilliant in execution as well as concept. And everything 'works', most of the time. I want to point out that the post you added was in 2010-Oct, and I still have this problem with the download from last week in 2012-May.
I assert that it wasn't fixed/worked out in prior releases since 2010.
I think it is a good idea to offer some directions in a readme or some place about what to do with this issue. I've made a few attempts and still I don't have a definitive receipie. When I get 'my' solution, I'll post it at the bottom. However ... from what I've seen, everyone reads the threads, and reinvents the wheel because what gets posted more than likely is a subjective experience of how they "think it worked".
For myself, I'm using a VirtualBox configuration and making step-by-step backups so I don't need to lose hours retracing mysteps to after checking a promising option.
Suggestion:
Hope that helps :-)
/w
turnkey-wordpress-11.0rc-lucid-x86.iso in VMware 7.1.0 build-261
I installed turnkey-wordpress-11.0rc-lucid-x86.iso in VMware 7.1.0 build-261024, installed and configured cntlm (package to get out to public web from behind ISA gateway/proxy) & then tried to install just udev by itself. It hung during the update process as shown below:
Workaround
I had the same problem. What I did to solve it:
Logged in on another terminal, from there I killed ("ps aux | grep apt" and "kill -15 ...") the offending process. This renders the update mechanism temporarily useless.
It will complain about a lock, just remove it (with rm) as the system suggests.
Do "dpkg --configure -a" to repair the package system, when it hangs with udev do "Ctrl-C".
"apt-get update" and "apt-get upgrade" should give you a working system again.
I found that the "udev
I found that the "udev --restart" process was hung (stalled?) whenever this happened (which seems 100% of the time). I just invoke the kill on the restart process and all worked from there. -- YMMV --
I found Peter's workaround useful
but killing the restart process may be a better one? Thanks for that.
I have tested in a couple of different environments and it only seems to happen in a VM (experienced it both in KVM and VirtualBox). Interestingly, I've found that it doesn't do it in a chroot environment, even if the chroot host does do it.
Killing the offending process is probably better
because I just worked on the assumption that the problem lies within the package system. By just killing the offending process you can circumvent all the measures to restore it to a working state. I am not sure though what this means for the functionality for the overall system.
>JedMeister - Mon, 2010/12/13
>JedMeister - Mon, 2010/12/13 - 05:52.
>but killing the restart process may be a better one? Thanks for that.
Works for me.
> I have tested in a couple of different environments and it only seems to happen in a VM
Experienced the same issue on 3 different rel hardware install :-(
That's not good!
I have changed the bug report to 'confirmed' as I think we have enough feedback here to suggest that this is quite a problem for many. It seems to me to be an upstream bug (Ubuntu?) but as I haven't found much on this issue anywhere else or experienced it on my desktop Ubuntu I haven't linked it to Ubuntu.
As the udev update is not security related perhaps the package should be held back from upgrade in TKL? I know its a hack but so long as its documented and there aren't any security updates to udev it shouldn't be a problem should it?
To hold back udev from further updates:
If the condition only happens
If the condition only happens in virtual environments, then the risk is rather low assuming people are doing snapshots prior to any changes. (and everyone should be doing this anyway).
I just offered the kill solution since... and I am making a huge assumption here... the process in question is just doing a restart/reload of the udev process. Now... if there are events in queue that rely on udev that are not getting notified as a result, then yes there might be some untoward results.
Another try: confirmed issue
Just unpacked a brand new machine (an interesting hp proliant microserver), installed the same lucid based Turnkey RC.
Bad things: got exactly the same issue.
Killed from another console session to workaroud...
Good things: all hardware recognized (not tried the embedded raid mode).
Still an issue in 11.0 (newly released stable - not RC)
I just ran apt-get upgrade on a clean install of v11.0 (stable - as yet officially announced - see here) and this bug still exists (as tested in VirtualBox v3.2.8_OSE under Ubuntu 10.04). Upgrade stalls at:
The workaround above still works though. For clarity I will reiterate here:
Create a new SSH connection to your server. In the new session find the PID of the offending process:
which returns something similar to (PID 1928 in this instance):
Then kill the process (substtute 1928 for the PID discovered above):
It still takes a long time to complete but it did for me. I then put a hold on udev so this problem doesn't happen again:
I'm getting this problem on
I'm getting this problem on the latest Trac appliance trac-11.0-lucid-x86
I used
and killed the process to finish the apt-get upgrade process.
I re-ran apt-get install udev and it thinks that it's at the latest version.
It should be
AFAIK its the restart process that hangs, after updating so it should now be at the latest version.
I encountered this problem while upgrading from 11.0-RC
I experienced this problem while upgrading from 11.0-RC. The upgrade hung when upgrading from udev (151-12.1) to udev (151-12.3). After 15 minutes of waiting, I started googling and found this thread. Killing 'restart udev' allowed the upgrade to complete, but left udev status "start/starting" not "start/running" and no udevd daemons were running. All attempts to start or restart udev failed. Finally crossed my fingers and rebooted afterwhich udev was running as expected. As an experiment, I tried 'restart udev' again to see if it was functional. Once again, udev stopped and then refused to start again. Additional googling turned up the following bug report which I think is related. https://bugs.launchpad.net/ubuntu/+source/udev/+bug/674704 Note that the bug report refers to a 'headless server' which I'm guessing would apply to a TurnKey appliance. I'll include my console output and a stack trace of 'start udev' in the hope it will be useful.
Checkout the following warnings I just spotted in the console capture. I think stop and start may have the wrong runlevels assigned.Nevermind different start & stop here.
Information is free, knowledge is acquired, but wisdom is earned.
Thanks John
Finding that Ubuntu Bug report was good. It confirms that its an Ubuntu issue rather than something specific to TKL.
I wonder if it's hardware specific?
Same issue with different ending
Same problem here with the wordpress Appliance, Just downloaded it and tested today, I did the workaround and tried to install udev again, hit ctrl+c and apt continued installing everything (not udev, the other packages to upgrade), then I did "apt-get install udev" and install went trough with an error complaining about a previous error (lol), but after that now systems says that udev is already the newest version. But now everytime I do apt-get update I get this error:
With Microsoft you get windows and gates, with Linux you get the whole house!!!
Try this:
To repair the package management system use
when it hangs with udev follow the steps in this post. Actually here's a copy-paste to make it really easy:
Create a new SSH connection to your server. In the new session find the PID of the offending process:
which returns something similar to (PID 1928 in this instance):
Then kill the process (substtute 1928 for the PID discovered above):
It still takes a long time to complete but it did for me. I then put a hold on udev so this problem doesn't happen again:
For also problem wiht KVM Proxmox
Confimr. LAtes Proxmox 1.7 on KVM VPS fails...
try apt-get install udev
Yo solo se que no se nada...
Castris Hosting
i have the same problem on
i have the same problem on the prestashop appliance with udev, it hangs up when doing an apt-upgrade
Still exists on fresh wordpress appliance installation
Bug still present, workaround still works, tried it on the turnkey wordpress appliance with no customization, using Virtualbox
With Microsoft you get windows and gates, with Linux you get the whole house!!!
I would've thought v11.2 would include latest udev!?
Which would mean no issue (until the next time udev is updated in the repos). Seems strange that the latest maintenance release doesn't include the latest udev.
That's exactly what I thought
That was one of the reasons I did a clean install, unfortunately bug is still there, I wonder if it's ubuntu or Turnkey package version issue?
With Microsoft you get windows and gates, with Linux you get the whole house!!!
It's an upstream Ubuntu bug
But it appears that it only occurs in certain headless scenarios (which unfortunately covers the whole TKL range). At this late stage I doubt that it will ever be fixed.
I anticipated that udev would be at the latest version in the v11.2 release meaning that it wouldn't resurface until the next udev update. But that's obviously not the case.
Oh well, doesn't really make that much difference. Seeing as TKL automatically takes care of security updates, there's no need to apply updates anyway, unless you really want to.
Not sure
That's what I've used and its worked for me on all systems I've used it on. You can also do that sort of thing with aptitude (a more advanced commandline package management app than apt-get) but you'll need to install it first (apt-get update && apt-get install aptitude).
I think it work's (i don't get the error anymore )
Hey Jer,
I think i got it...
if you use apt-get install aptitude
after the installation has finished
try aptitude install update
then aptitude install udev and it works...
Hope it helps !!!
Perhaps the udev package has been fixed?
AFAIK using aptitude or apt-get shouldn't make any difference as they are both front-ends for dpkg. So although the front-end handling is a little different, the back-end processing should be identical.
So my guess is either that the udev package in Ubuntu has been fixed. Or if you are using the latest v11.3 TKL release, the version of udev included is the latest and doesn't need to be updated (hence no error).
Sorry to burst your bubble... But glad its working for you! :)
Although there is obviously a 3rd possibility, and that is that aptitude does indeed do something slightly differently with the dpkg commands it calls which makes a difference (but I'm not convinced).
Hey... i was'nt using the
Hey... i was'nt using the last version...
I had the error.. i could'nt do the undev update... but i play'd around with it.. and after i installed aptitude it worked... any way... just want to let you know.. :)
Thanks for posting
I don't mean to sound ungrateful, I just don't exactly understand why installing aptitude seems to work around this bug for you. The bug is actually with the udev package itself (nothing to do with apt-get) so I don't understand how installing an alternative package management app can have any bearing on it.
But I guess bottom line is that it works for you now which is great! Did you also put a hold on udev? So it doesn't happen again! If not I'd recommend that you do, although it's possible there won't be any new updates to udev now at this late stage (although you never know...)
And although apt-get upgrade should really work flawlessly, I find the best workaround is to just not do it! :) Security updates install automatically and it's a server, not a desktop so IMO there isn't really any need to upgrade the packages manually.
Second part of step one not required
The 'apt-get install aptitude' bit (from step 1) installs a commandline app called aptitude and as is not required (assuming the rest works ok for you). The '&&' just means that the part after it will execute once the part before has completed successfully.
On the other hand if you wish to use aptitude to hold the package (instead of step 2) then you'll need to check google cause I don't use it.
That can work
But I have had mixed result from that way of doing it. The above method is preferred (using a second ssh connection to kill the udev restart process) IMO.
There should be no security risk in not upgrading
All the main components have security patches applied automatically (it's set up as a daily cron job OOTB). So doing a system wide upgrade is only applying the non-security updates. Therefore is generally not required.
Like it is described above, if you do still wish to do a full system upgrade, then just put a hold on udev. I haven't checked recently, but none of the previous udev updates have involved security issues.
Figured out how to get this to work without error!
I've tested this several times on multiple installs.
What I ended up doing was just after the install, be it using the image or iso.
1) connect with putty
2) stop all services that work with udev ( I also added a few more just to be safe)
3) apt-get update
4) apt-get dist-upgrade
This will result with every needed update completeing without issue.
Note: you can also use ps -e to check to ensure services has been stopped before embarking on the upgrade.
-Jason
Failed Webmin update - apparent udev issue
Thank you thank you thank you to everyone who has provided solutions. I stupidly did a webmin update and it borked my turnkey torrentserver. I have tried many different procedures over the past week, but what ultimately worked was:
1. logging in with putty from a windows machine
2. following Jeremy's solution (Jeremy (aka JedMe... - Wed, 2010/12/29 - 07:47.), however (and interestingly) when I typed "ps aux|grep "restart udev"", I was getting some process that kept changing its PID, UNTIL I typed just "ps aux|grep "udev"" (hit return) and then "ps aux|grep "restart udev"". Then the correct (unchanging) PID came up (along with the one that changed). After that it was smooth sailing!
3. killed the process, echo hold, and reboot.
I mention it in case anyone else runs into the same problem. Also, I did all commands as sudo. just in case. I did not have to do a clean install. Now I just have to figure out how to get MLDonkey going again!
Thanks again!
Worked perfect for me
This worked for me
Regards,
Ken
":0)
http://www.github.com/DocCyblade
Bit slow getting to you...
Obviously you've fixed it, but problems like that are almost always caused by networking issues (connectivity/proxy/firewall/DNS/etc).
No Solution on Turnkey (11.3-lucid-x86)
Hi gang,
I hope you are going well. I also had this problem with the udev upgrade. I did the
sudo service udev stop
Command and ran the upgrade. When I did that I ran fowl of a circular error between initramfs and casper packages. I tried out the various receipes suggested in the article mentioned below, but the entanglement with the casper upgrade stopped all these options.
Luck we are on a virtual machine. I wiped everything and started with a fresh copy of the redmine server vm. At each step, I took a numbered back-up snapshot of the vm-image files. By trial and back-stepping to the last working image, I got to a point were all the other upgrades worked except for the ones that depend on initframfs (9 in all, including casper & udev). My plan is to again look at the suggestions here:
If you look at the blog, you need initframs problems repaired before a reboot. That's true I had a few failed-to-boot trials. So, I recommend using the (equivalent) virtualbox "save machine state" Quit option when making the back-up snapshots. Then, test the re-boot ;-) It will save hours.
I saw with sym-link problems with initframs in the console output, so my gut feel is that none of the nine packages that depend on initframs package actually upgraded successfully, including udev. At least with the current ubuntu archive and this turnkey-redmine vm.
I'd love to hear if someone has a receipe to remove the initframs, clean apt and then install it afresh?
Good luck and let us (all) know if you do better than I've got so far.
/ will
Easiest solution IMO...
The easiest solution I think is to just not run apt-get upgrade! Unless you have a specific reason to, there is no issue not running it as all security updates are auto installed every day. If there is a specific package you wish to update then just 'apt-get update && apt-get install <package-name>' and that package (and it's dependancies) will upgrade and nothing else.
Hopefully it won't be too long and we can all move on to TKL v12 and be done with this bug...
initramfs / casper deadly embrace ...
Hi all,
Just for fun ( ) I created a new redmine vm from the download and watched the very first "Security updates" console output. The deadly embrace between casper and initramfs I documented above, is there at the begining in the output on-screen for the current security updates. I observe,
That this premise is false (at present) imho. Quite a few things will not actually update. I feel that the answer will be in the ubuntu forums. For me, I'm going to skip the initial security update on a virgin machine and see if that lets me individually upgrade the casper and initramfs package or not.
It is kind of annoying so if one of you is a wizard perhaps you can let me know how to fix the problem manually? I'm more fussed about the other things that also depend on initramfs myself. Here I was thinking it was only udev failing. No such luck, a lot of red shows on the aptitude preview screen.
Looking forward to comments and suggestions ...
/ Will
Not sure about initramfs, but casper errors don't matter
Casper is only required for live systems (and AFAIK the install process) but once you have installed it can have as many errors as it likes without being a problem. I haven't had any initramfs problems. And if they are anything more than warnings you will know because your sysytem won't reboot (from my understanding initramfs is the RAM image that linux first boots into prior to mounting the full filesystem).
Add new comment