Re: UPStart errors on Xenial with systemd
Serge Hallyn [2016-04-05 13:30 +]: > Note I can easily reproduce this by creating a 14.04 lxd container and > doing do-release-upgrade in there. Thanks, I see that as well. Since there was no existing bug report, I created one now: https://bugs.launchpad.net/ubuntu/+source/cron/+bug/1566333 So please feel free to subscribe. Let's keep the conversation on the bug report, as private mail is an exceptionally bad medium for bug reports. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: UPStart errors on Xenial with systemd
Hello Martinx, Martinx - ジェームズ [2016-04-04 18:49 -0300]: > > Symlink: > > cron -> /lib/init/upstart-job > > And a file: > > cron.dpkg-new > > Maybe, during "do-release-upgrade" from 14.04 to 16.04, it didn't upgraded > that file / link... > > This looks like an upgrade bug! Right, it sounds like the new "cron" got unpacked, but not configured, i. e. the upgrade crashed somewhere in the middle. What's the output of "dpkg -s cron"? It should have "Status: install ok installed", if it's anything like "unpacked", or "unconfigured" or so it's broken. Does "sudo apt-get -f install" clean this up? Can you put the upgrade logs from /var/log/dist-upgrade/ somewhere? This hopefully has some clues where the upgrade failed. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: Distro-provided mechanism to clean up old kernels
Dustin Kirkland [2012-02-16 10:11 -0600]: > I don't want to go into all the ways and reasons that the one-liner > above is sub-optimal or even evil, but I would like to call attention > to the generic problem and suggest that as a distribution, we provide > a supported and recommended utility to handle this. I agree. Especially since we switched to a two-weeks kernel update rhythm where almost every update in the most recent stable and LTS releases breaks ABI, kernels pile up like mad. > 1) Surely we're not the only Ubuntu users whose /boot or root > partition has filled up with age-old kernels, are we? Certainly not. I ran into several "home support" cases where Ubuntu started acting strangely because the root partition filled up, and we removed about 15 old kernels. > 2) Is computer-janitor here to stay, or to be abandoned in favor of > something else? > 3) Can we expect computer-janitor to work on command-line only > environments (Ubuntu servers) too? If so, can we get SRUs out so that > it works on older distributions? TBH, I don't think c-j or any other manual tool is the right answer here. While it's nice to have it, it doesn't feel right that Ubuntu "automatically" introduces the problem, but not automatically clean up after itself. > 4) Can we, as a distro, provide and recommend a utility to clean out > specifically old kernels (perhaps aside from cleaning up userspace > cruft a la computer-janitor)? I think it'd be best if update-manager would auto-remove all kernel packages except the most recent two or three during dist-upgrade. This needs to be specified carefully of course, as people might explicitly run a kernel from the previous distro release. So perhaps some clevernes like if you install linux-image-3.2.0-N-generic, delete all kernels up to linux-image-3.2.0-(N-2)-generic. linux-headers-* is already covered by apt-get autoremove, which is good. Perhaps we can mark older kernels as auto-removable as well, so that without any other tools you at least have one command to clean them up all? For servers it'd be even better if apt-get dist-upgrade would do the cleanup itself, of course. But we have fewer places to hook into the logic than in update-manager, so this might be tricky. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: Using biosdevname by default?
Colin Watson [2012-01-31 14:29 +]: > There are certainly some advantages to enabling biosdevname by default. > On systems that support it, it makes it somewhat easier to write scripts > that predictably apply to a certain interface without having to mess > around with looking up interfaces by MAC address. I agree that in many situations where you work with multiple interfaces, stable names would be much preferrable. > [...] > Secondly, while as I said above I agree that enabling biosdevname solves > some problems, it seems likely that this change will cause problems of > its own. For example, any software that needs to know about network > interfaces (let's say it listens on a particular interface) might well > default to eth0 Stephane confirmed that this is an actual problem in his reply. This situation has a striking similarity with stable names for block, sound, and input devices. There was a time when the "classic" names like hda/sda went away entirely, but this situation never lasted very long because of pretty much exactly this problem: too much software making hardcoded assumptions about device names. That's why the current policy eventually distilled itself: it is actively wrong, and now even unsupported by udev to rename devices, so schemas like "sd[a-z][0-9]" or input/event* will always continue to work. Instead, the only thing you can and should do is to create aliases in the form of symlinks (/dev/disks/by-uuid/, /dev/input/by-id/, etc.) Now, unfortunately network devices have always been special in that they are not proper character devices, so symlinks don't work. But as the kernel supports renaming devices, is there any way of providing the same devices under two names, i. e. adding aliases instead of ifrename? interfaces(5) already supports mappings and renames, so from my naive POV it seems this shouldn't be too hard to get a concept of aliases? Perhaps even the Dell folks would be interested in this, as it would remove the main blocker for adoption? If we can get this to work, then I see no reason to not introduce biosdevname, as it would not break any existing setup, local configuration, or hardcoded assumption. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: proposed universe demotion: virt-manager (or, a request for active maintenance)
Hello Dustin, Dustin Kirkland [2010-01-29 12:33 -0600]: > Bugs pile up > that we do very little about. > * https://bugs.launchpad.net/ubuntu/+source/virt-manager > * 113 bugs, 70+ untriaged As as side note: That by itself is not really a metric for quality, but more a suggestion of popularity. Firefox/OO.o/cups have _far_ more bugs. :-) > a) the Ubuntu Desktop Team provides active maintenance of virt-manager, or > b) virt-manager is demoted to Universe for Lucid. If someone in the Desktop team feels very attached to virt-manager, taking up maintenance would be nice, but speaking for my own, it's so much easier to use the CLI.. Also, it's not anywhere near the stated goals of the desktop team, so it would be a kind of hobby project only. If it's not really getting maintenance from core devs, but needs some, then demotion sounds appropriate. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: RFC: Ipsec support in main
Hello Mathias, Mathias Gug [2010-01-04 12:23 -0500]: > If not the following packages could be demoted to universe: > * ipsec-tools (and racoon) given its vulnerability history Some years ago I actually used ipsec-tools (not racoon) to setup a VPN in our university, but nowadays I'm using openvpn; it's simpler to set up, and is supported with more devices (mobile phones, routers, etc.) Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: Moving w3m out of standard
Matt Zimmerman [2008-06-16 15:31 +0100]: > * w3m# we need some text-based html presenter > [...] > Now that this is becoming possible with the new server seed[1], I'd like to > propose that it move to the server seed instead (or even be removed, if the > server team doesn't feel it's appropriate). +1 from me. (Also, yay for claiming back 1.1 MB on the desktop CDs!) Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
