Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

upgrade failed debian 8.7

233 views
Skip to first unread message

Mike Nunn

unread,
Feb 4, 2017, 11:50:03 AM2/4/17
to

uname -a 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux

I ran sudo apt update followed by upgrade

it hangs at the following point:

Setting up linux-image-3.16.0-4-amd64 (3.16.39-1) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-3.16.0-4-amd64

Progress: [  0%]

Any advice very gratefully received.

Thanks

Mike 

Sven Hartge

unread,
Feb 4, 2017, 12:10:04 PM2/4/17
to
Please interrupt the currently running process (STRG+C) and do it in two
steps:

a) sudo -i
to get a genuine root shell

b) apt upgrade

With this I want to check if there is anything funny happening with the
terminal when using just "sudo apt upgrade".

If this does not change anything, interrupt the process again and just
issue "update-initramfs -u -v -k 3.16.0-4-amd64" to see if anything
strange happens during the generation of the initramfs.



--
Sigmentation fault. Core dumped.

Mike Nunn

unread,
Feb 4, 2017, 1:20:03 PM2/4/17
to
Thanks for the reply,

It seems to stop after the last line shown below.

update-initramfs -u -v -k 3.16.0-4-amd64
Keeping /boot/initrd.img-3.16.0-4-amd64.dpkg-bak
update-initramfs: Generating /boot/initrd.img-3.16.0-4-amd64
Copying module directory kernel/drivers/hid

********
Calling hook zz-busybox
Adding binary /bin/busybox
Calling hook dmsetup
/usr/share/initramfs-tools/scripts/local-block/ORDER ignored: not executable
/usr/share/initramfs-tools/scripts/local-premount/ORDER ignored: not executable
/usr/share/initramfs-tools/scripts/init-premount/ORDER ignored: not executable
/usr/share/initramfs-tools/scripts/init-top/ORDER ignored: not executable
/usr/share/initramfs-tools/scripts/init-bottom/ORDER ignored: not executable
/usr/share/initramfs-tools/scripts/local-top/ORDER ignored: not executable
Building cpio /boot/initrd.img-3.16.0-4-amd64.new initramfs

Thanks

Mike

Mike Nunn

unread,
Feb 4, 2017, 1:30:03 PM2/4/17
to

Sven Hartge

unread,
Feb 4, 2017, 1:40:03 PM2/4/17
to
Mike Nunn <bonn...@gmail.com> wrote:

> It seems to stop after the last line shown below.

> Building cpio /boot/initrd.img-3.16.0-4-amd64.new initramfs

Hmm. How long did you wait for it to complete? Is "/boot" full? Or is
the disk /boot is on just abysmally slow?

Grüße,
Sven.

Mike Nunn

unread,
Feb 4, 2017, 1:50:03 PM2/4/17
to

Sven Hartge <sv...@svenhartge.de> wrote:

> Hmm. How long did you wait for it to complete? Is "/boot" full? 
> Or is the disk /boot is on just abysmally slow?

It's still stuck, been over an hour now. Everything else seems fast, 
no obvious slowdown.

Filesystem Size  Used Avail Use% Mounted on
/dev/md1   488M   52M  411M  12% /boot

Disks are NVMe Gen3 x4 SSD (Software-RAID 1)

Thanks

Mike

Sven Hartge

unread,
Feb 4, 2017, 2:10:04 PM2/4/17
to
Please do

a) lsof -p `pidof cpio`
b) strace -f -p `pidof cpio`

(If those tools are not installed, please install them.)

Henrique de Moraes Holschuh

unread,
Feb 4, 2017, 2:40:04 PM2/4/17
to
On Sat, 04 Feb 2017, Mike Nunn wrote:
> /usr/share/initramfs-tools/scripts/local-block/ORDER ignored: not executable

Is /tmp mounted "noexec"? Just Don't Do It[tm]. The system will break
in hideously crazy, suprising ways. BTW, this is also valid for the
filesystem hosting whatever directory $TMPDIR (and $TEMP, $TMP...)
points to.

Mounting /tmp "noexec" is not really supported, regardless of whether it
used to work in the past or not.


If that's the case, here's a rough idea on how to fix the breakage:

1. fix the /tmp definiton on /etc/fstab, it must not be "noexec".

2. assuming you actually managed to boot, run as root:

mount /tmp -o remount,exec
update-initramfs -u

that should create a working initramfs for the next boot.

--
Henrique Holschuh

Sven Hartge

unread,
Feb 4, 2017, 3:00:03 PM2/4/17
to
Henrique de Moraes Holschuh <h...@debian.org> wrote:
> On Sat, 04 Feb 2017, Mike Nunn wrote:

>> /usr/share/initramfs-tools/scripts/local-block/ORDER ignored: not executable

> Is /tmp mounted "noexec"? Just Don't Do It[tm]. The system will break
> in hideously crazy, suprising ways. BTW, this is also valid for the
> filesystem hosting whatever directory $TMPDIR (and $TEMP, $TMP...)
> points to.

The above output seems to be normal, I get the same on my system.
Besides, the files mentioned ...

,----
| /usr/share/initramfs-tools/scripts/panic/ORDER ignored: not executable
| /usr/share/initramfs-tools/scripts/local-premount/ORDER ignored: not executable
| /usr/share/initramfs-tools/scripts/local-bottom/ORDER ignored: not executable
| /usr/share/initramfs-tools/scripts/local-block/ORDER ignored: not executable
| /usr/share/initramfs-tools/scripts/local-top/ORDER ignored: not executable
| /usr/share/initramfs-tools/scripts/init-bottom/ORDER ignored: not executable
| /usr/share/initramfs-tools/scripts/init-top/ORDER ignored: not executable
| /usr/share/initramfs-tools/scripts/init-premount/ORDER ignored: not executable
`----

... don't even exist on those directories:

,----
| # ls -l /usr/share/initramfs-tools/scripts/*
| -rw-r--r-- 1 root root 9394 Dec 15 22:34 /usr/share/initramfs-tools/scripts/functions
| -rw-r--r-- 1 root root 4457 Apr 17 2016 /usr/share/initramfs-tools/scripts/local
| -rw-r--r-- 1 root root 3050 Feb 20 2016 /usr/share/initramfs-tools/scripts/nfs
|
| /usr/share/initramfs-tools/scripts/init-bottom:
| total 8
| -rwxr-xr-x 1 root root 147 Dec 18 11:50 plymouth
| -rwxr-xr-x 1 root root 572 Feb 1 22:45 udev
|
| /usr/share/initramfs-tools/scripts/init-premount:
| total 4
| -rwxr-xr-x 1 root root 464 Dec 18 11:50 plymouth
|
| /usr/share/initramfs-tools/scripts/init-top:
| total 16
| -rwxr-xr-x 1 root root 351 Dec 9 2015 all_generic_ide
| -rwxr-xr-x 1 root root 295 Dec 9 2015 blacklist
| -rwxr-xr-x 1 root root 358 Dec 9 2015 keymap
| -rwxr-xr-x 1 root root 501 Feb 1 22:45 udev
|
| /usr/share/initramfs-tools/scripts/local-block:
| total 8
| -rwxr-xr-x 1 root root 689 Dec 16 12:56 lvm2
| -rwxr-xr-x 1 root root 1206 Jul 28 2016 mdadm
|
| /usr/share/initramfs-tools/scripts/local-bottom:
| total 4
| -rwxr-xr-x 1 root root 46 Jul 28 2016 mdadm
|
| /usr/share/initramfs-tools/scripts/local-premount:
| total 8
| -rwxr-xr-x 1 root root 270 Sep 22 15:48 btrfs
| -rwxr-xr-x 1 root root 1041 Dec 9 2015 resume
|
| /usr/share/initramfs-tools/scripts/local-top:
| total 4
| -rwxr-xr-x 1 root root 970 Dec 16 12:56 lvm2
|
| /usr/share/initramfs-tools/scripts/panic:
| total 4
| -rwxr-xr-x 1 root root 151 Dec 18 11:50 plymouth
`----

I think the error message is misleading in this case.

> Mounting /tmp "noexec" is not really supported, regardless of whether it
> used to work in the past or not.

Looking at "lsof -p `pidof cpio` it looks like the initramfs is build
inside /var/tmp and not /tmp.

Grüße,

Mike Nunn

unread,
Feb 4, 2017, 3:30:02 PM2/4/17
to
can't install strace as apt suggests running dpkg --configure -a , prob due to the failure of the upgrade

with update-initramfs -u -v -k 3.16.0-4-amd64 hung there doesn't seem to be a cpio process running

Sven Hartge

unread,
Feb 4, 2017, 3:50:03 PM2/4/17
to
Mike Nunn <bonn...@gmail.com> wrote:

> can't install strace as apt suggests running dpkg --configure -a , prob due
> to the failure of the upgrade

> with update-initramfs -u -v -k 3.16.0-4-amd64 hung there doesn't seem to be
> a cpio process running

Strange.

If it hangs at "Building cpio /boot/initrd.img-3.16.0-4-amd64.new
initramfs" then there should be a cpio process.

Could then please share the full output of "df", "df -i" and "cat
/proc/mounts", each done as user "root"?

Grüße,

Mike Nunn

unread,
Feb 4, 2017, 4:00:04 PM2/4/17
to
update-initramfs pid 1373

sudo lsof -p 1373    
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
update-in 1373 root  cwd    DIR    9,2     4096 16515073 /root
update-in 1373 root  rtd    DIR    9,2     4096        2 /
update-in 1373 root  txt    REG    9,2   125400 23461891 /bin/dash
update-in 1373 root  mem    REG    9,2  1738176 26869908 /lib/x86_64-linux-gnu/libc-2.19.so
update-in 1373 root  mem    REG    9,2   140928 26869905 /lib/x86_64-linux-gnu/ld-2.19.so
update-in 1373 root    0u   CHR  136,4      0t0        7 /dev/pts/4
update-in 1373 root    1u   CHR  136,4      0t0        7 /dev/pts/4
update-in 1373 root    2u   CHR  136,4      0t0        7 /dev/pts/4
update-in 1373 root   10r   REG    9,2     8974 19546736 /usr/sbin/update-initramfs


Mike Nunn

unread,
Feb 4, 2017, 4:00:04 PM2/4/17
to
df 
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/md2       458453504 6569528 428572808   2% /
udev               10240       0     10240   0% /dev
tmpfs           13187516  320656  12866860   3% /run
tmpfs           32968784     504  32968280   1% /dev/shm
tmpfs               5120       0      5120   0% /run/lock
tmpfs           32968784       0  32968784   0% /sys/fs/cgroup
/dev/md1          498980   52528    420267  12% /boot
tmpfs            6593760       0   6593760   0% /run/user/1000
none           458453504 6569528 428572808   2% /var/lib/docker/aufs/mnt/bce41dd5773c817aea6e833cf53e43a1679c29e3d73c20c09ad3040bca57d573
shm                65536       0     65536   0% /var/lib/docker/containers/e9c96303b37e485c0990ac5c0b60e75009c2663b4bba9310867e73ec22c71401/shm
none           458453504 6569528 428572808   2% /var/lib/docker/aufs/mnt/bbe023c51a117696a4cf8cf9770ca7bfdb47e79a8b65d7a733afaba6d2b15839
none           458453504 6569528 428572808   2% /var/lib/docker/aufs/mnt/a238b58eeb33998d8adbeefa3b82d129d1cc5d9990667cafec8d818399cf6f03
shm                65536       0     65536   0% /var/lib/docker/containers/97a599c4375ce06d3df465529851f20fd6c63dae5da25221abce1e768d25a215/shm
shm                65536       0     65536   0% /var/lib/docker/containers/f839ffd572eb8d2a9e5059012227e06778bf491da83b0058c115be724f857e66/shm
none           458453504 6569528 428572808   2% /var/lib/docker/aufs/mnt/d0fe269d720b17579a9939bfa9d64b0d1607f35140f0dfd593cc7f9f20bc7f9e
shm                65536       0     65536   0% /var/lib/docker/containers/13e5125d33b80f5a54dcaeddb078ce093b27f8fa19797359166b32be9b122a7d/shm
none           458453504 6569528 428572808   2% /var/lib/docker/aufs/mnt/4e773bf15bc02540a2478aef0fffec0b83879712557d4985c31d0a80c3bbc498
none           458453504 6569528 428572808   2% /var/lib/docker/aufs/mnt/91ebefd722e8aab74b1037511bdbc22ce8366b98fd4f081695116cbecd40c992
shm                65536       0     65536   0% /var/lib/docker/containers/e7f8c5eccb175562c2a7941be220790d36240f0e9e38d96311166fd25a91d368/shm
shm                65536       0     65536   0% /var/lib/docker/containers/4fff1f2b2b141846488d39aede964a2629b16f0d97913f7207841c4444d4ca69/shm

df -i
Filesystem       Inodes  IUsed    IFree IUse% Mounted on
/dev/md2       29122560 270014 28852546    1% /
udev            8239770    310  8239460    1% /dev
tmpfs           8242196    685  8241511    1% /run
tmpfs           8242196     22  8242174    1% /dev/shm
tmpfs           8242196      7  8242189    1% /run/lock
tmpfs           8242196     13  8242183    1% /sys/fs/cgroup
/dev/md1         131072    329   130743    1% /boot
tmpfs           8242196      4  8242192    1% /run/user/1000
none           29122560 270014 28852546    1% /var/lib/docker/aufs/mnt/bce41dd5773c817aea6e833cf53e43a1679c29e3d73c20c09ad3040bca57d573
shm             8242196      1  8242195    1% /var/lib/docker/containers/e9c96303b37e485c0990ac5c0b60e75009c2663b4bba9310867e73ec22c71401/shm
none           29122560 270014 28852546    1% /var/lib/docker/aufs/mnt/bbe023c51a117696a4cf8cf9770ca7bfdb47e79a8b65d7a733afaba6d2b15839
none           29122560 270014 28852546    1% /var/lib/docker/aufs/mnt/a238b58eeb33998d8adbeefa3b82d129d1cc5d9990667cafec8d818399cf6f03
shm             8242196      1  8242195    1% /var/lib/docker/containers/97a599c4375ce06d3df465529851f20fd6c63dae5da25221abce1e768d25a215/shm
shm             8242196      1  8242195    1% /var/lib/docker/containers/f839ffd572eb8d2a9e5059012227e06778bf491da83b0058c115be724f857e66/shm
none           29122560 270014 28852546    1% /var/lib/docker/aufs/mnt/d0fe269d720b17579a9939bfa9d64b0d1607f35140f0dfd593cc7f9f20bc7f9e
shm             8242196      1  8242195    1% /var/lib/docker/containers/13e5125d33b80f5a54dcaeddb078ce093b27f8fa19797359166b32be9b122a7d/shm
none           29122560 270014 28852546    1% /var/lib/docker/aufs/mnt/4e773bf15bc02540a2478aef0fffec0b83879712557d4985c31d0a80c3bbc498
none           29122560 270014 28852546    1% /var/lib/docker/aufs/mnt/91ebefd722e8aab74b1037511bdbc22ce8366b98fd4f081695116cbecd40c992
shm             8242196      1  8242195    1% /var/lib/docker/containers/e7f8c5eccb175562c2a7941be220790d36240f0e9e38d96311166fd25a91d368/shm
shm             8242196      1  8242195    1% /var/lib/docker/containers/4fff1f2b2b141846488d39aede964a2629b16f0d97913f7207841c4444d4ca69/shm

cat /proc/mounts
rootfs / rootfs rw 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,relatime 0 0
udev /dev devtmpfs rw,relatime,size=10240k,nr_inodes=8239770,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,relatime,size=13187516k,mode=755 0 0
/dev/md2 / ext4 rw,relatime,data=ordered 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd 0 0
pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/net_cls,net_prio cgroup rw,nosuid,nodev,noexec,relatime,net_cls,net_prio 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,relatime 0 0
/dev/md1 /boot ext3 rw,relatime,data=ordered 0 0
/dev/md2 /var/lib/docker/aufs ext4 rw,relatime,data=ordered 0 0
tmpfs /run/user/1000 tmpfs rw,nosuid,nodev,relatime,size=6593760k,mode=700,uid=1000,gid=1000 0 0
none /var/lib/docker/aufs/mnt/bce41dd5773c817aea6e833cf53e43a1679c29e3d73c20c09ad3040bca57d573 aufs rw,relatime,si=73a3abc983bbbe2b,dio,dirperm1 0 0
shm /var/lib/docker/containers/e9c96303b37e485c0990ac5c0b60e75009c2663b4bba9310867e73ec22c71401/shm tmpfs rw,nosuid,nodev,noexec,relatime,size=65536k 0 0
proc /run/docker/netns/b519628d5243 proc rw,relatime 0 0
none /var/lib/docker/aufs/mnt/bbe023c51a117696a4cf8cf9770ca7bfdb47e79a8b65d7a733afaba6d2b15839 aufs rw,relatime,si=73a3abc49f688e2b,dio,dirperm1 0 0
none /var/lib/docker/aufs/mnt/a238b58eeb33998d8adbeefa3b82d129d1cc5d9990667cafec8d818399cf6f03 aufs rw,relatime,si=73a3abcad2b12e2b,dio,dirperm1 0 0
shm /var/lib/docker/containers/97a599c4375ce06d3df465529851f20fd6c63dae5da25221abce1e768d25a215/shm tmpfs rw,nosuid,nodev,noexec,relatime,size=65536k 0 0
proc /run/docker/netns/afb4cc8d9867 proc rw,relatime 0 0
shm /var/lib/docker/containers/f839ffd572eb8d2a9e5059012227e06778bf491da83b0058c115be724f857e66/shm tmpfs rw,nosuid,nodev,noexec,relatime,size=65536k 0 0
proc /run/docker/netns/a78a51049371 proc rw,relatime 0 0
none /var/lib/docker/aufs/mnt/d0fe269d720b17579a9939bfa9d64b0d1607f35140f0dfd593cc7f9f20bc7f9e aufs rw,relatime,si=73a3abc922ec6e2b,dio,dirperm1 0 0
shm /var/lib/docker/containers/13e5125d33b80f5a54dcaeddb078ce093b27f8fa19797359166b32be9b122a7d/shm tmpfs rw,nosuid,nodev,noexec,relatime,size=65536k 0 0
proc /run/docker/netns/c46f84f48fac proc rw,relatime 0 0
none /var/lib/docker/aufs/mnt/4e773bf15bc02540a2478aef0fffec0b83879712557d4985c31d0a80c3bbc498 aufs rw,relatime,si=73a3abcbf2719e2b,dio,dirperm1 0 0
none /var/lib/docker/aufs/mnt/91ebefd722e8aab74b1037511bdbc22ce8366b98fd4f081695116cbecd40c992 aufs rw,relatime,si=73a3abcb5dae2e2b,dio,dirperm1 0 0
shm /var/lib/docker/containers/e7f8c5eccb175562c2a7941be220790d36240f0e9e38d96311166fd25a91d368/shm tmpfs rw,nosuid,nodev,noexec,relatime,size=65536k 0 0
shm /var/lib/docker/containers/4fff1f2b2b141846488d39aede964a2629b16f0d97913f7207841c4444d4ca69/shm tmpfs rw,nosuid,nodev,noexec,relatime,size=65536k 0 0
proc /run/docker/netns/5d85c10ebc3b proc rw,relatime 0 0
proc /run/docker/netns/be28a4421d53 proc rw,relatime 0 0


Ric Moore

unread,
Feb 5, 2017, 12:10:03 AM2/5/17
to
On 02/04/2017 03:25 PM, Mike Nunn wrote:

Please don't top post. Thanx, Ric
--
My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
http://linuxcounter.net/user/44256.html

Mike Nunn

unread,
Feb 5, 2017, 6:30:04 AM2/5/17
to
I have an strace output for the following:

strace -f -o foo update-initramfs -u -v

It stopped at the following line as usual:

Building cpio /boot/initrd.img-3.16.0-4-amd64.new initramfs

The last few lines of the strace output:

12056 open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3 
12056 fstat(3, {st_mode=S_IFREG|0644, st_size=2855152, ...}) = 0 
12056 mmap(NULL, 2855152, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f46dea0e000 
12056 close(3)                          = 0
12056 sync(

I have tried this twice with the same screen output and strace output.

I'm not sure what to do next.

Thanks for any help.

Mike

Lisi Reisz

unread,
Feb 5, 2017, 8:40:05 AM2/5/17
to
And please don't break threads.

In addition to Ric's "Please don't top post".

This email above which I am top posting requires a lot of effort on the part
of any potential helper. No "history". Thread broken. Replied to wrong
email .....

Lisi

Mike Nunn

unread,
Feb 5, 2017, 9:00:03 AM2/5/17
to

On 5 February 2017 at 13:33, Lisi Reisz <lisi....@gmail.com> wrote:
In addition to Ric's "Please don't top post".

OK will do Thanks, Is it worth starting a new thread as the problem is now much more specific?

Mike

Sven Hartge

unread,
Feb 5, 2017, 9:50:04 AM2/5/17
to
Mike Nunn <bonn...@gmail.com> wrote:
> [-- text/plain, encoding 7bit, charset: UTF-8, 24 lines --]
Can you please check if process 12056 is "/bin/sync"? Search for a line
above looking like

3400 execve("/bin/sync", ["sync"], [/* 23 vars */]) = 0

(3400 being the PID of sync in my example here)

If this is the case, then you build stops at line 176 of
/usr/sbin/update-initramfs. Good news is: at that point the initramfs
has already been created successfully and moved into the right place.
The only step left is to run "update-grub".

But when the sync() system call blocks for such a long time, there is
something very wrong with either the kernel or the underlying medium.

Please test if just calling "strace sync" as root hangs as well.

But right now, I don't think this is a bug in update-initramfs but
somewhere else. Maybe inside the NVMe driver in the Linux Kernel.

Mike Nunn

unread,
Feb 5, 2017, 10:20:03 AM2/5/17
to
On 5 February 2017 at 14:47, Sven Hartge <sv...@svenhartge.de> wrote:

> Can you please check if process 12056 is "/bin/sync"? Search for a line
> above looking like
> 3400 execve("/bin/sync", ["sync"], [/* 23 vars */]) = 0

Yes it is:

12056 execve("/bin/sync", ["sync"], [/* 18 vars */]) = 0

> Please test if just calling "strace sync" as root hangs as well.

Yes it does

strace sync
.................
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2855152, ...}) = 0
mmap(NULL, 2855152, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fc63a03c000
close(3) = 0
sync(

20 minutes now, exits immediately on my local machine.

Looks like you narrowed it down to an underlying problem.

Thanks very much for your help.

Sven Hartge

unread,
Feb 5, 2017, 10:40:03 AM2/5/17
to
Mike Nunn <bonn...@gmail.com> wrote:
> On 5 February 2017 at 14:47, Sven Hartge <sv...@svenhartge.de> wrote:

>> Please test if just calling "strace sync" as root hangs as well.

> Yes it does

> strace sync
> .................
> open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=2855152, ...}) = 0
> mmap(NULL, 2855152, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fc63a03c000
> close(3) = 0
> sync(

> 20 minutes now, exits immediately on my local machine.

This should not take that long. On a normal system, sync times of over 2
seconds are rare and if you have something like a SSD or NVMe as storage
it should be nearly instant.

> Looks like you narrowed it down to an underlying problem.

You can unfuzz your package system by temporarily commenting the call to
"sync" in update-initramfs to get it to complete, but you really should
try to find out the real problem.

Maybe by using the latest kernel from backports.


Mike Nunn

unread,
Feb 5, 2017, 12:10:04 PM2/5/17
to
On 5 February 2017 at 15:31, Sven Hartge <sv...@svenhartge.de> wrote:
> You can unfuzz your package system by temporarily commenting the call to
> "sync" in update-initramfs to get it to complete, but you really should
> try to find out the real problem.

Package system unfuzzed, thanks!

It's Hetzners standard build on their hardware so will follow up with
them, as you say
something seriously wrong.

Thanks very much for you help!

Mike

Sven Hartge

unread,
Feb 5, 2017, 12:10:04 PM2/5/17
to
Mike Nunn <bonn...@gmail.com> wrote:

> It's Hetzners standard build on their hardware so will follow up with
> them, as you say something seriously wrong.

Knowing Hetzner, I doubt they will be helpful.

Mike Nunn

unread,
Feb 7, 2017, 7:40:03 AM2/7/17
to
On 5 February 2017 at 17:08, Sven Hartge <sv...@svenhartge.de> wrote:
> Knowing Hetzner, I doubt they will be helpful.

They suggested changing the nvme disks though I thought this should
only be a last resort.

I tried your earlier suggestion and upgraded to 4.9 kernel from
backports all seems well with sync!

Thanks again for your help.

Regards

Mike

Henrique de Moraes Holschuh

unread,
Feb 8, 2017, 5:40:03 AM2/8/17
to
On Sat, Feb 4, 2017, at 17:52, Sven Hartge wrote:
> Henrique de Moraes Holschuh <h...@debian.org> wrote:
> > On Sat, 04 Feb 2017, Mike Nunn wrote:
>
> >> /usr/share/initramfs-tools/scripts/local-block/ORDER ignored: not executable
>
> > Is /tmp mounted "noexec"? Just Don't Do It[tm]. The system will break
> > in hideously crazy, suprising ways. BTW, this is also valid for the
> > filesystem hosting whatever directory $TMPDIR (and $TEMP, $TMP...)
> > points to.
>
> The above output seems to be normal, I get the same on my system.

Argh. Indeed, a boot hang could/would happen should you get exec
failures on the ORDER files that are *inside* the initramfs, i.e. if the
file reported as not being executable was something like this:

/var/tmp/mkinitramfs_########/scripts/local-block/ORDER

(and yes, it is /var/tmp and not /tmp as I said... My recollection of
this very obscure issue was slightly corrupted by time :-( )

I failed to notice the path on the ORDER files it was reporting as not
being able to execute, I apologize for that.

--

solitone

unread,
Feb 8, 2017, 6:00:03 AM2/8/17
to
Hi,

as I told in thread "Monitor switched off after resume from hibernation", my
MacBookPro 12,1 had problems with hibernation in stretch. If hibernation
happened after the monitor had been switched off, the system would not turn
the monitor on again after resume. Therefore I disabled hibernation.

With time, though, I noticed that even suspension doesn't work very well.
Sometimes the laptop does not suspend, neither if I wait for the set 5
minutes, nor if I close the lid. It basically remains active, cunsuming
battery.

So today I tried to re-enable hibernation, and discovered that now it does not
work at all. Perhaps it was a recent stretch update, but now hibernation can't
be used at all. Previously it worked at least when the monitor was on. Now
even when the monitor is on and I hibernate, when the system resumes I don't
get a usable session. I just get an emtpy black screen with the white cursor
on it, but nothing happens. I can't even switch to a virtual console with crtl
+alt+F<n>.

What do you suggest to do to investigate this issue? A functional power
management is a must on a portable computer.

Thanks!

solitone

unread,
Feb 8, 2017, 9:40:03 AM2/8/17
to
Hi, I resend this message because in my previous attempt I mistakenly linked
it to a completely unrelated thread. Sorry for the inconvenience.

solitone

unread,
Feb 10, 2017, 6:40:04 AM2/10/17
to
On Wednesday, 8 February 2017 15:37:48 CET solitone wrote:
> With time, though, I noticed that even suspension doesn't work very well.
> Sometimes the laptop does not suspend, neither if I wait for the set 5
> minutes, nor if I close the lid. It basically remains active, cunsuming
> battery.

After a fresh boot, suspend does work. However, after resume, a second suspend
attempt doesn't work--the system automatically resumes after a couple of
seconds.

I'm still far from a solution at the moment.

solitone

unread,
Feb 12, 2017, 3:10:03 PM2/12/17
to
On Friday, 10 February 2017 12:31:39 CET solitone wrote:
> After a fresh boot, suspend does work. However, after resume, a second
> suspend attempt doesn't work--the system automatically resumes after a
> couple of seconds.

Now it always resumes immediately after suspend. I have no idea why initially
suspend worked ok, then it started to work only intermittently, and now it
never works.

Anyhow, it depends on the the wakeup capable devices. Here's is the default
configuration:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
solitone@alan:~$ acpitool -w
[sudo] password for solitone:
Device S-state Status Sysfs node
---------------------------------------
1. PEG0 S3 *disabled
2. EC S4 *disabled platform:PNP0C09:00
3. HDEF S3 *disabled pci:0000:00:1b.0
4. RP01 S3 *disabled pci:0000:00:1c.0
5. RP02 S3 *disabled pci:0000:00:1c.1
6. RP03 S3 *disabled pci:0000:00:1c.2
7. ARPT S4 *enabled pci:0000:03:00.0
8. RP05 S3 *disabled pci:0000:00:1c.4
9. RP06 S3 *disabled pci:0000:00:1c.5
10. SPIT S3 *disabled
11. XHC1 S3 *enabled pci:0000:00:14.0
12. ADP1 S4 *disabled platform:ACPI0003:00
13. LID0 S4 *enabled platform:PNP0C0D:00
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Device #13 (LID0) is the lid, and #11 (XCHI) is the USB xHCI controller. If I
disable both, suspend works well again:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
solitone@alan:~$ sudo acpitool -W 13; sudo acpitool -W 11
[...]
Changed status for wakeup device #11 (XHC1)

Device S-state Status Sysfs node
---------------------------------------
1. PEG0 S3 *disabled
2. EC S4 *disabled platform:PNP0C09:00
3. HDEF S3 *disabled pci:0000:00:1b.0
4. RP01 S3 *disabled pci:0000:00:1c.0
5. RP02 S3 *disabled pci:0000:00:1c.1
6. RP03 S3 *disabled pci:0000:00:1c.2
7. ARPT S4 *enabled pci:0000:03:00.0
8. RP05 S3 *disabled pci:0000:00:1c.4
9. RP06 S3 *disabled pci:0000:00:1c.5
10. SPIT S3 *disabled
11. XHC1 S3 *disabled pci:0000:00:14.0
12. ADP1 S4 *disabled platform:ACPI0003:00
13. LID0 S4 *disabled platform:PNP0C0D:00
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The thing is that now I can wake the system up only pressing the power
button--neither the keybord nor the trackpad does.

solitone

unread,
Feb 13, 2017, 12:50:05 AM2/13/17
to
On Wednesday, 8 February 2017 15:37:48 CET solitone wrote:
> today I tried to re-enable hibernation, and discovered that now it does
> not work at all. Perhaps it was a recent stretch update, but now
> hibernation can't be used at all. Previously it worked at least when the
> monitor was on. Now even when the monitor is on and I hibernate, when the
> system resumes I don't get a usable session. I just get an emtpy black
> screen with the white cursor on it, but nothing happens. I can't even
> switch to a virtual console with crtl +alt+F<n>.

As for hibernate, I'm still far from a solution.

I've noticed that when I hibernate from the multi-user target (i.e. not from
graphical mode), resume does end up with a usable console session (although
the wifi adapter does not work, and unloading/reloading the kernel module
doesn't work either).

However, when I hibernate from the graphical target (KDE Plasma), I experience
the problem I described above.

Uff.. power management is complex!

Lisi Reisz

unread,
Feb 15, 2017, 12:30:03 PM2/15/17
to
On Wednesday 08 February 2017 10:50:52 solitone wrote:
> What do you suggest to do to investigate this issue?

Not hijack another thread.

Lisi

Darac Marjal

unread,
Feb 15, 2017, 12:40:03 PM2/15/17
to
I'm not sure that I see how hijacking a thread prevents a laptop from
suspending, but - certainly - avoiding it is SOMETHING to try.

The OP could also try the information in, for example:

https://wiki.ubuntu.com/DebuggingKernelSuspend
https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues
https://wiki.archlinux.org/index.php/Power_management/Suspend_and_hibernate#Troubleshooting

>

>Lisi
>

--
For more information, please reread.

solitone

unread,
Feb 15, 2017, 12:50:04 PM2/15/17
to
Sorry for the hijacking, I mistakenly replied to a message in this thread, it
wasn't deliberate :^)

In the meanwhile I did open another thread, and if you will we can discuss
there. For now, thanks for the links.

Cheers,
Davide

solitone

unread,
Feb 15, 2017, 1:00:04 PM2/15/17
to
For reference, I resend Darac's advice on this thread, that is the correct
one:
0 new messages