[Bug 315896] Re: freeradius upgrade broken in hardy backports
Brilliant, thanks Alan. -- freeradius upgrade broken in hardy backports https://bugs.launchpad.net/bugs/315896 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to freeradius in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 315896] Re: freeradius upgrade broken in hardy backports
Brilliant, thanks Alan. -- freeradius upgrade broken in hardy backports https://bugs.launchpad.net/bugs/315896 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 315896] Re: freeradius upgrade broken in hardy backports
I understand that it might not be recommended to do cross major version upgrades, but it is one of the (usually) strong points of the APT system, and indeed, I've rarely had any issues doing such things in the past. However, normally there's a ncurses dialog that mentions a few things, possibly warns about issues that might be faced, and often offers to show the admin a diff of old vs. new configuration files (not that that is always easy between major revisions, due to changes in config syntax and options). What I take issue with is that there weren't any of these warnings to enlighten me. What I see as the main issue here is the inconsistency of the package itself, not that it's a cross major version upgrade. Indeed, the major issue, other than the post-upgrade missing binaries (that was easily fixed by installing the errant package) is that the NEW radiusd.conf and the NEW initscript don't match, and from what I can gather, this would also have been the had I installed freeradius 2.1.0 fresh, rather than as an upgrade. The simple matter is that the installed radiusd.conf configures the daemon to use /var/run/radiusd/radiusd.pid as it's PIDFILE, where as the initscript chooses to use /var/run/freeradius/freeradius.pid. Other than the SQL $INDCLUDE files issue (which probably don't need to be there by default, and are likely useless without further configuration by the system admin), the matter of the pidfiles should be a simple and inconsequential fix -- I don't really care which way round it goes, but radiusd.conf and the daemon's initscript need to agree on where the PIDFILE is going to go, and what it's called. I've attached a small patch that fixes both non-existant $INCLUDE and PIDFILE issues. It works for me. ** Attachment added: Comments unnecessary SQL includes, and brings conf and initscripts into agreement http://launchpadlibrarian.net/21110031/freeradius_upgrade_confs.diff -- freeradius upgrade broken in hardy backports https://bugs.launchpad.net/bugs/315896 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to freeradius in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 315896] Re: freeradius upgrade broken in hardy backports
I understand that it might not be recommended to do cross major version upgrades, but it is one of the (usually) strong points of the APT system, and indeed, I've rarely had any issues doing such things in the past. However, normally there's a ncurses dialog that mentions a few things, possibly warns about issues that might be faced, and often offers to show the admin a diff of old vs. new configuration files (not that that is always easy between major revisions, due to changes in config syntax and options). What I take issue with is that there weren't any of these warnings to enlighten me. What I see as the main issue here is the inconsistency of the package itself, not that it's a cross major version upgrade. Indeed, the major issue, other than the post-upgrade missing binaries (that was easily fixed by installing the errant package) is that the NEW radiusd.conf and the NEW initscript don't match, and from what I can gather, this would also have been the had I installed freeradius 2.1.0 fresh, rather than as an upgrade. The simple matter is that the installed radiusd.conf configures the daemon to use /var/run/radiusd/radiusd.pid as it's PIDFILE, where as the initscript chooses to use /var/run/freeradius/freeradius.pid. Other than the SQL $INDCLUDE files issue (which probably don't need to be there by default, and are likely useless without further configuration by the system admin), the matter of the pidfiles should be a simple and inconsequential fix -- I don't really care which way round it goes, but radiusd.conf and the daemon's initscript need to agree on where the PIDFILE is going to go, and what it's called. I've attached a small patch that fixes both non-existant $INCLUDE and PIDFILE issues. It works for me. ** Attachment added: Comments unnecessary SQL includes, and brings conf and initscripts into agreement http://launchpadlibrarian.net/21110031/freeradius_upgrade_confs.diff -- freeradius upgrade broken in hardy backports https://bugs.launchpad.net/bugs/315896 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 315896] [NEW] freeradius upgrade broken in hardy backports
Public bug reported: When upgrading from freeradius 1.1.7 to freeradius 2.1.0 from the hardy backports repository, the upgrade isn't clean, and left freeradius on my system unusable without remediation. It seems that the freeradius package from 1.1.7 has been split into several smaller packages in 2.1.0, and while the upgrade correctly pulls in the new freeradius-common package, it doesn't also pull in the also new freeradius-utils package as a dependency. This means that many binaries, such as radtest, that were previously installed, are no longer available, until the new -utils package is installed. Additionally, there seem to be issues with the supplied configuration and initscripts. With the configuration as delivered by the package, freeradius won't start due to configuration errors, where files that don't exist are pulled in using $INDLUDE. The main issue here is with some of the SQL config files. Commenting out the relevant $INCLUDE lines in /etc/freeradius/radiusd.conf means that `freeradius -XC` has a return code of 0, indicating the config is clean, and freeradius will then start. The initscript gives the impression that the daemon should use /var/run/freeradius/freeradius.pid as it's $PIDFILE, and that if the containing directory doesn't exist, it will be created. This only partially happens -- the directory is created, and correctly chown'd, but no PIDFILE is created within it. However, a logentry in /var/log/freeradius/radius.log states: Error: Failed creating PID file /var/run/radiusd/radiusd.pid: No such file or directory. If I create that directory, then a PIDFILE is created correctly, but when shutting down freeradius, the initscript looks for the configured PIDFILE in /var/run/freeradius, doesn't find it, and therefore can't kill the process, leaving freeradius running, and un-restartable (it can't bind to it's socket, because it's already in use, by the previous, unstopped, freeradius process), leaveing the system in an inconsistent state -- the PIDFILE, which isn't used, says one thing, but `ps aux | grep rad` says another. Editing the initscript seems to clear up this ambiguity, but it's not a clean fix as it means that it's no longer in sync with the repository package, and while that's usually OK and expected with config files, it's not normally a good idea for initscripts. Has anyone else had this issue? I can't see any other bugs relating to it here on launchpad, but maybe I just got here first... Cheers. Dameon. ** Affects: ubuntu Importance: Undecided Status: New -- freeradius upgrade broken in hardy backports https://bugs.launchpad.net/bugs/315896 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 67012] Re: Marvell PATA controller (88SE6101) is not supported
On Tue, Jan 16, 2007 at 09:35:39AM -, Shriramana Sharma wrote: And how does one add it to initramfs please? Thanks. P.S: I did whereis initramfs on my terminal and got nothing. All did to get it into my initramfs was to run depmod(8), and then use update-initramfs(8). My next boot picked it all up. Cheers. Dameon. -- Marvell PATA controller (88SE6101) is not supported https://launchpad.net/bugs/67012 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 67012] Re: Marvell PATA controller (88SE6101) is not supported
I couldn't get it to compile against my vanilla 2.6.18.3, but a bit of hacking got it to work. Now I've just got to work out why the DVD burner attached to it will read perfectly, but not burn ;-) I've attached the diff I ended up with, just in case it's useful to anyone else. -- Marvell PATA controller (88SE6101) is not supported https://launchpad.net/bugs/67012 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
