[Touch-packages] [Bug 1785351] [NEW] package initramfs-tools 0.122ubuntu8.11 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1

2018-08-03 Thread John Center
Public bug reported:

I'm not sure why I received this error, but it could be because I'm
running btrfs-tools v4.17.  (I'm running btrfs on imsm mdadm raid1.)
The btrfs hooks script has this line in it:

copy_exec /bin/btrfs-zero-log

but this program isn't a part of btrfs-progs anymore, replaced by "btrfs
rescue zero-log"

Processing triggers for initramfs-tools (0.122ubuntu8.11) ...
update-initramfs: Generating /boot/initrd.img-4.17.4-041704-generic
E: /usr/share/initramfs-tools/hooks/btrfs failed with return 1.
update-initramfs: failed for /boot/initrd.img-4.17.4-041704-generic with 1.
dpkg: error processing package initramfs-tools (--configure):
 subprocess installed post-installation script returned error exit status 1
Processing triggers for libc-bin (2.23-0ubuntu10) ...
Processing triggers for menu (2.1.47ubuntu1.16.04.1) ...
Errors were encountered while processing:
 initramfs-tools

ProblemType: Package
DistroRelease: Ubuntu 16.04
Package: initramfs-tools 0.122ubuntu8.11
Uname: Linux 4.17.4-041704-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.18
Architecture: amd64
Date: Fri Aug  3 20:52:17 2018
ErrorMessage: subprocess installed post-installation script returned error exit 
status 1
InstallationDate: Installed on 2016-05-30 (795 days ago)
InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
PackageArchitecture: all
RelatedPackageVersions:
 dpkg 1.18.4ubuntu1.4
 apt  1.2.27
SourcePackage: initramfs-tools
Title: package initramfs-tools 0.122ubuntu8.11 failed to install/upgrade: 
subprocess installed post-installation script returned error exit status 1
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: initramfs-tools (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-package xenial

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1785351

Title:
  package initramfs-tools 0.122ubuntu8.11 failed to install/upgrade:
  subprocess installed post-installation script returned error exit
  status 1

Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  I'm not sure why I received this error, but it could be because I'm
  running btrfs-tools v4.17.  (I'm running btrfs on imsm mdadm raid1.)
  The btrfs hooks script has this line in it:

  copy_exec /bin/btrfs-zero-log

  but this program isn't a part of btrfs-progs anymore, replaced by
  "btrfs rescue zero-log"

  Processing triggers for initramfs-tools (0.122ubuntu8.11) ...
  update-initramfs: Generating /boot/initrd.img-4.17.4-041704-generic
  E: /usr/share/initramfs-tools/hooks/btrfs failed with return 1.
  update-initramfs: failed for /boot/initrd.img-4.17.4-041704-generic with 1.
  dpkg: error processing package initramfs-tools (--configure):
   subprocess installed post-installation script returned error exit status 1
  Processing triggers for libc-bin (2.23-0ubuntu10) ...
  Processing triggers for menu (2.1.47ubuntu1.16.04.1) ...
  Errors were encountered while processing:
   initramfs-tools

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: initramfs-tools 0.122ubuntu8.11
  Uname: Linux 4.17.4-041704-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.18
  Architecture: amd64
  Date: Fri Aug  3 20:52:17 2018
  ErrorMessage: subprocess installed post-installation script returned error 
exit status 1
  InstallationDate: Installed on 2016-05-30 (795 days ago)
  InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 
(20160420.1)
  PackageArchitecture: all
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.4
   apt  1.2.27
  SourcePackage: initramfs-tools
  Title: package initramfs-tools 0.122ubuntu8.11 failed to install/upgrade: 
subprocess installed post-installation script returned error exit status 1
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1785351/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


Re: [Touch-packages] [Bug 1587142] Re: Shutdown hangs in md kworker after "Reached target Shutdown."

2018-02-22 Thread John Center
Hi Dimitri,

> On Feb 22, 2018, at 8:32 AM, Dimitri John Ledkov <launch...@surgut.co.uk> 
> wrote:
> 
> john-center - I believe mdadm is used by default, instead of dmraid.
> However, I'm not sure if we do correctly activate Intel Raids with
> mdadm. I have not done an install with either 16.04 or 18.04. Or I guess
> at least start the install up to the partitioning screen. My expectation
> is, if one has raid arrays pre-setup in BIOS (ctrl+I on boot) already,
> they should show up as assembled and offered to be autopartitioned. With
> both 16.04 and 18.04.
> 
I know with 16.04 it wasn’t used by default. I had to do a lot of manipulation 
to set up the raid array before I could do the install. It used dmraid once it 
detected the imsm raid. I removed dmraid completely, then installed mdadm, 
assembled the array & ran the installation program again. I was hoping that 
mdadm would just do it all instead. 

-John

> -- 
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1587142
> 
> Title:
>  Shutdown hangs in md kworker after "Reached target Shutdown."
> 
> Status in systemd package in Ubuntu:
>  Confirmed
> 
> Bug description:
>  I'm booting a fully patched 16.04 from an Intel Rapid Storage
>  Technology enterprise RAID1 volume (ThinkServer TS140 with two SATA
>  ST1000NM0033-9ZM drives, ext4 root partition, no LVM, UEFI mode).
> 
>  If the RAID volume is recovering or resyncing for whatever reason, then 
> `sudo systemctl reboot` and `sudo systemctl poweroff` work fine (I had to 
> `sudo systemctl --now disable lvm2-lvmetad lvm2-lvmpolld lvm2-monitor` in 
> order to consistently get that). However, once the recovery/resync is 
> complete and clean, the reboot and poweroff commands above hang forever after 
> "Reached target Shutdown.". Note that issuing `sudo swapoff -a` beforehand 
> (suggested in the bug #1464917) does not help.
>  [EDIT]Actually, the shutdown also hangs from time to time during a resync. 
> But I've never seen it succeed once the resync is complete.[/EDIT]
> 
>  Then, if the server has been forcibly restarted with the power button,
>  the Intel Matrix Storage Manager indicates a "Normal" status for the
>  RAID1 volume, but Ubuntu then resyncs the volume anyway:
> 
>  [1.223649] md: bind
>  [1.228426] md: bind
>  [1.230030] md: bind
>  [1.230738] md: bind
>  [1.232985] usbcore: registered new interface driver usbhid
>  [1.233494] usbhid: USB HID core driver
>  [1.234022] md: raid1 personality registered for level 1
>  [1.234876] md/raid1:md126: not clean -- starting background 
> reconstruction
>  [1.234956] input: CHESEN USB Keyboard as 
> /devices/pci:00/:00:14.0/usb3/3-10/3-10:1.0/0003:0A81:0101.0001/input/input5
>  [1.236273] md/raid1:md126: active with 2 out of 2 mirrors
>  [1.236797] md126: detected capacity change from 0 to 1000202043392
>  [1.246271] md: md126 switched to read-write mode.
>  [1.246834] md: resync of RAID array md126
>  [1.247325] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
>  [1.247503]  md126: p1 p2 p3 p4
>  [1.248269] md: using maximum available idle IO bandwidth (but not more 
> than 20 KB/sec) for resync.
>  [1.248774] md: using 128k window, over a total of 976759940k.
> 
>  Note that the pain of "resync upon every (re)boot" cannot even be a
>  bit relieved thanks to bitmaps because mdadm does not support them for
>  IMSM containers:
> 
>  $ sudo mdadm --grow --bitmap=internal /dev/md126
>  mdadm: Cannot add bitmaps to sub-arrays yet
> 
>  I also get this in syslog during boot when the individual drives are
>  detected, but this seems to be harmless:
> 
>  May 30 17:26:07 wssrv1 systemd-udevd[608]: Process '/sbin/mdadm 
> --incremental /dev/sdb --offroot' failed with exit code 1.
>  May 30 17:26:07 wssrv1 systemd-udevd[608]: Process '/lib/udev/hdparm' failed 
> with exit code 1.
> 
>  May 30 17:26:07 wssrv1 systemd-udevd[606]: Process '/sbin/mdadm 
> --incremental /dev/sda --offroot' failed with exit code 1.
>  May 30 17:26:07 wssrv1 systemd-udevd[606]: Process '/lib/udev/hdparm' failed 
> with exit code 1.
> 
>  During a resync, `sudo sh -c 'echo idle >
>  /sys/block/md126/md/sync_action'` actually stops it as expected, but
>  it restarts immediately though nothing seems to have triggered it:
> 
>  May 30 18:17:02 wssrv1 kernel: [ 3106.826710] md: md126: resync interrupted.
>  May 30 18:17:02 wssrv1 kernel: [ 3106.836320] md: checkpointing resync of 
> md126.
>  May 30 18:17:02 wssrv1 kernel: [ 3106.836623] md: resync of RAID array md126
>  May 30 18:17:02 wssrv1 kernel: [ 3106.8

[Touch-packages] [Bug 1587142] Re: Shutdown hangs in md kworker after "Reached target Shutdown."

2017-10-23 Thread John Center
I added a comment about this new fix on
https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1608495.  One thing
I wanted to add here, for the first time shutdown completed
successfully.  In fact, I was a little startled when it happened.  :-)
It powered off at the end of shutdown, instead of hanging at the
"Reached target Shutdown" message.

One question: Does this mean that Ubuntu 18.04 will use mdadm by default
during installation instead of dmraid?  I really hope so.  It's a real
pain to do it manually.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1587142

Title:
  Shutdown hangs in md kworker after "Reached target Shutdown."

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  I'm booting a fully patched 16.04 from an Intel Rapid Storage
  Technology enterprise RAID1 volume (ThinkServer TS140 with two SATA
  ST1000NM0033-9ZM drives, ext4 root partition, no LVM, UEFI mode).

  If the RAID volume is recovering or resyncing for whatever reason, then `sudo 
systemctl reboot` and `sudo systemctl poweroff` work fine (I had to `sudo 
systemctl --now disable lvm2-lvmetad lvm2-lvmpolld lvm2-monitor` in order to 
consistently get that). However, once the recovery/resync is complete and 
clean, the reboot and poweroff commands above hang forever after "Reached 
target Shutdown.". Note that issuing `sudo swapoff -a` beforehand (suggested in 
the bug #1464917) does not help.
  [EDIT]Actually, the shutdown also hangs from time to time during a resync. 
But I've never seen it succeed once the resync is complete.[/EDIT]

  Then, if the server has been forcibly restarted with the power button,
  the Intel Matrix Storage Manager indicates a "Normal" status for the
  RAID1 volume, but Ubuntu then resyncs the volume anyway:

  [1.223649] md: bind
  [1.228426] md: bind
  [1.230030] md: bind
  [1.230738] md: bind
  [1.232985] usbcore: registered new interface driver usbhid
  [1.233494] usbhid: USB HID core driver
  [1.234022] md: raid1 personality registered for level 1
  [1.234876] md/raid1:md126: not clean -- starting background reconstruction
  [1.234956] input: CHESEN USB Keyboard as 
/devices/pci:00/:00:14.0/usb3/3-10/3-10:1.0/0003:0A81:0101.0001/input/input5
  [1.236273] md/raid1:md126: active with 2 out of 2 mirrors
  [1.236797] md126: detected capacity change from 0 to 1000202043392
  [1.246271] md: md126 switched to read-write mode.
  [1.246834] md: resync of RAID array md126
  [1.247325] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
  [1.247503]  md126: p1 p2 p3 p4
  [1.248269] md: using maximum available idle IO bandwidth (but not more 
than 20 KB/sec) for resync.
  [1.248774] md: using 128k window, over a total of 976759940k.

  Note that the pain of "resync upon every (re)boot" cannot even be a
  bit relieved thanks to bitmaps because mdadm does not support them for
  IMSM containers:

  $ sudo mdadm --grow --bitmap=internal /dev/md126
  mdadm: Cannot add bitmaps to sub-arrays yet

  I also get this in syslog during boot when the individual drives are
  detected, but this seems to be harmless:

  May 30 17:26:07 wssrv1 systemd-udevd[608]: Process '/sbin/mdadm --incremental 
/dev/sdb --offroot' failed with exit code 1.
  May 30 17:26:07 wssrv1 systemd-udevd[608]: Process '/lib/udev/hdparm' failed 
with exit code 1.

  May 30 17:26:07 wssrv1 systemd-udevd[606]: Process '/sbin/mdadm --incremental 
/dev/sda --offroot' failed with exit code 1.
  May 30 17:26:07 wssrv1 systemd-udevd[606]: Process '/lib/udev/hdparm' failed 
with exit code 1.

  During a resync, `sudo sh -c 'echo idle >
  /sys/block/md126/md/sync_action'` actually stops it as expected, but
  it restarts immediately though nothing seems to have triggered it:

  May 30 18:17:02 wssrv1 kernel: [ 3106.826710] md: md126: resync interrupted.
  May 30 18:17:02 wssrv1 kernel: [ 3106.836320] md: checkpointing resync of 
md126.
  May 30 18:17:02 wssrv1 kernel: [ 3106.836623] md: resync of RAID array md126
  May 30 18:17:02 wssrv1 kernel: [ 3106.836625] md: minimum _guaranteed_  
speed: 1000 KB/sec/disk.
  May 30 18:17:02 wssrv1 kernel: [ 3106.836626] md: using maximum available 
idle IO bandwidth (but not more than 20 KB/sec) for resync.
  May 30 18:17:02 wssrv1 kernel: [ 3106.836627] md: using 128k window, over a 
total of 976759940k.
  May 30 18:17:02 wssrv1 kernel: [ 3106.836628] md: resuming resync of md126 
from checkpoint.
  May 30 18:17:02 wssrv1 mdadm[982]: RebuildStarted event detected on md device 
/dev/md/Volume0

  I attach screenshots of the hanging shutdown log after a `sudo sh -c 'echo 8 
> /proc/sys/kernel/printk'`. The second screenshot shows that the kernel has 
deadlocked in md_write_start(). Note that `sudo systemctl start debug-shell` is 
unusable on this machine at this point because Ctrl+Alt+F9 brings tty9 

[Touch-packages] [Bug 1464917] Re: reboot hangs at 'Reached target Shutdown'

2015-12-19 Thread John Center
My Dell workstation is a fresh install of 15.04, also.  I'm having the
same problem.  I've attached some screen shots that show the last
messages typically seen after I try REISUB.

** Attachment added: "IMG_0765.JPG"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1464917/+attachment/4537644/+files/IMG_0765.JPG

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1464917

Title:
  reboot hangs at 'Reached target Shutdown'

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  I rebooted my 15.04 system, and found it hanging indefinitely at the
  plymouth shutdown screen.  Hitting esc to reveal the console showed a
  normal set of shutdown messages, ending with 'Reached target Shutdown'
  (paraphrased from memory).

  The system never rebooted on its own.  I had to use SysRq to finish
  the shutdown.

  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: systemd 219-7ubuntu6
  ProcVersionSignature: Ubuntu 3.19.0-20.20-generic 3.19.8
  Uname: Linux 3.19.0-20-generic x86_64
  ApportVersion: 2.17.2-0ubuntu1.1
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Sat Jun 13 11:53:10 2015
  InstallationDate: Installed on 2010-09-24 (1723 days ago)
  InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 
(20100816.1)
  MachineType: LENOVO 2306CTO
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.19.0-20-generic 
root=/dev/mapper/hostname-root ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UpgradeStatus: Upgraded to vivid on 2014-12-06 (189 days ago)
  dmi.bios.date: 10/25/2013
  dmi.bios.vendor: LENOVO
  dmi.bios.version: G2ET97WW (2.57 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 2306CTO
  dmi.board.vendor: LENOVO
  dmi.board.version: Not Defined
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Not Available
  dmi.modalias: 
dmi:bvnLENOVO:bvrG2ET97WW(2.57):bd10/25/2013:svnLENOVO:pn2306CTO:pvrThinkPadX230:rvnLENOVO:rn2306CTO:rvrNotDefined:cvnLENOVO:ct10:cvrNotAvailable:
  dmi.product.name: 2306CTO
  dmi.product.version: ThinkPad X230
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1464917/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1464917] Re: reboot hangs at 'Reached target Shutdown'

2015-12-19 Thread John Center
** Attachment added: "IMG_0766.JPG"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1464917/+attachment/4537645/+files/IMG_0766.JPG

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1464917

Title:
  reboot hangs at 'Reached target Shutdown'

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  I rebooted my 15.04 system, and found it hanging indefinitely at the
  plymouth shutdown screen.  Hitting esc to reveal the console showed a
  normal set of shutdown messages, ending with 'Reached target Shutdown'
  (paraphrased from memory).

  The system never rebooted on its own.  I had to use SysRq to finish
  the shutdown.

  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: systemd 219-7ubuntu6
  ProcVersionSignature: Ubuntu 3.19.0-20.20-generic 3.19.8
  Uname: Linux 3.19.0-20-generic x86_64
  ApportVersion: 2.17.2-0ubuntu1.1
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Sat Jun 13 11:53:10 2015
  InstallationDate: Installed on 2010-09-24 (1723 days ago)
  InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 
(20100816.1)
  MachineType: LENOVO 2306CTO
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.19.0-20-generic 
root=/dev/mapper/hostname-root ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UpgradeStatus: Upgraded to vivid on 2014-12-06 (189 days ago)
  dmi.bios.date: 10/25/2013
  dmi.bios.vendor: LENOVO
  dmi.bios.version: G2ET97WW (2.57 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 2306CTO
  dmi.board.vendor: LENOVO
  dmi.board.version: Not Defined
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Not Available
  dmi.modalias: 
dmi:bvnLENOVO:bvrG2ET97WW(2.57):bd10/25/2013:svnLENOVO:pn2306CTO:pvrThinkPadX230:rvnLENOVO:rn2306CTO:rvrNotDefined:cvnLENOVO:ct10:cvrNotAvailable:
  dmi.product.name: 2306CTO
  dmi.product.version: ThinkPad X230
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1464917/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1186662] Re: isc-dhcp-server fails to renew lease file

2015-06-19 Thread John Center
There are a number of things that need to be addressed with the isc-
dhcp-server package.  I think I've worked through most of the issues,
based on items here  ones I've researched; maybe the maintainer or
someone else could review this?

1)  /etc/default/isc-dhcp-server needs to be updated to enable several
env variables  include one more:

diff -Nru /etc/default/isc-dhcp-server isc-dhcpd-4.2.4/isc-dhcp-server.default 
--- /etc/default/isc-dhcp-server2015-06-19 17:32:49.849591118 -0400
+++ isc-dhcpd-4.2.4/isc-dhcp-server.default 2015-06-19 17:17:36.537576347 
-0400
@@ -7,10 +7,13 @@
 #
 
 # Path to dhcpd's config file (default: /etc/dhcp/dhcpd.conf).
-#DHCPD_CONF=/etc/dhcp/dhcpd.conf
+DHCPD_CONF=/etc/dhcp/dhcpd.conf
+
+# Path to dhcpd's leases file (default: /var/lib/dhcp/dhcpd.leases).
+DHCPD_LEASES=/var/lib/dhcp/dhcpd.leases
 
 # Path to dhcpd's PID file (default: /var/run/dhcpd.pid).
-#DHCPD_PID=/var/run/dhcpd.pid
+DHCPD_PID=/var/run/dhcp-server/dhcpd.pid
 
 # Additional options to start dhcpd with.
 #  Don't use options -cf or -pf here; use DHCPD_CONF/ DHCPD_PID instead
@@ -18,4 +21,4 @@


2)  /etc/init/isc-dhcp-server.conf  sources the default isc-dhcp-server file, 
but does not include the correct env variable to find dhcpd.conf.  It should 
also set the extended file attributes as mentioned earlier.  Finally, it should 
use the env variables defined in the default isc-dhcp-server file when starting 
the service:

diff -Nru /etc/init/isc-dhcp-server.conf 
isc-dhcpd-4.2.4/isc-dhcp-server.conf.init 
--- /etc/init/isc-dhcp-server.conf  2014-04-03 17:51:15.0 -0400
+++ isc-dhcpd-4.2.4/isc-dhcp-server.conf.init   2015-06-19 18:38:04.661654434 
-0400
@@ -13,22 +13,17 @@
 fi
 . /etc/default/isc-dhcp-server
 
-if [ -f /etc/ltsp/dhcpd.conf ]; then
-CONFIG_FILE=/etc/ltsp/dhcpd.conf
-else
-CONFIG_FILE=/etc/dhcp/dhcpd.conf
-fi
-if [ ! -f $CONFIG_FILE ]; then
-echo $CONFIG_FILE does not exist! - Aborting...
-echo Please create and configure $CONFIG_FILE to fix the problem.
+if [ ! -f $DHCPD_CONF ]; then
+echo $DHCPD_CONF does not exist! - Aborting...
+echo Please create and configure $DHCPD_CONF to fix the problem.
 stop
 exit 0
 fi
 
-if ! dhcpd -user dhcpd -group dhcpd -t -q -4 -cf $CONFIG_FILE  /dev/null 
21; then
+if ! dhcpd -user dhcpd -group dhcpd -t -q -4 -cf $DHCPD_CONF  /dev/null 
21; then
 echo dhcpd self-test failed. Please fix the config file.
 echo The error was: 
-dhcpd -user dhcpd -group dhcpd -t -4 -cf $CONFIG_FILE
+dhcpd -user dhcpd -group dhcpd -t -4 -cf $DHCPD_CONF
 stop
 exit 0
 fi
@@ -36,12 +31,6 @@
 
 respawn
 script
-if [ -f /etc/ltsp/dhcpd.conf ]; then
-CONFIG_FILE=/etc/ltsp/dhcpd.conf
-else
-CONFIG_FILE=/etc/dhcp/dhcpd.conf
-fi
-
 . /etc/default/isc-dhcp-server
 
 # Allow dhcp server to write lease and pid file as 'dhcpd' user
@@ -50,10 +39,8 @@
 
 # The leases files need to be root:root even when dropping privileges
 [ -e /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases
-chown root:root /var/lib/dhcp /var/lib/dhcp/dhcpd.leases
-if [ -e /var/lib/dhcp/dhcpd.leases~ ]; then
-chown root:root /var/lib/dhcp/dhcpd.leases~
-fi
+setfacl -dm u:dhcpd:rwx /var/lib/dhcp
+setfacl -m u:dhcpd:rwx /var/lib/dhcp
 
-exec dhcpd -user dhcpd -group dhcpd -f -q -4 -pf 
/run/dhcp-server/dhcpd.pid -cf $CONFIG_FILE $INTERFACES
+exec dhcpd -user dhcpd -group dhcpd -f -4 $OPTIONS -pf $DHCPD_PID -cf 
$DHCPD_CONF -lf $DHCPD_LEASES $INTERFACES
 end script


3)  Checks for upstart should be added to the sysvinit script:

diff -Nru /etc/init.d/isc-dhcp-server isc-dhcpd-4.2.4/isc-dhcp-server.initd 
--- /etc/init.d/isc-dhcp-server 2014-04-03 17:51:15.0 -0400
+++ isc-dhcpd-4.2.4/isc-dhcp-server.initd   2015-06-19 18:20:49.873637698 
-0400
@@ -31,6 +31,13 @@
 
 . /lib/lsb/init-functions
 
+check_for_upstart()
+{
+   if init_is_upstart; then
+   exit $1
+   fi
+}
+
 # Read init script configuration
 [ -f $DHCPD_DEFAULT ]  . $DHCPD_DEFAULT
 
@@ -38,15 +45,18 @@
 DESC=ISC DHCP server
 # fallback to default config file
 DHCPD_CONF=${DHCPD_CONF:-/etc/dhcp/dhcpd.conf}
-# try to read pid file name from config file, with fallback to 
/var/run/dhcpd.pid
+# try to read pid file name from config file, with fallback to
+/var/run/dhcpd.pid
 if [ -z $DHCPD_PID ]; then
-   DHCPD_PID=$(sed -n -e 's/^[ \t]*pid-file-name[ \t]*(.*)[ 
\t]*;.*$/\1/p'  $DHCPD_CONF 2/dev/null | head -n 1)
+   DHCPD_PID=$(sed -n -e 's/^[ \t]*pid-file-name[ \t]*\(.*\)[
+\t]*;.*$/\1/p'  $DHCPD_CONF 2/dev/null | head -n 1)
 fi
 DHCPD_PID=${DHCPD_PID:-/var/run/dhcpd.pid}
 
 test_config()
 {
-   if ! /usr/sbin/dhcpd -t $OPTIONS -q -cf $DHCPD_CONF  /dev/null 21; 
then
+   if ! /usr/sbin/dhcpd -t $OPTIONS -q -cf $DHCPD_CONF  /dev/null 21;
+then

[Touch-packages] [Bug 1186662] Re: isc-dhcp-server fails to renew lease file

2015-05-22 Thread John Center
We're having the same problem running dhcpd under trusty.  As a
workaround, if we make the file attribute changes in #25, is this the
only thing that needs to be done?  Can we also change chown root:root to
dhcpd:dhcpd for /var/lib/dhcp/* in isc-dhcp-server.conf, too?

Thanks.

-John

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1186662

Title:
  isc-dhcp-server fails to renew lease file

Status in isc-dhcp package in Ubuntu:
  Triaged
Status in isc-dhcp source package in Trusty:
  Confirmed

Bug description:
  After raring upgrade, the dhcp server fails to renew lease file when
  it tries to (about every hour).

  The syslog says:
  dhcpd: Can't create new lease file: Permission denied

  It looks like a permission problem, because

  # chown -R dhcpd:dhcpd /var/lib/dhcp

  the above command temporarily solves the issue, until dhcpd is
  restarted: at that time, the ownership of the directory and the lease
  file is set back to root:root.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1186662/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1368688] Re: Inconsistence between /etc/init and /etc/init.d files

2015-05-21 Thread John Center
This just bit us, also.  We migrated from Solaris to Ubuntu 14.04 for
our dhcp server.  Please fix!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1368688

Title:
  Inconsistence between /etc/init and /etc/init.d files

Status in isc-dhcp package in Ubuntu:
  Confirmed

Bug description:
  After upgrade Ubuntu server from 12.04 LTS to 14.04 LTS (with 
do-release-upgrade) I found a strange behavior in /var/log/messages from 
isc-dhcp-server. It had doubled DHCPREQUESTS/OFFERS/ACKs... It was like:
  ~~
  dhcpd: DHCPDISCOVER from 00:0b:82:27:be:d1 via eth0
  dhcpd: DHCPDISCOVER from 00:0b:82:27:be:d1 via eth0
  DHCPREQUEST for 192.168.1.102 (10.112.1.252) from 00:0b:82:27:be:d1 via eth0
  DHCPREQUEST for 192.168.1.102 (10.112.1.252) from 00:0b:82:27:be:d1 via eth0
  DHCPACK on 192.168.1.102 to 00:0b:82:27:be:d1 via eth0
  DHCPACK on 192.168.1.102 to 00:0b:82:27:be:d1 via eth0
  ~~

  Futher investigation show that there was actually two dhcpd processes:
  ~~
  dhcpd -q -cf /etc/dhcp/dhcpd.conf -pf /var/run/dhcp-server/dhcpd.pid
  /usr/sbin/dhcpd -q -cf /etc/dhcp/dhcpd.conf -pf /var/run/dhcpd.pid
  ~~

  The first one was executed from /etc/init/isc-dhcp-server.conf and second 
from /etc/init.d/isc-dhcp-server.
  Looking inside init/isc-dhcp-server.conf I found:
  ~~
  respawn
  script
     . /etc/default/isc-dhcp-server
    ..
   exec dhcpd -user dhcpd -group dhcpd -f -q -4 -pf /run/dhcp-server/dhcpd.pid 
-cf $CONFIG_FILE $INTERFACES
  ~~

  As you can see path to PID file is hardcoded.

  But in init.d/isc-dhcp-server startup script:
  ~~
  # try to read pid file name from config file, with fallback to 
/var/run/dhcpd.pid
  if [ -z $DHCPD_PID ]; then
  DHCPD_PID=$(sed -n -e 's/^[ \t]*pid-file-name[ \t]*(.*)[ 
\t]*;.*$/\1/p'  $DHCPD_CONF 2/dev/null | head -n 1)
  fi
  DHCPD_PID=${DHCPD_PID:-/var/run/dhcpd.pid}
    ..
  case $1 in
  start)
  test_config
  log_daemon_msg Starting $DESC $NAME
  start-stop-daemon --start --quiet --pidfile $DHCPD_PID \
  --exec /usr/sbin/dhcpd -- \
  -q $OPTIONS -cf $DHCPD_CONF -pf $DHCPD_PID 
$INTERFACES
  ~~

  
  So obivous is to either change init script to NOT use hardcoded path to PID 
file and use $DHCP_PID (from /etc/default/isc-dhcp-server, which is sourced 
inside this script), or at least change it to default one: /var/run/dhcpd.pid

  OR

  change init.d script to fallback to /run/dhcp-server/dhcpd.pid
  instead of /var/run/dhcpd.pid

  P.S. /var/run is a link to /run

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1368688/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1424747] Re: findmnt only displays /dev/pts on Trusty w/ Utopic Kernel (14.04.2)

2015-04-25 Thread John Center
Hi,

I've been trying to build snapper on 14.04 x64, but the old version of
util-linux is tripping me up.  I get the following error:

In file included from Btrfs.cc:34:0:
/usr/include/libmount/libmount.h:345:28: error: expected ',' or '...' before 
'new'
struct libmnt_table *new);
^
Btrfs.cc: In constructor 'snapper::MntTable::MntTable()':
Btrfs.cc:1386:40: error: 'mnt_table_enable_comments' was not declared in this 
scope
mnt_table_enable_comments(table, 1);
^
Btrfs.cc: In member function 'void snapper::MntTable::replace_file()':
Btrfs.cc:1402:52: error: 'mnt_table_replace_file' was not declared in this scope
if (mnt_table_replace_file(table, /etc/fstab) != 0)
^

The old version of libmount.h using the C++ keyword new as a variable
name.  This was fixed in the upstream version 2.22.1 of util-linux.  It
looks like a later version of util-linux is available for Utopic.
Please backport this to Trusty.

Thanks.

-John

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to util-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1424747

Title:
  findmnt only displays /dev/pts on Trusty w/ Utopic Kernel (14.04.2)

Status in util-linux package in Ubuntu:
  Confirmed

Bug description:
  The findmnt command from util-linux only displays /dev/pts when run on
  a Ubuntu Truty install using the 3.16 Utopic kernel:

  $ findmnt
  TARGET   SOURCE FSTYPE OPTIONS
  /dev/pts devpts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000

  This is true on both fresh Ubuntu 14.04.2 installs as well as Ubuntu
  14.04.1 installs with the kernel upgraded to 'linux-generic-lts-
  utopic'. The same command works correctly on a fresh Ubuntu 14.04.1
  install with the original 3.13 kernel. Also, the command seems to work
  correctly in the Ubuntu 14.04.2 liveboot environment, but not after
  rebooting into a fresh Ubuntu 14.04.2 install.

  According to the discussion in the comments at
  http://lwn.net/Articles/634263/, this seems to be a known bug in util-
  linux due to a 3.14 kernel chnage. The util-linux bug has been fixed
  upstream:

  http://thread.gmane.org/gmane.linux.utilities.util-linux-ng/8557/focus=8558
  
https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=6c373810f5b1d32824371e9dff6ee5a006388f98

  The updated version of util-linux, however, is not available in the
  Trusty repos.

  Can we get the upstream fix backported into the Trusty-version of
  util-linux? Or better yet, should there be a 'util-linux-lts-utopic'
  package that tracks the newer versions of util-linux matched to the
  newer LTS kernel versions? It seems that as long as Ubuntu is going to
  supply LTS Enablement Stack kernels, it also needs to supply LTS-
  variants of user-space packages that closely track the kernel like
  util-linux. Other examples of similar scenarios also come to mind
  (e.g. btrfs-tools, iproute2, etc).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1424747/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp