Bug#816959: apticron: Error with packages on hold.

[Rick Thomas]

Package: apticron
Version: 1.1.58
Followup-For: Bug #816959

Dear Maintainer,

 Me too...


-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: armel (armv5tel)

Kernel: Linux 4.6.0-1-marvell
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


Versions of packages apticron depends on:
ii  apt1.3~rc1
ii  bsd-mailx [mailx]  8.1.2-0.20160123cvs-3
ii  bzip2  1.0.6-8
ii  cron [cron-daemon] 3.0pl1-128
ii  debconf [debconf-2.0]  1.5.59
ii  dpkg   1.18.10
ii  ucf3.0036

Versions of packages apticron recommends:
ii  apt-listchanges  2.89
ii  iproute2 4.6.0-2

apticron suggests no packages.

-- debconf information:
  apticron/notification: root

Bug#832713: systemd: after "systemd (231-1) unstable" update systemd-jurnald.service fails to start

[Rick Thomas]

On Aug 12, 2016, at 9:21 AM, Pete Batard  wrote:

> Okay. I have now gone through a dpkg -i install of all the (non dbgsym) .deb 
> I see on your server, and also issued a reboot for good measure, but I still 
> see the same problem with journald being failed, along with dependent services

Hi Filipe,

Would you like me to also do what pete describes (all the .deb files) or is 
there a more fine-grained test you’d like me to try?

Rick

Bug#832713: systemd: after "systemd (231-1) unstable" update systemd-jurnald.service fails to start

[Rick Thomas]

> On Aug 3, 2016, at 3:58 PM, Felipe Sateler <fsate...@debian.org> wrote:
> 
> On 3 August 2016 at 16:44, Rick Thomas <rbtho...@pobox.com> wrote:
>> 
>> On Aug 3, 2016, at 9:06 AM, Felipe Sateler <fsate...@debian.org> wrote:
>> 
>>> On 1 August 2016 at 18:32, Rick Thomas <rbtho...@pobox.com> wrote:
>>>> 
>>>> Thanks, Filipe!
>>>> 
>>>> What do we have to do at this point to test this and then translate it 
>>>> into a patch?
>>> 
>>> OK, so I have a proof-of-concept patch. Rick, could you test it in your 
>>> machine?
>> 
>> I’m afraid I don’t have the facilities or the expertise to turn this into a 
>> loadable kernel .deb .
>> 
>> If someone can provide an installable kernel .deb file for a Cuboxi4-Pro 
>> machine, I’ll he happy to test it.
> 
> This is a patch for systemd, not the kernel. I prepared a source
> package for easier testing. Do the following:
> 
> apt-get install dpkg-dev devscripts
> apt-get build-dep systemd
> dget https://people.debian.org/~fsateler/systemd_231-2.dsc
> cd systemd-231
> dpkg-buildpackage
> 
> That should leave you with several .debs (after a long time). Install
> libsystemd0 and systemd from those debs.

Great!  Thanks for the instructions.  I’ll give it a try soon.
Rick

Bug#832713: systemd: after "systemd (231-1) unstable" update systemd-jurnald.service fails to start

[Rick Thomas]

On Aug 3, 2016, at 9:06 AM, Felipe Sateler <fsate...@debian.org> wrote:

> On 1 August 2016 at 18:32, Rick Thomas <rbtho...@pobox.com> wrote:
>> 
>> Thanks, Filipe!
>> 
>> What do we have to do at this point to test this and then translate it into 
>> a patch?
> 
> OK, so I have a proof-of-concept patch. Rick, could you test it in your 
> machine?

I’m afraid I don’t have the facilities or the expertise to turn this into a 
loadable kernel .deb .

If someone can provide an installable kernel .deb file for a Cuboxi4-Pro 
machine, I’ll he happy to test it.

Thanks!
Rick

Bug#832713: systemd: after "systemd (231-1) unstable" update systemd-jurnald.service fails to start

[Rick Thomas]

On Aug 2, 2016, at 11:15 PM, Michael Biebl  wrote:

> Am 01.08.2016 um 23:40 schrieb Felipe Sateler:
>> So I think the kernel should enable SECCOMP.
> 
> I agree, unless SECCOMP on arm has some unwanted side-effects.
> Felipe, can you file a bug report against the linux package accordingly?

It may be that there are size considerations that preclude turning on such 
features for kernels on certain arm devices (armel comes to mind with 
SheevaPlug and OpenRD as examples).

I’m not sure of that — and definitely unsure of the details, but I guess the 
linux package maintainers will know for sure.

Rick

Bug#832713: systemd: after "systemd (231-1) unstable" update systemd-jurnald.service fails to start

[Rick Thomas]

On Aug 1, 2016, at 2:40 PM, Felipe Sateler <fsate...@debian.org> wrote:

> On 28 July 2016 at 17:04, Michael Biebl <bi...@debian.org> wrote:
>> Am 28.07.2016 um 22:50 schrieb Rick Thomas:
>>> In the interest of having a working system, I reverted that machine to 
>>> systemd version 230-7.  Unsurprisingly, the problem went away.
>>> 
>>> I’ll try re-installing 231-1 and commenting that line.  I’ll probably have 
>>> a chance tonight.  I’ll report when I have something.
>>> 
>>> It may be worth noticing that other things failed as well when 231-1 was 
>>> in.  I’m attaching a ‘grep -i fail -C20’ of the screen log.  Of particular 
>>> note are “Failed to start Raise network interfaces” and “Failed to start 
>>> Login Service.”
>>> 
>>> Are there other places where I should remove a “SystemCallFilter” ?
>>> 
>> 
>> Various units were locked down like e.g. in
>> https://github.com/systemd/systemd/commit/4e069746fe0de1f60bd1b75c113b0f40ffe86736
>> 
>> If the SystemCallFilter= is what causes journald to fail, it's likely it
>> also affects those other services.
> 
> Turns out seccomp is disabled in the arm* kernels:
> 
> % grep SECCOMP boot/config-4.6.0-1-marvell
> CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
> # CONFIG_SECCOMP is not set
> 
> % grep SECCOMP boot/config-4.6.0-1-armmp
> CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
> # CONFIG_SECCOMP is not set
> 
> So I think the kernel should enable SECCOMP.
> 
> However, I think systemd should also simply (warn and) ignore seccomp
> calls if seccomp is not available in the current kernel.
> 
> -- 
> 
> Saludos,
> Felipe Sateler

Thanks, Filipe!

What do we have to do at this point to test this and then translate it into a 
patch?

Michael, do you have any suggestions?

Thanks!
Rick

Bug#461461: [pkg-ntp-maintainers] Bug#461461: This bug is still present -- change to systemd did not fix it!

[Rick Thomas]

On Aug 1, 2016, at 6:32 AM, Kurt Roeckx  wrote:

>> 
>> The DHCPACK that assigns the IP address to the interface occurs during the 
>> middle of ntpd's startup, so two of three pool statements get failed DNS.  
>> The third one succeeds, so ntpd gets some servers, but not all the servers 
>> it's configured for.
>> 
> 
> It looked to me like it was working.  It says that it was a
> temporary failure, and as far as I know it will retry it in that
> case.
> 
> Also not that ntpd has some weird logic of how many servers it's
> using when using "pool", and it's probably not using it from all
> the pools.  You can set the maximum higher using "tos maxclock
> XX".
> 
> I was under the impression that when using "server" and getting
> a permanent DNS error it would give up on it but that with a
> temporary error it will retry.  And that with pool it keeps
> retrying, but I'm not sure about that.
> 
> Anyway, that it's a temporary or permanent error depends on what
> glibc returns, and I've been trying to get that fixed for years.
> 
> 
> Kurt

Thanks, Kurt!  I understand your frustration.

Fragility of ntpd in the presence of DNS errors is important, and
it should be fixed.  But it’s not the point I was trying to make
with these bug reports.

My point is that whole thing could be avoided if systemd would
wait to start ntpd and ntpdate until *after* the network interface
has been *fully* initialized.

If I understood more about the details of how systemd orders such
things, I might be able to come up with a patch.  But, sadly, every
time I try to understand that aspect of systemd, I wind up in a maze
of twisty little man pages and wiki references, all alike…   /-:

Rick

Bug#833136: Fwd: [pkg-ntp-maintainers] Bug#461461: This bug is still present -- change to systemd did not fix it!

[Rick Thomas]

On Aug 1, 2016, at 2:56 AM, Kurt Roeckx <k...@roeckx.be> wrote:

> On Mon, Aug 01, 2016 at 02:37:58AM -0700, Rick Thomas wrote:
>> This 8 year old bug is still present in jessie and stretch -- the change to 
>> systemd did not fix it!
>> 
>> Please, somebody pay attention!  This bug makes ntpd unreliable tending to 
>> useless on systems that get their network config from dhcp.
> 
> There are various things broken, but as far as I know in stretch
> things should just work.
> 
> You seem to say that this is related to getting the ntp servers
> from dhcp, but that's not making sense to me.  The dhcp server
> should give you IP addresses, so it can never be a problem with
> DNS, the peers should always be there.
> 
> 
> Kurt



I’ll try it again in sid and stretch, but it was there the last time I looked.

The problem is not getting dhcpclient to give ntp servers.  I’ve put hard coded 
ipv4 addresses in /etc/default/ntpdate, so that’s not it.

The problem is that the network interface is not fully available when ntpdate 
runs.  I think this is because dhcpclient has not provided an IP address for 
the interface yet.

Here’s a snatch from journalctl that shows the problem in jessie:

> Aug 01 02:49:46 dillserver kernel: sungem_phy: PHY ID: 206053, addr: 0
> Aug 01 02:49:46 dillserver kernel: gem 0002:20:0f.0 eth0: Found BCM5401 PHY
> Aug 01 02:49:46 dillserver kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is 
> not ready
> Aug 01 02:49:46 dillserver ntpdate[661]: no servers can be used, exiting
> Aug 01 02:49:46 dillserver networking[469]: Configuring network 
> interfaces...done.
> Aug 01 02:49:46 dillserver systemd[1]: Started LSB: Raise network interfaces..
> Aug 01 02:49:46 dillserver systemd[1]: Starting ifup for eth0...
> Aug 01 02:49:46 dillserver systemd[1]: Started ifup for eth0.
> Aug 01 02:49:46 dillserver systemd[1]: Starting Network.
> Aug 01 02:49:46 dillserver systemd[1]: Reached target Network.
> Aug 01 02:49:46 dillserver systemd[1]: Starting Network is Online.
> Aug 01 02:49:46 dillserver systemd[1]: Reached target Network is Online.
> Aug 01 02:49:46 dillserver systemd[1]: Starting LSB: RPC portmapper 
> replacement...
> Aug 01 02:49:47 dillserver rpcbind[672]: Starting rpcbind daemon
> Aug 01 02:49:47 dillserver systemd[1]: Started LSB: RPC portmapper 
> replacement.
> Aug 01 02:49:47 dillserver systemd[1]: Starting RPC Port Mapper.
> Aug 01 02:49:47 dillserver systemd[1]: Reached target RPC Port Mapper.
> Aug 01 02:49:47 dillserver systemd[1]: Starting LSB: NFS support files common 
> to client and server...
> Aug 01 02:49:47 dillserver dhclient[685]: Internet Systems Consortium DHCP 
> Client 4.3.1
> Aug 01 02:49:47 dillserver dhclient[685]: Copyright 2004-2014 Internet 
> Systems Consortium.
> Aug 01 02:49:47 dillserver dhclient[685]: All rights reserved.
> Aug 01 02:49:47 dillserver dhclient[685]: For info, please visit 
> https://www.isc.org/software/dhcp/
> Aug 01 02:49:47 dillserver dhclient[685]: 
> Aug 01 02:49:47 dillserver ifup[671]: Internet Systems Consortium DHCP Client 
> 4.3.1
> Aug 01 02:49:47 dillserver ifup[671]: Copyright 2004-2014 Internet Systems 
> Consortium.
> Aug 01 02:49:47 dillserver ifup[671]: All rights reserved.
> Aug 01 02:49:47 dillserver ifup[671]: For info, please visit 
> https://www.isc.org/software/dhcp/
> Aug 01 02:49:47 dillserver dhclient[685]: Listening on 
> LPF/eth0/00:03:93:3d:bd:bc
> Aug 01 02:49:47 dillserver dhclient[685]: Sending on   
> LPF/eth0/00:03:93:3d:bd:bc
> Aug 01 02:49:47 dillserver dhclient[685]: Sending on   Socket/fallback
> Aug 01 02:49:47 dillserver dhclient[685]: DHCPDISCOVER on eth0 to 
> 255.255.255.255 port 67 interval 4
> Aug 01 02:49:47 dillserver ifup[671]: Listening on LPF/eth0/00:03:93:3d:bd:bc
> Aug 01 02:49:47 dillserver ifup[671]: Sending on   LPF/eth0/00:03:93:3d:bd:bc
> Aug 01 02:49:47 dillserver ifup[671]: Sending on   Socket/fallback
> Aug 01 02:49:47 dillserver ifup[671]: DHCPDISCOVER on eth0 to 255.255.255.255 
> port 67 interval 4

Rick

Bug#833136: [pkg-ntp-maintainers] Bug#461461: This bug is still present -- change to systemd did not fix it!

[Rick Thomas]

 03:52:26 ultimate dhclient[247]: DHCPREQUEST of 192.168.3.4 on eth0 to 
> 255.255.255.255 port 67
> May 18 03:52:26 ultimate dhclient[247]: DHCPOFFER of 192.168.3.4 from 
> 192.168.3.111
> May 18 03:52:26 ultimate sh[234]: DHCPACK of 192.168.3.4 from 192.168.3.111
> May 18 03:52:26 ultimate dhclient[247]: DHCPACK of 192.168.3.4 from 
> 192.168.3.111
> May 18 03:52:26 ultimate avahi-daemon[299]: Joining mDNS multicast group on 
> interface eth0.IPv4 with address 192.168.3.4.
> May 18 03:52:26 ultimate avahi-daemon[299]: New relevant interface eth0.IPv4 
> for mDNS.
> May 18 03:52:26 ultimate avahi-daemon[299]: Registering new address record 
> for 192.168.3.4 on eth0.IPv4.
> May 18 03:52:26 ultimate dhclient[247]: bound to 192.168.3.4 -- renewal in 
> 3521 seconds.
> May 18 03:52:26 ultimate sh[234]: bound to 192.168.3.4 -- renewal in 3521 
> seconds.
> May 18 03:52:26 ultimate ntpd[399]: Soliciting pool server 
> 2001:4978:1:400:202:b3ff:feb4:59cb
> May 18 03:52:27 ultimate systemd[1]: Reloading OpenBSD Secure Shell server.
> May 18 03:52:27 ultimate sshd[305]: Received SIGHUP; restarting.
> May 18 03:52:27 ultimate systemd[1]: Reloaded OpenBSD Secure Shell server.
> May 18 03:52:28 ultimate sh[234]: eth0=eth0
> May 18 03:52:28 ultimate sshd[305]: Server listening on 0.0.0.0 port 22.
> May 18 03:52:28 ultimate sshd[305]: Server listening on :: port 22.
> May 18 03:52:28 ultimate ntpd[399]: Listen normally on 5 eth0 192.168.3.4:123
> May 18 03:52:28 ultimate ntpd[399]: Listen normally on 6 eth0 
> [2001:4978:2d2:1:f2ad:4eff:fe00:613c]:123
> May 18 03:52:28 ultimate ntpd[399]: Listen normally on 7 eth0 
> [fe80::f2ad:4eff:fe00:613c%2]:123
> May 18 03:52:31 ultimate colord[387]: (colord:387): Cd-WARNING **: failed to 
> get session [pid 318]: No such device or address
> May 18 03:52:32 ultimate kernel: warning: process `colord-sane' used the 
> deprecated sysctl system call with 8.1.2.
> May 18 03:52:40 ultimate ntpd[399]: Soliciting pool server 192.168.3.111
> May 18 03:52:41 ultimate ntpd[399]: Soliciting pool server 192.168.3.207
> May 18 03:52:41 ultimate systemd[1]: Time has been changed
> May 18 03:52:41 ultimate systemd[1]: apt-daily.timer: Adding 8h 21min 
> 54.588061s random time.
> May 18 03:52:42 ultimate ntpd[399]: Soliciting pool server 192.168.1.14
> May 18 03:52:57 ultimate sshd[813]: Accepted publickey for rbthomas from 
> 192.168.3.23 port 52072 ssh2: RSA SHA256:5oYjhr5L23tD0o
> May 18 03:52:57 ultimate sshd[813]: pam_unix(sshd:session): session opened 
> for user rbthomas by (uid=0)
> May 18 03:52:57 ultimate systemd-logind[307]: New session 1 of user rbthomas.
> May 18 03:52:57 ultimate systemd[1]: Created slice User Slice of rbthomas.
> May 18 03:52:57 ultimate systemd[1]: Starting User Manager for UID 1000...
> May 18 03:52:57 ultimate systemd[1]: Started Session 1 of user rbthomas.
> May 18 03:52:57 ultimate systemd[815]: pam_unix(systemd-user:session): 
> session opened for user rbthomas by (uid=0)
> May 18 03:52:57 ultimate systemd[815]: Reached target Paths.
> May 18 03:52:57 ultimate systemd[815]: Reached target Sockets.
> May 18 03:52:57 ultimate systemd[815]: Reached target Timers.
> May 18 03:52:57 ultimate systemd[815]: Reached target Basic System.
> May 18 03:52:57 ultimate systemd[815]: Reached target Default.
> May 18 03:52:57 ultimate systemd[815]: Startup finished in 128ms.
> May 18 03:52:57 ultimate systemd[1]: Started User Manager for UID 1000.
> May 18 03:53:29 ultimate ntpd[399]: Soliciting pool server 199.199.208.25
> May 18 03:53:30 ultimate ntpd[399]: Soliciting pool server 129.250.35.250
> May 18 03:53:31 ultimate ntpd[399]: Soliciting pool server 50.116.55.65

The DHCPACK that assigns the IP address to the interface occurs during the 
middle of ntpd’s startup, so two of three pool statements get failed DNS.  The 
third one succeeds, so ntpd gets some servers, but not all the servers it’s 
configured for.



On Aug 1, 2016, at 3:53 AM, Rick Thomas <rbtho...@pobox.com> wrote:

> First of all, thanks very much for the prompt reply!
> 
> I’ll try it again in sid and stretch, but it was there the last time I looked.
> 
> The problem is not getting dhcpclient to give ntp servers.  I’ve put hard 
> coded ipv4 addresses in /etc/default/ntpdate, so that’s not it.
> 
> The problem is that the network interface is not fully available when ntpdate 
> runs.  I think this is because dhcpclient has not provided an IP address for 
> the interface yet.
> 
> Here’s a snatch from journalctl that shows the problem in jessie:
> 
>> Aug 01 02:49:46 dillserver kernel: sungem_phy: PHY ID: 206053, addr: 0
>> Aug 01 02:49:46 dillserver kernel: gem 0002:20:0f.0 eth0: Found BCM5401 PHY
>> Aug 01 02:49:46 dillserver kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link 

Bug#461461: [pkg-ntp-maintainers] Bug#461461: This bug is still present -- change to systemd did not fix it!

[Rick Thomas]

First of all, thanks very much for the prompt reply!

I’ll try it again in sid and stretch, but it was there the last time I looked.

The problem is not getting dhcpclient to give ntp servers.  I’ve put hard coded 
ipv4 addresses in /etc/default/ntpdate, so that’s not it.

The problem is that the network interface is not fully available when ntpdate 
runs.  I think this is because dhcpclient has not provided an IP address for 
the interface yet.

Here’s a snatch from journalctl that shows the problem in jessie:

> Aug 01 02:49:46 dillserver kernel: sungem_phy: PHY ID: 206053, addr: 0
> Aug 01 02:49:46 dillserver kernel: gem 0002:20:0f.0 eth0: Found BCM5401 PHY
> Aug 01 02:49:46 dillserver kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is 
> not ready
> Aug 01 02:49:46 dillserver ntpdate[661]: no servers can be used, exiting
> Aug 01 02:49:46 dillserver networking[469]: Configuring network 
> interfaces...done.
> Aug 01 02:49:46 dillserver systemd[1]: Started LSB: Raise network interfaces..
> Aug 01 02:49:46 dillserver systemd[1]: Starting ifup for eth0...
> Aug 01 02:49:46 dillserver systemd[1]: Started ifup for eth0.
> Aug 01 02:49:46 dillserver systemd[1]: Starting Network.
> Aug 01 02:49:46 dillserver systemd[1]: Reached target Network.
> Aug 01 02:49:46 dillserver systemd[1]: Starting Network is Online.
> Aug 01 02:49:46 dillserver systemd[1]: Reached target Network is Online.
> Aug 01 02:49:46 dillserver systemd[1]: Starting LSB: RPC portmapper 
> replacement...
> Aug 01 02:49:47 dillserver rpcbind[672]: Starting rpcbind daemon
> Aug 01 02:49:47 dillserver systemd[1]: Started LSB: RPC portmapper 
> replacement.
> Aug 01 02:49:47 dillserver systemd[1]: Starting RPC Port Mapper.
> Aug 01 02:49:47 dillserver systemd[1]: Reached target RPC Port Mapper.
> Aug 01 02:49:47 dillserver systemd[1]: Starting LSB: NFS support files common 
> to client and server...
> Aug 01 02:49:47 dillserver dhclient[685]: Internet Systems Consortium DHCP 
> Client 4.3.1
> Aug 01 02:49:47 dillserver dhclient[685]: Copyright 2004-2014 Internet 
> Systems Consortium.
> Aug 01 02:49:47 dillserver dhclient[685]: All rights reserved.
> Aug 01 02:49:47 dillserver dhclient[685]: For info, please visit 
> https://www.isc.org/software/dhcp/
> Aug 01 02:49:47 dillserver dhclient[685]: 
> Aug 01 02:49:47 dillserver ifup[671]: Internet Systems Consortium DHCP Client 
> 4.3.1
> Aug 01 02:49:47 dillserver ifup[671]: Copyright 2004-2014 Internet Systems 
> Consortium.
> Aug 01 02:49:47 dillserver ifup[671]: All rights reserved.
> Aug 01 02:49:47 dillserver ifup[671]: For info, please visit 
> https://www.isc.org/software/dhcp/
> Aug 01 02:49:47 dillserver dhclient[685]: Listening on 
> LPF/eth0/00:03:93:3d:bd:bc
> Aug 01 02:49:47 dillserver dhclient[685]: Sending on   
> LPF/eth0/00:03:93:3d:bd:bc
> Aug 01 02:49:47 dillserver dhclient[685]: Sending on   Socket/fallback
> Aug 01 02:49:47 dillserver dhclient[685]: DHCPDISCOVER on eth0 to 
> 255.255.255.255 port 67 interval 4
> Aug 01 02:49:47 dillserver ifup[671]: Listening on LPF/eth0/00:03:93:3d:bd:bc
> Aug 01 02:49:47 dillserver ifup[671]: Sending on   LPF/eth0/00:03:93:3d:bd:bc
> Aug 01 02:49:47 dillserver ifup[671]: Sending on   Socket/fallback
> Aug 01 02:49:47 dillserver ifup[671]: DHCPDISCOVER on eth0 to 255.255.255.255 
> port 67 interval 4
> 




On Aug 1, 2016, at 2:56 AM, Kurt Roeckx <k...@roeckx.be> wrote:

> On Mon, Aug 01, 2016 at 02:37:58AM -0700, Rick Thomas wrote:
>> This 8 year old bug is still present in jessie and stretch -- the change to 
>> systemd did not fix it!
>> 
>> Please, somebody pay attention!  This bug makes ntpd unreliable tending to 
>> useless on systems that get their network config from dhcp.
> 
> There are various things broken, but as far as I know in stretch
> things should just work.
> 
> You seem to say that this is related to getting the ntp servers
> from dhcp, but that's not making sense to me.  The dhcp server
> should give you IP addresses, so it can never be a problem with
> DNS, the peers should always be there.
> 
> 
> Kurt
> 

Bug#833136: ntpdate has the same problem as ntp in Bug#461461. ntpdate starts before dhcpclient finishes

[Rick Thomas]

Package: ntpdate
Version: 1:4.2.6.p5+dfsg-7+deb8u2
Severity: important

during system startup ntpdate starts before dhcpclient finishes.  hence ntpdate 
can't find its server so it dies and fails to set the clock.


-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: powerpc (ppc)

Kernel: Linux 3.16.0-4-powerpc
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ntpdate depends on:
ii  dpkg 1.17.27
ii  libc62.19-18+deb8u4
ii  libssl1.0.0  1.0.1t-1+deb8u2
ii  netbase  5.3

Versions of packages ntpdate recommends:
ii  lockfile-progs  0.1.17

ntpdate suggests no packages.

-- Configuration Files:
/etc/default/ntpdate changed:
NTPDATE_USE_NTP_CONF=yes
NTPSERVERS="192.168.1.15 192.168.3.207 192.168.3.111"
NTPOPTIONS=" -bs "


-- no debconf information

Bug#461461: This bug is still present -- change to systemd did not fix it!

[Rick Thomas]

This 8 year old bug is still present in jessie and stretch — the change to 
systemd did not fix it!

Please, somebody pay attention!  This bug makes ntpd unreliable tending to 
useless on systems that get their network config from dhcp.

Rick

Bug#832713: systemd: after "systemd (231-1) unstable" update systemd-jurnald.service fails to start

[Rick Thomas]

Thanks for you help so far, Michael!

Can I ask one last favor on this?

It seems that the bug (whatever it is) depends on things like kernel version 
and machine architecture.

So, can you suggest someone who can take this further?

Thanks!
Rick

Bug#832713: Systemd version 231-1 (current in Sid) doesn't work on arm

[Rick Thomas]

On Jul 31, 2016, at 2:02 AM, Christian Marillat <maril...@free.fr> wrote:

> On 31 juil. 2016 10:50, Rick Thomas <rbtho...@pobox.com> wrote:
> 
>> Can you send the output of ‘uname -a ; systemd —version’ on that box?
> 
> Linux rpi3.XXX 4.4.0-1-rpi2 #1 SMP Debian 4.4.6-1+rpi14 (2016-05-05) armv7l 
> GNU/Linux
> 
> ,
> | $ systemd -—version 
> | systemd: invalid option -- 'â'
> `——

darn spelling corrector!  changed my double-dash into an m-dash. humph!

But fortunately you figured out what I *meant*.  Thanks!

> 
> Anyway I've downgraded systemd to 230-7 :
> 
> ,
> | $ systemd --version
> | systemd 230
> | +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
> +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN
> `
> 
> Christian

So I guess there must be something different between the kernel your raspberry 
pi is using and the one my sheevaplug is using.  I know that the “marvel” 
series of kernels have several optional features turned off to save space.  
Maybe there’s something there.

> rbthomas@sheeva:~$ uname -a
> Linux sheeva 4.6.0-1-marvell #1 Debian 4.6.4-1 (2016-07-18) armv5tel GNU/Linux

On the other hand, my Cubox-iP4 has the problem and it’s running

> rbthomas@cube:~$ uname -a
> Linux cube 4.6.0-1-armmp #1 SMP Debian 4.6.4-1 (2016-07-18) armv7l GNU/Linux

The Cubox, I think, doesn’t have those space limitations.

Thanks for your help!
Rick

Bug#832713: Systemd version 231-1 (current in Sid) doesn't work on arm

[Rick Thomas]

Can you send the output of ‘uname -a ; systemd —version’ on that box?

Thanks!

On Jul 31, 2016, at 12:22 AM, Christian Marillat <maril...@free.fr> wrote:

> On 31 juil. 2016 08:50, Rick Thomas <rbtho...@pobox.com> wrote:
> 
>> Thanks, Christian!
>> 
>> What is your armel box?  I *do* see it on my SheevaPlug (armel), so
>> there may be a clue.  Is your armel kernel customized in some way?
> 
> Raspberry Pi 2 kernel 4.1.12
> 
> Christian

Bug#832713: Systemd version 231-1 (current in Sid) doesn't work on arm

[Rick Thomas]

Thanks, Christian!

What is your armel box?  I *do* see it on my SheevaPlug (armel), so there may 
be a clue.  Is your armel kernel customized in some way?

Enjoy!
Rick

> On Jul 30, 2016, at 11:33 PM, Christian Marillat <maril...@free.fr> wrote:
> 
> On 30 juil. 2016 23:02, Rick Thomas <rbtho...@pobox.com> wrote:
> 
>> Has anyone else noticed this bug?
>> 
>> Bug#832713: systemd: after "systemd (231-1) unstable" update
>> systemd-jurnald.service fails to start
>> 
>> I’ve tried it on armel (SheevaPlug) and armmp (Cubox-i4Pro).  It fails on 
>> both.
>> I’ve also tried it on amd64 and powerpc hardware.  The bug is not present 
>> there.
> 
> I see this bug on a Raspberry Pi3 armhf 4.4.6 but not on a
> Pandaboard ES armhf 4.2.8
> 
> Also I don't see this bug on armel, i386, powerpc, arm64 arches.
> 
> Christian

Bug#832713: Systemd version 231-1 (current in Sid) doesn't work on arm

[Rick Thomas]

Has anyone else noticed this bug?

Bug#832713: systemd: after "systemd (231-1) unstable" update 
systemd-jurnald.service fails to start

I’ve tried it on armel (SheevaPlug) and armmp (Cubox-i4Pro).  It fails on both.
I’ve also tried it on amd64 and powerpc hardware.  The bug is not present there.

Anybody got any ideas as to how to track it down?

Thanks!
Rick

Bug#832713: systemd: after "systemd (231-1) unstable" update systemd-jurnald.service fails to start

[Rick Thomas]

As I replied to that (did you see it? There may have been some problems with my 
email about that time),
commenting out the “SystemCallFilter” did not make the problem go away on 
either of the ARM systems.

Another interesting datapoint:  I upgraded my PowerMac G4 powerpc machine to 
latest Sid (including the systemd version in question) and it does *not* have 
the problem.  This is the same result I saw on the amd64 (virtual) machine.

So it seems to be arm specific…

Any thoughts?

On Jul 29, 2016, at 3:02 PM, Michael Biebl <bi...@debian.org> wrote:

> Am 29.07.2016 um 23:29 schrieb Rick Thomas:
>> Hmmm…  Curiouser and curiouser!
>> 
>> I upgraded a VM (amd64) to latest Sid (with systemd version 231-1).  The 
>> problem is *not* present there.
>> 
>> The problem may be specific to arm hardware?  I’ll try it on a PowerPC G4 
>> (Apple Mac PPC) machine later today.
> 
> I think this might be arch specific, yes.
> See my reply earlier:
> 
>> SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module @mount
>> @obsolete @raw-io
>> 
>> is causing the problem? If you comment out that line from
>> systemd-journald.service, does it start properly?
>> 
>> SystemCallFilter uses libseccomp, maybe libseccomp on armel is not fully
>> functional and we need to reassign this.
> 
> 
> 
> 
> -- 
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> 

Bug#832713: systemd: after "systemd (231-1) unstable" update systemd-jurnald.service fails to start

[Rick Thomas]

Hmmm…  Curiouser and curiouser!

I upgraded a VM (amd64) to latest Sid (with systemd version 231-1).  The 
problem is *not* present there.

The problem may be specific to arm hardware?  I’ll try it on a PowerPC G4 
(Apple Mac PPC) machine later today.

Rick


On Jul 28, 2016, at 5:18 PM, Rick Thomas <rbtho...@pobox.com> wrote:

> I upgraded one of my test systems (an armhf Cubox-i4Pro) to Sid.
> After rebooting, I saw the same symptoms as on the SheevaPlug.

Bug#832713: systemd: after "systemd (231-1) unstable" update systemd-jurnald.service fails to start

[Rick Thomas]

I upgraded one of my test systems (an armhf Cubox-i4Pro) to Sid.
After rebooting, I saw the same symptoms as on the SheevaPlug.

I commented the line in question in 
/lib/systemd/system/systemd-logind.service
and
/lib/systemd/system/systemd-journald.service

There was no corresponding line in
/lib/systemd/system/networking.service
so I did nothing there.

I then did ‘update-initramfs -u’.

Then I rebooted.  Symptoms still persist, so that doesn’t seem to be it.

I still have
root@cube:~# systemctl status systemd-journald.service
* systemd-journald.service - Journal Service
   Loaded: loaded (/lib/systemd/system/systemd-journald.service; static; vendor 
preset: enabled)
   Active: failed (Result: start-limit-hit) since Thu 2016-07-28 17:05:29 PDT; 
8min ago
 Docs: man:systemd-journald.service(8)
   man:journald.conf(5)
 Main PID: 608 (code=exited, status=228/SECCOMP)

Any other thoughts?

Rick



On Jul 28, 2016, at 2:04 PM, Michael Biebl <bi...@debian.org> wrote:

> Am 28.07.2016 um 22:50 schrieb Rick Thomas:
>> In the interest of having a working system, I reverted that machine to 
>> systemd version 230-7.  Unsurprisingly, the problem went away.
>> 
>> I’ll try re-installing 231-1 and commenting that line.  I’ll probably have a 
>> chance tonight.  I’ll report when I have something.
>> 
>> It may be worth noticing that other things failed as well when 231-1 was in. 
>>  I’m attaching a ‘grep -i fail -C20’ of the screen log.  Of particular note 
>> are “Failed to start Raise network interfaces” and “Failed to start Login 
>> Service.”
>> 
>> Are there other places where I should remove a “SystemCallFilter” ?
>> 
> 
> Various units were locked down like e.g. in
> https://github.com/systemd/systemd/commit/4e069746fe0de1f60bd1b75c113b0f40ffe86736
> 
> If the SystemCallFilter= is what causes journald to fail, it's likely it
> also affects those other services.
> 
> Michael
> 
> 
> -- 
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> 

Bug#832713: systemd: after "systemd (231-1) unstable" update systemd-jurnald.service fails to start

[Rick Thomas]

In the interest of having a working system, I reverted that machine to systemd 
version 230-7.  Unsurprisingly, the problem went away.

I’ll try re-installing 231-1 and commenting that line.  I’ll probably have a 
chance tonight.  I’ll report when I have something.

It may be worth noticing that other things failed as well when 231-1 was in.  
I’m attaching a ‘grep -i fail -C20’ of the screen log.  Of particular note are 
“Failed to start Raise network interfaces” and “Failed to start Login Service.”

Are there other places where I should remove a “SystemCallFilter” ?



screenlog.xz
Description: Binary data



On Jul 28, 2016, at 1:24 PM, Michael Biebl <bi...@debian.org> wrote:

> Am 28.07.2016 um 22:01 schrieb Rick Thomas:
>> No.  This is a stock kernel.  It’s available from both testing and unstable 
>> repos.  The machine itself is a SheevaPlug.  Nothing custom about it.
>> 
>> What makes you think it’s custom?
> 
> This was more of a question then a statement.
> I wanted to rule out, that the kernel was missing any relevant features.
> 
> I assume the previous version worked properly and the addition of
> 
> SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module @mount
> @obsolete @raw-io
> 
> is causing the problem? If you comment out that line from
> systemd-journald.service, does it start properly?
> 
> SystemCallFilter uses libseccomp, maybe libseccomp on armel is not fully
> functional and we need to reassign this.
> 
> 
> -- 
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> 

Bug#832713: systemd: after "systemd (231-1) unstable" update systemd-jurnald.service fails to start

[Rick Thomas]

No.  This is a stock kernel.  It’s available from both testing and unstable 
repos.  The machine itself is a SheevaPlug.  Nothing custom about it.

What makes you think it’s custom?

Rick


 
On Jul 28, 2016, at 3:59 AM, Michael Biebl <bi...@debian.org> wrote:

> control: tags -1 + moreinfo
> Am 28.07.2016 um 12:08 schrieb Rick Thomas:
>> Main PID: 477 (code=exited, status=228/SECCOMP)
> ...
>> Kernel: Linux 4.6.0-1-marvell
> 
> That looks like you are using a custom kernel. Is the problem
> reproducible with the default Debian Linux kernel?
> 
> 
> -- 
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> 

Bug#800005: fbset gets 'ioctl FBIOPUT_VSCREENINFO: Invalid argument'

[Rick Thomas]

On Jun 30, 2016, at 12:50 AM, Mathieu Malaterre <ma...@debian.org> wrote:

> On Thu, Jun 30, 2016 at 9:45 AM, Rick Thomas <rbtho...@pobox.com> wrote:
>> Do I understand correctly that I should put “drm.debug=0xe” as a kernel 
>> argument at boot time?  Then boot, try running my “fbset” test and send you 
>> the entire output of dmesg including all boot messages.  Is this correct?
>> 
>> Further, I guess you would prefer to have this on the amd64 machine in 
>> question rather than the original powerpc machine?
>> 
>> What other info should I send?  If I use the amd64 machine, I guess you’d 
>> like some hardware configuration info as well?  Please be specific: a 
>> verbatim list of shell commands you’d like me to run would be most helpful!
> 
> Hi Rick,
> 
> Adding the boot parameter *should* tell us what went wrong in the
> fbset command. So yes I do expect you change the boot parameter, run
> dmesg before and after the fbset command. I do not care about amd64,
> so please do it on the powerpc.
> 
> Thanks.

Still no help…  
On powerpc64 (dual core Mac G5 running Debian 8.5):

> rbthomas@bigal:~$ dmesg > /tmp/dmesg-before.out
> 
> rbthomas@bigal:~$ fbset
> 
> mode "1680x1050"
> geometry 1680 1050 1680 1050 32
> timings 0 0 0 0 0 0 0
> accel true
> rgba 8/16,8/8,8/0,0/0
> endmode
> 
> rbthomas@bigal:~$ fbset 800x600-60
> ioctl FBIOPUT_VSCREENINFO: Invalid argument
> rbthomas@bigal:~$ grep 800x600 /etc/fb.modes 
> # 800x600, 48 Hz, Interlaced (36.00 MHz dotclock)
> mode "800x600-48-lace"
> # 800x600, 56 Hz, Non-Interlaced (36.00 MHz dotclock)
> mode "800x600-56"
> # 800x600, 60 Hz, Non-Interlaced (40.00 MHz dotclock)
> mode "800x600-60"
> # 800x600, 70 Hz, Non-Interlaced (44.90 MHz dotclock)
> mode "800x600-70"
> # 800x600, 72 Hz, Non-Interlaced (50.00 MHz dotclock)
> mode "800x600-72"
> # 800x600, 75 Hz, Non-Interlaced (49.50 MHz dotclock)
> mode "800x600-75"
> # 800x600, 90 Hz, Non-Interlaced (56.64 MHz dotclock)
> mode "800x600-90"
> # 800x600, 100 Hz, Non-Interlaced (67.50 MHz dotclock)
> mode “800x600-100"
> 
> rbthomas@bigal:~$ dmesg > /tmp/dmesg-after.out
> 
> rbthomas@bigal:~$ diff /tmp/dmesg-before.out /tmp/dmesg-after.out
> 
> rbthomas@bigal:~$ cat /proc/cmdline 
> root=/dev/mapper/bigal-root ro drm.debug=0xe
> 
> rbthomas@bigal:~$ lsmod | grep drm
> drm_kms_helper 82001  1 nouveau
> drm   325466  6 ttm,drm_kms_helper,nouveau,sil164
> agpgart39217  2 drm,ttm
> i2c_core   31058  10 
> drm,i2c_powermac,windfarm_smu_sat,drm_kms_helper,
>  
> i2c_algo_bit,windfarm_lm75_sensor,nouveau,sil164,
>  windfarm_max6690_sensor,snd_aoa_codec_onyx

Bug#800005: fbset gets 'ioctl FBIOPUT_VSCREENINFO: Invalid argument'

[Rick Thomas]

Do I understand correctly that I should put “drm.debug=0xe” as a kernel 
argument at boot time?  Then boot, try running my “fbset” test and send you the 
entire output of dmesg including all boot messages.  Is this correct?

Further, I guess you would prefer to have this on the amd64 machine in question 
rather than the original powerpc machine?

What other info should I send?  If I use the amd64 machine, I guess you’d like 
some hardware configuration info as well?  Please be specific: a verbatim list 
of shell commands you’d like me to run would be most helpful!

Thanks!
Rick

On Jun 29, 2016, at 11:20 PM, Mathieu Malaterre <ma...@debian.org> wrote:

> On Sun, Jun 26, 2016 at 2:59 AM, Rick Thomas <rbtho...@pobox.com> wrote:
>> For what it’s worth, I get the same behavior on amd64 running stretch.  It’s 
>> not just on powerpc.
> 
> Great ! Could you please turn more debugging info. eg: drm.debug=0xe
> and try again.
> 
> ref:
> https://01.org/linuxgraphics/documentation/how-report-bugs
> 
> thanks

Bug#825794: procmail: attachments containing the string From at the beginning of a line confuse procmail

[Rick Thomas]

On May 31, 2016, at 2:18 AM, Santiago Vila <sanv...@unex.es> wrote:

> On Mon, 30 May 2016, Rick Thomas wrote:
> 
>> Here’s the setup:
>> 
>> I have a POP/IMAP account at pobox.com.  I use cron to run fetchmail which 
>> retrieves (POP3) mail from pobox to a local server on my home network.
>> I process the retrieved mail with procmail to split it into folders and 
>> subfolders based on who it’s from, addressed to, subject, etc…
>> 
>> Here’s the .fetchmailrc file”:
>> = .fetchmailrc ===
>> # Configuration created Thu Aug 15 20:08:16 2002 by fetchmailconf
>> # Lightly edited later by Rick Thomas
>> set postmaster "rbthomas"
>> set bouncemail
>> set no spambounce
>> set properties ""
>> # set syslog
>> 
>> poll mail.pobox.com with proto POP3 timeout 20 and options uidl
>>   user 'XXX' there with password 'YY' is 'rbthomas' here options 
>> keep ssl 
>> 
>> mda "formail -s procmail"
>> ==
>> 
>> As I interpret your reply, I should be using a different mda — NOT
>> formail.  Can you give me some hint as to what it should look like?
> 
> If you are running fetchmail as a user (not daemon, not root), what about 
> this?
> 
> mda "procmail"
> 
> 
> What you are using right now (formail -s procmail) would be required if the 
> output
> of fetchmail were a single mbox folder containing all the emails concatenated.
> 
> "formail -s some-command" splits a whole mbox folder made of concatenaded 
> messages
> and feeds them to "some-command" one at a time.
> 
> I have to confess that I'm also using "formail -s procmail" in my
> setup and I'm not sure why. Maybe there was a time in which fetchmail
> output was a whole mbox folder and you had to split it yourself.
> 
> So I did the following test:
> 
> I created a special mbox folder in my server called "test-folder",
> containing several messages, then I used this script to retrieve it:
> 
> fetchmail -a myserver --folder test-folder -m $HOME/bin/process-email
> 
> where process-email is like this:
> 
> #!/bin/sh
> t=`tempfile`
> cat > ${t}
> 
> What I see after running the above command line is a set of temporary
> files at /tmp, corresponding to each of the messages in the "test-folder".
> 
> This means that fetchmail already feeds a message at a time to whatever
> mda command you are using and you don't need to split them yourself.
> 
> 
> The general problem that you discovered (namely, that the mbox format
> is not 100% reliable regarding message boundaries) has a fix and it's
> called "Maildir format". There is no way to fix that in procmail
> because it is a limitation of the mbox format itself.
> 
> May I close this bug?

Thank you!  Yes, you may close this bug.

My .fetchmailrc file now has
mda “procmail”
and is otherwise unchanged.  I’m using POP3 still, though I’ll experiment with 
imap soon.

Enjoy!
Rick

Bug#825794: procmail: attachments containing the string From at the beginning of a line confuse procmail

[Rick Thomas]

On May 30, 2016, at 2:36 AM, Santiago Vila <sanv...@unex.es> wrote:

> On Sun, 29 May 2016, Rick Thomas wrote:
> 
>> Package: procmail
>> Version: 3.22-24
>> Severity: normal
>> 
>> Dear Maintainer,
>> 
>> *** Reporter, please consider answering these questions, where appropriate 
>> ***
>> 
>> If procmail processes a mail with body containing a plaintext attachment 
>> that has a line
>> that begins with the string "From " it seems to think this is a separator 
>> between mails.
>> It winds up splitting the original mail into two parts and filing each as a 
>> separate mail
>> item.
>> 
>> This can happen when the attachment is a mail item that has not had the 
>> proper quoting
>> for lines beginning with "From ".  I have attached such an email to this 
>> bugreport.
> 
> procmail does not split anything unless explicitly told.
> 
> In fact, it is usually "formail -s" who split emails, not procmail.
> 
>> There needs to be some way of telling procmail that it will receive input 
>> one email item
>> at a time, (as when being fed by fetchmail) so the line-begins-with-From 
>> processing is
>> not necessary.
> 
> And there is a way indeed, which is to use procmail alone, not "formail -s 
> procmail".
> 
> Your report says "If procmail processes a mail". What do you mean
> exactly by "processes a mail"? Could you please be more explicit?
> A sample email is good, but the report is incomplete if you don't
> tell me what I'm supposed to do with the email.
> 
> Thanks.

Thank you very much, Santiago, for the prompt reply!

Here’s the setup:

I have a POP/IMAP account at pobox.com.  I use cron to run fetchmail which 
retrieves (POP3) mail from pobox to a local server on my home network.
I process the retrieved mail with procmail to split it into folders and 
subfolders based on who it’s from, addressed to, subject, etc…

Here’s the .fetchmailrc file”:
= .fetchmailrc ===
# Configuration created Thu Aug 15 20:08:16 2002 by fetchmailconf
# Lightly edited later by Rick Thomas
set postmaster "rbthomas"
set bouncemail
set no spambounce
set properties ""
# set syslog

poll mail.pobox.com with proto POP3 timeout 20 and options uidl
   user 'XXX' there with password 'YY' is 'rbthomas' here options 
keep ssl 

mda "formail -s procmail"
==

As I interpret your reply, I should be using a different mda — NOT formail.  
Can you give me some hint as to what it should look like?

Thanks!
Rick

Bug#825794: procmail: attachments containing the string From at the beginning of a line confuse procmail

[Rick Thomas]

uired (image does not boot
 if flashed with L4T R21.X).
 
+=== Jetson TX1 ===
+
+sudo ./flash.sh -L /usr/lib/u-boot/p2371-2180/u-boot-dtb.bin jetson-tx1 mmcblk0p1
+
+=== TODO ===
+
 TODO: Figure out how to do this with tools within Debian,
 e.g. tegracrm and cbootimage.
 
diff --git a/debian/u-boot-tegra.links b/debian/u-boot-tegra.links
new file mode 100644
index 000..8b9628d
--- /dev/null
+++ b/debian/u-boot-tegra.links
@@ -0,0 +1 @@
+/usr/lib/u-boot/p2371-2180/uboot.elf /usr/lib/u-boot/p2371-2180/u-boot
diff --git a/debian/u-boot-tegra.lintian-overrides b/debian/u-boot-tegra.lintian-overrides
index 661add3..4186db9 100644
--- a/debian/u-boot-tegra.lintian-overrides
+++ b/debian/u-boot-tegra.lintian-overrides
@@ -4,9 +4,11 @@
 # targets could be built on multiple architectures, but could instead install
 # the package for the architecture needed.
 u-boot-tegra [armhf]: arch-dependent-file-not-in-arch-specific-directory usr/lib/u-boot/jetson-tk1/uboot.elf
+u-boot-tegra [arm64]: arch-dependent-file-not-in-arch-specific-directory usr/lib/u-boot/p2371-2180/uboot.elf
 
 # These bootloaders need to be statically linked.
 u-boot-tegra [armhf]: statically-linked-binary usr/lib/u-boot/jetson-tk1/uboot.elf
+u-boot-tegra [arm64]: statically-linked-binary usr/lib/u-boot/p2371-2180/uboot.elf
 
 u-boot-tegra: description-synopsis-starts-with-article
 
-- 
2.1.4

--- End Message ---
--- Begin Message ---
Source: u-boot
Source-Version: 2016.03+dfsg1-5

We believe that the bug you reported is fixed in the latest version of
u-boot, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 825...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Vagrant Cascadian <vagr...@debian.org> (supplier of updated u-boot package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 29 May 2016 14:29:59 -0700
Source: u-boot
Binary: u-boot u-boot-imx u-boot-tegra u-boot-omap u-boot-sunxi u-boot-exynos 
u-boot-rockchip u-boot-rpi u-boot-tools
Architecture: source
Version: 2016.03+dfsg1-5
Distribution: unstable
Urgency: medium
Maintainer: Vagrant Cascadian <vagr...@debian.org>
Changed-By: Vagrant Cascadian <vagr...@debian.org>
Description:
 u-boot - A boot loader for embedded systems
 u-boot-exynos - A boot loader for exynos systems
 u-boot-imx - A boot loader for imx systems
 u-boot-omap - A boot loader for omap systems
 u-boot-rockchip - A boot loader for rockchip systems
 u-boot-rpi - A boot loader for Raspberry PI systems
 u-boot-sunxi - A boot loader for sunxi systems
 u-boot-tegra - A boot loader for tegra systems
 u-boot-tools - companion tools for Das U-Boot bootloader
Closes: 781873 821056 824730 825458
Changes:
 u-boot (2016.03+dfsg1-5) unstable; urgency=medium
 .
   [ Vagrant Cascadian ]
   * Add patches from upstream to detect fdtfile on am57xx, and update
 distro_bootcmd patch accordingly.
   * u-boot-tools: Add fw_env.config for openrd (Closes: #821056). Thanks
 to Rick Thomas.
   * u-boot-omap: Add support for dra74_evm (Closes: #824730). Thanks to
 Ben Hutchings.
   * Added odroid-xu3 target, tested on Odroid-XU4.
 .
   [ Gerald Kerma ]
   * Correct the guruplug.config to match the new upstream env address.
 (Closes: #781873).
 .
   [ Vagrant Cascadian ]
   * u-boot-exynos: Add patch to support distro_bootcmd on odroid target.
 .
   [ Martin Michlmayr ]
   * u-boot-tegra: Add Jetson TX1 (P2371-2180) target (Closes: #825458).
   * u-boot-tegra: Add arm64 arch.
   * u-boot-tegra: Update README.Debian for Jetson TX1.
Checksums-Sha1:
 c2038e48da9dd6bc5ec12201a1d5ea4b335b11e6 2555 u-boot_2016.03+dfsg1-5.dsc
 1ba365a71cac860a22c620fe12087cd4ee29cecd 41020 
u-boot_2016.03+dfsg1-5.debian.tar.xz
Checksums-Sha256:
 93b1309fa27252567f3145e81805fef6f833e73a486e0c02162b2bfc281a6841 2555 
u-boot_2016.03+dfsg1-5.dsc
 0a7d96bc05f3922e708a8c87e9843f579c13a16139c9368344eee0ff3213ca4f 41020 
u-boot_2016.03+dfsg1-5.debian.tar.xz
Files:
 c99c22757fad10675f83f181d8e33d33 2555 admin optional u-boot_2016.03+dfsg1-5.dsc
 d1547ddfebd920ecbdd650d7e35b05f2 41020 admin optional 
u-boot_2016.03+dfsg1-5.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJXS2DCAAoJELeLgtSBS5G2mUsQAJz7X0WdI0hA5OHYpScll3/z
FVuC0rzk9cIHBXDygSIYRJJR5CsXx6Y5Z898hSe6pSbJHNI+cxIlTwqYgFvWPgqS
vdwzaAToyaChU2LXoujhGftMLXs7qy1mywS4gQbzHQZmqy3aEuBKJi8SrBD6RDIj
WhXCrwWN/PuZdN7jAKTCejVfOLZEHeTuTsse5VvUWnBltVNXbuUKzD7TGwJQ1smk
2QSXeCaLhM8TtYDfNYlq7BKZRHMJKM9201r0dmWvin+Vb3MgRk78Lu96oILeU4OY
XmT/YOkxNK5Egwj99KlbopnBDVGujAP5gmoN7YF/gy

Bug#812395: u-boot-tools: sheevaplug /etc/fw_env.config - explain how env address depends on your version of u-boot.

[Rick Thomas]

>> If you could please provide a patch detailing exactly what you would
>> like changed, that would be appreciated.

It look like the latest u-boot-tools has exactly what I would have said.  Very 
sorry for taking so long to get back.

I think this bug can be closed now.

Thanks!
Rick

Bug#821056: u-boot-tools: no example /etc/fw_env.config files for openrd devices

[Rick Thomas]

On Apr 17, 2016, at 8:35 AM, Vagrant Cascadian <vagr...@debian.org> wrote:

> On 2016-04-16, Rick Thomas wrote:
>> Re-reading this, I realize that I said “0x8” for the environment
>> location of legacy u-boot.  But when I went to test it, the true value
>> turned out to be “0xa”.
>> 
>> Sorry for the confusion.  The latter value (0xa) is correct.
> 
> Ok, what you submitted was:
> 
>>> # MTD device name   Device offset   Env. size   Flash sector size
>>> # Legacy u-boot versions:
>>> #/dev/mtd0   0xa 0x2 0x2
>>> 
>>> # New u-boot versions:
>>> /dev/mtd0   0x6 0x2 0x2
> 
> Are those the values you would like in the example fw_env.config for
> openrd, or are you saying they need to be adjusted? If those values need
> to be changed, please re-submit the example fw_env.config you would like
> included in the package.
> 
> 
> live well,
>  vagrant

The correct values for “Device offset” are:

0xa for “Legacy”  u-boot
   and
0x6 for “New”  u-boot

So my suggested /etc/fw_env.config for u-boot-tools on OpenRD machines is:

/usr/share/doc/u-boot-tools/examples/openrd.config
# Configuration file for fw_(printenv/saveenv) utility.
# Up to two entries are valid, in this case the redundant
# environment sector is assumed present.
#
# XXX this configuration might miss a fifth parameter for the "Number of
# sectors"

# MTD device name   Device offset   Env. size   Flash sector size
# Legacy u-boot versions:
#/dev/mtd0   0xa 0x2 0x2

# New u-boot versions:
/dev/mtd0   0x6 0x2 0x2
 cut here ===

Sorry for any confusion I may have caused!

For completeness, my testing procedure was:

1) On an OpenRD Ultimate, running latest u-boot
(specifically, “U-Boot 2016.03+dfsg1-3 (Apr 04 2016 - 18:23:06 +)”)
I used the above file as is.
With it, I was able to read the u-boot environment from Linux with fw_printenv.
I did not try fw_setenv.

2) On an OpenRD Client, running a legacy u-boot
(specifically. “U-Boot 1.1.4 (May 18 2009 - 13:33:10) Marvell version: 3.4.16”)
I reversed the commenting on the two “/dev/mtd0” lines.
With that, I was able to read the u-boot environment from Linux with 
fw_printenv.
I did not try fw_setenv.

For the time being, I plan to leave the Client machine with the legacy u-boot, 
incase
you find that further testing is required.

Thank you for your efforts!

Rick

Bug#821056: u-boot-tools: no example /etc/fw_env.config files for openrd devices

[Rick Thomas]

Re-reading this, I realize that I said “0x8” for the environment location 
of legacy u-boot.  But when I went to test it, the true value turned out to be 
“0xa”.

Sorry for the confusion.  The latter value (0xa) is correct.

Rick

PS:  Just out of curiosity, was there a reason behind the change?  Or was it 
just one of those things that “seemed like a good idea at the time” ?

On Apr 16, 2016, at 6:04 PM, Rick Thomas <rbtho...@pobox.com> wrote:

> 
> On Apr 15, 2016, at 12:29 PM, Vagrant Cascadian <vagr...@debian.org> wrote:
> 
>> On 2016-04-14, Rick Thomas wrote:
>>> The directory /usr/share/doc/u-boot-tools/examples/ has example .config 
>>> files
>>> for a variety of devices, but none for the OpenRD base, client or ultimate.
>> ...
>>> Oh, and BTW, the lastest u-boot puts the environment at 0x6, while 
>>> legacy
>>> versions put it at 0x8, so it would be nice to reflect that (as was
>>> done for sheevaplug -- thanks!) in the example .config file. 
>> 
>> If you could provide a tested, working config, I can include it, but I
>> have no way of testing it myself.
>> 
>> 
>> live well,
>> vagrant
> 
> Here you go:
> 
> /usr/share/doc/u-boot-tools/examples/openrd.config
> # Configuration file for fw_(printenv/saveenv) utility.
> # Up to two entries are valid, in this case the redundant
> # environment sector is assumed present.
> #
> # XXX this configuration might miss a fifth parameter for the "Number of
> # sectors"
> 
> # MTD device name   Device offset   Env. size   Flash sector size
> # Legacy u-boot versions:
> #/dev/mtd0   0xa 0x2 0x2
> 
> # New u-boot versions:
> /dev/mtd0   0x6 0x2 0x2
>  cut here ===
> 
> Tested and working on openrd client and ultimate hardware for both versions 
> of u-boot:
> Legacy: U-Boot 1.1.4 (May 18 2009 - 13:33:10) Marvell version: 3.4.16
> New: U-Boot 2016.03+dfsg1-3 (Apr 04 2016 - 18:23:06 +)
> 
> Rick Thomas
> 
> PS: You may add my name as a tester if you want.

Bug#821056: u-boot-tools: no example /etc/fw_env.config files for openrd devices

[Rick Thomas]

On Apr 15, 2016, at 12:29 PM, Vagrant Cascadian <vagr...@debian.org> wrote:

> On 2016-04-14, Rick Thomas wrote:
>> The directory /usr/share/doc/u-boot-tools/examples/ has example .config files
>> for a variety of devices, but none for the OpenRD base, client or ultimate.
> ...
>> Oh, and BTW, the lastest u-boot puts the environment at 0x6, while legacy
>> versions put it at 0x8, so it would be nice to reflect that (as was
>> done for sheevaplug -- thanks!) in the example .config file. 
> 
> If you could provide a tested, working config, I can include it, but I
> have no way of testing it myself.
> 
> 
> live well,
>  vagrant

Her you go:

/usr/share/doc/u-boot-tools/examples/openrd.config
# Configuration file for fw_(printenv/saveenv) utility.
# Up to two entries are valid, in this case the redundant
# environment sector is assumed present.
#
# XXX this configuration might miss a fifth parameter for the "Number of
# sectors"

# MTD device name   Device offset   Env. size   Flash sector size
# Legacy u-boot versions:
#/dev/mtd0   0xa 0x2 0x2

# New u-boot versions:
/dev/mtd0   0x6 0x2 0x2
 cut here ===

Tested and working on openrd client and ultimate hardware for both versions of 
u-boot:
Legacy: U-Boot 1.1.4 (May 18 2009 - 13:33:10) Marvell version: 3.4.16
New: U-Boot 2016.03+dfsg1-3 (Apr 04 2016 - 18:23:06 +)

Rick Thomas

PS: You may add my name as a tester if you want.

Bug#821056: u-boot-tools: no example /etc/fw_env.config files for openrd devices

[Rick Thomas]

Package: u-boot-tools
Version: 2016.03+dfsg1-3
Severity: normal

Dear Maintainer,

The directory /usr/share/doc/u-boot-tools/examples/ has example .config files
for a variety of devices, but none for the OpenRD base, client or ultimate.

Until recently, this was not a roblem because recent versions of u-boot did not
support the OpenRD devices.

But as of version 2016.03+dfsg1-3, there is full u-boot support for OpenRD
and u-boot-tools needs to reflect that fact.

Oh, and BTW, the lastest u-boot puts the environment at 0x6, while legacy
versions put it at 0x8, so it would be nice to reflect that (as was
done for sheevaplug -- thanks!) in the example .config file. 

Enjoy!


-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: armel (armv5tel)

Kernel: Linux 4.4.0-1-marvell
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages u-boot-tools depends on:
ii  libc6  2.22-5

u-boot-tools recommends no packages.

u-boot-tools suggests no packages.

-- no debconf information

Bug#818860: python-gnuplot: errors or warnings from gnuplot when running python-gnuplot demo.py

[Rick Thomas]

Package: python-gnuplot
Version: 1.8-6
Severity: normal

Dear Maintainer,

   * What led up to the situation?
Installed python-gnuplot then unpacked and ran the demo.py from
/usr/share/doc/python-gnuplot/examples
   * What was the outcome of this action?
error/warning messages were not expected, though demo seemed to run OK.

Please see attached output.

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable')
Architecture: powerpc (ppc64)

Kernel: Linux 4.5.0-rc2-powerpc64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python-gnuplot depends on:
ii  gnuplot   4.6.6-3
ii  python2.7.11-1
ii  python-numpy  1:1.10.4-2

python-gnuplot recommends no packages.

python-gnuplot suggests no packages.

-- no debconf information
gnuplot> set title "A simple example"
gnuplot> set data style linespoints
gnuplot> plot "/tmp/tmp0sZGjZ.gnuplot/fifo" notitle

gnuplot> set data style linespoints
 ^
 line 0: unrecognized option - see 'help set'.

libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
gnuplot> reset
gnuplot> set title "Data can be computed by python or gnuplot"
gnuplot> set xlabel "x"
gnuplot> set ylabel "x squared"
gnuplot> plot x**2 title "calculated by gnuplot", "/tmp/tmpeJZf31.gnuplot/fifo" 
title "calculated by python" with points 3 3

gnuplot> plot x**2 title "calculated by gnuplot", "/tmp/tmpeJZf31.gnuplot/fifo" 
title "calculated by python" with points 3 3

 ^
 line 0: unexpected or unrecognized token

gnuplot> set ylabel "x^2"
gnuplot> set output "gp_test.ps"
gnuplot> set terminal postscript enhanced color
gnuplot> plot x**2 title "calculated by gnuplot", "/tmp/tmph1xQH2.gnuplot/fifo" 
title "calculated by python" with points 3 3
gnuplot> set terminal x11
gnuplot> set output

gnuplot> plot x**2 title "calculated by gnuplot", "/tmp/tmph1xQH2.gnuplot/fifo" 
title "calculated by python" with points 3 3

 ^
 line 0: unexpected or unrecognized token

gnuplot> reset
gnuplot> set parametric
gnuplot> set data style lines
gnuplot> set hidden
gnuplot> set contour base
gnuplot> set title "An example of a surface plot"
gnuplot> set xlabel "x"
gnuplot> set ylabel "y"

gnuplot> set data style lines
 ^
 line 0: unrecognized option - see 'help set'.

gnuplot> splot "/tmp/tmp6lu9P6.gnuplot/fifo" notitle
 line 0: warning: Cannot contour non grid data. Please use "set 
dgrid3d".
gnuplot> splot "/tmp/tmph7C4WQ.gnuplot/fifo" notitle
 line 0: warning: Cannot contour non grid data. Please use "set 
dgrid3d".
Please press return to continue...
Please press return to continue...

 Saved plot to postscript file "gp_test.ps" 

Please press return to continue...
Please press return to continue...
Please press return to continue...

Bug#812719: apticron: Me too

[Rick Thomas]

Package: apticron
Version: 1.1.58
Followup-For: Bug #812719

Dear Maintainer,

I see the same problem.  Stock, out of the box, stretch installation.

I have tested the fix in the original bugreport.  It works.

Thanks!

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: armhf (armv7l)

Kernel: Linux 4.5.0-rc4-armmp (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apticron depends on:
ii  apt1.2.6
ii  bzip2  1.0.6-8
ii  cron [cron-daemon] 3.0pl1-128
ii  debconf [debconf-2.0]  1.5.58
ii  dpkg   1.18.4
ii  s-nail [mailx] 14.8.6-1
ii  ucf3.0035

Versions of packages apticron recommends:
ii  apt-listchanges  2.85.14
ii  iproute2 4.3.0-1+b1

apticron suggests no packages.

-- debconf information:
  apticron/notification: root

Bug#762634: initramfs-tools: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs

[Rick Thomas]

On Wed, 24 Feb 2016 15:06:27 -0800 Vagrant Cascadian  wrote:
> On 2016-02-24, Vagrant Cascadian wrote:
> > On 2016-02-04, Ben Hutchings wrote:
> >> Oh, so the MODULES=most case is bust and we need to list more host
> >> controller drivers (or include all modules under drivers/usb/host/).
> >> How about MODULES=dep; does that work now?
> >
> > MODULES=dep appears to pull in the necessary drivers on a recent stretch
> > install on a wandboard solo, using initramfs-tools 0.123, but
> > MODULES=most still requires manually including them in
> > /etc/initramfs-tools/modules.
> 
> And, FWIW, MODULES=dep appears to also workaround the issue on the wandboard 
> dual
> with initramfs-tools 0.120.
> 
> 
> live well,
>   vagrant

would it make sense to ensure that MODULES=most is always a superset of 
MODULES=dep?  Could this be done by running MODULES=dep first, then running 
MODULES=most and delivering the union of the two sets?

Thanks!
Rick

Bug#812611: u-boot should have update-u-boot automatic in postinst like update-grub

[Rick Thomas]

On Jan 31, 2016, at 11:37 AM, Kilian Krause  wrote:

>  If you have the impression that "most" of the
> ARM systems out there are only equipped with a single boot device that's not
> removable, please do give a list. Otherwise, unbricking a vfat or ext4
> partition on a PC should be piece of cake.

I agree that installing U-boot to a removable μSD is, as you say, "a piece of 
cake" for most Linux users.  And as long as you keep an old, working, μSD 
around, you're safe enough if you know what you're doing.

Except for three things:

1) Not all machines that run U-boot have their boot firmware on removable 
media.  I know of at least two fairly popular, though admittedly old, armel 
architecture series of machines, each with several models -- SheevaPlug and 
OpenRD -- all of which boot from internal MMC flash that is soldered to the 
mainboard.  I believe there are others as well.  Modern machines are less 
likely to be that way, but I'm not willing to bet that the upcoming IoT 
generation will follow that trend.  If manufacturers can save a few pennies by 
soldering the boot ROM, they probably will -- even if it inconveniences a few 
of us Linux hackers.

2) We're talking about auto-updating, not about a manual process that involves 
pulling out the old μSD and replacing it with a new one that you have prepared 
off-line.  In those circumstances, the risk of corrupting the only working copy 
is not small.

3) The users of such devices can hardly be expected to be very 
hardware/software/firmware sophisticated, regardless of whether the boot 
firmware is on removable media.  I know a lot of people who might want a smart 
thermostat, but I wouldn't trust more than a tiny handful of them with the man 
page for the dd command and a μSD card to recover from a U-boot auto-update 
that went catastrophically wrong.

So, if the feature is optional, and the default is OFF, do what you like.  But 
I would recommend for most users to leave the feature turned off.

Just my two cents worth...

Rick

Bug#812611: u-boot should have update-u-boot automatic in postinst like update-grub

[Rick Thomas]

On Jan 31, 2016, at 2:42 PM, Rick Thomas <rbtho...@pobox.com> wrote:

> boot from internal MMC flash that is soldered to the mainboard.

Sorry, *not* "MMC flash".  That *should* be "MTD flash".

see:
http://www.linux-mtd.infradead.org/faq/general.html
for an explanation of the difference.

Enjoy!
Rick

Bug#812611: u-boot should have update-u-boot automatic in postinst like update-grub

[Rick Thomas]

On Jan 25, 2016, at 8:07 AM, Kilian Krause  wrote:

> Package: u-boot
> Severity: wishlist
> Tags: d-i
> 
> Hi Vagrant,
> 
> as just discussed the d-i mimic of installing u-boot should also be
> available when updating u-boot packages in an installed system.
> 
> There may be cases, where automatic updates may not be desired or where
> defaults are just simply not matching, so there should probably be a
> /etc/defaults/u-boot with:
> - an option to ENABLE/DISABLE
> - dd parameters like offset
> - the u-boot flavor and image file (if one would want to override it)
> 
> When enabled the u-boot postinst should ensure the latest code is
> auto-activated just like at the end of d-i when installing the system.
> 
> Since duplicating d-i code is not what we want, this probably means also
> creating a udeb with the u-boot-tools (and especially this "installer")
> and moving the relevant installer heuristic over to u-boot and replacing
> it in d-i with a matching structure to call this new tool.
> 
> Best,
> Kilian

With all due respect...

Please don't do this!

Installing u-boot is not at all like installing grub.

If something goes wrong with installing grub, you can boot from a CD or via 
ethernet and recover or re-install.
If something goes wrong with installing u-boot, you have bricked your device.  
The only recourse is J-tag.  Not fun at all!

Installing u-boot is something that should only be undertaken very carefully if 
you know what you're doing and are prepared to recover from a mishap.  Doing it 
automatically every time there's an update is not wise.

Thanks for including me in the discussion!

Rick

Bug#812395: u-boot-tools: sheevaplug /etc/fw_env.config - explain how env address depends on your version of u-boot.

[Rick Thomas]

Package: u-boot-tools
Version: 2016.01+dfsg1-1
Severity: wishlist

I believe the following to be true based on experiments with my two
sheevaplugs: 

If your Sheevaplug has a u-boot version prior to 2014.10+dfsg1-5,
including any of the original "Marvell" versions, the environment is
located at 0x6 and this should be reflected in the "Device offset"
field in the /etc/fw_env.config file.

If your Sheevaplug has a u-boot version of 2014.10+dfsg1-5, e.g. if
you upgraded u-boot while running Debian Jessie, or 2016.01+dfsg1-1
or later from Debian Stretch or later, the environment is located at
0x8 and this should, in turn, be reflected in the "Device offset"
field in the /etc/fw_env.config file.

I theorize that the reason for this is that versions of the u-boot.kwb
binary prior to 2014.10 were shorter than 0x6 (three erase pages
in the MTD flash), so it made sense to locate the environment at the
beginning of the fourth erase page, 0x6.

But with the 2014.10 version and later, the u-boot.kwb binary had grown
and now encroached upon part of the fourth erase page.  This meant that
the environment had to move up one erase page to 0x8.

If this is correct, it needs to be reflected in
/usr/share/doc/u-boot-tools/examples/sheevaplug.config so that users
can configure /etc/fw_env.config correctly for their particular machines.

If a similar analysis applies to other arm devices that use u-boot
(I don't know whether it does), then it might be appropriate to put
it in a README file in the /usr/share/doc/u-boot-tools/examples
directory.  A pointer to that README should go in
/usr/share/doc/u-boot-tools/examples/*.config, as appropriate for
affected devices.

Thanks!

-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: armel (armv5tel)

Kernel: Linux 4.3.0-1-kirkwood
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages u-boot-tools depends on:
ii  libc6  2.21-6

u-boot-tools recommends no packages.

u-boot-tools suggests no packages.

-- no debconf information

Bug#811351: additional request...

[Rick Thomas]

> On Jan 20, 2016, at 2:54 PM, Aaro Koskinen  wrote:
> 
> I can add more verbose comments to mainline kernel .dts on how to
> enable serial port, and how to select between rs232/485. Andrew, do
> you want me to resend the current patches, or can it be done with an
> incremental patch?
> 
> However, Debian probably needs to provide its own documentation how to
> modify the .dtb (probably some example how to convert the dtb to source
> with dtc, then how to do the modifications, and compile the source back
> to dtb).
> 
> A.

Andrew (I think it was) suggested that the instructions for doing that could go 
on Martin’s web page, which anyone who wants to use Debian on OpenRD will need 
to reference anyway.

Martin, are you willing to do that?

I can (and will gladly) test any changes and help with debuging (if such is 
necessary) .

Rick

Bug#811351: additional request...

[Rick Thomas]

Hi Aaro,

Andrew wrote
> On Sun, Jan 17, 2016 at 11:55:19PM -0800, Rick Thomas wrote:
>> 
>> On Jan 17, 2016, at 2:42 PM, Martin Michlmayr <t...@cyrius.com> wrote:
>>> * Andrew Lunn <and...@lunn.ch> [2016-01-10 16:38]:
>>>> Please can you try the following patch. If this works, i can add it to
>>>> mainline. The issue we might run into is that somebody else wants
>>>> serial not MMC
>> 
>> Is it possible to make this depend on a DTB setting?  e.g. the
>> mainline kernel supports either serial or mmc, but which one depends
>> on which one is configured in the DTB?
> 
> Hi Rick
> 
> Device tree is not particularly good for dynamic hardware. We would
> probably have to have two device tree blobs, one for MMC and one for
> RS232. I don't remember if this is just an issue for Base, or if
> Client and Ultimate have the same muxing. If so, we would want two DT
> blobs for those as well...
> 
> If there is demand, we can do it, but i would prefer to avoid this if
> possible.
> 
>   Andrew

Andrew wrote:
> On Mon, Jan 18, 2016 at 02:49:50PM -0800, Martin Michlmayr wrote:
>> * Rick Thomas <rbtho...@pobox.com> [2016-01-18 14:45]:
>>> Would it be reasonable to put a note in the release docs (or in 
>>> /usr/share/doc/??? ) describing how to modify the released dtb for personal 
>>> use?
>> 
>> Oh, right, I was going to make that comment but I forgot.
>> 
>> Andrew: maybe instead of removing the code from the base DTB, you
>> should comment it out and add a comment about this.  This way, people
>> can easily edit the DTS and recompile the DTB if needed.
> 
> I was going to take Aaro Koskinen patches, since they have Tested-by:
> etc.
> 
> How about you ask Aaro to add the comment?
> 
> Thanks
>Andrew

As per the above discussion, would it be possible to have the patch comment the 
code, rather than delete it, so that people with a need for the serial port 
could activate it?  Maybe also add a note in the /usr/share/doc/ as to how to 
perform the activation.

As long as both are possible, my own preference would be to have the MMC be 
default and the serial port be optional. But YMMV.

I'll be more than happy to test any changes...

Thanks!

Rick

Bug#811351: linux-image-4.3.0-0.bpo.1-kirkwood: MMC does not work on OpenRD Client / fix pending

[Rick Thomas]

Package: src:linux
Version: 4.3.3-5~bpo8+1
Severity: normal

Dear Maintainer,

The 4.3.0.0 kernel on an "OpenRD Client" fails to recognize the SD card -- 
there is no mmc device shown by lsblk.

This is fixed by using a modified DTB file provided by Aaro Koskinen.
Fix tested by Rick Thomas.
Martin Michlmayr has the details.


-- Package-specific info:
** Version:
Linux version 4.3.0-0.bpo.1-kirkwood (debian-ker...@lists.debian.org) (gcc 
version 4.9.2 (Debian 4.9.2-10) ) #1 Debian 4.3.3-5~bpo8+1 (2016-01-07)

** Command line:
console=ttyS0,115200

** Tainted: C (1024)
 * Module from drivers/staging has been loaded.

** Kernel log:
[7.702388] NET: Registered protocol family 10
[7.707889] systemd[1]: Inserted module 'ipv6'
[7.714743] systemd[1]: Set hostname to .
[8.185269] systemd[1]: Cannot add dependency job for unit 
display-manager.service, ignoring: Unit display-manager.service failed to load: 
No such file or directory.
[8.203342] systemd[1]: Starting Forward Password Requests to Wall Directory 
Watch.
[8.211470] systemd[1]: Started Forward Password Requests to Wall Directory 
Watch.
[8.219225] systemd[1]: Expecting device dev-ttyS0.device...
[8.236795] systemd[1]: Starting Remote File Systems (Pre).
[8.252761] systemd[1]: Reached target Remote File Systems (Pre).
[8.259054] systemd[1]: Starting Dispatch Password Requests to Console 
Directory Watch.
[8.267366] systemd[1]: Started Dispatch Password Requests to Console 
Directory Watch.
[8.275428] systemd[1]: Starting Paths.
[8.288760] systemd[1]: Reached target Paths.
[8.293257] systemd[1]: Starting Encrypted Volumes.
[8.308756] systemd[1]: Reached target Encrypted Volumes.
[8.314360] systemd[1]: Starting Arbitrary Executable File Formats File 
System Automount Point.
[8.336767] systemd[1]: Set up automount Arbitrary Executable File Formats 
File System Automount Point.
[8.346341] systemd[1]: Expecting device 
dev-disk-by\x2duuid-d5b98715\x2df529\x2d4170\x2d8559\x2d6f9fae4ac1e9.device...
[8.368782] systemd[1]: Expecting device 
dev-disk-by\x2duuid-806d1dac\x2d2026\x2d4b31\x2d977d\x2df47f0f9b7207.device...
[8.392770] systemd[1]: Starting Root Slice.
[8.404756] systemd[1]: Created slice Root Slice.
[8.409591] systemd[1]: Starting User and Session Slice.
[8.424758] systemd[1]: Created slice User and Session Slice.
[8.430643] systemd[1]: Starting Delayed Shutdown Socket.
[8.444761] systemd[1]: Listening on Delayed Shutdown Socket.
[8.450649] systemd[1]: Starting /dev/initctl Compatibility Named Pipe.
[8.468761] systemd[1]: Listening on /dev/initctl Compatibility Named Pipe.
[8.475867] systemd[1]: Starting Journal Socket (/dev/log).
[8.492758] systemd[1]: Listening on Journal Socket (/dev/log).
[8.498852] systemd[1]: Starting udev Control Socket.
[8.512762] systemd[1]: Listening on udev Control Socket.
[8.518332] systemd[1]: Starting udev Kernel Socket.
[8.532758] systemd[1]: Listening on udev Kernel Socket.
[8.538225] systemd[1]: Starting Journal Socket.
[8.552759] systemd[1]: Listening on Journal Socket.
[8.557930] systemd[1]: Starting System Slice.
[8.572760] systemd[1]: Created slice System Slice.
[8.577823] systemd[1]: Started File System Check on Root Device.
[8.584037] systemd[1]: Starting system-systemd\x2dfsck.slice.
[8.600764] systemd[1]: Created slice system-systemd\x2dfsck.slice.
[8.607171] systemd[1]: Starting system-getty.slice.
[8.624758] systemd[1]: Created slice system-getty.slice.
[8.630294] systemd[1]: Starting system-serial\x2dgetty.slice.
[8.648761] systemd[1]: Created slice system-serial\x2dgetty.slice.
[8.655241] systemd[1]: Starting Increase datagram queue length...
[8.675792] systemd[1]: Starting Create list of required static device nodes 
for the current kernel...
[8.703721] systemd[1]: Starting udev Coldplug all Devices...
[8.734742] systemd[1]: Started Set Up Additional Binary Formats.
[8.746369] systemd[1]: Starting Load Kernel Modules...
[8.771856] systemd[1]: Mounted Huge Pages File System.
[8.792795] systemd[1]: Mounting POSIX Message Queue File System...
[8.819522] systemd[1]: Mounting Debug File System...
[8.843315] systemd[1]: Starting Slices.
[8.868822] systemd[1]: Reached target Slices.
[8.875562] systemd[1]: Starting Remount Root and Kernel File Systems...
[8.908840] systemd[1]: Mounted Debug File System.
[8.926006] EXT4-fs (sdb2): re-mounted. Opts: errors=remount-ro
[8.932879] systemd[1]: Mounted POSIX Message Queue File System.
[8.956788] systemd[1]: Started Increase datagram queue length.
[8.976779] systemd[1]: Started Create list of required static device nodes 
for the current kernel.
[8.996885] systemd[1]: Started Load Kernel Modules.
[9.016818] systemd[1]: Started Remount Root and Kernel File Systems.
[9.084783] systemd[1]: Started udev Coldplug a

Bug#806215: problem found in mdadm_3.3.4-1.1+b1_armhf [Re: mdadm: upgraded mdadm now does not recognize RAID6 array causing boot to drop into emergency mode]

[Rick Thomas]

This problem persists in mdadm_3.3.4-1.1+b1_armhf.

Attached is the output of dmesg after booting, dropping into emergency mode, 
running “systemctl restart mdadm-raid” and typing “exit” resulting in boot 
completion.



dmesg-mdadm_3.3.4-1.1+b.out
Description: Binary data


Rick

Bug#810790: u-boot: It would be nice if u-boot was supported on OpenRD boards...

[Rick Thomas]

Package: u-boot
Version: 2014.10+dfsg1-5
Severity: wishlist

Dear Maintainer,

I have two OpenRD machines, a "Client" and an "Ultimate" that I'm willing to 
use for testing new releases.



-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armel (armv5tel)

Kernel: Linux 3.16.0-4-kirkwood
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#809932: installation-reports: Successful install of Debian Stretch on Sheevaplug

[Rick Thomas]

On Jan 7, 2016, at 7:25 PM, Martin Michlmayr  wrote:

> So it sounds like you had:
> - standard
> - SSH server
> - print server
> 
>> tmpfs  tmpfs   102788 348102440   1% /run
>> /dev/sda2  ext4   2065152 1878636 61896  97% /
> 
> I'm surprised it took 1.8 GB.
> 
> I just performed an installation with standard + SSH server and I
> have about 600 MB:
> Filesystem  Size  Used Avail Use% Mounted on
> /dev/sda2   6.3G  617M  5.4G  11% /

The only two ‘task’ packages I installed were task-print-server and 
task-ssh-server.  print-server is not small.

On the other hand, some of the individual packages I installed so I could 
comfortably run an X-session via “ssh -X” , such as xterm, xpdf, xinit, 
iceweasel, icedove, and a few others, do seem to drag in a lot of other stuff, 
much of it of questionable value on a headless machine.  So maybe that accounts 
for my added size over your 617M.

When I get a couple of spare hours, I’ll fire up a VM and see just how much is 
added by the various packages I routinely load as part of my “customization” 
procedure after an install.

“Fascinating!” (said with one raised eyebrow and a slight tilt of the head…)

Rick

Bug#793426: Debian 8.1 - missing separate /usr in guided encrypted LVM partitioning scheme

[Rick Thomas]

On Jan 7, 2016, at 9:07 PM, Martin Michlmayr  wrote:

> * Patryk Hanckowiak  [2015-07-24 00:58]:
>> The guided LVM encrypted partitioning layout does not create a separate /usr
>> partition and creates a 8-10 GB / (root) partition. This happens in both
>> separate /var, /tmp, /home installer option and separate /home option -
>> guided encrypted LVM. You end up with a 8-10 GB / (root) (which includes the
>> /usr partition) and this seems too small for a desktop system. If you don't
>> want to give the user the option of a separate / (root) partition, for some
>> reason, / (root) has to be assigned more space.
> 
> How large should the maximum size of / be in your opinion?
> 
> -- 
> Martin Michlmayr
> http://www.cyrius.com/

I haven’t seen a combined root, /usr, /var, /tmp (with separate /home) 
partition get above 20GB, but if I had to pick a “maximum” beyond which would 
require manual intervention, I’d go to at least 30GB.  Remember, most desktop 
machines these days come standard with a 1TB - 2TB drive.  Reserving 1.5% - 3% 
for the system files doesn’t seem unreasonable…

As for “minimum”, below which would require manual intervention, I’d allow at 
least 4 GB.  Remember, you can always get whatever size you need by choosing 
manual partitioning.

Just my opinion,

Rick

Bug#781874: sheeveplug u-boot environment - correction!

[Rick Thomas]

On Jan 6, 2016, at 12:59 PM, Rick Thomas <rbtho...@pobox.com> wrote:

> At a minimum, the patch in bug#781874 needs to be applied in order to be 
> compatible with modern version of u-boot.

Oooops!  Sorry!  Brain-fart…  The patch doesn’t do what I thought it did.

What I should have said is:

At a minimum, the file /usr/share/doc/u-boot-tools/examples/sheevaplug.config 
needs to be patched to look like this…

> # Configuration file for fw_(printenv/saveenv) utility.
> # Up to two entries are valid, in this case the redundant
> # environment sector is assumed present.
> #
> # XXX this configuration might miss a fifth parameter for the "Number of
> # sectors"
> 
> # MTD device name   Device offset   Env. size   Flash sector size
> /dev/mtd0   0x8 0x2 0x2

Sorry for the confusion!

Rick

Bug#781874: sheeveplug u-boot environment

[Rick Thomas]

On Jan 6, 2016, at 9:10 AM, Vagrant Cascadian  wrote:

>> So I guess it’s all explained by https://bugs.debian.org/781874 .
> 
> I really don't understand the logic outlined in that bug report, and
> your results don't exactly come to the same conclusion, which is why
> I've never "fixed" it.

Well, I’m no expert, but as I understand it this is what’s happened:

The u-boot binary has grown so big that it overlaps the area where it 
traditionally stored the environment strings.
So it now puts its environment at 0x8, instead of 0x6; the FLASH erase 
pages are 0x2 (128KiB) long and the flash-write process requires that 
things start at erase page boundaries — hence 0x8 rather than 0x7.
Now, fw_printenv (and its cousins) need to know about this change.
The way the developers have chosen to configure that information is by putting 
it in /etc/fw_env.config .
Those numbers are device specific, so what goes there depends on what type of 
machine you have — and possibly what version of u-boot you have.
However, the u-boot-tools package can’t (or simply choses not to) automatically 
figure out what your hardware (SheevaPlug, CuBox-i4, whatever) and put the 
right values in /etc/fw_env.config.
Instead it leaves this up to the user by putting a bunch of options in 
/usr/share/doc/u-boot-tools/examples and telling the user to pick the one she 
needs and copy it to /etc/

Unfortunately, the values in 
/usr/share/doc/u-boot-tools/examples/sheevaplug.config (at least, possibly 
others as well) are out of date and need to be updated.

At a minimum, the patch in bug#781874 needs to be applied in order to be 
compatible with modern version of u-boot.

But the problem is, doing this breaks machines with older version of u-boot 
firmware, so if you have a stock fresh-out-of-the-box SheevaPlug, the first 
thing you need to do is update your u-boot firmware! So it’s not as easy as it 
sounds.  

Would it be OK if I put all this analysis in a wishlist bugreport requesting 
that the debian u-boot-tools package figure this out at installation time and 
do the right thing, so the user doesn’t have to?

Thanks for all the help!
Rick

Bug#809932: installation-reports: Successful install of Debian Stretch on Sheevaplug

[Rick Thomas]

Package: installation-reports
Severity: normal

Dear Maintainer,

First, I upgraded U-boot on the machine to version "2014.10+dfsg1-5"
Second, I downloaded uImage and uInitrd from

https://d-i.debian.org/daily-images/armel/daily/kirkwood/netboot/marvell/sheevaplug/
and put them on a USB stick (8GB) prepared with an ext2 filesystem.
Then I connected to the serial port (using "screen -L /dev/ttyUSB0 115200")
and followed the instructions on Martin's website
http://www.cyrius.com/debian/kirkwood/sheevaplug/install/
to boot the installer.
At the first installer screen, I hit "back" a couple of times till I got to the 
main menu
where I could get a screen that allowed me to change the installer priority
to "low" (i.e. to make it an "expert" install)
Then I followed the normal installation procedure til it got to the screen 
asking which
non-standard udebs I wanted to install.  I chose the network-console so I could 
log in
via ssh with a larger screen than 24x80.

After that, it was just answering questions as usual, taking defaults whenever 
I could.
When it got to tasksel, I chose a basic installation with only the ssh server 
enabled,
but nothing else.

After the reboot (and some more u-boot magic from Martin's web page) I used 
tasksel
to install the print-server task.  No problems were encountered.
I also moved /tmp to tmpfs

-- Package-specific info:

Boot method: I followed the instructions from Martin Michlmayer's web page,
Image version: I got the uI* files from
https://d-i.debian.org/daily-images/armel/daily/kirkwood/netboot/
Date: 2015/01/03 about 23:30 UTC

Machine: Stock Sheevaplug without SATA
Partitions: 
Disk /dev/sda: 7.2 GiB, 7748222976 bytes, 15133248 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x74cb16e8

Device Boot   Start  End  Sectors  Size Id Type
/dev/sda1  *   2048   499711   497664  243M 83 Linux
/dev/sda2499712  4829183  4329472  2.1G 83 Linux
/dev/sda3   4831230 15132671 10301442  4.9G  5 Extended
/dev/sda5   4831232  5294079   462848  226M 82 Linux swap / Solaris
/dev/sda6   5296128 15132671  9836544  4.7G 83 Linux

Filesystem Type 1K-blocksUsed Available Use% Mounted on
udev   devtmpfs 10240   0 10240   0% /dev
tmpfs  tmpfs   102788 348102440   1% /run
/dev/sda2  ext4   2065152 1878636 61896  97% /
tmpfs  tmpfs   256964   0256964   0% /dev/shm
tmpfs  tmpfs 5120   0  5120   0% /run/lock
tmpfs  tmpfs   256964   0256964   0% /sys/fs/cgroup
tmpfs  tmpfs   102400  20102380   1% /tmp
/dev/sda6  ext4   47099209736   4437888   1% /home
/dev/sda1  ext2240972   44594183937  20% /boot
tmpfs  tmpfs51396   0 51396   0% /run/user/1000


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [o]
Detect network card:[o]
Configure network:  [o]
Detect CD:  [ ]
Load installer modules: [o]
Clock/timezone setup:   [o]
User/password setup:[o]
Detect hard drives: [o]
Partition hard drives:  [o] see note 1
Install base system:[o]
Install tasks:  [o]
Install boot loader:[ ]
Overall install:[o]

Comments/Problems:

note 1: As you can see from the partition table shown above, It took
almost 5GB of the 8GB USB stick I gave it for /home.  This leaves root
and swap perilously little space for anything but a very basic install.

If I ran the world, I'd make sure that the root ("everything but /home and swap)
partition got at least 4GB; and swap got at least 4 times the size of system 
RAM.


-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="9 (stretch) - installer build 20160104-00:05"
X_INSTALLATION_MEDIUM=netboot

==
Installer hardware-summary:
==
uname -a: Linux sheeva 4.3.0-1-kirkwood #1 Debian 4.3.3-4 (2016-01-03) armv5tel 
GNU/Linux
usb-list: 
usb-list: Bus 01 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 01
usb-list:Manufacturer: Linux 4.3.0-1-kirkwood ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 01 Device 02: USB DISK 2.0 [13fe:4100]
usb-list:Level 01 

Bug#806858: s-nail: mailx: Unable to (dot) lock mailbox, aborting operation: Permission denied

[Rick Thomas]

Package: s-nail
Version: 14.8.5-4
Followup-For: Bug #806858

Dear Maintainer,

So what, exactly, are the correct permissions for s-nail-privsep?

Should it be:
-rwxr-sr-x 1 root mail 10104 Dec  4 14:52 /usr/lib/s-nail/s-nail-privsep
or:
-rwsr-xr-x 1 root mail 10104 Dec  4 14:52 /usr/lib/s-nail/s-nail-privsep
or:
-rwsr-sr-x 1 root mail 10104 Dec  4 14:52 /usr/lib/s-nail/s-nail-privsep

Or something else?

And why does it not come with those permissions as installed?

(In other words, is it a feature, or a bug, that I have to change the
permissions for s-nail to work as I expect it to?)  I'm willing to accept
that this may be the intended behavior, but if so, I'd like to know why.

Thanks!
Rick

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.3.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages s-nail depends on:
ii  base-files9.5
ii  libc6 2.21-4
ii  libcomerr21.42.13-1
ii  libgssapi-krb5-2  1.13.2+dfsg-4
ii  libidn11  1.32-3
ii  libk5crypto3  1.13.2+dfsg-4
ii  libkrb5-3 1.13.2+dfsg-4
ii  libssl1.0.2   1.0.2e-1
ii  libtinfo5 6.0+20151024-2

s-nail recommends no packages.

Versions of packages s-nail suggests:
ii  exim4  4.86-7
ii  exim4-daemon-heavy [mail-transport-agent]  4.86-7

-- no debconf information

Bug#806215: mdadm: upgraded mdadm now does not recognize RAID6 array causing boot to drop into emergency mode

[Rick Thomas]

Package: mdadm
Version: 3.3.4-1
Severity: important

Cubox-i system has a RAID6 array of usb-keys (it's just an experiment -- I'd 
never use it in a production system)
Runs Debian Sid.  I recently did an upgrade that replaced 
mdadm_3.3.4-1_armhf.deb with mdadm_3.3.4-1.1_armhf.deb.
Reboot following the upgrade now does not recognize the array, and the boot 
falls into emergency mode shell.
doing "mdadm -A /dev/md/backup" in emergency mode shell found the array and 
allowed boot to continue.

I downgraded mdadm back to mdadm_3.3.4-1_armhf.deb and now it boots OK with no 
emergency shell.

changelog.Debian says that the difference between 3.3.4-1 and 3.3.4-1.1 is

|mdadm (3.3.4-1.1) unstable; urgency=medium
|  * Non-maintainer upload.
|  * disable-incremental-assembly.patch: incremental assembly prevents 
booting
|   in degraded mode (Closes: #784070)
|
|-- Yann Soubeyrand   Tue, 10 Nov 2015 
11:18:39 +0100

Could this cause what I'm seeing?

Thanks for your efforts!
Rick



-- Package-specific info:
--- mdadm.conf
CREATE owner=root group=disk mode=0660 auto=yes
HOMEHOST 
MAILADDR root
ARRAY /dev/md/backup  metadata=1.2 UUID=a0316c61:b0fdc012:704e5fdb:db6c9405 
name=cube:backup

--- /etc/default/mdadm
INITRDSTART='all'
AUTOCHECK=true
START_DAEMON=true
DAEMON_OPTIONS="--syslog"
VERBOSE=false

--- /proc/mdstat:
Personalities : [raid6] [raid5] [raid4] 
md127 : active raid6 sdf[5] sde[6] sdd[2] sdc[1] sdb[0]
  91534848 blocks super 1.2 level 6, 512k chunk, algorithm 2 [5/5] [U]
  
unused devices: 

--- /proc/partitions:
major minor  #blocks  name

 1790   15183872 mmcblk0
 1791 248832 mmcblk0p1
   80  976762584 sda
   81   19530752 sda1
   829765888 sda2
   83  1 sda3
   85  947463168 sda5
   8   16   30528032 sdb
   9  127   91534848 md127
   8   32   30528032 sdc
   8   48   30528032 sdd
   8   64   30528032 sde
   8   80   30528032 sdf
 2540   91533312 dm-0

--- LVM physical volumes:
  PV VG   Fmt  Attr PSize  PFree
  /dev/md127 vg1  lvm2 a--  87.29g0 
--- mount output
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=182799,mode=755)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,relatime,size=413380k,mode=755)
/dev/sda1 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
securityfs on /sys/kernel/security type securityfs 
(rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup 
(rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup 
(rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/freezer type cgroup 
(rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/devices type cgroup 
(rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/blkio type cgroup 
(rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup 
(rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/cpuset type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpuset)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs 
(rw,relatime,fd=33,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
tmpfs on /tmp type tmpfs (rw,relatime,size=4194304k,nr_inodes=1048576)
/dev/mmcblk0p1 on /boot type ext2 (rw,relatime)
/dev/sda5 on /home type ext4 (rw,relatime,data=ordered)
/dev/mapper/vg1-backup on /backup type ext4 
(rw,relatime,stripe=384,data=ordered)
tmpfs on /run/user/1000 type tmpfs 
(rw,nosuid,nodev,relatime,size=206692k,mode=700,uid=1000,gid=1000)

--- initrd.img-4.2.0-1-armmp:
76299 blocks
742e1c6517849fac1ddf74b4a2c2f183  
./lib/modules/4.2.0-1-armmp/kernel/drivers/md/dm-mirror.ko
f52d1927de962a250c9f0578e5c3a6d8  
./lib/modules/4.2.0-1-armmp/kernel/drivers/md/dm-bufio.ko
0f62ec7afda3e692f3dcefa0fb609b97  
./lib/modules/4.2.0-1-armmp/kernel/drivers/md/dm-raid.ko
8769193bd52b1180bb271a84626e0c95  
./lib/modules/4.2.0-1-armmp/kernel/drivers/md/raid10.ko
42579f57a90237ad22abe956e7ca6be0  
./lib/modules/4.2.0-1-armmp/kernel/drivers/md/raid1.ko
57c23011e796b4ec0fb28c5f867ae205  
./lib/modules/4.2.0-1-armmp/kernel/drivers/md/md-mod.ko
538a0315eda0b730322ead91479bb6c0  
./lib/modules/4.2.0-1-armmp/kernel/drivers/md/raid0.ko
ec8e3f439ce092ea9f26eebfea7f5c7f  

Bug#804766: inetutils-inetd: please support ipv6

[Rick Thomas]

Package: inetutils-inetd
Version: 2:1.9.2.39.3a460-3
Severity: wishlist

Dear Maintainer,

inetd does not listen on IPv6 ports, only IPv4.



-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
'stable'), (500, 'oldstable')
Architecture: armel (armv5tel)

Kernel: Linux 3.16.0-4-kirkwood
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages inetutils-inetd depends on:
ii  libc62.19-18+deb8u1
ii  lsb-base 4.1+Debian13+nmu1
ii  rsyslog [system-log-daemon]  8.4.2-1+deb8u1
ii  tcpd 7.6.q-25
ii  update-inetd 4.43

inetutils-inetd recommends no packages.

inetutils-inetd suggests no packages.

-- no debconf information

Bug#618862: systemd: ignores keyscript in crypttab

[Rick Thomas]

I tested Marcello’s workaround.  It works!  That’s wonderful!  Thank you so 
much, Marcello!

Now some further thoughts on the subject…

It’s a workaround for this bug, but, unfortunately it’s just a workaround not a 
real fix.  In particular, using a “luks=no” kernel command line option disables 
all luks encryption that is not unlocked in the initrd phase.  Decryption that 
waits until we’re out of the initrd is a less common use-case, but nevertheless 
a legitimate one.

A better work around would be to recognize the (documented but not currently 
working under systemd) crypttab option “noearly” — which prevents attempts to 
decrypt when in initrd — and a new (not currently documented or implemented) 
option “earlyonly” — which specifies that decryption for this item must occur 
while in initrd and should not be attempted outside of initrd.

But even that’s just a workaround.  A true _fix_ would be to never attempt to 
decrypt any item has already been successfully decrypted by an earlier stage.

Enjoy!
Rick

 
On Oct 18, 2015, at 4:17 AM, Marcello Barnaba  wrote:

> 
>>> Does this work for encrypted root as well?
> 
>> FTR, systemd isn't involved in unlocking the root file system, that
>> already (has to) happen in the initramfs. So this can only affect
>> non-root file systems.
> 
> With the setup I've detailed above (encrypted LUKS root
> unlocked via the passdev keyscript) I see autogenerated
> systemd units trying to setup an *already mounted root*.
> Same for encrypted swap, already set up in initramfs.
> 
> The units wait and time out after 90 seconds, causing a
> noticeable boot delay. Adding "luks=no" (or rd.luks=no)
> disables the generator and the delay.
> 
> If you need more details or information other than what I've
> provided above please let me know.
> 
> Thanks,
> 
> ~Marcello
> -- 
> ~ v...@openssl.it
> ~ http://sindro.me/
> 
> -- 
> To unsubscribe, send mail to 618862-unsubscr...@bugs.debian.org.
> 

Bug#618862: systemd: ignores keyscript in crypttab

[Rick Thomas]

On Oct 16, 2015, at 3:02 AM, Marcello Barnaba  wrote:

>> On Sat, 19 Mar 2011 03:40:25 +0100 Mourad De Clerck wrote:
>> my root and swap partition are encrypted with cryptsetup; root uses a custom
>> keyscript and swap uses the cryptsetup-provided "decrypt_derived" keyscript.
>> systemd seems to be unable to work with keyscripts at all
> 
> I confirm the same problem albeit while using the passdev keyscript.
> 
> Workaround: add "luks=no" to the kernel command line to disable systemd's 
> generator: 
> http://www.freedesktop.org/software/systemd/man/systemd-cryptsetup-generator.html
> 
> Debian Jessie *supports* keyscripts, as long as faulty software is disabled.
> 
> ~Marcello

Marcello,

Does this work for encrypted root as well?  Or is it only for things like swap 
and /home that can wait until after switching out of initramdisk?
If it works for encrypted root, this is genuinely good news!


Thanks!
Rick

Bug#618862: systemd: ignores keyscript in crypttab

[Rick Thomas]

On Oct 16, 2015, at 9:20 AM, Marcello Barnaba  wrote:

> 
>>> Workaround: add "luks=no" to the kernel command line to disable systemd's 
>>> generator: 
>>> http://www.freedesktop.org/software/systemd/man/systemd-cryptsetup-generator.html
> 
>> Does this work for encrypted root as well?  Or is it only for things like 
>> swap and /home that can wait until after switching out of initramdisk?
>> If it works for encrypted root, this is genuinely good news!
> 
> Yes. I'm using passdev in initramfs at the scripts/local-top
> stage as per cryptsetup docs to mount an encrypted root,
> unlocking it via a keyfile located on an USB key.
> 
> /etc/crypttab:
> 
>  # dev source keyfile opts
>  root /dev/sda2 /dev/disk/by-label/keys:/rootkey luks,keyscript=passdev
> 
> Then, update-initramfs -u
> 
> /dev/sda2 set up using cryptsetup luksFormat. No LVM.
> Working on current Kali Linux, based on Jessie/sid.
> Sorry I don't have version numbers at hand.
> 
> HTH, YMMV! :)
> 
> ~Marcello

Woo Hoo!  I can’t wait to test it!  (-: (-: (-:

Bug#800147: cryptsetup: keyscript=/lib/cryptsetup/scripts/passdev and noearly do not work

[Rick Thomas]

Package: cryptsetup
Version: 2:1.6.6-5
Severity: important

Under Wheezy, I was able to put "keyscript=/lib/cryptsetup/scripts/passdev"
in /etc/crypttab to make it use a key file on a USB stick

Now with jessie, this doesn''t work.

The relevant lines from /etc/crypttab look like this:

aux 
/dev/disk/by-id/ata-VMware_Virtual_IDE_Hard_Drive_0101-part1  
/dev/disk/by-label/keys:/keys 
luks,noearly,keyscript=/lib/cryptsetup/scripts/passdev
swap  
/dev/disk/by-id/ata-VMware_Virtual_SATA_Hard_Drive_0001-part1  
/dev/urandom   swap,noearly

And the relevant parts of the output of "journalctl -b" look like this

systemd-cryptsetup[434]: Encountered unknown /etc/crypttab option 
'noearly', ignoring.
systemd-cryptsetup[434]: Key file /dev/urandom is world-readable. This is 
not a good idea!
systemd[1]: Job dev-disk-by\x2dlabel-keys:-keys.device/start timed out.
systemd[1]: Timed out waiting for device 
dev-disk-by\x2dlabel-keys:-keys.device.
systemd[1]: Dependency failed for Cryptography Setup for aux.
systemd[1]: Dependency failed for Encrypted Volumes.
systemd[1]: Dependency failed for dev-mapper-aux.device.

# lsinitramfs /boot/initrd.img-3.16.0-4-amd64 | grep cryptsetup
lib/x86_64-linux-gnu/libcryptsetup.so.4
lib/cryptsetup
lib/cryptsetup/askpass
sbin/cryptsetup

which seems to indicate that the passdev script is not present in the initramfs.
The "noearly" option is supposed to make those lines in crypttab be ignored when
setting up encrypted devices at initramfs time.  Instead, they are being 
processed
at initramfs time when the relevant tools are not available, and being ignored
after the switch to the real root.

And, yes, I did "update-initramfs -u" after putting that entry into 
/etc/crypttab.




 Package-specific info:
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 root=/dev/mapper/crypt--vg-root ro quiet

-- /etc/crypttab
sdc5_crypt UUID=6c75641f-6905-4ec5-959f-84d4aecd9481 none luks

swap  
/dev/disk/by-id/ata-VMware_Virtual_SATA_Hard_Drive_0001-part1  
/dev/urandom   swap,noearly

aux 
/dev/disk/by-id/ata-VMware_Virtual_IDE_Hard_Drive_0101-part1  
/dev/disk/by-label/keys:/keys 
luks,noearly,keyscript=/lib/cryptsetup/scripts/passdev

-- /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#
/dev/mapper/crypt--vg-root /   ext4errors=remount-ro 0   1
# /boot was on /dev/sdc1 during installation
UUID=662211d8-6f25-47d2-b61e-f533bbb5bd1b /boot   ext2defaults  
  0   2
# /dev/mapper/crypt--vg-swap_1 noneswapsw  0   0
/dev/mapper/swap noneswapsw  0   0
/dev/sr0/media/cdrom0   udf,iso9660 user,noauto 0   0

-- lsmod
Module  Size  Used by
nfsd  263032  2 
auth_rpcgss51211  1 nfsd
oid_registry   12419  1 auth_rpcgss
nfs_acl12511  1 nfsd
nfs   188136  0 
lockd  83389  2 nfs,nfsd
fscache45542  1 nfs
sunrpc237402  6 nfs,nfsd,auth_rpcgss,lockd,nfs_acl
sha256_ssse3   25692  2 
sha256_generic 16804  1 sha256_ssse3
ecb12737  1 
ppdev  16782  0 
vmw_balloon12658  0 
coretemp   12820  0 
psmouse99249  0 
serio_raw  12849  0 
pcspkr 12595  0 
snd_ens137123119  0 
snd_rawmidi26806  1 snd_ens1371
uvcvideo   79005  0 
snd_seq_device 13132  1 snd_rawmidi
videobuf2_vmalloc  12816  1 uvcvideo
snd_ac97_codec118711  1 snd_ens1371
btusb  29721  0 
evdev  17445  3 
videobuf2_memops   12519  1 videobuf2_vmalloc
bluetooth 374429  2 btusb
6lowpan_iphc   16588  1 bluetooth
rfkill 18867  1 bluetooth
videobuf2_core 47787  1 uvcvideo
v4l2_common12995  1 videobuf2_core
videodev  126451  3 uvcvideo,v4l2_common,videobuf2_core
media  18305  2 uvcvideo,videodev
snd_pcm88662  2 snd_ac97_codec,snd_ens1371
snd_timer  26614  1 snd_pcm
snd65244  6 
snd_ac97_codec,snd_timer,snd_pcm,snd_rawmidi,snd_ens1371,snd_seq_device
soundcore  13026  1 snd
ac97_bus   12510  1 snd_ac97_codec
gameport   13449  1 snd_ens1371
parport_pc 26300  0 
battery13356  0 
parport35749  2 ppdev,parport_pc
processor  28221  0 
thermal_sys27642  1 processor
vmwgfx165847  0 
ttm77862  1 vmwgfx
drm_kms_helper  

Bug#800005: fbset gets 'ioctl FBIOPUT_VSCREENINFO: Invalid argument'

[Rick Thomas]

Package: fbset
Version: 2.1-28
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Prior to Jessie, I could use "fbset" toset the screen resolution on my PowerPC 
Macs.
This was often necessary if the system happened to mis-guess the actual screen
resolution, or the screen was on a KVM switch.

But now, with Jessie, when fbset is used this way does one of two things,
neither of them useful:
1) It complains that the resolution is not in /etc/fb.modes so is "Unknown".
2) If the resolution is actually present in /etc/fb.modes, it says
 ioctl FBIOPUT_VSCREENINFO: Invalid argument
In either case it does not change the screen resolution.

The bug may not be in fbset, of course.  It may be in the kernel.


-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: powerpc (ppc)

Kernel: Linux 3.16.0-4-powerpc
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fbset depends on:
ii  libc6  2.19-18+deb8u1
ii  udev   215-17+deb8u2

fbset recommends no packages.

fbset suggests no packages.

-- no debconf information

Bug#794636: dnsmasq: /etc/dnsmasq.conf does not end with newline

[Rick Thomas]

Package: dnsmasq
Version: 2.72-3+deb8u1
Severity: normal

Dear Maintainer,

The default /etc/dnsmasq.conf file does not end with a newline.

-- System Information:
Debian Release: 8.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
'stable'), (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dnsmasq depends on:
ii  dnsmasq-base 2.72-3+deb8u1
ii  init-system-helpers  1.22
ii  netbase  5.3

dnsmasq recommends no packages.

Versions of packages dnsmasq suggests:
pn  resolvconf  none

-- Configuration Files:
/etc/dbus-1/system.d/dnsmasq.conf 9a18c8a761c2262dbf0c8b3345a85242 [Errno 2] No 
such file or directory: u'/etc/dbus-1/system.d/dnsmasq.conf 
9a18c8a761c2262dbf0c8b3345a85242'
/etc/dnsmasq.conf changed [not included]

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#794640: dnsmasq: last line of /etc/dnsmasq.conf is missing a comma.

[Rick Thomas]

Package: dnsmasq
Version: 2.72-3+deb8u1
Severity: normal

Dear Maintainer,

The last line of the default /etc/dnsmasq.conf file needs a comma to be 
syntacticaly correct:

   Currently is:
  #conf-dir=/etc/dnsmasq.d/*.conf
   Should be:
  #conf-dir=/etc/dnsmasq.d/,*.conf

-- System Information:
Debian Release: 8.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
'stable'), (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dnsmasq depends on:
ii  dnsmasq-base 2.72-3+deb8u1
ii  init-system-helpers  1.22
ii  netbase  5.3

dnsmasq recommends no packages.

Versions of packages dnsmasq suggests:
pn  resolvconf  none

-- Configuration Files:
/etc/dbus-1/system.d/dnsmasq.conf 9a18c8a761c2262dbf0c8b3345a85242 [Errno 2] No 
such file or directory: u'/etc/dbus-1/system.d/dnsmasq.conf 
9a18c8a761c2262dbf0c8b3345a85242'
/etc/dnsmasq.conf changed:
conf-dir=/etc/dnsmasq.d


-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#794642: dnsmasq: pick one of the conf-dir directives and un-comment it, please

[Rick Thomas]

Package: dnsmasq
Version: 2.72-3+deb8u1
Severity: wishlist

Dear Maintainer,

The default /etc/dnsmasq.conf file, toward the end of the file, suggests 
several options
for allowing local drop-in configurations without changing the dnsmasq.conf 
file itself.
But they are all commented out.  If one of them were enabled, it would not be 
ironically
necessary to modify /etc/dnsmasq.conf in order to avoid modifying 
/etc/dnsmasq.conf .

My personal preference would be to activate the last option (once the syntax
error in it is corrected -- swap the last / for a ,)  I.E.

  conf-dir=/etc/dnsmasq.d,*.conf

But nearly anything would be better than nothing.

-- System Information:
Debian Release: 8.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
'stable'), (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dnsmasq depends on:
ii  dnsmasq-base 2.72-3+deb8u1
ii  init-system-helpers  1.22
ii  netbase  5.3

dnsmasq recommends no packages.

Versions of packages dnsmasq suggests:
pn  resolvconf  none

-- Configuration Files:
/etc/dbus-1/system.d/dnsmasq.conf 9a18c8a761c2262dbf0c8b3345a85242 [Errno 2] No 
such file or directory: u'/etc/dbus-1/system.d/dnsmasq.conf 
9a18c8a761c2262dbf0c8b3345a85242'
/etc/dnsmasq.conf changed:
conf-dir=/etc/dnsmasq.d


-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#794642: dnsmasq: pick one of the conf-dir directives and un-comment it, please

[Rick Thomas]

Thanks!

I missed that.  Sorry for the noise.

Enjoy!
Rick

On Aug 5, 2015, at 1:32 PM, Simon Kelley si...@thekelleys.org.uk wrote:

 The Debian package provides a directory, /etc/dnsmasq.d for config file
 fragments. This is automagically enabled with a command-line argument
 provided by the init-system start script, without the need to include is
 in /etc/dnsmasq.conf
 
 This is documented in para 2 of /usr/shar/doc/dnsmasq/README.Debian
 
 Cheers,
 
 Simon.
 
 
 
 On 05/08/15 11:12, Rick Thomas wrote:
 Package: dnsmasq
 Version: 2.72-3+deb8u1
 Severity: wishlist
 
 Dear Maintainer,
 
 The default /etc/dnsmasq.conf file, toward the end of the file, suggests 
 several options
 for allowing local drop-in configurations without changing the dnsmasq.conf 
 file itself.
 But they are all commented out.  If one of them were enabled, it would not 
 be ironically
 necessary to modify /etc/dnsmasq.conf in order to avoid modifying 
 /etc/dnsmasq.conf .
 
 My personal preference would be to activate the last option (once the syntax
 error in it is corrected -- swap the last / for a ,)  I.E.
 
  conf-dir=/etc/dnsmasq.d,*.conf
 
 But nearly anything would be better than nothing.
 
 -- System Information:
 Debian Release: 8.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
 'stable'), (500, 'oldstable')
 Architecture: i386 (i686)
 
 Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
 Shell: /bin/sh linked to /bin/dash
 Init: systemd (via /run/systemd/system)
 
 Versions of packages dnsmasq depends on:
 ii  dnsmasq-base 2.72-3+deb8u1
 ii  init-system-helpers  1.22
 ii  netbase  5.3
 
 dnsmasq recommends no packages.
 
 Versions of packages dnsmasq suggests:
 pn  resolvconf  none
 
 -- Configuration Files:
 /etc/dbus-1/system.d/dnsmasq.conf 9a18c8a761c2262dbf0c8b3345a85242 [Errno 2] 
 No such file or directory: u'/etc/dbus-1/system.d/dnsmasq.conf 
 9a18c8a761c2262dbf0c8b3345a85242'
 /etc/dnsmasq.conf changed:
 conf-dir=/etc/dnsmasq.d
 
 
 -- no debconf information
 
 
 


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#791869: lvm2: updating src:lvm2 from 2.02.111-2.2 to 2.02.122-1 breaks booting, mounting LVs other than / fails

[Rick Thomas]

On Jul 25, 2015, at 3:21 PM, Bastian Blank wrote:

 On Tue, Jul 21, 2015 at 07:05:42PM -0700, Rick Thomas wrote:
 I created a virtual machine with VMWare running on my Mac.  It has a virtual 
 DVD-drive (loaded with the Jessie 8.1.0 amd64 install image) and three 
 virtual disk drives.  One virtual disk is a small (1 GB) drive to hold 
 /boot.  The other two (4GB each) to be configured at installation time as a 
 software RAID0 housing a single LVM2 physical volume with three logical 
 volumes for root, home, and swap.
 
 Okay, detection of lvm on md have two problems:
 - udev rules in mdadm breaks detection of lvm and
 - lvm rules break coldplug.
 
 Bastian

OK.  We have a tentative diagnosis.  That's good.  Is there something I can do 
to verify for sure that this is what's actually happening and give us a clue as 
to what we need to do to fix it?

I'll do the udev stuff you requested in your previous email (I'm traveling 
right now, but I'll get to it after I return home -- the middle of next week)  
Is that enough to complete the diagnosis, or are there other tests we 
can/should do?

Enjoy!
Rick

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#791869: lvm2: updating src:lvm2 from 2.02.111-2.2 to 2.02.122-1 breaks booting, mounting LVs other than / fails

[Rick Thomas]

On Jul 21, 2015, at 12:11 PM, Bastian Blank wa...@debian.org wrote:

  However I'm still unable to reproduce the problem
 without a sledgehammer.

I reproduced the problem in a tiny test system as follows:

I created a virtual machine with VMWare running on my Mac.  It has a virtual 
DVD-drive (loaded with the Jessie 8.1.0 amd64 install image) and three virtual 
disk drives.  One virtual disk is a small (1 GB) drive to hold /boot.  The 
other two (4GB each) to be configured at installation time as a software RAID0 
housing a single LVM2 physical volume with three logical volumes for root, 
home, and swap.

When installed with Jessie, everything works fine.

Then I did full-upgrade to Testing/Stretch.  Everything still works fine.

Then I did full-upgrade to Unstable/Sid, and it broke.

When i disabled use_lvmetad in /etc/lvm/lvm.conf and did “update-initramfs -u” 
things went back to working.

I don’t expect the choice of VMWare as a platform has anything to do with this 
problem, so you can probably duplicate this procedure with a different VM 
platform…

The output of lsblk looks like this:

 NAME   MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
 fd0  2:014K  0 disk  
 sda  8:001G  0 disk  
 `-sda1   8:10 1022M  0 part  /boot
 sdb  8:16   04G  0 disk  
 `-sdb1   8:17   04G  0 part  
   `-md0  9:008G  0 raid0 
 |-stretch-root 253:00  3.7G  0 lvm   /
 |-stretch-swap 253:10  1.9G  0 lvm   [SWAP]
 `-stretch-home 253:20  2.4G  0 lvm   /home
 sdc  8:32   04G  0 disk  
 `-sdc1   8:33   04G  0 part  
   `-md0  9:008G  0 raid0 
 |-stretch-root 253:00  3.7G  0 lvm   /
 |-stretch-swap 253:10  1.9G  0 lvm   [SWAP]
 `-stretch-home 253:20  2.4G  0 lvm   /home
 sr0 11:01 1024M  0 rom   



If it matters, the VM has two virtual CPUs and 2 GB of virtual RAM.

Hope it helps!
Rick

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#791869: Output of 'systemctl status' in broken state and just after un-breaking it...

[Rick Thomas]

In case it helps, here’s systemctl status as logged during emergency shell.

Rick

Jul 19 22:43:49 stretch fixup[687]: + systemctl status
Jul 19 22:43:49 stretch fixup[687]: * stretch
Jul 19 22:43:49 stretch fixup[687]: State: maintenance
Jul 19 22:43:49 stretch fixup[687]:  Jobs: 0 queued
Jul 19 22:43:49 stretch fixup[687]:Failed: 0 units
Jul 19 22:43:49 stretch fixup[687]: Since: Sun 2015-07-19 22:41:41 PDT; 
2min 7s ago
Jul 19 22:43:49 stretch fixup[687]:CGroup: /
Jul 19 22:43:49 stretch fixup[687]:|-1 /sbin/init
Jul 19 22:43:49 stretch fixup[687]:`-system.slice
Jul 19 22:43:49 stretch fixup[687]:  |-lvm2-lvmetad.service
Jul 19 22:43:49 stretch fixup[687]:  | `-287 /sbin/lvmetad -f
Jul 19 22:43:49 stretch fixup[687]:  |-nfs-common.service
Jul 19 22:43:49 stretch fixup[687]:  | |-654 /sbin/rpc.statd
Jul 19 22:43:49 stretch fixup[687]:  | `-677 /usr/sbin/rpc.idmapd
Jul 19 22:43:49 stretch fixup[687]:  |-emergency.service
Jul 19 22:43:49 stretch fixup[687]:  | |-682 /bin/sh -c 
/sbin/sulogin; /bin/systemctl --job-mode=fail --no-block default
Jul 19 22:43:49 stretch fixup[687]:  | |-684 bash
Jul 19 22:43:49 stretch fixup[687]:  | |-686 bash -x bin/fixup
Jul 19 22:43:49 stretch fixup[687]:  | |-687 logger -s -t fixup
Jul 19 22:43:49 stretch fixup[687]:  | `-701 systemctl status
Jul 19 22:43:49 stretch fixup[687]:  |-systemd-journald.service
Jul 19 22:43:49 stretch fixup[687]:  | `-293 
/lib/systemd/systemd-journald
Jul 19 22:43:49 stretch fixup[687]:  |-systemd-timesyncd.service
Jul 19 22:43:49 stretch fixup[687]:  | `-449 
/lib/systemd/systemd-timesyncd
Jul 19 22:43:49 stretch fixup[687]:  |-systemd-udevd.service
Jul 19 22:43:49 stretch fixup[687]:  | `-295 
/lib/systemd/systemd-udevd
Jul 19 22:43:49 stretch fixup[687]:  |-rpcbind.service
Jul 19 22:43:49 stretch fixup[687]:  | `-645 /sbin/rpcbind -w
Jul 19 22:43:49 stretch fixup[687]:  `-system-ifup.slice
Jul 19 22:43:49 stretch fixup[687]:`-ifup@eth0.service
Jul 19 22:43:49 stretch fixup[687]:  `-605 dhclient -v -pf 
/run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0
Jul 19 22:43:49 stretch fixup[687]: + vgchange -a ay
Jul 19 22:43:49 stretch systemd[1]: Found device 
/dev/disk/by-uuid/46fac389-6646-4166-af3a-d03e9f885a41.
Jul 19 22:43:49 stretch fixup[687]:   3 logical volume(s) in volume group 
stretch now active
Jul 19 22:43:49 stretch systemd[1]: Found device /dev/disk/by-label/HOME.
Jul 19 22:43:49 stretch systemd[1]: Found device 
/dev/disk/by-id/dm-uuid-LVM-04rFhEmC9zV7NuS8clm8ymGQYGH3TifIaxFBoTV3Na3deugGPex3cERrD1rRYvzE.
Jul 19 22:43:49 stretch systemd[1]: Found device 
/dev/disk/by-id/dm-name-stretch-home.
Jul 19 22:43:49 stretch fixup[687]: + sleep 5
Jul 19 22:43:49 stretch systemd[1]: Found device /dev/dm-2.
Jul 19 22:43:49 stretch systemd[1]: Found device 
/sys/devices/virtual/block/dm-2.
Jul 19 22:43:49 stretch systemd[1]: Starting File System Check on 
/dev/mapper/stretch-home...
Jul 19 22:43:49 stretch systemd[1]: Started File System Check Daemon to report 
status.
Jul 19 22:43:49 stretch systemd[1]: Starting File System Check Daemon to report 
status...
Jul 19 22:43:49 stretch systemd-fsck[712]: HOME: clean, 30/157760 files, 
27366/630784 blocks
Jul 19 22:43:49 stretch systemd[1]: Started File System Check on 
/dev/mapper/stretch-home.
Jul 19 22:43:49 stretch systemd[1]: Mounting /home...
Jul 19 22:43:49 stretch systemd[1]: Mounted /home.
Jul 19 22:43:49 stretch kernel: EXT4-fs (dm-2): mounted filesystem with ordered 
data mode. Opts: (null)
Jul 19 22:43:53 stretch systemd-timesyncd[449]: Timed out waiting for reply 
from [2001:418:8405:4002::2]:123 (2.debian.pool.ntp.org).
Jul 19 22:43:54 stretch fixup[687]: + systemctl status
Jul 19 22:43:54 stretch fixup[687]: * stretch
Jul 19 22:43:54 stretch fixup[687]: State: maintenance
Jul 19 22:43:54 stretch fixup[687]:  Jobs: 0 queued
Jul 19 22:43:54 stretch fixup[687]:Failed: 0 units
Jul 19 22:43:54 stretch fixup[687]: Since: Sun 2015-07-19 22:41:41 PDT; 
2min 12s ago
Jul 19 22:43:54 stretch fixup[687]:CGroup: /
Jul 19 22:43:54 stretch fixup[687]:|-1 /sbin/init
Jul 19 22:43:54 stretch fixup[687]:`-system.slice
Jul 19 22:43:54 stretch fixup[687]:  |-lvm2-lvmetad.service
Jul 19 22:43:54 stretch fixup[687]:  | `-287 /sbin/lvmetad -f
Jul 19 22:43:54 stretch fixup[687]:  |-nfs-common.service
Jul 19 22:43:54 stretch fixup[687]:  | |-654 /sbin/rpc.statd
Jul 19 22:43:54 stretch fixup[687]:  | `-677 /usr/sbin/rpc.idmapd
Jul 19 22:43:54 stretch fixup[687]:  |-emergency.service
Jul 19 22:43:54 stretch fixup[687]:  | |-682 /bin/sh -c 
/sbin/sulogin; 

Bug#791869: Info received (Output of 'systemctl status' in broken state and just after un-breaking it...)

[Rick Thomas]

On a hunch, I made the following change

 # diff /SAVE/etc/lvm/lvm.conf /etc/lvm/lvm.conf 
 823c823
  use_lvmetad = 1
 ---
  use_lvmetad = 0

and ran
 # update-initramfs -u

Then rebooted.  The problem went away…

As I understand it, this makes LVM always check the actual physical volumes to 
see which PVs are present, rather than relying on the cached information kept 
by lvmetad.  Since lvmetad is not present in the initramfs (and wouldn’t be 
useful, even if it was) this allows the PVs to be scanned in the initramfs 
phase, at the cost of having to re-scan them after switching to real-root…

Maybe getting lvmetad into the initramfs, so it can be used there, then doing a 
strategically placed ‘pvscan —cache’ when switching to real-root, might do the 
trick?

Hope that helps!

Rick

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#783381: upgrade from wheezy to jessie on a PowerMac G4 Silver/Confirmation

[Rick Thomas]

Try adding 
append=“ nomodeset
to the end of the main stanza in /etc/yaboot.conf.  Then (as root) execute 
“ybin” to propagate the change to the bootstrap routines.

This will set the kernel command line to inhibit the kernel from trying to use 
hardware acceleration for your video.

The result will be (hopefully) two-fold: (1) slower video (but not much slower 
as long as you’re not using 3D features) and (2) better control over the color 
and layout of your screen.

I’ve found it’s the only thing that works for my G5 PowerMac.

Hope it helps you too!
Rick

On Jun 8, 2015, at 1:56 PM, Alois Zoitl aloiszo...@gmail.com wrote:

 Hi,
 
 thanks. Looks like there is no Gnome for non Intel platforms. With XFCE and 
 lightdm I got graphics partly working. Still rad and blue is exchanged. 
 
 But I don't want to hijack this bug for the graphics problems ;-)
 
 Regards,
 Alois
 
 On Sat, Jun 6, 2015 at 1:57 PM, Manfred Stock 
 manfred.stock+deb...@gmail.com wrote:
 Package: upgrade-reports, linux-image-3.16.0-4-powerpc
 Followup-For: Bug #783381
 
 Hi,
 
  And now to the graphics problems :-(
 
 on my system, I could improve the situation by replacing GDM3 with Lightdm, 
 and
 Gnome3 with the Awesome or Fluxbox window manager (since they actually started
 and displayed something, which was not the case with GDM or Gnome, they just
 displayed an error along the lines of something went wrong, with a logout
 button). However, I then got some kind of crash/lockup when I executed eg.
 dmesg in an xterm (mouse pointer still visible/movable, but otherwise, nothing
 changed, and restarting X iirc just got me a black screen with mouse pointer).
 I could improve that by adding
 append=radeon.agpmode=-1
 to the yaboot config of the kernel I'm booting, which disables AGP mode, but 
 so
 far seems to result in a stable system (I have the feeling that it feels 
 slower
 on certain UI updates though, but I'm not sure about his). So far, I've found
 some bug reports [1,2,3] which might be related to these issues, but haven't
 tried anything further.
 
 Still don't have working suspend to disk/ram though, but that could actually 
 be
 related to the graphics issues and/or my workaround.
 
 Kind regards
 Manfred
 
 [1] https://bugs.debian.org/762047
 [2] https://bugs.debian.org/782066
 [3] https://bugs.debian.org/683796
 
 
 -- System Information:
 Debian Release: 8.0
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'stable')
 Architecture: powerpc (ppc)
 
 Kernel: Linux 3.16.0-4-powerpc
 Locale: LANG=de_CH.utf8, LC_CTYPE=de_CH.utf8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/bash
 Init: systemd (via /run/systemd/system)
 
 --
 To unsubscribe, send mail to 783381-unsubscr...@bugs.debian.org.
 


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#786877: u-boot-tools does not have .config file for cubox

[Rick Thomas]

On May 28, 2015, at 9:56 AM, Vagrant Cascadian vagr...@aikidev.net wrote:

   … lots of useful explanation …  Thank you very much!  Useful stuff!
 
 I suppose I should document this in README.Debian...

That would be great!  Thank you!

Rick

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#786877: u-boot-tools does not have .config file for cubox

[Rick Thomas]

On 05/26/15 13:35, Vagrant Cascadian wrote:

On 2015-05-26, Rick Thomas wrote:

On May 26, 2015, at 12:44 PM, Rick Thomas rbtho...@pobox.com wrote:

On May 26, 2015, at 10:32 AM, Vagrant Cascadian vagr...@aikidev.net wrote:

On 2015-05-26, Rick Thomas wrote:
The entry committed may not work with older versions of u-boot, as some
of the device offsets in the cubox-i support included in mainline
u-boot, and the patches in 2015.04+ in debian are based on mainline
u-boot.

...

Thanks!  Would it be possible to include in the comments some reference to the 
minimum level
of uboot for which it is applicable?

Sure.



I installed the file in that URL as /etc/fw_env.config and when I run 
fw_printenv, it says
 Warning: Bad CRC, using default environment
and prints only a few lines.  I was expecting to see the many-line printout I 
get when
I do “printenv” in u-boot.

Is this expected behavior?

It is if you're running the default environment and haven't saved your
environment to the mmc (e.g. saveenv from the u-boot prompt).



I’m running uboot version 2015.04+dfsg1-2

That's the right version...


In general I prefer to work with the default environment, as I'm often
testing new u-boot versions and want to make sure it continues to work
with the defaults, and it can be tricky to remember to reset the default
environment.


live well,
   vagrant
Thanks for the explanation.  I wasn't aware that there were two 
environments.  Is this explained somewhere?  I'd love to RTFM if I only 
knew where the FM was!


I assume, if I do saveenv in uboot, that I'll  make the two 
environments equal and see the same thing from fw_printenv in Linux as I 
do from printenv in u-boot?  Is this correct?


...  I tried it and that's what happened.  Thanks!

Enjoy!
Rick


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#786877: u-boot-tools does not have .config file for cubox

[Rick Thomas]

Package: u-boot-tools
Version: 2014.10+dfsg1-5
Severity: normal


When I try fw_printenv on my cubox i4Pro, it complains 
Cannot parse config file: No such file or directory

Looking in 
/usr/share/doc/u-boot-tools/examples/
there are several example .config files, but none for the cubox machines.

Could you please provide one?

Thanks!

-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 4.0.0-1-armmp (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages u-boot-tools depends on:
ii  libc6  2.19-18

u-boot-tools recommends no packages.

u-boot-tools suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#786879: u-boot-tools: need a way to set kernel command line parameters in u-boot

[Rick Thomas]

Package: u-boot-tools
Version: 2015.04+dfsg1-2
Severity: wishlist

If I wish to boot into, e.g. single user mode on my arm device, I find that
there is no way to set the kernel command parameter single other than
by mucking with bootargs_console in ways its creator did not intend.

The problem is more general, of course, than just booting into single-user
mode.  For example, there is currently no clean way to set _any_ kernel 
parameter
either permanently or for a one-shot test.

It would be useful to have a u-boot environment parameter that will optionally 
be
passed to the kernel at boot.

Possibly, change the (sheeva plug -- wheezy)
bootcmd=setenv bootargs $(bootargs_console); run bootcmd_mmc; bootm 
0x0080 0x0110
to
bootcmd=setenv bootargs $(bootargs_console) $(cmdline); run bootcmd_mmc; 
bootm 0x0080 0x0110
and put my kernel command line args in cmdline

-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 4.0.0-1-armmp (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages u-boot-tools depends on:
ii  libc6  2.19-18

u-boot-tools recommends no packages.

u-boot-tools suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#786877: u-boot-tools does not have .config file for cubox

[Rick Thomas]

On May 26, 2015, at 12:44 PM, Rick Thomas rbtho...@pobox.com wrote:

 
 On May 26, 2015, at 10:32 AM, Vagrant Cascadian vagr...@aikidev.net wrote:
 
 Control: tags -1 +pending
 
 On 2015-05-26, Rick Thomas wrote:
 When I try fw_printenv on my cubox i4Pro, it complains 
   Cannot parse config file: No such file or directory
 
 Looking in 
   /usr/share/doc/u-boot-tools/examples/
 there are several example .config files, but none for the cubox machines.
 
 Could you please provide one?
 
 Committed to git:
 
 https://anonscm.debian.org/cgit/collab-maint/u-boot.git/commit/?id=b8e4763e5d920ad8dcacc1d51231647f7fddbf83
 
 Will include it in the next upload.
 
 The entry committed may not work with older versions of u-boot, as some
 of the device offsets in the cubox-i support included in mainline
 u-boot, and the patches in 2015.04+ in debian are based on mainline
 u-boot.
 
 
 live well,
 vagrant
 
 Thanks!  Would it be possible to include in the comments some reference to 
 the minimum level
 of uboot for which it is applicable?

Hmmm…

I installed the file in that URL as /etc/fw_env.config and when I run 
fw_printenv, it says
Warning: Bad CRC, using default environment
and prints only a few lines.  I was expecting to see the many-line printout I 
get when
I do “printenv” in u-boot.

Is this expected behavior?

I’m running uboot version 2015.04+dfsg1-2

Enjoy!
Rick

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#786879: u-boot-tools: need a way to set kernel command line parameters in u-boot

[Rick Thomas]

On May 26, 2015, at 9:30 AM, Vagrant Cascadian vagr...@aikidev.net wrote:

 Control: title -1 way to set kernel command line parameters in u-boot
 
 On 2015-05-26, Rick Thomas wrote:
 If I wish to boot into, e.g. single user mode on my arm device, I find that
 there is no way to set the kernel command parameter single other than
 by mucking with bootargs_console in ways its creator did not intend.
 
 It should be fine to edit bootcmd or bootargs_console or whatever for on
 the fly changes.
 
 
 The problem is more general, of course, than just booting into single-user
 mode.  For example, there is currently no clean way to set _any_ kernel 
 parameter
 either permanently or for a one-shot test.
 
 It would be useful to have a u-boot environment parameter that will 
 optionally be
 passed to the kernel at boot.
 
 Possibly, change the (sheeva plug -- wheezy)
bootcmd=setenv bootargs $(bootargs_console); run bootcmd_mmc; bootm 
 0x0080 0x0110
 to
bootcmd=setenv bootargs $(bootargs_console) $(cmdline); run bootcmd_mmc; 
 bootm 0x0080 0x0110
 and put my kernel command line args in cmdline
 
 I don't really see how this could be implemented in u-boot-tools...
 
 We could patch each and every board to respect additional u-boot
 environment variables, but that doesn't really seem like a maintainable
 approach...
 
 It seems like the easier thing to do is to use flash-kernel and
 /etc/default/flash-kernel or even a customized boot script.
 
 With boards that support config_distro_bootcmd, you can create an
 extlinux.conf file with menu options to select between, though it
 doesn't allow configuration of anything at boot time.
 
 
 live well,
  vagrant

Thanks for the quick response!

I’m not sure I understand what you’re saying here.  I get that I probably 
picked the wrong package to file
the bug against.  But I’m not experienced enough with the u-boot environment to 
understand the implications
of your other suggestions.

If there’s a better package for this discussion to occur, let me know and I’ll 
redirect this bug.

I agree that editing bootargs_console or bootcmd will get the job done for 
on-the-fly changes, but it seems “hackish”.  A more general solution would be 
preferable.

Enjoy!
Rick


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#786877: u-boot-tools does not have .config file for cubox

[Rick Thomas]

On May 26, 2015, at 10:32 AM, Vagrant Cascadian vagr...@aikidev.net wrote:

 Control: tags -1 +pending
 
 On 2015-05-26, Rick Thomas wrote:
 When I try fw_printenv on my cubox i4Pro, it complains 
Cannot parse config file: No such file or directory
 
 Looking in 
/usr/share/doc/u-boot-tools/examples/
 there are several example .config files, but none for the cubox machines.
 
 Could you please provide one?
 
 Committed to git:
 
  
 https://anonscm.debian.org/cgit/collab-maint/u-boot.git/commit/?id=b8e4763e5d920ad8dcacc1d51231647f7fddbf83
 
 Will include it in the next upload.
 
 The entry committed may not work with older versions of u-boot, as some
 of the device offsets in the cubox-i support included in mainline
 u-boot, and the patches in 2015.04+ in debian are based on mainline
 u-boot.
 
 
 live well,
  vagrant

Thanks!  Would it be possible to include in the comments some reference to the 
minimum level
of uboot for which it is applicable?

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#785419: linux-image-4.0.0-1-armmp: with 2 RTC devices -- need way to chose which one sets system clock on boot

[Rick Thomas]

On May 16, 2015, at 6:02 AM, Ben Hutchings b...@decadent.org.uk wrote:

 If that’s correct, I’m not sure if even sysvinit
 with /etc/default/hwclock could have done the right thing in my case.
 
 This is not implemented directly by the init system.  util-linux
 installs the script /lib/udev/hwclock-set and a udev rule that runs it
 for each RTC device.  However, the hwclock-set script does nothing if
 systemd is running.

Thank you Ben.  As usual, your clear explanation has helped me to better 
understand my problem and pointed me in new directions.

Why does it do that?  Is there some systemd feature that should make setting 
the system time unnecessary?  If so, it’s not working.

Thanks!
Rick

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#785419: linux-image-4.0.0-1-armmp: with 2 RTC devices -- need way to chose which one sets system clock on boot

[Rick Thomas]

On May 16, 2015, at 6:02 AM, Ben Hutchings b...@decadent.org.uk wrote:

 This is not implemented directly by the init system.  util-linux
 installs the script/lib/udev/hwclock-set and a udev rule that runs it
 for each RTC device.  However, the hwclock-set script does nothing if
 systemd is running.

curiouser and curiouser…

Looking at the code in /lib/udev/hwclock-set, I can’t see that it would would 
ever do anything useful (except by chance) in the case like mine where there 
are two rtc devices, only one of which should actually be used to set system 
time at boot.

In particular, it goes to some effort to source /etc/default/rcS and 
/etc/default/hwclock, but it pays no attention to the HCTOSYS_DEVICE parameter.

It appears to set the system time from each RTC device in turn as it discovers 
them.  So system time ends up set by the last RTC to be discovered.  If the 
right one happens to be last, that’s good.  But that’s not guaranteed.

Enjoy!
Rick

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#785419: linux-image-4.0.0-1-armmp: with 2 RTC devices -- need way to chose which one sets system clock on boot

[Rick Thomas]

On May 16, 2015, at 12:58 PM, Rick Thomas rbtho...@pobox.com wrote:

 
 On May 16, 2015, at 6:02 AM, Ben Hutchings b...@decadent.org.uk wrote:
 
 This is not implemented directly by the init system.  util-linux
 installs the script/lib/udev/hwclock-set and a udev rule that runs it
 for each RTC device.  However, the hwclock-set script does nothing if
 systemd is running.
 
 curiouser and curiouser…
 
 Looking at the code in /lib/udev/hwclock-set, I can’t see that it would would 
 ever do anything useful (except by chance) in the case like mine where there 
 are two rtc devices, only one of which should actually be used to set system 
 time at boot.
 
 In particular, it goes to some effort to source /etc/default/rcS and 
 /etc/default/hwclock, but it pays no attention to the HCTOSYS_DEVICE 
 parameter.
 
 It appears to set the system time from each RTC device in turn as it 
 discovers them.  So system time ends up set by the last RTC to be discovered. 
  If the right one happens to be last, that’s good.  But that’s not guaranteed.

Looking further, I find that what I said is not quite true.  hwclock-set only 
gets called for /dev/rtc0, i.e. the *first* one to be discovered.  This happens 
in /lib/udev/rules.d/85-hwclock.rules.  There is provision in 
/lib/udev/rules.d/50-udev-default.rules to swing the /dev/rtc symlink to the 
device that has ATTR{hctosys}==“1”, but that doesn’t fix the problem at hand, 
because the symlink is not used anywhere in hwclock-set.

Fascinating!
Rick

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#785419: linux-image-4.0.0-1-armmp: with 2 RTC devices -- need way to chose which one sets system clock on boot

[Rick Thomas]

On May 16, 2015, at 3:13 AM, Ian Campbell i...@debian.org wrote:

 On Fri, 2015-05-15 at 17:55 -0700, Rick Thomas wrote:
 [...]
 There does not seem to be any way to over-ride this.  There's code in 
 /etc/default/hwclock
 that would do part of the work in a sysvinit setup, but it seems to be 
 ignored under systemd.
 [...]
 Presumably, there is systemd magic that could do the same thing as was 
 available under
 sysvinit.  Is there anybody out there with enough systemd foo to tell me how 
 to do that?
 
 I think that if systemd is not supporting /etc/default/hwclock and the
 replacement mechanism is not apparent after some searching of the docs
 etc then this should be considered a systemd bug (either in the docs if
 not an actual code bug or missing feature).
 
 Perhaps someone on the pkg-systemd-maintainers@alioth list will be
 better able to advise on if/how systemd solves this problem?
 
 Ian.

Thanks, Ian, for the prompt response.  I’ve submitted a separate bug to systemd 
asking for a fix.  However, it may not be possible to do this with systemd…  
Looking at the dmesg output, it looks like the decision to use /dev/rtc0 is 
being made at the kernel level, before systemd even gets started.  If that’s 
correct, I’m not sure if even sysvinit with /etc/default/hwclock could have 
done the right thing in my case.

Do you happen to know why the patch I came across never made it into the kernel?

Thanks, again!
Rick


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#785419: linux-image-4.0.0-1-armmp: with 2 RTC devices -- need way to chose which one sets system clock on boot

[Rick Thomas]

Package: src:linux
Version: 4.0.2-1
Severity: normal
Tags: upstream


My cubox-i4pro armhf device has two real-time-clocks.  One, snvs, is not 
battery backed,
hence is not useful for setting the system clock on boot after a power failure.
The other, pcf8523, does have battery backup.

Unfortunately, the snvs is recognzed first, so it become /dev/rtc0 (the pcf8523 
becomes /dev/rtc1)
and the kernel at boot time uses /dev/rtc0 by default to set the system time 
from.

There does not seem to be any way to over-ride this.  There's code in 
/etc/default/hwclock
that would do part of the work in a sysvinit setup, but it seems to be ignored 
under systemd.

In googling about, I stumbled across a proposed patch that would add a kernel 
command line
parameter, hctosys=rtc#' that would over-ride the default, but it seems not
to have ever been implemented ( 
http://lkml.iu.edu/hypermail/linux/kernel/1407.0/03989.html )

Presumably, there is systemd magic that could do the same thing as was 
available under
sysvinit.  Is there anybody out there with enough systemd foo to tell me how to 
do that?

Other ways to attack this problem may involve something with udev rules, but 
I'm not savvy
enough to figure that out for myself, either.

Personally, I kind of like the kernel command line parameter, but others may 
have other
ideas.

Thanks for your consideration!
Rick 


-- Package-specific info:
** Version:
Linux version 4.0.0-1-armmp (debian-ker...@lists.debian.org) (gcc version 4.9.2 
(Debian 4.9.2-16) ) #1 SMP Debian 4.0.2-1 (2015-05-11)

** Command line:
hctosys=rtc1 console=ttymxc0,115200 quiet

** Not tainted

** extracts from dmesg
rbthomas@cube:~$ dmesg | egrep 'rtc|clock' | grep -v crtc
[0.00] Kernel command line: hctosys=rtc1 console=ttymxc0,115200 quiet
[0.00] L2C-310 dynamic clock gating enabled, standby mode enabled
[0.07] sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 
1431655765682ns
[0.114449] PTP clock support registered
[0.115986] Switched to clocksource mxc_timer1
[1.303721] snvs_rtc 20cc034.snvs-rtc-lp: rtc core: registered 
20cc034.snvs-rtc-lp as rtc0
[1.311100] snvs_rtc 20cc034.snvs-rtc-lp: setting system clock to 2015-05-15 
23:43:56 UTC (1431733436)
[5.634623] rtc-pcf8523 2-0068: rtc core: registered rtc-pcf8523 as rtc1


** Kernel log:
[7.857815] usb-storage 1-1.4.2:1.0: USB Mass Storage device detected
[7.858173] scsi host6: usb-storage 1-1.4.2:1.0
[7.865466] scsi 1:0:0:0: Direct-Access Generic  STORAGE DEVICE   0272 
PQ: 0 ANSI: 0
[7.866779] sd 1:0:0:0: Attached scsi generic sg1 type 0
[7.873156] scsi 2:0:0:0: Direct-Access SanDisk  Cruzer Fit   1.27 
PQ: 0 ANSI: 6
[7.873790] scsi 3:0:0:0: Direct-Access SanDisk  Cruzer Fit   1.27 
PQ: 0 ANSI: 6
[7.874380] sd 2:0:0:0: Attached scsi generic sg2 type 0
[7.875645] sd 3:0:0:0: Attached scsi generic sg3 type 0
[7.876241] sd 2:0:0:0: [sdc] 61056064 512-byte logical blocks: (31.2 
GB/29.1 GiB)
[7.876886] sd 3:0:0:0: [sdd] 61056064 512-byte logical blocks: (31.2 
GB/29.1 GiB)
[7.877015] sd 2:0:0:0: [sdc] Write Protect is off
[7.877033] sd 2:0:0:0: [sdc] Mode Sense: 43 00 00 00
[7.877632] sd 3:0:0:0: [sdd] Write Protect is off
[7.877651] sd 3:0:0:0: [sdd] Mode Sense: 43 00 00 00
[7.877881] sd 2:0:0:0: [sdc] Write cache: disabled, read cache: enabled, 
doesn't support DPO or FUA
[7.878766] sd 3:0:0:0: [sdd] Write cache: disabled, read cache: enabled, 
doesn't support DPO or FUA
[7.892636] sd 3:0:0:0: [sdd] Attached SCSI removable disk
[7.896288] sd 2:0:0:0: [sdc] Attached SCSI removable disk
[7.927904] md: bindsdd
[7.938387] md: bindsdc
[8.068936] scsi 4:0:0:0: Direct-Access SanDisk  Cruzer Fit   1.27 
PQ: 0 ANSI: 6
[8.070109] sd 4:0:0:0: Attached scsi generic sg4 type 0
[8.070636] sd 4:0:0:0: [sde] 61056064 512-byte logical blocks: (31.2 
GB/29.1 GiB)
[8.071369] sd 4:0:0:0: [sde] Write Protect is off
[8.071386] sd 4:0:0:0: [sde] Mode Sense: 43 00 00 00
[8.072145] sd 4:0:0:0: [sde] Write cache: disabled, read cache: enabled, 
doesn't support DPO or FUA
[8.082631] sd 4:0:0:0: [sde] Attached SCSI removable disk
[8.119009] md: bindsde
[8.122659] sd 1:0:0:0: [sdb] 122519552 512-byte logical blocks: (62.7 
GB/58.4 GiB)
[8.123764] sd 1:0:0:0: [sdb] Write Protect is off
[8.123780] sd 1:0:0:0: [sdb] Mode Sense: 0b 00 00 08
[8.125874] sd 1:0:0:0: [sdb] No Caching mode page found
[8.125892] sd 1:0:0:0: [sdb] Assuming drive cache: write through
[8.136889]  sdb: sdb1 sdb2 sdb3  sdb5 sdb6 sdb7 
[8.142922] sd 1:0:0:0: [sdb] Attached SCSI removable disk
[8.661076] scsi 5:0:0:0: Direct-Access SanDisk  Cruzer Fit   1.27 
PQ: 0 ANSI: 6
[8.662322] sd 5:0:0:0: Attached scsi generic sg5 type 0
[8.663763] sd 5:0:0:0: [sdf] 61056064 512-byte logical blocks: (31.2 
GB/29.1 GiB)
[8.665357] sd 5:0:0:0: [sdf] Write Protect is off
[   

Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks

[Rick Thomas]

On May 6, 2015, at 3:35 AM, Rick Thomas rbtho...@pobox.com wrote:

 
 On May 6, 2015, at 3:27 AM, Ian Campbell i...@debian.org wrote:
 
 It would be preferable to test the thing in Sid before the upload to
 jessie-proposed-updates
 
 I’ll keep an eye out for it.
 
 But I don’t have one of the cubox models without the battery-backed RTC, so I 
 won’t be able to test that case.   Is there anyone out there in debian-arm 
 land with an appropriate test box?
 
 Enjoy!
 Rick

Am I looking in the wrong place?  I would have expected to see something show 
up in sid by now.

Is there a particular linux-image….deb I should download from somewhere to test 
this?

Thanks for all your help!
Rick

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks

[Rick Thomas]

On May 12, 2015, at 2:11 AM, Ian Campbell i...@debian.org wrote:

 On Tue, 2015-05-12 at 01:33 -0700, Rick Thomas wrote:
 On May 6, 2015, at 3:35 AM, Rick Thomas rbtho...@pobox.com wrote:
 
 
 On May 6, 2015, at 3:27 AM, Ian Campbell i...@debian.org wrote:
 
 It would be preferable to test the thing in Sid before the upload to
 jessie-proposed-updates
 
 I’ll keep an eye out for it.
 
 But I don’t have one of the cubox models without the battery-backed
 RTC, so I won’t be able to test that case.   Is there anyone out there
 in debian-arm land with an appropriate test box?
 
 Enjoy!
 Rick

It arrived this morning.  I’ve got two RTC entries now in /dev.  But I’m a bit 
confused…

Looking at the boot log with journalctl (see attachment), it appears that the 
snvs RTC (i.e. the one without a battery backup) is being found first, and the 
_kernel_ is setting system time from it — ignoring /etc/init.d/hwclock.sh 
completely.

The pcf8523 RTC (the one with battery backup) is being discovered later, and is 
not being used to set the system time at all.

This is exactly the opposite of the behavior I was hoping for.

Well… I thought I was prepared for that by planning to use parameters in 
/etc/default/hwclock to tell it which RTC to use when shutting-down or 
booting-up.  But it appears that those parameters are being ignored.

Looking in /lib/systemd/system/hwclock-save.service (the systemd equivalent of 
/etc/init.d/hwclock), I find “ExecStart=/sbin/hwclock -D —systohc” which is 
interesting because (1) it invokes a “-D” option which is not documented in 
“man hwclock”, (2) it ignores the /etc/default parameters, and (3) it’s only 
being done on shutdown/halt/reboot; there’s no corresponding service that gets 
run at boot time…  Is the RTC driver itself supposed to be doing that, so 
there’s no need for sysvinit or systemd to worry about it???  The “setting 
system clock” log entry would seem to substantiate that.

So what to do now?

Any constructive suggestions will appreciated.

Rick

root@cube:~# journalctl | egrep 'rtc|clock|date|time'
May 12 20:54:53 cube systemd-journal[167]: Runtime journal is using 5.0M (max 
allowed 40.3M, trying to leave 60.5M free of 398.5M available → current limit 
40.3M).
May 12 20:54:53 cube systemd-journal[167]: Runtime journal is using 5.0M (max 
allowed 40.3M, trying to leave 60.5M free of 398.5M available → current limit 
40.3M).
May 12 20:54:53 cube kernel: L2C-310 dynamic clock gating enabled, standby mode 
enabled
May 12 20:54:53 cube kernel: Switching to timer-based delay loop, resolution 
333ns
May 12 20:54:53 cube kernel: sched_clock: 32 bits at 3000kHz, resolution 333ns, 
wraps every 1431655765682ns
May 12 20:54:53 cube kernel: Calibrating delay loop (skipped), value calculated 
using timer frequency.. 6.00 BogoMIPS (lpj=12000)
May 12 20:54:53 cube kernel: AppArmor: AppArmor disabled by boot time parameter
May 12 20:54:53 cube kernel: PTP clock support registered
May 12 20:54:53 cube kernel: Switched to clocksource mxc_timer1
May 12 20:54:53 cube kernel: snvs_rtc 20cc034.snvs-rtc-lp: rtc core: registered 
20cc034.snvs-rtc-lp as rtc0
May 12 20:54:53 cube kernel: snvs_rtc 20cc034.snvs-rtc-lp: setting system clock 
to 2015-05-13 03:54:49 UTC (1431489289)
May 12 20:54:53 cube kernel: imx2-wdt 20bc000.wdog: timeout 60 sec (nowayout=0)
May 12 20:54:53 cube kernel: rtc-pcf8523 2-0068: rtc core: registered 
rtc-pcf8523 as rtc1
May 12 20:54:54 cube kernel: [drm] Supports vblank timestamp caching Rev 2 
(21.10.2013).
May 12 20:54:54 cube kernel: [drm] No driver support for vblank timestamp query.
May 12 20:54:54 cube kernel: imx-drm display-subsystem: bound imx-ipuv3-crtc.0 
(ops ipu_drm_driver_exit [imx_ipuv3_crtc])
May 12 20:54:54 cube kernel: imx-drm display-subsystem: bound imx-ipuv3-crtc.1 
(ops ipu_drm_driver_exit [imx_ipuv3_crtc])
May 12 20:54:54 cube kernel: imx-drm display-subsystem: bound imx-ipuv3-crtc.4 
(ops ipu_drm_driver_exit [imx_ipuv3_crtc])
May 12 20:54:54 cube kernel: imx-drm display-subsystem: bound imx-ipuv3-crtc.5 
(ops ipu_drm_driver_exit [imx_ipuv3_crtc])
May 12 20:54:54 cube kernel: [drm] Cannot find any crtc or sizes - going 
1024x768
May 12 20:55:56 cube systemd-journal[167]: Runtime journal is using 5.0M (max 
allowed 40.3M, trying to leave 60.5M free of 398.3M available → current limit 
40.3M).
May 12 20:55:56 cube adjtimex[356]: Regulating system clock...done.
May 12 20:55:59 cube ntpd[481]: Listening on routing socket on fd #20 for 
interface updates
May 12 20:56:03 cube colord[833]: Cannot adopt OID in UCD-SNMP-MIB: 
versionUpdateConfig ::= { version 11 }
May 12 20:56:06 cube ntpd[918]: Listening on routing socket on fd #23 for 
interface updates
May 12 21:23:02 cube CRON[1236]: (rbthomas) CMD (bash bin/check_cmos_ctime)

Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks

[Rick Thomas]

OK, How will I identify the upload when I see it?  The box is running 
Debian/Sid and I do regular updates.  So presumably, I’ll see a 
“linux-image-3.16.0-4-armmp” package go by sometime soon?  And I’ll know I’ve 
got it when I see two /dev/rtc* devices?

As for “rbtho...@cube.rcthomas.org” — I’m afraid it’s bogus.  I had exim4 
configured wrong when I submitted the original bugreport  /-:.  I’m subscribed 
to the bugreport with my proper address (“rbtho...@pobox.com”) now; so you can 
either just send stuff for me to the bugreport directly or to the “@pobox.com” 
address, and delete (or simply ignore) “rbtho...@cube.rcthomas.org” whenever it 
raises its head.

Thanks!  This has been an interesting and educational discussion!
Rick


On May 6, 2015, at 1:01 AM, Ian Campbell i...@debian.org wrote:

 On Sat, 2015-05-02 at 17:21 +0100, Ian Campbell wrote:
 We typically build RTCs statically (for this sort of reason) so it seems
 like the right thing for us to do here is to build both in.
 
 Which I've now done in SVN. Rick, please test the next upload.
 
 Also, Rick, I'm getting messages from my MTA about not being able to
 deliver to rbtho...@cube.rcthomas.org, it's been queuing/retrying since
 the weekend and says I shouldn't worry, but I thought I'd mention it
 since I was here. Exim logs say:
 
 2015-05-06 06:48:50 1YoZqj-0002JC-G0 == rbtho...@cube.rcthomas.org 
 R=dnslookup T=remote_smtp defer (-53): retry time not reached for any host
 
 Hopefully you will see this via some other route.
 
 Ian.
 
 -- 
 To unsubscribe, send mail to 782364-unsubscr...@bugs.debian.org.
 


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks

[Rick Thomas]

On May 6, 2015, at 3:27 AM, Ian Campbell i...@debian.org wrote:

 It would be preferable to test the thing in Sid before the upload to
 jessie-proposed-updates

I’ll keep an eye out for it.

But I don’t have one of the cubox models without the battery-backed RTC, so I 
won’t be able to test that case.   Is there anyone out there in debian-arm land 
with an appropriate test box?

Enjoy!
Rick

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks

[Rick Thomas]

On Apr 28, 2015, at 8:02 PM, Fabio Estevam feste...@gmail.com wrote:

 On Fri, Apr 10, 2015 at 9:08 PM, Ben Hutchings b...@decadent.org.uk wrote:
 
 Whenever I reset my cubox-i4Pro by disconnecting the power plug, the 
 hardware real-time-clock gets
 reset to midnight UTC, Dec 31, 1970.
 Even though the SolidRun literature says that the i4Pro has a battery 
 backed RTC.
 
 If this RTC is not battery backed, it seems like it ought to be disabled
 in this board's device tree.
 
 Agreed. Just sent a patch for this.
 
 # CONFIG_RTC_DRV_PCF8523 is not set
 
 and
 
 CONFIG_RTC_DRV_SNVS=y
 
 And also a patch for turning on this option as well.
 
 Regards,
 
 Fabio Estevam

I don’t know if this makes any difference, but please remember that this box 
comes in several flavors.  Only the i4pro flavor has the battery-backed clock 
turned on in the hardware.

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks

[Rick Thomas]

On Apr 28, 2015, at 8:02 PM, Fabio Estevam feste...@gmail.com wrote:

 On Fri, Apr 10, 2015 at 9:08 PM, Ben Hutchings b...@decadent.org.uk wrote:
 
 Whenever I reset my cubox-i4Pro by disconnecting the power plug, the 
 hardware real-time-clock gets
 reset to midnight UTC, Dec 31, 1970.
 Even though the SolidRun literature says that the i4Pro has a battery 
 backed RTC.
 
 If this RTC is not battery backed, it seems like it ought to be disabled
 in this board's device tree.
 
 Agreed. Just sent a patch for this.
 
 # CONFIG_RTC_DRV_PCF8523 is not set
 
 and
 
 CONFIG_RTC_DRV_SNVS=y
 
 And also a patch for turning on this option as well.
 
 Regards,
 
 Fabio Estevam

Cool… Thanks!  Any idea when we’ll see it in the kernel from Sid/Unstable 
repo’s?

Rick

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#782793: systemd: ext4 filesystem on lvm on raid causes boot to enter emergency shell

[Rick Thomas]

On Apr 23, 2015, at 1:29 AM, Michael Biebl bi...@debian.org wrote:

 There might be a race somewhere, i.e. lvm2-activation(-early).service
 being run *before* mdadm has assembled the RAID.
 
 You could test this theory, be artifically delaying those two services.
 Copy them to /etc/systemd/system, and add a ExecStartPre=/bin/sleep 30
 to the [Service] section of those two units.


So… That worked (adding a 30-second delay) twice in a row.

Let me know if you want to see a log with debug turned on for such a reboot.

Thanks for your help!

Rick

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#782793: systemd: ext4 filesystem on lvm on raid causes boot to enter emergency shell

[Rick Thomas]

On Apr 22, 2015, at 8:17 AM, Michael Biebl bi...@debian.org wrote:

 Am 22.04.2015 um 12:10 schrieb Rick Thomas:
 This works.  Interestingly, without the sleep loop the vgchange
 fails.
 
 Now, you say that a VM with two virtual disks configured as RAID1
 with a logical volume works fresh out of the box.  This makes me
 wonder if it’s some kind of a timing problem…  It takes a few seconds
 for the freshly rebooted system to find the USB-Flash sticks and
 assemble them.  So  some time-out is triggered in the systemd stuff
 on my setup, while your setup has no such physical constraints —
 everything is available immediately.
 
 So you're running vgchange in a loop, which suggests that the
 lvm2-activation.service and lvm2-activation-early.service unitsas
 shipped by lvm2 are not sufficient. Those are supposed to run vgchange.
 
 I notice, that the /etc/init.d/lvm2 init script has
 Should-Start: mdadm-raid
 but the systemd unit files have no such ordering.
 
 I wonder, if that makes a difference.
 
 Could you copy /lib/systemd/system/lvm2-activation.service to
 /etc/systemd/system and add a line
 After=mdadm-raid.service
 to the [Unit] section.


Odd… That didn’t work.  I was almost sure you had it nailed!  /-:

It’s worth noting that there is no file named “mdadm-raid.service” anywhere 
that I could find in /etc/systemd/ or /lib/systemd/.
Also, the files /lib/systemd/system/mdadm-waitidle.service  and 
/lib/systemd/system/mdadm.service are both symlinks to /dev/null.

Does that tell you anything?

Attached is the output of journalctl for that boot…

The potentially interesting parts (with time-stamps as pointers to the context 
in which they occur in the full journal) are:

rbthomas@cube:~$ egrep -i 'md127|mdadm|lvm|backup|md array|mount'  
/tmp/boot-journal.txt 
Apr 22 23:58:02 cube kernel: Mount-cache hash table entries: 2048 (order: 1, 
8192 bytes)
Apr 22 23:58:02 cube kernel: Mountpoint-cache hash table entries: 2048 (order: 
1, 8192 bytes)
Apr 22 23:58:02 cube kernel: EXT4-fs (mmcblk0p2): mounted filesystem with 
ordered data mode. Opts: (null)
Apr 22 23:58:02 cube kernel: EXT4-fs (mmcblk0p2): re-mounted. Opts: 
errors=remount-ro
Apr 22 23:58:02 cube mdadm-raid[185]: Generating udev events for MD 
arrays...done.
Apr 22 23:58:03 cube lvm[196]: 1 logical volume(s) in volume group vg now 
active
Apr 22 23:58:03 cube lvm[260]: 1 logical volume(s) in volume group vg now 
active
Apr 22 23:58:03 cube kernel: EXT4-fs (mmcblk0p1): mounting ext2 file system 
using the ext4 subsystem
Apr 22 23:58:03 cube kernel: EXT4-fs (mmcblk0p6): mounted filesystem with 
ordered data mode. Opts: (null)
Apr 22 23:58:04 cube kernel: EXT4-fs (mmcblk0p1): mounted filesystem without 
journal. Opts: (null)
Apr 22 23:58:04 cube kernel: EXT4-fs (mmcblk0p7): mounted filesystem with 
ordered data mode. Opts: (null)
Apr 22 23:58:04 cube kernel: EXT4-fs (dm-0): mounted filesystem with ordered 
data mode. Opts: (null)
Apr 22 23:58:04 cube lvm[296]: 1 logical volume(s) in volume group vg 
monitored
Apr 22 23:58:05 cube kernel: md/raid:md127: device sdf operational as raid disk 
4
Apr 22 23:58:05 cube kernel: md/raid:md127: device sde operational as raid disk 
3
Apr 22 23:58:05 cube kernel: md/raid:md127: device sdd operational as raid disk 
2
Apr 22 23:58:05 cube kernel: md/raid:md127: device sdc operational as raid disk 
1
Apr 22 23:58:05 cube kernel: md/raid:md127: device sdb operational as raid disk 0
Apr 22 23:58:05 cube kernel: md/raid:md127: allocated 0kB
Apr 22 23:58:05 cube kernel: md/raid:md127: raid level 6 active with 5 out of 5 
devices, algorithm 2
Apr 22 23:58:05 cube kernel: md127: detected capacity change from 0 to 
93731684352
Apr 22 23:58:05 cube kernel:  md127: unknown partition table
Apr 22 23:59:31 cube systemd[1]: Job dev-disk-by\x2dlabel-BACKUP.device/start 
timed out.
Apr 22 23:59:31 cube systemd[1]: Timed out waiting for device 
dev-disk-by\x2dlabel-BACKUP.device.
Apr 22 23:59:31 cube systemd[1]: Dependency failed for /backup.
Apr 22 23:59:53 cube lvm[588]: 1 logical volume(s) in volume group vg1 now 
active
Apr 22 23:59:54 cube lvm[588]: 1 logical volume(s) in volume group vg now 
active
Apr 22 23:59:54 cube systemd[1]: backup.mount: Directory /backup to mount over 
is not empty, mounting anyway.
Apr 22 23:59:54 cube kernel: EXT4-fs (dm-1): mounted filesystem with ordered 
data mode. Opts: (null)
Apr 22 23:59:54 cube lvm[635]: 1 logical volume(s) in volume group vg1 now 
active
Apr 22 23:59:54 cube lvm[635]: 1 logical volume(s) in volume group “vg” now 
active


I don’t see any events having to do with LVM between the point when the md127 
raid is assembled by the kernel (not by systemd) and the point when the systemd 
time-out occurs a minute and a half later.  However, there is an LVM event for 
vg (the volume group on the eSATA disk) a second or two before the md127 raid 
stuff…

Hope this helps!

Rick


-- Logs begin at Wed 2015-04-22 23:58:02 PDT, end at Thu 2015-04-23 00:01:24 
PDT. --
Apr 22 23:58:02 cube

Bug#782793: systemd: ext4 filesystem on lvm on raid causes boot to enter emergency shell

[Rick Thomas]

On Apr 23, 2015, at 1:29 AM, Michael Biebl bi...@debian.org wrote:

 Can you boot with systemd.log_level=debug on the kernel command line and
 attach the journal output of this boot, so we have more information out
 the timing, i.e. when certain services are started
 
 There might be a race somewhere, i.e. lvm2-activation(-early).service
 being run *before* mdadm has assembled the RAID.
 
 You could test this theory, be artifically delaying those two services.
 Copy them to /etc/systemd/system, and add a ExecStartPre=/bin/sleep 30
 to the [Service] section of those two units.
 
 Michael

OK, here’s the log…  Hope it helps!

Interestingly, one time (just once! out of several tries) it booted fine — so 
it pretty clearly *is* a race condition!

-- Logs begin at Thu 2015-04-23 03:24:37 PDT, end at Thu 2015-04-23 03:28:32 
PDT. --
Apr 23 03:24:37 cube systemd-journal[163]: Runtime journal is using 5.0M (max 
allowed 40.4M, trying to leave 60.6M free of 399.0M available → current limit 
40.4M).
Apr 23 03:24:37 cube systemd-journal[163]: Runtime journal is using 5.0M (max 
allowed 40.4M, trying to leave 60.6M free of 399.0M available → current limit 
40.4M).
Apr 23 03:24:37 cube kernel: Booting Linux on physical CPU 0x0
Apr 23 03:24:37 cube kernel: Initializing cgroup subsys cpuset
Apr 23 03:24:37 cube kernel: Initializing cgroup subsys cpu
Apr 23 03:24:37 cube kernel: Initializing cgroup subsys cpuacct
Apr 23 03:24:37 cube kernel: Linux version 3.16.0-4-armmp 
(debian-ker...@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP 
Debian 3.16.7-ckt9-2 (2015-04-13)
Apr 23 03:24:37 cube kernel: CPU: ARMv7 Processor [412fc09a] revision 10 
(ARMv7), cr=10c5387d
Apr 23 03:24:37 cube kernel: CPU: PIPT / VIPT nonaliasing data cache, VIPT 
aliasing instruction cache
Apr 23 03:24:37 cube kernel: Machine model: SolidRun Cubox-i Dual/Quad
Apr 23 03:24:37 cube kernel: Memory policy: Data cache writealloc
Apr 23 03:24:37 cube kernel: On node 0 totalpages: 524288
Apr 23 03:24:37 cube kernel: free_area_init_node: node 0, pgdat c09dc700, 
node_mem_map ee7f8000
Apr 23 03:24:37 cube kernel:   DMA zone: 1520 pages used for memmap
Apr 23 03:24:37 cube kernel:   DMA zone: 0 pages reserved
Apr 23 03:24:37 cube kernel:   DMA zone: 194560 pages, LIFO batch:31
Apr 23 03:24:37 cube kernel:   HighMem zone: 2576 pages used for memmap
Apr 23 03:24:37 cube kernel:   HighMem zone: 329728 pages, LIFO batch:31
Apr 23 03:24:37 cube kernel: PERCPU: Embedded 9 pages/cpu @ee7b3000 s12608 
r8192 d16064 u36864
Apr 23 03:24:37 cube kernel: pcpu-alloc: s12608 r8192 d16064 u36864 alloc=9*4096
Apr 23 03:24:37 cube kernel: pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 
Apr 23 03:24:37 cube kernel: Built 1 zonelists in Zone order, mobility grouping 
on.  Total pages: 522768
Apr 23 03:24:37 cube kernel: Kernel command line: console=ttymxc0,115200 quiet
Apr 23 03:24:37 cube kernel: PID hash table entries: 4096 (order: 2, 16384 
bytes)
Apr 23 03:24:37 cube kernel: Dentry cache hash table entries: 131072 (order: 7, 
524288 bytes)
Apr 23 03:24:37 cube kernel: Inode-cache hash table entries: 65536 (order: 6, 
262144 bytes)
Apr 23 03:24:37 cube kernel: Memory: 2054816K/2097152K available (6404K kernel 
code, 828K rwdata, 2204K rodata, 684K init, 393K bss, 42336K reserved, 1318912K 
highmem)
Apr 23 03:24:37 cube kernel: Virtual kernel memory layout:
 vector  : 0x - 0x1000   (   4 kB)
 fixmap  : 0xffc0 - 0xffe0   (2048 kB)
 vmalloc : 0xf000 - 0xff00   ( 240 MB)
 lowmem  : 0xc000 - 0xef80   ( 760 MB)
 pkmap   : 0xbfe0 - 0xc000   (   2 MB)
 modules : 0xbf00 - 0xbfe0   (  14 MB)
   .text : 0xc0008000 - 0xc08702e4   (8609 kB)
   .init : 0xc0871000 - 0xc091c140   ( 685 kB)
   .data : 0xc091e000 - 0xc09ed3d0   ( 829 kB)
.bss : 0xc09ed3d0 - 0xc0a4f874   ( 394 kB)
Apr 23 03:24:37 cube kernel: Hierarchical RCU implementation.
Apr 23 03:24:37 cube kernel: RCU dyntick-idle grace-period acceleration 
is enabled.
Apr 23 03:24:37 cube kernel: NR_IRQS:16 nr_irqs:16 16
Apr 23 03:24:37 cube kernel: L2C-310 erratum 769419 enabled
Apr 23 03:24:37 cube kernel: L2C-310 enabling early BRESP for Cortex-A9
Apr 23 03:24:37 cube kernel: L2C-310 full line of zeros enabled for Cortex-A9
Apr 23 03:24:37 cube kernel: L2C-310 ID prefetch enabled, offset 1 lines
Apr 23 03:24:37 cube kernel: L2C-310 dynamic clock gating enabled, standby mode 
enabled
Apr 23 03:24:37 cube kernel: L2C-310 cache controller enabled, 16 ways, 1024 kB
Apr 23 03:24:37 cube kernel: L2C-310: CACHE_ID 0x41c7, AUX_CTRL 0x76070001
Apr 23 03:24:37 cube kernel: Switching to timer-based delay loop
Apr 23 03:24:37 cube kernel: sched_clock: 32 

Bug#782793: systemd: ext4 filesystem on lvm on raid causes boot to enter emergency shell

[Rick Thomas]

On Apr 21, 2015, at 11:17 AM, Michael Biebl bi...@debian.org wrote:

 If you have the sysvinit package installed,
 you can try booting with sysvinit temporarily via
 init=/lib/sysvinit/init on the kernel command line.
 
 Does that work?

I had to install sysvinit.  And I had to make up a suitable /etc/inittab file, 
but I was able to try that.

Unfortunately, it didn’t work either.  Let me know if you want to see the log 
files.

Enjoy!
Rick


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#782793: systemd: ext4 filesystem on lvm on raid causes boot to enter emergency shell

[Rick Thomas]

On Apr 23, 2015, at 2:31 PM, Michael Biebl bi...@debian.org wrote:

 Am 23.04.2015 um 21:47 schrieb Rick Thomas:
 
 On Apr 23, 2015, at 1:29 AM, Michael Biebl bi...@debian.org wrote:
 
 There might be a race somewhere, i.e. lvm2-activation(-early).service
 being run *before* mdadm has assembled the RAID.
 
 You could test this theory, be artifically delaying those two services.
 Copy them to /etc/systemd/system, and add a ExecStartPre=/bin/sleep 30
 to the [Service] section of those two units.
 
 
 So… That worked (adding a 30-second delay) twice in a row.
 
 Let me know if you want to see a log with debug turned on for such a reboot.
 
 
 Ok, I guess I have bad news then.
 lvm2 in jessie is not really hotplug aware. The
 lvm2-activation(-early).service units run at a static, fixed time during
 boot. You'd need something like lvm2's lvmetad support [1]. I tried to
 enable that in Debian today, but failed miserably due to various bugs
 (already filed 3 bugs today regarding lvmetad).
 Ultimately, this is something which needs to be fixed in lvm2 and at
 this point I don't think there is a lot more that I can do from the
 systemd side.
 
 Sorry for the unsatisfying answer.
 
 Regards,
 Michael
 
 
 
 [1]
 https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Logical_Volume_Manager_Administration/metadatadaemon.html

No reason to be sorry!

First of all, you have given me two solid work-arounds to the problem (#1 the 
30-second delay you suggested; #2 the cron reboot script I wrote based on your 
preliminary suggestions.)

Second, you have filed bug reports that (hopefully) will be a prod to get the 
real problem worked on by those folks who are able to actually fix it.

This is what the open-source philosophy is all about: Given enough eyeballs, 
all bugs are shallow!  We each contributed a pair of eyeballs to this bug.  Now 
it’s time for others to contribute theirs.

Early on, I cloned this bug as 782865 and re-assigned it to lvm2.  You may want 
to close the clone and re-assign this one to lvm2 so the folks in that part of 
the woods have access to the full record.  I’ll leave that up to you because 
you probably know more about the proper procedures and protocols than I do.

Thanks *very* much for all your patient help!

Enjoy!
Rick


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#782793: systemd: ext4 filesystem on lvm on raid causes boot to enter emergency shell

[Rick Thomas]

On Apr 22, 2015, at 8:17 AM, Michael Biebl bi...@debian.org wrote:

 Could you copy /lib/systemd/system/lvm2-activation.service to
 /etc/systemd/system and add a line
 After=mdadm-raid.service
 to the [Unit] section.

Will do.   Thanks! 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#782793: systemd: ext4 filesystem on lvm on raid causes boot to enter emergency shell

[Rick Thomas]

Hi Michael,

Thanks very much for helping me with this. (continued following quoted material)

On Apr 21, 2015, at 11:17 AM, Michael Biebl bi...@debian.org wrote:

 control: tags -1 moreinfo unreproducible
 
 Am 18.04.2015 um 02:02 schrieb Rick Thomas:
 
 On Apr 17, 2015, at 3:44 PM, Michael Biebl bi...@debian.org wrote:
 
 Thanks for the data.
 Looks like an lvm issue to me:
 
 root@cube:~# lvscan
 inactive  '/dev/vg1/backup' [87.29 GiB] inherit
 
 and as a result, /dev/disk/by-label/BACKUP is missing.
 
 Yes, that’s true, of course.  But the question is, what is keeping lvm from 
 activating the volume?
 
 It works fine for a logical volume on a single physical disk.  And 
 /proc/mdstat shows that the RAID device, /dev/md127, _is_ active.  Or, at 
 least it is when we get to emergency mode… I don’t know if it’s active when 
 the fsck times out, of course… If you know how to figure that out from the 
 systemd journal I attached to the original bug report, or any other way that 
 I can try, I’d appreciate any assistance you can give!
 
 fwiw, I tried to reproduce the problem in a VM with two additional disks
 attached and a setup like the following:
 
 ext4 on RAID1 (via mdadm)
 ext4 on LVM on RAID1 (mdadm)
 ext4 on LVM
 ext4 on dos partition.
 
 All partitions were correctly mounted during boot without any issues.
 
 
 Is this a fresh jessie installation or an upgraded system?
 Do you have any custom udev rules in /lib/udev/rules.d or /etc/udev/rules.d?
 
 If it's an upgraded system and you have the sysvinit package installed,
 you can try booting with sysvinit temporarily via
 init=/lib/sysvinit/init on the kernel command line.
 
 Does that work?

My physical setup is this:  The hardware is a quad-core armv7 Cubox i4pro ( 
https://wiki.debian.org/ArmHardFloatPort/CuBox-i )

With some help from Karsten Merker, I got a plain-vanilla — un-modified — 
Jessie installed on it to use for experimenting.  I wanted experience with the 
Cubox hardware and with using Jessie in a “real life” situation.

The boot (and system residency: root, swap, /home, /var — the works) is on a 
32GB microSD card.

I’ve added to that an eSATA 1TB hard disk (currently configured as single 
filesystem using LVM) and a 7-port USB2.0 hub with 5 of the ports each holding 
a 32GB USB-Flash stick.  Those 5 devices are configured as a software (md) 
RAID6 array (I wanted to get some experience with RAID6) providing about 90GB 
of useful space configured with LVM as a single logical volume.

It’s the RAID6 array (or rather the lv on it) that is having the problem.

I’ve managed to make it work using a cron script that runs at reboot time 
(crontab has:
@reboot bash -x bin/mount-backup
and the mount-backup script looks like this:
###
logger -s -t mount-backup 'Mounting the /backup filesystem'

(
let count=10# don’t try uselessly forever if it fails
# If it doesn’t exist, take remedial action.
while [ ! -h /dev/disk/by-label/BACKUP ]
do
let count=$count-1
[ $count -lt 1 ]  exit 1
sleep 10   # give things some time to settle
cat /proc/mdstat# show some debugging information
# see if the raid has assembled and can be used
/sbin/vgchange -ay
done

# If the fsck isn’t perfect, quit and wait for human intervention
/sbin/fsck -nf /backup  /bin/mount /backup
) | logger -s -t mount-backup
###

This works.  Interestingly, without the sleep loop the vgchange fails.

Now, you say that a VM with two virtual disks configured as RAID1 with a 
logical volume works fresh out of the box.  This makes me wonder if it’s some 
kind of a timing problem…  It takes a few seconds for the freshly rebooted 
system to find the USB-Flash sticks and assemble them.  So  some time-out is 
triggered in the systemd stuff on my setup, while your setup has no such 
physical constraints — everything is available immediately.

That’s just a guess…  But fortunately, it’s a testable guess!

My setup is (at the moment) just for experimentation and learning — no actual 
useful work.  So I can re-install it at will or make any changes I need to to 
track this down.

Your suggestion about trying sysvinit will be a good place to start.  If that 
works with my workaround script disabled, the next experiment will be to try 
systemd with a rootdelay=10.   I will also try the VM setup, just to see if I 
can replicate your result.  After that, I’m not sure — any suggestions will be 
appreciated!

I’ll get back to you when I’ve made those tests.  Real-life(TM) will probably 
prevent me from doing that before the week-end.

Enjoy!  And Thanks for all the help!

Rick


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762953: Bug still present in latest Sid -- /etc/network/interfaces

[Rick Thomas]

interfaces
Description: Binary data


This is “fresh out of the box” as it comes from the debian installer process.  
I have made no changes.

Rick


On Apr 17, 2015, at 2:57 PM, Michael Biebl bi...@debian.org wrote:

 Am 17.04.2015 um 22:49 schrieb Rick Thomas:
 
 I’ve seen this bug today.
 
 System drops into emergency mode for reasons that have nothing to do with 
 this bug.  Network is active when in emergency shell.  I type root password 
 then immediately exit, system continues to boot.  When boot is finished, 
 network is not active.
 
 system journal of full boot is attached.
 
 I assume you use ifupdown to configure your network?
 Do you use allow-hotplug or auto? Can you attach your
 /etc/network/interfaces file?
 
 Michael
 
 -- 
 Why is it that all of the instruments seeking intelligent life in the
 universe are pointed away from Earth?
 

Bug#762953: Bug still present in latest Sid

[Rick Thomas]

I’ve seen this bug today.

System drops into emergency mode for reasons that have nothing to do with this 
bug.  Network is active when in emergency shell.  I type root password then 
immediately exit, system continues to boot.  When boot is finished, network is 
not active.

system journal of full boot is attached.

Hope this helps!

Rick

-- Logs begin at Fri 2015-04-17 04:55:26 PDT, end at Fri 2015-04-17 13:39:47 
PDT. --
Apr 17 04:55:26 cube systemd-journal[163]: Runtime journal is using 5.0M (max 
allowed 40.4M, trying to leave 60.6M free of 399.0M available → current limit 
40.4M).
Apr 17 04:55:26 cube systemd-journal[163]: Runtime journal is using 5.0M (max 
allowed 40.4M, trying to leave 60.6M free of 399.0M available → current limit 
40.4M).
Apr 17 04:55:26 cube kernel: Booting Linux on physical CPU 0x0
Apr 17 04:55:26 cube kernel: Initializing cgroup subsys cpuset
Apr 17 04:55:26 cube kernel: Initializing cgroup subsys cpu
Apr 17 04:55:26 cube kernel: Initializing cgroup subsys cpuacct
Apr 17 04:55:26 cube kernel: Linux version 3.16.0-4-armmp 
(debian-ker...@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP 
Debian 3.16.7-ckt9-2 (2015-04-13)
Apr 17 04:55:26 cube kernel: CPU: ARMv7 Processor [412fc09a] revision 10 
(ARMv7), cr=10c5387d
Apr 17 04:55:26 cube kernel: CPU: PIPT / VIPT nonaliasing data cache, VIPT 
aliasing instruction cache
Apr 17 04:55:26 cube kernel: Machine model: SolidRun Cubox-i Dual/Quad
Apr 17 04:55:26 cube kernel: Memory policy: Data cache writealloc
Apr 17 04:55:26 cube kernel: On node 0 totalpages: 524288
Apr 17 04:55:26 cube kernel: free_area_init_node: node 0, pgdat c09dc700, 
node_mem_map ee7f8000
Apr 17 04:55:26 cube kernel:   DMA zone: 1520 pages used for memmap
Apr 17 04:55:26 cube kernel:   DMA zone: 0 pages reserved
Apr 17 04:55:26 cube kernel:   DMA zone: 194560 pages, LIFO batch:31
Apr 17 04:55:26 cube kernel:   HighMem zone: 2576 pages used for memmap
Apr 17 04:55:26 cube kernel:   HighMem zone: 329728 pages, LIFO batch:31
Apr 17 04:55:26 cube kernel: PERCPU: Embedded 9 pages/cpu @ee7b3000 s12608 
r8192 d16064 u36864
Apr 17 04:55:26 cube kernel: pcpu-alloc: s12608 r8192 d16064 u36864 alloc=9*4096
Apr 17 04:55:26 cube kernel: pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 
Apr 17 04:55:26 cube kernel: Built 1 zonelists in Zone order, mobility grouping 
on.  Total pages: 522768
Apr 17 04:55:26 cube kernel: Kernel command line: console=ttymxc0,115200 quiet
Apr 17 04:55:26 cube kernel: PID hash table entries: 4096 (order: 2, 16384 
bytes)
Apr 17 04:55:26 cube kernel: Dentry cache hash table entries: 131072 (order: 7, 
524288 bytes)
Apr 17 04:55:26 cube kernel: Inode-cache hash table entries: 65536 (order: 6, 
262144 bytes)
Apr 17 04:55:26 cube kernel: Memory: 2054820K/2097152K available (6404K kernel 
code, 828K rwdata, 2204K rodata, 684K init, 393K bss, 42332K reserved, 1318912K 
highmem)
Apr 17 04:55:26 cube kernel: Virtual kernel memory layout:
 vector  : 0x - 0x1000   (   4 kB)
 fixmap  : 0xffc0 - 0xffe0   (2048 kB)
 vmalloc : 0xf000 - 0xff00   ( 240 MB)
 lowmem  : 0xc000 - 0xef80   ( 760 MB)
 pkmap   : 0xbfe0 - 0xc000   (   2 MB)
 modules : 0xbf00 - 0xbfe0   (  14 MB)
   .text : 0xc0008000 - 0xc08702e4   (8609 kB)
   .init : 0xc0871000 - 0xc091c140   ( 685 kB)
   .data : 0xc091e000 - 0xc09ed3d0   ( 829 kB)
.bss : 0xc09ed3d0 - 0xc0a4f874   ( 394 kB)
Apr 17 04:55:26 cube kernel: Hierarchical RCU implementation.
Apr 17 04:55:26 cube kernel: RCU dyntick-idle grace-period acceleration 
is enabled.
Apr 17 04:55:26 cube kernel: NR_IRQS:16 nr_irqs:16 16
Apr 17 04:55:26 cube kernel: L2C-310 erratum 769419 enabled
Apr 17 04:55:26 cube kernel: L2C-310 enabling early BRESP for Cortex-A9
Apr 17 04:55:26 cube kernel: L2C-310 full line of zeros enabled for Cortex-A9
Apr 17 04:55:26 cube kernel: L2C-310 ID prefetch enabled, offset 1 lines
Apr 17 04:55:26 cube kernel: L2C-310 dynamic clock gating enabled, standby mode 
enabled
Apr 17 04:55:26 cube kernel: L2C-310 cache controller enabled, 16 ways, 1024 kB
Apr 17 04:55:26 cube kernel: L2C-310: CACHE_ID 0x41c7, AUX_CTRL 0x76070001
Apr 17 04:55:26 cube kernel: Switching to timer-based delay loop
Apr 17 04:55:26 cube kernel: sched_clock: 32 bits at 66MHz, resolution 15ns, 
wraps every 65075262448ns
Apr 17 04:55:26 cube kernel: Console: colour dummy device 80x30
Apr 17 04:55:26 cube kernel: Calibrating delay loop (skipped), value calculated 
using timer frequency.. 132.00 BogoMIPS (lpj=264000)
Apr 17 04:55:26 cube kernel: pid_max: default: 32768 minimum: 301
Apr 17 04:55:26 cube kernel: Security Framework initialized
Apr 17 04:55:26 cube kernel: 

Bug#782793: systemd: ext4 filesystem on lvm on raid causes boot to enter emergency shell

[Rick Thomas]

On Apr 17, 2015, at 3:17 PM, Michael Biebl bi...@debian.org wrote:

 Am 17.04.2015 um 23:43 schrieb Rick Thomas:
 Package: systemd
 Version: 215-16
 Severity: important
 
 When /etc/fstab has an ext4 filesystem on a logical volume which is itself
 on a software raid, the system times out waiting for (I think!) fsck on that 
 filesystem.
 This causes the boot to drop into the emergency shell.
 If I just type ^D and allow the boot to continue, the filesystem is 
 mounted but
 never fsck-ed.
 
 systemd journal of boot is attached.
 /etc/fstab is attached.
 /etc/modules is attached
 /etc/modprobe.d/mdadm.conf is attached
 /etc/mdadm/mdadm.conf is attached
 
 The filesystem in question is /backup which is on logical-volume 
 vg1-backup, which is on RAID device /dev/md127
 
 When you are dropped into emergency shell, can you get the following data
 ls -al /dev/disk/by-label
 udevadm info -e
 mdadm --info /dev/md127
 lvscan
 pvscan
 vgscan

See attached.



typescript
Description: Binary data

Bug#782793: systemd: ext4 filesystem on lvm on raid causes boot to enter emergency shell

[Rick Thomas]

On Apr 17, 2015, at 3:44 PM, Michael Biebl bi...@debian.org wrote:
 
 Thanks for the data.
 Looks like an lvm issue to me:
 
 root@cube:~# lvscan
  inactive  '/dev/vg1/backup' [87.29 GiB] inherit
 
 and as a result, /dev/disk/by-label/BACKUP is missing.

Yes, that’s true, of course.  But the question is, what is keeping lvm from 
activating the volume?

It works fine for a logical volume on a single physical disk.  And /proc/mdstat 
shows that the RAID device, /dev/md127, _is_ active.  Or, at least it is when 
we get to emergency mode… I don’t know if it’s active when the fsck times out, 
of course… If you know how to figure that out from the systemd journal I 
attached to the original bug report, or any other way that I can try, I’d 
appreciate any assistance you can give!

Thanks!
Rick

PS: In the meantime, can you do whatever magic is involved with passing this on 
the the LVM2 maintainers?  Thanks!

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#782364: Actually, it makes some sense to keep both clocks

[Rick Thomas]

Ben Hutchings indicates that his preference would be to disable the 
non-battery-backed RTC and enable the battery-backed RTC in the kernel for the 
Cubox-i4pro.

I’m not a kernel hacker, so what I’m about to say may be off the mark, but:

If I’m not mistaken, this kernel is intended to be used on the entire Cubox 
line of computers.  Only the i4Pro model has the battery-backed RTC available.  
The other models do not enable that hardware feature.  So disabling the 
non-battery-backed RTC would break those models.

I don’t know if it’s possible (without modifications to other packages) to have 
the battery-backed clock be the one pointed to by /dev/rtc (though that would 
be nice…).  However, if that’s not possible, I’m willing to configure 
/etc/default/hwclock as a workaround.

I don’t know whether the two RTCs on the Cubox-i4Pro differ in their properties 
other than battery-backed-ness — e.g. accuracy, precision, etc… But if they do, 
that would be an argument in favor of providing both in the kernel.  One may be 
good for some uses, the other for other uses.

Thanks!
Rick

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#782364: Actually, it makes some sense to keep both clocks

[Rick Thomas]

On Apr 12, 2015, at 6:10 AM, Ben Hutchings b...@decadent.org.uk wrote:

 On Sun, 2015-04-12 at 01:37 -0700, Rick Thomas wrote:
 Ben Hutchings indicates that his preference would be to disable the
 non-battery-backed RTC and enable the battery-backed RTC in the kernel
 for the Cubox-i4pro.
 
 I’m not a kernel hacker, so what I’m about to say may be off the mark,
 but:
 
 If I’m not mistaken, this kernel is intended to be used on the entire
 Cubox line of computers.  Only the i4Pro model has the battery-backed
 RTC available.  The other models do not enable that hardware feature. 
 [...]
 
 Are you saying that a single device tree is used for multiple models?
 That should not be the case.
 
 But it looks like there are only two device trees defined for Cubox, one
 for those with the i.MX6DL and one for the i.MX6Q.  Both of which enable
 both RTCs!
 
 So you're right, we can't just disable the non-battery-backed RTC for
 this one model.

Thanks for clarifying what I was trying to get at.

Looking forward to help test this!


 Ben.
 
 -- 
 Ben Hutchings
 compatible: Gracefully accepts erroneous data from any source

Rick

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#782314: fake-hwclock writes to /etc

[Rick Thomas]

Hi!

Thanks for the clarification.  I see your point.

Rick


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks

[Rick Thomas]

Package: src:linux
Version: 3.16.7-ckt7-1
Severity: wishlist
Tags: newcomer

Whenever I reset my cubox-i4Pro by disconnecting the power plug, the hardware 
real-time-clock gets
reset to midnight UTC, Dec 31, 1970.
Even though the SolidRun literature says that the i4Pro has a battery backed 
RTC.

A bit of googling reveals that this is related to the following fact (Quoted 
from the SolidRun forums)

There are two RTC inside CuBox-i 
1. One connected to the SNVS rail (internal i.MX6) which is not battery backed 
and typically goes to /dev/rtc0
2. Second is NXP PFC8523 based and that one has battery backup (/dev/rtc1)
SolidRun Engineering
user rabeeh in #cubox on Freenode IRC
by rabeeh » Sat Jan 25, 2014 7:04 pm 

It's a standard non rechargeable lithium 3.3v coin cell.
Available only on the models that has RTC.
SolidRun Engineering
user rabeeh in #cubox on Freenode IRC

Curiously, when I look at the Debian Jessie system running on the box, I find 
that there is only one /dev/rtc* device,
and that seems to be associated with the SNVS clock.  The PFC8523 clock is not 
available…

Checking /boot/config-3.16.0-4-armmp, I see what I think is an explanation, 
because

# CONFIG_RTC_DRV_PCF8523 is not set

and

CONFIG_RTC_DRV_SNVS=y

Other Linux systems (e.g. Arch) appear (according to the above mentioned 
googling) to have their kernel compiled so as to
provide both /dev/rtc0 attached to the SNVS clock, and /dev/rtc1 attached to 
the PFC8523 clock.

Would it be possible to configure the default Debian Jessie kernel to do the 
same?

Ideally, the PFC8523 clock should show up as /dev/rtc0, linked to /dev/rtc,
so that the battery backed clock is used by default to set the system clock at 
boot-time.
Failing that, it may be possible to address this by setting HCTOSYS_DEVICE in 
/etc/default/hwclock appropriately.
Or maybe one could tweak a rule in /etc/udev ?

Karsten Merker commented via email:

Yes, that should just need enabling the appropriate module.
The device-tree instantiates the pcf8523 clock chip:

i2c3 {
   pinctrl-names = default;
   pinctrl-0 = pinctrl_cubox_i_i2c3;

   status = okay;

   rtc: pcf8523@68 {
   compatible = nxp,pcf8523;
   reg = 0x68;
   };
};

So if the module is available, it should be loaded automatically.

Please file a wishlist bug against Source: linux, Version: 
3.16.7-ckt9-1 so that the kernel maintainers can enable the
module for the next kernel upload.


-- Package-specific info:
** Version:
Linux version 3.16.0-4-armmp (debian-ker...@lists.debian.org) (gcc version 
4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt7-1 (2015-03-01)

** Command line:
console=ttymxc0,115200 quiet

** Tainted: C (1024)
 * Module from drivers/staging has been loaded.

** Kernel log:
[3.659929] IR RC5(x) protocol handler initialized
[3.661235] IR SANYO protocol handler initialized
[3.682273] [drm] Initialized drm 1.1.0 20060810
[3.684385] ipu_smfc_init: ioremap 0x0265 - f05a8000
[3.685339] imx-ipuv3 240.ipu: IPUv3H probed
[3.685411] lirc_dev: IR Remote Control driver registered, major 243 
[3.685844] ipu_smfc_init: ioremap 0x02a5 - f05c2000
[3.685851] leds_pwm pwmleds: unable to request PWM for imx6:red:front: -517
[3.685879] platform pwmleds: Driver leds_pwm requests probe deferral
[3.694394] imx-ipuv3 280.ipu: IPUv3H probed
[3.722182] i2c i2c-1: IMX I2C adapter registered
[3.726369] rc rc0: lirc_dev: driver ir-lirc-codec (gpio-rc-recv) registered 
at minor = 0
[3.726389] IR LIRC bridge handler initialized
[3.735281] i2c i2c-2: IMX I2C adapter registered
[3.764961] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[3.768187] imxdrm: module is from the staging directory, the quality is 
unknown, you have been warned.
[3.769810] imxdrm: module is from the staging directory, the quality is 
unknown, you have been warned.
[3.775554] imx_hdmi: module is from the staging directory, the quality is 
unknown, you have been warned.
[3.794884] imx_ipuv3_crtc: module is from the staging directory, the 
quality is unknown, you have been warned.
[3.794888] imx_ipuv3_crtc: module is from the staging directory, the 
quality is unknown, you have been warned.
[3.794893] imx_ipuv3_crtc: module is from the staging directory, the 
quality is unknown, you have been warned.
[3.796261] imx_ipuv3_crtc: module is from the staging directory, the 
quality is unknown, you have been warned.
[3.799664] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[3.799677] [drm] No driver support for vblank timestamp query.
[3.799852] imx-drm display-subsystem: bound imx-ipuv3-crtc.0 (ops .LANCHOR0 
[imx_ipuv3_crtc])
[3.799942] imx-drm display-subsystem: bound imx-ipuv3-crtc.1 (ops .LANCHOR0 
[imx_ipuv3_crtc])
[3.800053] imx-drm display-subsystem: bound imx-ipuv3-crtc.4 (ops .LANCHOR0 
[imx_ipuv3_crtc])
[3.800140] imx-drm display-subsystem: bound 

Bug#773688: ntp: NTP version 4.2.8 is available.

[Rick Thomas]

Package: ntp
Version: 1:4.2.6.p5+dfsg-2+deb7u1
Severity: wishlist

Dear Maintainer,

NTP version 4.2.8 includes over 1000 bug fixes and new features,
including final replacement and deprecation of the ntpdc command.

We should consider upgrading.

Anything I can do to help, let me know...

-- System Information:
Debian Release: 7.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages ntp depends on:
ii  adduser  3.113+nmu3
ii  dpkg 1.16.15
ii  libc62.13-38+deb7u6
ii  libcap2  1:2.22-1.2
ii  libedit2 2.11-20080614-5
ii  libopts251:5.12-0.1
ii  libssl1.0.0  1.0.1e-2+deb7u13
ii  lsb-base 4.1+Debian8+deb7u1
ii  netbase  5.0

Versions of packages ntp recommends:
ii  perl  5.14.2-21+deb7u2

Versions of packages ntp suggests:
pn  ntp-doc  none

-- Configuration Files:
/etc/ntp.conf changed:
server base.rcthomas.org iburst
pool pool.rcthomas.org minpoll 4 maxpoll 4 prefer iburst
driftfile /var/lib/ntp/ntp.drift
statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
pool us.pool.ntp.org iburst preempt
pool ntp.sixxs.net iburst preempt
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1
restrict 192.168.0.0  mask  255.255.240.0 nomodify
restrict 2001:4978:2d2:1::0 mask ::::::: 
nomodify


-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org