Bug#1016963: Please test u-boot for sheevaplug mx6cuboxi

[Rick Thomas]

Sadly, my sheevaplug was not revivable.  I have a couple of OpenRD boxes and a 
couple of CUBox-i boxes I can test for you, as well as a RaspberryPi-4B and a 
couple of Orange-Pi boxes that can also be tested.   I'll send results as I get 
to them.

BTW, are there directions for installing and configuring the debian packages 
into firmware for these boxes?  On the few I've looked at, the firmware doesn't 
seem to have kept up with the installed .deb packages for some reason.

Thanks for all your hard work!
Rick

On Wed, Dec 28, 2022, at 4:33 PM, Vagrant Cascadian wrote:
> On 2022-12-28, Vagrant Cascadian wrote:
>> On 2022-12-22, Vagrant Cascadian wrote:
>>> On 2022-08-20, Vagrant Cascadian wrote:
 On 2022-08-10, Vagrant Cascadian wrote:
> This bug is just to delay migration to testing while more platforms get
> tested. If you have a relevent board, please consider testing and
> reporting the status:
>
>   https://wiki.debian.org/U-boot/Status
>>
>> I have not received many test results for current or even remotely
>> recent u-boot platforms in Debian, and u-boot has been blocked from
>> migration to testing partly because of this.
>>
>> As the bookworm freeze approaches, this is getting to be... worrysome!
>>
>> If you have access to any of these boards, please consider testing
>> u-boot versions as packaged in debian for versions from debian stable
>> (2021.01*), testing (2022.04*), unstable (2022.10*) and experimental
>> (2023.01-rc*) and updating the wiki page if successful and/or replying
>> to 1016...@bugs.debian.org with a positive confirmation...
>>
>> ...and if not successful, filing bugs against the relevent u-boot-*
>> packages and marking them as blocking 1016963.
>
> sheevaplug
> mx6cuboxi
>
> live well,
>   vagrant
>
> Attachments:
> * signature.asc

Bug#1016963: Help with testing u-boot!

[Rick Thomas]

Here's another Cubox-i.  This one's running Bookworm.
 shows a surprising number of u-boot- 
packages installed, ( = exynos, imx, omap, sunxi)  as well as plain 
"u-boot".  All of them are version 2022.04+dfsg-2+b1.

Rebooting while watching the serial console output says "U-Boot SPL 
2016.05-rc2+dfsg0~20160423~1-1 (Apr 24 2016 - 04:24:21)"  So the firmware does 
not correspond to what aptitude says.   

Should I try installing the "22.04" version in the firmware?   If so, are there 
directions for doing that available somewhere?

HTH
Rick

On Wed, Dec 28, 2022, at 3:21 PM, Vagrant Cascadian wrote:
> On 2022-12-22, Vagrant Cascadian wrote:
>> On 2022-08-20, Vagrant Cascadian wrote:
>>> On 2022-08-10, Vagrant Cascadian wrote:
 This bug is just to delay migration to testing while more platforms get
 tested. If you have a relevent board, please consider testing and
 reporting the status:

   https://wiki.debian.org/U-boot/Status
>
> I have not received many test results for current or even remotely
> recent u-boot platforms in Debian, and u-boot has been blocked from
> migration to testing partly because of this.
>
> As the bookworm freeze approaches, this is getting to be... worrysome!
>
> If you have access to any of these boards, please consider testing
> u-boot versions as packaged in debian for versions from debian stable
> (2021.01*), testing (2022.04*), unstable (2022.10*) and experimental
> (2023.01-rc*) and updating the wiki page if successful and/or replying
> to 1016...@bugs.debian.org with a positive confirmation...
>
> ...and if not successful, filing bugs against the relevent u-boot-*
> packages and marking them as blocking 1016963.
>
> # arm64
> khadas-vim
> khadas-vim2
> libretech-cc
> nanopi-k2
> odroid-c2
> odroid-n2
> mvebu_espressobin-88f3720
> dragonboard410c
> dragonboard820c
> firefly-rk3399
> nanopc-t4-rk3399
> nanopi-neo4-rk3399
> pinebook-pro-rk3399
> puma-rk3399
> roc-pc-rk3399
> rock-pi-4-rk3399
> rock-pi-e-rk3328
> rock64-rk3328
> rockpro64-rk3399
> rpi_3
> rpi_4
> rpi_arm64
> a64-olinuxino
> a64-olinuxino-emmc
> nanopi_neo2
> nanopi_neo_plus2
> orangepi_one_plus
> orangepi_zero_plus2
> pine64-lts
> pine64_plus
> pinebook
> pinephone
> pinetab
> sopine_baseboard
> teres_i
> p2371-2180
>
> # armel
> dockstar
> dreamplug
> guruplug
> sheevaplug
> rpi
> rpi_0_w
>
> # armhf
> arndale
> odroid
> odroid-xu3
> colibri_imx6
> dh_imx6
> mx53loco
> mx6cuboxi
> mx6qsabrelite
> nitrogen6q
> novena
> novena-rawsd
> udoo
> usbarmory
> wandboard
> am335x_boneblack
> am335x_evm
> am57xx_evm
> dra7xx_evm
> igep00x0
> nokia_rx51
> omap3_beagle
> omap4_panda
> firefly-rk3288
> rpi_2
> rpi_3_32b
> rpi_4_32b
> stm32mp157c-dk2
> A10-OLinuXino-Lime
> A10s-OLinuXino-M
> A20-OLinuXino-Lime
> A20-OLinuXino-Lime2
> A20-OLinuXino-Lime2-eMMC
> A20-OLinuXino_MICRO
> A20-OLinuXino_MICRO-eMMC
> A20-Olimex-SOM-EVB
> Bananapi
> Bananapi_M2_Ultra
> Bananapro
> CHIP
> Cubieboard
> Cubieboard2
> Cubieboard4
> Cubietruck
> Cubietruck_plus
> Lamobo_R1
> Linksprite_pcDuino
> Linksprite_pcDuino3
> Mini-X
> Sinovoip_BPI_M3
> bananapi_m2_berry
> nanopi_neo
> nanopi_neo_air
> orangepi_plus
> orangepi_zero
> jetson-tk1
>
>
> Thanks!
>
>
> live well,
>   vagrant
>
> Attachments:
> * signature.asc

Bug#1016963: Help with testing u-boot!

[Rick Thomas]

A Cubox-i running Debian bullseye (11.6).  According to  It 
has "u-boot-tools" (version 2021.01+dfsg-5) installed, but none of the 
u-boot-  packages installed.

If I reboot it and watch the serial console, I see it showing "U-boot 
2021.01-dfsg-5" so that version must have gotten into the firmware somehow 
without telling Linux about it... 
Other info that might be helpful that shows with the reboot is
CPU: Freescale i.MX6Q rev 1.3
Board: MX6 Cubox-i

HTH,
Rick

On Wed, Dec 28, 2022, at 3:21 PM, Vagrant Cascadian wrote:
> On 2022-12-22, Vagrant Cascadian wrote:
>> On 2022-08-20, Vagrant Cascadian wrote:
>>> On 2022-08-10, Vagrant Cascadian wrote:
 This bug is just to delay migration to testing while more platforms get
 tested. If you have a relevent board, please consider testing and
 reporting the status:

   https://wiki.debian.org/U-boot/Status
>
> I have not received many test results for current or even remotely
> recent u-boot platforms in Debian, and u-boot has been blocked from
> migration to testing partly because of this.
>
> As the bookworm freeze approaches, this is getting to be... worrysome!
>
> If you have access to any of these boards, please consider testing
> u-boot versions as packaged in debian for versions from debian stable
> (2021.01*), testing (2022.04*), unstable (2022.10*) and experimental
> (2023.01-rc*) and updating the wiki page if successful and/or replying
> to 1016...@bugs.debian.org with a positive confirmation...
>
> ...and if not successful, filing bugs against the relevent u-boot-*
> packages and marking them as blocking 1016963.
>
> # arm64
> khadas-vim
> khadas-vim2
> libretech-cc
> nanopi-k2
> odroid-c2
> odroid-n2
> mvebu_espressobin-88f3720
> dragonboard410c
> dragonboard820c
> firefly-rk3399
> nanopc-t4-rk3399
> nanopi-neo4-rk3399
> pinebook-pro-rk3399
> puma-rk3399
> roc-pc-rk3399
> rock-pi-4-rk3399
> rock-pi-e-rk3328
> rock64-rk3328
> rockpro64-rk3399
> rpi_3
> rpi_4
> rpi_arm64
> a64-olinuxino
> a64-olinuxino-emmc
> nanopi_neo2
> nanopi_neo_plus2
> orangepi_one_plus
> orangepi_zero_plus2
> pine64-lts
> pine64_plus
> pinebook
> pinephone
> pinetab
> sopine_baseboard
> teres_i
> p2371-2180
>
> # armel
> dockstar
> dreamplug
> guruplug
> sheevaplug
> rpi
> rpi_0_w
>
> # armhf
> arndale
> odroid
> odroid-xu3
> colibri_imx6
> dh_imx6
> mx53loco
> mx6cuboxi
> mx6qsabrelite
> nitrogen6q
> novena
> novena-rawsd
> udoo
> usbarmory
> wandboard
> am335x_boneblack
> am335x_evm
> am57xx_evm
> dra7xx_evm
> igep00x0
> nokia_rx51
> omap3_beagle
> omap4_panda
> firefly-rk3288
> rpi_2
> rpi_3_32b
> rpi_4_32b
> stm32mp157c-dk2
> A10-OLinuXino-Lime
> A10s-OLinuXino-M
> A20-OLinuXino-Lime
> A20-OLinuXino-Lime2
> A20-OLinuXino-Lime2-eMMC
> A20-OLinuXino_MICRO
> A20-OLinuXino_MICRO-eMMC
> A20-Olimex-SOM-EVB
> Bananapi
> Bananapi_M2_Ultra
> Bananapro
> CHIP
> Cubieboard
> Cubieboard2
> Cubieboard4
> Cubietruck
> Cubietruck_plus
> Lamobo_R1
> Linksprite_pcDuino
> Linksprite_pcDuino3
> Mini-X
> Sinovoip_BPI_M3
> bananapi_m2_berry
> nanopi_neo
> nanopi_neo_air
> orangepi_plus
> orangepi_zero
> jetson-tk1
>
>
> Thanks!
>
>
> live well,
>   vagrant
>
> Attachments:
> * signature.asc

Bug#1016963: Help with testing u-boot!

[Rick Thomas]

Raspberry Pi 4B (8GB) running bullseye, but does not seem to have any version 
of u-boot installed.  Weird?
Running   tells me that the following (among 
lots of others) versions are available.  Should I install one of them and see 
what happens?

Package u-boot-rpi:
p  2021.01+dfsg-5 stable 500

Package u-boot-rpi:armhf:
p  2021.01+dfsg-5 stable 500

HTH
Rick

Bug#985196: haveged: OpenRD "client" ( arch = armv5tel ) Upgraded from Buster to Bullseye and haveged stoped working

[Rick Thomas]

On Sun, 14 Mar 2021 00:39:40 -0800 Rick Thomas  wrote:
> Package: haveged
> Version: 1.9.14-1
> Severity: normal
> 
> Dear Maintainer,
> 
> I recently updated my OpenRD "client" ( arch = armv5tel ) from Buster to 
> Bullseye and now haveged crashes.
> 

I tried Dave Holland’s proposed workaround and it still doesn’t work — Any 
suggestions?

rbthomas@sheeva:~$ systemctl status haveged -n 100
* haveged.service - Entropy Daemon based on the HAVEGE algorithm
 Loaded: loaded (/lib/systemd/system/haveged.service; enabled; vendor 
preset: enabled)
 Active: failed (Result: signal) since Wed 2022-06-29 04:56:35 PDT; 2min 
13s ago
   Docs: man:haveged(8)
 http://www.issihosts.com/haveged/
Process: 14464 ExecStart=/usr/sbin/haveged --Foreground --verbose=1 
$DAEMON_ARGS (code=killed, signal=SYS)
   Main PID: 14464 (code=killed, signal=SYS)
CPU: 248ms

Jun 29 04:56:35 sheeva systemd[1]: haveged.service: Scheduled restart job, 
restart counter is at 5.
Jun 29 04:56:35 sheeva systemd[1]: Stopped Entropy Daemon based on the HAVEGE 
algorithm.
Jun 29 04:56:35 sheeva systemd[1]: haveged.service: Start request repeated too 
quickly.
Jun 29 04:56:35 sheeva systemd[1]: haveged.service: Failed with result 'signal'.
Jun 29 04:56:35 sheeva systemd[1]: Failed to start Entropy Daemon based on the 
HAVEGE algorithm.
rbthomas@sheeva:~$ 
rbthomas@sheeva:~$ cat /etc/systemd/system/haveged.service.d/override.conf
[Service]
SystemCallFilter=uname

rbthomas@sheeva:~$ ls -l /etc/systemd/system/haveged.service.d/override.conf
-rw-r--r-- 1 root root 34 Jun 29 04:56 
/etc/systemd/system/haveged.service.d/override.conf

rbthomas@sheeva:~$ uname -a
Linux sheeva 5.10.0-15-marvell #1 Debian 5.10.120-1 (2022-06-09) armv5tel 
GNU/Linux
rbthomas@sheeva:~$ arch
armv5tel

rbthomas@sheeva:~$ aptitude versions haveged
i   1.9.14-1   stable   500 

Thanks!
Rick

Bug#934072: OpenRD images are gone

[Rick Thomas]

Short story:
Works a treat!

Longer story:
 Details will have to wait (it's 3AM right now) but to keep it short -- I 
put the two uI* files (ignored the .dtb file) onto an ext2 partition of a USB 
stick.  Followed the instructions on Martin's page, and successfully installed 
back to the same USB stick (a trick I've used frequently in the past).  System 
booted and ran just fine.

Next test:
1) Install from/to a uSD card
2) Install from a uSD card to an eSATA disk drive --leaving the /boot 
partition on the uSD.
3) Anything else you might want to try?

Detail:
The u-boot version that's on the "ultimate" is 
=> version
U-Boot 2016.11+dfsg1-4~20170308~1 (Mar 09 2017 - 01:27:49 +)
OpenRD-Ultimate
arm-linux-gnueabi-gcc (Debian 6.3.0-8) 6.3.0 20170221
GNU ld (GNU Binutils for Debian) 2.28
=> 
So it's not current, but it's also not the ancient original from 2011.  

Enjoy!
Rick

Bug#934072: OpenRD images are gone

[Rick Thomas]

On Wed, Jun 22, 2022, at 7:27 AM, Cyril Brulebois wrote:
>> (If it builds, can you upload the images somewhere so Rick can test
>> them?)
>
> Sure, that was the plan all along.
>
> https://people.debian.org/~kibi/openrd4bullseye/ has the tarball after a
> full debian-installer build (it'll stay there until it's superseded by
> another attempt if required, or until that ends up being published in a
> point release).

Great!  Thanks!  Now for testing: what exactly should I do with this tar-ball? 
I've been relying on Martin's instruction page at 
https://www.cyrius.com/debian/kirkwood/openrd/install/ which only mentions 
downloading two files (uImage and uInitrd) and putting them on a fat or ext2 
USB-stick or MMC-card.

Downloading the tar-ball and un-tar-ing it I see there's a uImage and uInitrd 
file for ultimate, but there's also a .dtb file?  Should I include it on the 
USB-stick as well?  Is there anything else in the tar-ball I should be paying 
attention to?

I'm hoping to do preliminary testing tonight.  If I don't hear back before then 
(about midnight Pacific Daylight time) I'll go ahead and put all three files on 
a USB-stick and see what happens...

Enjoy!
Rick

Bug#934072: OpenRD images are gone

[Rick Thomas]

Hi all,

This has suddenly had it's priority raised a bit for me.  I was fiddling around 
with my Ultimate OpenRD, and I managed to render the boot disk un-bootable.  
I'd like to re-install with either Bullseye or Bookworm (Prior to my fumble 
fingers, it was happily running Bullseye via upgrade from Buster and probably 
Stretch back before that).  Ideally, I'd like to try Bookworm, but if that's 
not possible, I'll be happy with Bullseye.

Do you think it's possible to make the install stuff for the OpenRD's sometime 
soon?

Thanks very much!
Rick

On Wed, Jun 8, 2022, at 10:25 PM, Martin Michlmayr wrote:
> Vagrant, see below:
>
> * Martin Michlmayr  [2019-08-06 20:10]:
>> I noticed that there are no pre-built images for OpenRD in buster
>> anymore.
>> 
>> I found:
>> 
>> commit e799d626f45e9c706d05003e3112d481db2870a9
>> Author: Vagrant Cascadian 
>> Date:   Wed Dec 5 17:45:22 2018 +0100
>> 
>> [armel] Disable OpenRD targets, no longer present in u-boot.
>> 
>> While it's true that there are no u-boot images for OpenRD anymore,
>> I think the installer and kernel should still work fine (people can
>> install u-boot from stretch or even use the Marvell u-boot that ships
>> with the device).
>> 
>> I think the part of the commit above that removed openrd from
>> build/config/armel/kirkwood/netboot.cfg should be reverted.
>> (the change to build/boot/arm/armel-kirkwood-u-boot-image-config
>> is obviously fine)
>> 
>> I don't have an OpenRD anymore but I can probably find someone if
>> testing is required.
>
> I became aware recently that this was never fixed.  Rick Thomas has
> two OpenRD (Ultimate and Client) and could test the images.
>
> Since bullseye is the last release to support these devices (I think?
> I never know what the status of armel is), I wonder if it would make
> sense to add the images back to d-i in a point release.
>
> Basically to revert the change to build/config/armel/kirkwood/netboot.cfg
> from commit e799d626f45e9c706d05003e3112d481db2870a9
>
> Vagrant, do you think you could do a bullseye d-i checkout, make that
> change and make the OpenRD images available for Rick to test?
> (I don't have any ARM machines)
>
> -- 
> Martin Michlmayr
> https://www.cyrius.com/

Bug#982270: Re Bug#982270 (installer can not find an ehternet driver for CuBox-i4Pro)

[Rick Thomas]

> Pushed a fix to git:
> 
> https://salsa.debian.org/kernel-team/linux/-/commit/f952b94621847732b3ed96a74babb89b6a1862f6

Wow!  Thanks!  At least I now know I'm not crazy...  Any idea how long it will 
be before the fix is in something I can download and install with?

Enjoy!
Rick

Bug#989645: /usr/sbin/grub-mkconfig: dpkg: error processing package linux-image-powerpc (--configure):

[Rick Thomas]

On Wed, Jun 9, 2021, at 3:15 AM, John Paul Adrian Glaubitz wrote:
> Control: severity -1 normal
> 
> Hello Rick!
> 
> On 6/9/21 11:15 AM, Rick Thomas wrote:
> > Package: grub-common
> > Version: 2.04-18
> > Severity: grave
> > File: /usr/sbin/grub-mkconfig
> > Justification: renders package unusable
> 
> Since powerpc is not a release architecture, setting the severity to 
> "grave" is not
> allowed here. I am therefore downgrading this to "normal".
> 

Got it.  Thanks for the info!

> > This is what happens when I attempt to do "aptitude full-upgrade" on my 
> > PowerPC machine:
> > 
> > root@dillserver:/home/rbthomas# aptitude full-upgrade
> > The following partially installed packages will be configured:
> >   linux-image-5.10.0-7-powerpc linux-image-powerpc 
> > No packages will be installed, upgraded, or removed.
> > 0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> > Need to get 0 B of archives. After unpacking 0 B will be used.
> > Setting up linux-image-5.10.0-7-powerpc (5.10.40-1) ...
> > /etc/kernel/postinst.d/initramfs-tools:
> > update-initramfs: Generating /boot/initrd.img-5.10.0-7-powerpc
> > /etc/kernel/postinst.d/zz-update-grub:
> > /usr/sbin/grub-mkconfig: 257: cannot create /boot/grub/grub.cfg.new: 
> > Read-only file system
> 
> Your HFS filesystem on /boot/grub is read-only. This is not related to GRUB 
> but
> to either your custom environment or something in the partitioning setup in 
> d-i
> that I need to fix.
> 
> Adrian

This happened on two machines (a G5 Mac and a G4 Mac), both of which were 
originally installed from the respective NETINST-1 iso from 2021-02-02.  For 
specificity, here are the checksums of the iso images:

9745c507771d6066546146c3d33755ac3b1ca0d4d489647d6a07da38c9612bfc  
debian-10.0.0-powerpc-NETINST-1.iso
cf357436e812b50ee8c381abf61c0f7ff634c5bdfd18f4ea8b55a4230a657f00  
debian-10.0.0-ppc64-NETINST-1.iso

I have run occasional (roughly weekly) "aptitude update ; aptitude 
full-upgrade" on each of them since installation.

I did nothing to affect the read-write-ability of /boot/grub on either of them. 
 So I'm guessing this is a bug you need to fix?

What can I do to help?  (Both of these machines exist at the moment solely to 
assist in testing your efforts, so I would have no problem re-installing either 
or both if that would help.)

Thanks for all your work!
Rick

Bug#989645: /usr/sbin/grub-mkconfig: dpkg: error processing package linux-image-powerpc (--configure):

[Rick Thomas]

Package: grub-common
Version: 2.04-18
Severity: grave
File: /usr/sbin/grub-mkconfig
Justification: renders package unusable
X-Debbugs-Cc: debian-powe...@lists.debian.org, glaub...@physik.fu-berlin.de, 
rbtho...@pobox.com

This is what happens when I attempt to do "aptitude full-upgrade" on my PowerPC 
machine:

root@dillserver:/home/rbthomas# aptitude full-upgrade
The following partially installed packages will be configured:
  linux-image-5.10.0-7-powerpc linux-image-powerpc 
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
Setting up linux-image-5.10.0-7-powerpc (5.10.40-1) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-5.10.0-7-powerpc
/etc/kernel/postinst.d/zz-update-grub:
/usr/sbin/grub-mkconfig: 257: cannot create /boot/grub/grub.cfg.new: Read-only 
file system
run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 2
dpkg: error processing package linux-image-5.10.0-7-powerpc (--configure):
 installed linux-image-5.10.0-7-powerpc package post-installation script 
subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of linux-image-powerpc:
 linux-image-powerpc depends on linux-image-5.10.0-7-powerpc (= 5.10.40-1); 
however:
  Package linux-image-5.10.0-7-powerpc is not configured yet.

dpkg: error processing package linux-image-powerpc (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 linux-image-5.10.0-7-powerpc
 linux-image-powerpc
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up linux-image-5.10.0-7-powerpc (5.10.40-1) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-5.10.0-7-powerpc
/etc/kernel/postinst.d/zz-update-grub:
/usr/sbin/grub-mkconfig: 257: cannot create /boot/grub/grub.cfg.new: Read-only 
file system
run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 2
dpkg: error processing package linux-image-5.10.0-7-powerpc (--configure):
 installed linux-image-5.10.0-7-powerpc package post-installation script 
subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of linux-image-powerpc:
 linux-image-powerpc depends on linux-image-5.10.0-7-powerpc (= 5.10.40-1); 
however:
  Package linux-image-5.10.0-7-powerpc is not configured yet.

dpkg: error processing package linux-image-powerpc (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 linux-image-5.10.0-7-powerpc
 linux-image-powerpc
 
-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/dill-root / ext4 rw,relatime,errors=remount-ro 0 0
/dev/mapper/dill-home /home ext4 rw,relatime 0 0
/dev/sda3 /boot ext2 rw,relatime 0 0
/dev/sda2 /boot/grub hfs ro,relatime,uid=0,gid=0 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_apple
insmod lvm
insmod ext2
set 
root='lvmid/KyeuOm-Fceg-PCoI-LcmV-eVLL-RnL7-Xh0WT4/Ut9qE2-72vC-tTDE-XyVH-6Z0i-GXy3-lyyiCh'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 
--hint='lvmid/KyeuOm-Fceg-PCoI-LcmV-eVLL-RnL7-Xh0WT4/Ut9qE2-72vC-tTDE-XyVH-6Z0i-GXy3-lyyiCh'
  9151f254-2918-4435-bd1c-9a0e70edfdf7
else
  search --no-floppy --fs-uuid --set=root 9151f254-2918-4435-bd1c-9a0e70edfdf7
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set 

Bug#982270: Re Bug#982270 (installer can not find an ehternet driver for CuBox-i4Pro)

[Rick Thomas]

On Tue, Jun 1, 2021, at 11:06 PM, Vagrant Cascadian wrote:
> On 2021-06-01, Rick Thomas wrote:
> > Is there any estimate of when the assumed fix (linux/5.10.40-1) will
> > show up in the installer at [1] ?  I'd love to test it!
> ...
> > [1] https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/
> 
> It should already be there kernel version 5.10.38-1 had it, 5.10.40-1
> should also have it.
> 
> I only tested it outside of debian-installer (e.g. upgrading kernel on
> an already installed system), so it is also possible that more modules
> are needed in one of the kernel udebs used by the installer, or that
> you're experiencing a different issue from the one that was fixed. I'll
> try to test debian-installer on Cubox-i4pro to see if I still have an
> issue.

Hmmm... Here's a log from the serial console while trying to use the above card 
image.  Best way to read it is with "less -r".
It does appear that the 5.10.40-1 kernel is being used by the installer.  But 
it still has the problem... 

Hope it helps!
Let me know if there's anything else I can provide that might help!

Rick


screenlog
Description: Binary data

Bug#982270: Re Bug#982270 (installer can not find an ehternet driver for CuBox-i4Pro)

[Rick Thomas]

Hi!
Is there any estimate of when the assumed fix (linux/5.10.40-1) will show up in 
the installer at [1] ?  I'd love to test it!
Failing that, is there some other place I can get an installer SDcard image 
with that fix?

Thanks!   Rick

[1] https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/

Bug#982270: linux: [armhf] several imx6 systems unable to detect ethernet

[Rick Thomas]

I neglected to mention that my test machine here is a SolidRun CuBox i4Pro (2 
GB RAM) model # I4P-300D .

What can I do to help debug this?
And again: Can anyone suggest which of the ethernet drivers to try in the long 
list it says is available?

Thanks,
Rick

On Sun, May 30, 2021, at 4:52 PM, Rick Thomas wrote:
> I just tried this using the two-part uSD-card image at [1].  The 
> problem is still present.  Can anyone suggest which of the ethernet 
> drivers to try in the long list it says is available?
> 
> Thanks!
> Rick
> 
> [1] https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/
>  date: 2021-05-30 00:09
> 
> 
> 
> On Thu, Feb 11, 2021, at 10:56 AM, Vagrant Cascadian wrote:
> > Control: reassign 982270 linux
> > Control: retitle 982270 linux: [armhf] several imx6 systems unable to 
> > detect ethernet
> > Control: found 982270 5.10.13-1
> > 
> > On 2021-02-07, Rick Thomas wrote:
> > > It booted fine but when it got to the "Detect network hardware" phase, 
> > > it failed and said:
> > >
> > >> No Ethernet card was detected. If you know the name of the driver 
> > >> needed by your Ethernet card, you can select it from the list. 
> > >> Driver needed by your Ethernet card:  
> > 
> > I can confirm this is an issue on hummingboard-i2ex, cubox-i4x4 and
> > wandboard quad, all of which are similar imx6 systems, and all of which
> > use the SoC's gigabit ethernet interface.
> > 
> > I've had better luck with linux 5.9.x and 4.19.x versions, although
> > possibly backported patches on the stable branches may also trigger
> > similar issues, just not consistantly. 5.10.x seems to consistantly
> > result in no working ethernet interface.
> > 
> > Marked as found in 5.10.13-1, but I believe this affects all 5.10.x
> > versions I have seen.
> > 
> > Possibly related to changes to the mdio interface infrastructure, but
> > this pretty much needs someone to able take the time to git bisect and
> > boot test the issue...
> > 
> > 
> > live well,
> >   vagrant
> > 
> > 
> > > ==
> > > Installer hardware-summary:
> > > ==
> > > uname -a: Linux cube 4.19.0-13-armmp #1 SMP Debian 4.19.160-2 
> > > (2020-11-28) armv7l 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.19.0-13-armmp ehci_hcd
> > > usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver 
> > > hub
> > > usb-list: 
> > > usb-list: Bus 02 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.19.0-13-armmp ehci_hcd
> > > usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver 
> > > hub
> > > lsmod: Module  Size  Used by
> > > lsmod: dm_mod122880  9
> > > lsmod: md_mod143360  0
> > > lsmod: jfs   184320  0
> > > lsmod: btrfs1241088  0
> > > lsmod: libcrc32c  16384  1 btrfs
> > > lsmod: xor16384  1 btrfs
> > > lsmod: zstd_decompress61440  1 btrfs
> > > lsmod: zstd_compress 159744  1 btrfs
> > > lsmod: xxhash 20480  2 zstd_compress,zstd_decompress
> > > lsmod: zlib_deflate   28672  1 btrfs
> > > lsmod: raid6_pq   98304  1 btrfs
> > > lsmod: vfat   24576  0
> > > lsmod: fat73728  1 vfat
> > > lsmod: ext4  618496  3
> > > lsmod: crc16  16384  1 ext4
> > > lsmod: mbcache16384  1 ext4
> > > lsmod: jbd2  102400  1 ext4
> > > lsmod: crc32c_generic 16384  6
> > > lsmod: fscrypto   28672  1 ext4
> > > lsmod: ecb16384  0
> > > lsmod: brcmfmac  253952  0
> > > lsmod: brcmutil   16384  1 brcmfmac
> > > lsmod: cfg80211  548864  1 brcmfmac
> > > lsmod: rfkill 28672  1 cfg80211
> > > lsmod: usb_storage53248  0
> > > lsmod: sd_mod 49152  3
> > &g

Bug#982270: linux: [armhf] several imx6 systems unable to detect ethernet

[Rick Thomas]

I just tried this using the two-part uSD-card image at [1].  The problem is 
still present.  Can anyone suggest which of the ethernet drivers to try in the 
long list it says is available?

Thanks!
Rick

[1] https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/
 date: 2021-05-30 00:09



On Thu, Feb 11, 2021, at 10:56 AM, Vagrant Cascadian wrote:
> Control: reassign 982270 linux
> Control: retitle 982270 linux: [armhf] several imx6 systems unable to 
> detect ethernet
> Control: found 982270 5.10.13-1
> 
> On 2021-02-07, Rick Thomas wrote:
> > It booted fine but when it got to the "Detect network hardware" phase, 
> > it failed and said:
> >
> >> No Ethernet card was detected. If you know the name of the driver 
> >> needed by your Ethernet card, you can select it from the list. 
> >> Driver needed by your Ethernet card:  
> 
> I can confirm this is an issue on hummingboard-i2ex, cubox-i4x4 and
> wandboard quad, all of which are similar imx6 systems, and all of which
> use the SoC's gigabit ethernet interface.
> 
> I've had better luck with linux 5.9.x and 4.19.x versions, although
> possibly backported patches on the stable branches may also trigger
> similar issues, just not consistantly. 5.10.x seems to consistantly
> result in no working ethernet interface.
> 
> Marked as found in 5.10.13-1, but I believe this affects all 5.10.x
> versions I have seen.
> 
> Possibly related to changes to the mdio interface infrastructure, but
> this pretty much needs someone to able take the time to git bisect and
> boot test the issue...
> 
> 
> live well,
>   vagrant
> 
> 
> > ==
> > Installer hardware-summary:
> > ==
> > uname -a: Linux cube 4.19.0-13-armmp #1 SMP Debian 4.19.160-2 (2020-11-28) 
> > armv7l 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.19.0-13-armmp ehci_hcd
> > usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver 
> > hub
> > usb-list: 
> > usb-list: Bus 02 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.19.0-13-armmp ehci_hcd
> > usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver 
> > hub
> > lsmod: Module  Size  Used by
> > lsmod: dm_mod122880  9
> > lsmod: md_mod143360  0
> > lsmod: jfs   184320  0
> > lsmod: btrfs1241088  0
> > lsmod: libcrc32c  16384  1 btrfs
> > lsmod: xor16384  1 btrfs
> > lsmod: zstd_decompress61440  1 btrfs
> > lsmod: zstd_compress 159744  1 btrfs
> > lsmod: xxhash 20480  2 zstd_compress,zstd_decompress
> > lsmod: zlib_deflate   28672  1 btrfs
> > lsmod: raid6_pq   98304  1 btrfs
> > lsmod: vfat   24576  0
> > lsmod: fat73728  1 vfat
> > lsmod: ext4  618496  3
> > lsmod: crc16  16384  1 ext4
> > lsmod: mbcache16384  1 ext4
> > lsmod: jbd2  102400  1 ext4
> > lsmod: crc32c_generic 16384  6
> > lsmod: fscrypto   28672  1 ext4
> > lsmod: ecb16384  0
> > lsmod: brcmfmac  253952  0
> > lsmod: brcmutil   16384  1 brcmfmac
> > lsmod: cfg80211  548864  1 brcmfmac
> > lsmod: rfkill 28672  1 cfg80211
> > lsmod: usb_storage53248  0
> > lsmod: sd_mod 49152  3
> > lsmod: ahci_imx   20480  2
> > lsmod: libahci_platform   20480  1 ahci_imx
> > lsmod: libahci32768  2 libahci_platform,ahci_imx
> > lsmod: libata208896  3 libahci_platform,libahci,ahci_imx
> > lsmod: scsi_mod  196608  3 sd_mod,usb_storage,libata
> > lsmod: sdhci_esdhc_imx24576  0
> > lsmod: sdhci_pltfm16384  1 sdhci_esdhc_imx
> > lsmod: sdhci  53248  2 sdhci_pltfm,sdhci_esdhc_imx
> > lsmod: ci_hdrc_imx16384  0
> > lsmod: ci_hdrc45056  1 ci_hdrc_imx
> > lsmod: ulpi   16384  1 ci_hdrc
> > lsmod: ehci_hcd   77824  1 ci_hdrc
> > lsmod: udc_core

Bug#785419: Bug#855203: hwclock-set: Synchronize from hwclock despite systemd presence

[Rick Thomas]

On Sat, May 8, 2021, at 12:02 PM, Salvatore Bonaccorso wrote:
> Control: tags -1 + moreinfo
> 
> Hi,
> 
> Ist this still an issue or has been fixed in meanwhile? I'm going
> through some older src:linux associated buts and noticed that it was
> considered here to reassign it to util-linux.
> 
> Is the problem still present?
> 
> Further:
> 
> On Fri, Mar 17, 2017 at 07:55:31PM +0100, Lukas Wunner wrote:
> [...]
> > @Rick Thomas: Could you verify if the attached patch solves this issue
> > for you?
> 
> Were you able to test the proposed patch?
> 
> Regards,
> Salvatore

Thanks for following up on this!

No, I got side-tracked by a family medical issue (now all resolved and OK) and 
never was able to test the patches.  Sorry!

Nevertheless, I can verify that the problem _is_ still with us.  I'm running

rbthomas@cube:~$ uname -a
Linux cube 4.19.0-16-armmp #1 SMP Debian 4.19.181-1 (2021-03-19) armv7l 
GNU/Linux
rbthomas@cube:~$ cat /etc/debian_version 
10.9

on a Cubox-i4Pro.   It still shows as having two RealTime clocks.  The one 
named /dev/rtc0 still looses it's time when I unplug/replug the device, while 
/dev/rtc1 still does manage to carry-over.  Unfortunately, the kernel still 
uses rtc0 to set system time when rebooting.

The workaround I use (such as it is) is to run ntpsec with the "-g" option, 
which allows the first system clock adjustment to be more than 1000 seconds. ( 
I also have to remember to reset rtc0 after a power outage.)

Along the same lines, I recently got a Raspberry Pi4B 4GB, and was somewhat 
surprised to find that it did not have a RT clock at all unless you buy an 
add-on hat for it.  So we not only have to deal with devices with two RT 
clocks, but also devices with zero RT clocks.

I'm not much of a software developer, so if you want me to test something, 
please provide it in the form of a ".deb" that I can install,  rather than a 
set of patches I have to apply.

Thanks!
Rick

Bug#741663: G4 MDD report (finally) Re: Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly

[Rick Thomas]

Here's the data from the G4 MDD.  Sorry for the delay getting it out!

rbthomas@macswell:~$ cat /proc/cpuinfo 
processor   : 0
cpu : 7455, altivec supported
clock   : 1416.61MHz
revision: 3.3 (pvr 8001 0303)
bogomips: 83.31

processor   : 1
cpu : 7455, altivec supported
clock   : 1416.61MHz
revision: 3.3 (pvr 8001 0303)
bogomips: 83.31

total bogomips  : 166.63
timebase: 41659125
platform: PowerMac
model   : PowerMac3,6
machine : PowerMac3,6
motherboard : PowerMac3,6 MacRISC3 Power Macintosh
detected as : 129 (PowerMac G4 Windtunnel)
pmac flags  : 0010
L2 cache: 256K unified
pmac-generation : NewWorld
Memory  : 2048 MB

rbthomas@macswell:~$ cat /proc/version 
Linux version 5.10.0-6-powerpc-smp (debian-ker...@lists.debian.org) (gcc-10 
(Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 
SMP Debian 5.10.28-1 (2021-04-09)

rbthomas@macswell:~$ lsmod | grep wind
therm_windtunnel7229  0

The fans come on at low speed when I give the CPU a short workout.  I haven't 
tried a long-term CPU intensive task yet.

Hope this helps!
Rick

On Tue, Apr 27, 2021, at 3:55 PM, Rick Thomas wrote:
> 
> 
> On Tue, Apr 27, 2021, at 12:15 AM, John Paul Adrian Glaubitz wrote:> 
> > On 4/27/21 8:54 AM, Rick Thomas wrote:
> > > I'll look around and see if I have any MDD (mirror drive door -- the type 
> > > in the
> > > original bugreport) machines.  If so, I'll try to find some time to 
> > > install Adrian's
> > > latest and report back.
> > 
> > OK, thank you. Maybe someone else with a machine that previously had 
> > this issue can also
> > comment so that we can be sure the issue has been fixed.
> > 
> > Rick, maybe you can check whether the windfarm module(s) get(s) loaded 
> > on your machine?
> > 
> > # lsmod |grep windfarm
> 
> On the G4 (which is _not_ the MDD) I get nothing from that
> 
> On the G5 I get:
> 
> rbthomas@kmac:~$ lsmod | grep wind
> windfarm_smu_sat8626  0
> windfarm_ad7417_sensor 7755  0
> windfarm_fcu_controls12227  0
> windfarm_cpufreq_clamp 3881  0
> windfarm_pm72  14329  0
> windfarm_pid3256  1 windfarm_pm72
> windfarm_lm75_sensor 5350  0
> windfarm_max6690_sensor 4600  0
> windfarm_core  11920  7 
> windfarm_cpufreq_clamp,windfarm_fcu_controls,windfarm_max6690_sensor,windfarm_smu_sat,windfarm_ad7417_sensor,windfarm_pm72,windfarm_lm75_sensor
> 
> Hope that helps.
> Rick
> 
> PS: I do have a MDD, but I haven't yet tried Adrian's latest on it.  
> Maybe later today, maybe it'll have to wait for the weekend.
> 

Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly

[Rick Thomas]

Hi William!

On Thu, Apr 29, 2021, at 11:05 AM, William Bonnet wrote:
> > The PowerMac G5 users on this list are kindly asked to confirm the bug
> > has been fixed. Until then, I'll reopen it.
> 
> I am running the latest version (5.10.0-6-sparc64-smp #1 SMP Debian
> 5.10.28-1 (2021-04-09) sparc64) from the ports repo and it runs ok on two 
> G5

Thanks for the report.

Can you run this: "lsmod | grep wind" (without the quotes) on one or both of 
the G5s, and report the results back here?

Thanks!
Rick

Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly

[Rick Thomas]

On Tue, Apr 27, 2021, at 12:15 AM, John Paul Adrian Glaubitz wrote:> 
> On 4/27/21 8:54 AM, Rick Thomas wrote:
> > I'll look around and see if I have any MDD (mirror drive door -- the type 
> > in the
> > original bugreport) machines.  If so, I'll try to find some time to install 
> > Adrian's
> > latest and report back.
> 
> OK, thank you. Maybe someone else with a machine that previously had 
> this issue can also
> comment so that we can be sure the issue has been fixed.
> 
> Rick, maybe you can check whether the windfarm module(s) get(s) loaded 
> on your machine?
> 
> # lsmod |grep windfarm

On the G4 (which is _not_ the MDD) I get nothing from that

On the G5 I get:

rbthomas@kmac:~$ lsmod | grep wind
windfarm_smu_sat8626  0
windfarm_ad7417_sensor 7755  0
windfarm_fcu_controls12227  0
windfarm_cpufreq_clamp 3881  0
windfarm_pm72  14329  0
windfarm_pid3256  1 windfarm_pm72
windfarm_lm75_sensor 5350  0
windfarm_max6690_sensor 4600  0
windfarm_core  11920  7 
windfarm_cpufreq_clamp,windfarm_fcu_controls,windfarm_max6690_sensor,windfarm_smu_sat,windfarm_ad7417_sensor,windfarm_pm72,windfarm_lm75_sensor

Hope that helps.
Rick

PS: I do have a MDD, but I haven't yet tried Adrian's latest on it.  Maybe 
later today, maybe it'll have to wait for the weekend.

Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly

[Rick Thomas]

On Mon, Apr 26, 2021, at 10:45 PM, John Paul Adrian Glaubitz wrote:
> On 4/27/21 2:07 AM, Rick Thomas wrote:
> > I've got the latest (Apr 17) running on my G5 right now.  No problems.
> 
> Rick, you should just confirm that this particular problem is fixed but I 
> assume
> that this is the case?

I've got a PowerMac G5 running the latest install from Adrian.  It does not 
have any problem with fans running at high speed for prolonged time.

rbthomas@kmac:~$ cat /proc/version ; cat /proc/cpuinfo
Linux version 5.10.0-6-powerpc64 (debian-ker...@lists.debian.org) (gcc-10 
(Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 
SMP Debian 5.10.28-1 (2021-04-09)
processor   : 0
cpu : PPC970FX, altivec supported
clock   : 2000.00MHz
revision: 3.0 (pvr 003c 0300)

processor   : 1
cpu : PPC970FX, altivec supported
clock   : 2000.00MHz
revision: 3.0 (pvr 003c 0300)

timebase: 
platform: PowerMac
model   : PowerMac7,3
machine : PowerMac7,3
motherboard : PowerMac7,3 MacRISC4 Power Macintosh 
detected as : 336 (PowerMac G5)
pmac flags  : 
L2 cache: 512K unified
pmac-generation : NewWorld

Looking at the original bugreport, this in not the type of machine about which 
the report was filed.

I also have a PowerMac G4 Silver running the 32-bit install from Feb  2, 2021 
from Adrian.  It also does not have any problem with fans running at high speed.

rbthomas@dillserver:~$ cat /proc/version ; cat /proc/cpuinfo
Linux version 5.10.0-6-powerpc (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 Debian 
5.10.28-1 (2021-04-09)
processor   : 0
cpu : 7410, altivec supported
temperature : 38-40 C (uncalibrated)
clock   : 533.32MHz
revision: 1.3 (pvr 800c 1103)
bogomips: 66.58

timebase: 33290001
platform: PowerMac
model   : PowerMac3,4
machine : PowerMac3,4
motherboard : PowerMac3,4 MacRISC2 MacRISC Power Macintosh
detected as : 69 (PowerMac G4 Silver)
pmac flags  : 0010
L2 cache: 1024K unified
pmac-generation : NewWorld
Memory  : 1536 MB

Unfortunately, this is also not the type of machine from the original 
bugreport. 

I'll look around and see if I have any MDD (mirror drive door -- the type in 
the original bugreport) machines.  If so, I'll try to find some time to install 
Adrian's latest and report back.

Rick

Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly

[Rick Thomas]

I've got the latest (Apr 17) running on my G5 right now.  No problems.

Rick

rbthomas@kmac:~$ cat /proc/version 
Linux version 5.10.0-6-powerpc64 (debian-ker...@lists.debian.org) (gcc-10 
(Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 
SMP Debian 5.10.28-1 (2021-04-09)

Bug#985196: haveged: OpenRD "client" ( arch = armv5tel ) Upgraded from Buster to Bullseye and haveged stoped working

[Rick Thomas]

Package: haveged
Version: 1.9.14-1
Severity: normal

Dear Maintainer,

I recently updated my OpenRD "client" ( arch = armv5tel ) from Buster to 
Bullseye and now haveged crashes.

$ sudo service haveged status
* haveged.service - Entropy Daemon based on the HAVEGE algorithm
 Loaded: loaded (/lib/systemd/system/haveged.service; enabled; vendor 
preset: enabled)
 Active: failed (Result: signal) since Sat 2021-03-13 05:06:23 PST; 19h ago
   Docs: man:haveged(8)
 http://www.issihosts.com/haveged/
Process: 1610 ExecStart=/usr/sbin/haveged --Foreground --verbose=1 
$DAEMON_ARGS (code=killed, signal=SYS)
   Main PID: 1610 (code=killed, signal=SYS)
CPU: 247ms

Mar 13 05:06:23 client systemd[1]: haveged.service: Scheduled restart job, 
restart counter is at 5.
Mar 13 05:06:23 client systemd[1]: Stopped Entropy Daemon based on the HAVEGE 
algorithm.
Mar 13 05:06:23 client systemd[1]: haveged.service: Start request repeated too 
quickly.
Mar 13 05:06:23 client systemd[1]: haveged.service: Failed with result 'signal'.
Mar 13 05:06:23 client systemd[1]: Failed to start Entropy Daemon based on the 
HAVEGE algorithm.


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

Kernel: Linux 5.10.0-4-marvell
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages haveged depends on:
ii  init-system-helpers  1.60
ii  libc62.31-9
ii  libhavege2   1.9.14-1
ii  lsb-base 11.1.0

haveged recommends no packages.

Versions of packages haveged suggests:
ii  apparmor  2.13.6-9

-- no debconf information

Bug#982270: installation-reports: Installing Debian Bullseye on Cubox-i4 - installer finds no ethernet

[Rick Thomas]

Package: installation-reports
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- Package-specific info:

Boot method: Followed the instruction in the README file
Image version:
https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/
dated 2021-01-30 (also tried 2021-02-06)
Date: 2021-02-06

Machine: Cubox-i4P
Partitions: Didn't get that far in the installation

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

Initial boot:   [ok]
Detect network card:[failed] could not proceed
Overall install:[failed ]

Comments/Problems:

I downloaded the two-part image from [1] dated 2021-01-30 and tried to 
install it on my Cubox-i4.

It booted fine but when it got to the "Detect network hardware" phase, 
it failed and said:

> No Ethernet card was detected. If you know the name of the driver 
> needed by your Ethernet card, you can select it from the list. 
> Driver needed by your Ethernet card:  

and gave a long list of available ethernet drivers, none of which seemed to be 
relevant.

I tried it again, this time with the components dated 2021-02-06.
I was hoping that the problem was transient and might have been fixed in
the intervening week, but I still got the same result: "No Ethernet card was 
detected."

Vagrant says:
> Pretty sure it is a kernel bug, since I can make it go away on a similar
> system by downgrading to linux 5.9.x. Please CC me on the report and
> I'll try to contribute what I can!

-- 

Log files attached to this report are from a successful Buster installation on 
the same hardware,
in hopes they might be some help...

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="10 (buster) - installer build 20190702+deb10u7"
X_INSTALLATION_MEDIUM=netboot

==
Installer hardware-summary:
==
uname -a: Linux cube 4.19.0-13-armmp #1 SMP Debian 4.19.160-2 (2020-11-28) 
armv7l 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.19.0-13-armmp ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 02 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.19.0-13-armmp ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
lsmod: Module  Size  Used by
lsmod: dm_mod122880  9
lsmod: md_mod143360  0
lsmod: jfs   184320  0
lsmod: btrfs1241088  0
lsmod: libcrc32c  16384  1 btrfs
lsmod: xor16384  1 btrfs
lsmod: zstd_decompress61440  1 btrfs
lsmod: zstd_compress 159744  1 btrfs
lsmod: xxhash 20480  2 zstd_compress,zstd_decompress
lsmod: zlib_deflate   28672  1 btrfs
lsmod: raid6_pq   98304  1 btrfs
lsmod: vfat   24576  0
lsmod: fat73728  1 vfat
lsmod: ext4  618496  3
lsmod: crc16  16384  1 ext4
lsmod: mbcache16384  1 ext4
lsmod: jbd2  102400  1 ext4
lsmod: crc32c_generic 16384  6
lsmod: fscrypto   28672  1 ext4
lsmod: ecb16384  0
lsmod: brcmfmac  253952  0
lsmod: brcmutil   16384  1 brcmfmac
lsmod: cfg80211  548864  1 brcmfmac
lsmod: rfkill 28672  1 cfg80211
lsmod: usb_storage53248  0
lsmod: sd_mod 49152  3
lsmod: ahci_imx   20480  2
lsmod: libahci_platform   20480  1 ahci_imx
lsmod: libahci32768  2 libahci_platform,ahci_imx
lsmod: libata208896  3 libahci_platform,libahci,ahci_imx
lsmod: scsi_mod  196608  3 sd_mod,usb_storage,libata
lsmod: sdhci_esdhc_imx24576  0
lsmod: sdhci_pltfm16384  1 sdhci_esdhc_imx
lsmod: sdhci  53248  2 sdhci_pltfm,sdhci_esdhc_imx
lsmod: ci_hdrc_imx16384  0
lsmod: ci_hdrc45056  1 ci_hdrc_imx
lsmod: ulpi   16384  1 ci_hdrc
lsmod: ehci_hcd   77824  1 ci_hdrc
lsmod: udc_core   36864  

Bug#918755: Bug#978158: [upgrade-system] upgrade-system wants to delete package deluge and everything it depends on

[Rick Thomas]

As I said, simply adding --no-guess-python to ORPHANOPTS does take care of the 
immediate problem of wanting to delete deluge, but in exchange, it opens up a 
potential can of worms when there is a python package that is indeed an orphan, 
which would then not be deleted by upgrade-system.

So, for the time being, I will "err on the side of caution" and add 
--no-guess-python to ORPHANOPTS.  If upgrade-system is as a result less zealous 
about deleting orphan packages, so be it.  I can live with that.

If someone wants to track down the underlying cause of deborphan's dislike for 
python-cffi-backend, I'll be happy to help in any way I can.

Rick

On Sun, Dec 27, 2020, at 1:02 PM, Martin-Éric Racine wrote:
> Right, so in that case, there is no bug in upgrade-system.
> 
> The backend 'deborphan --guess-all' simply makes broad assumptions
> about what is superflous libraries and, for some reason, it considers
> python-cffi-backend as superflous as explained in bug #918755.
> 
> In your case, the solution indeed is to add --no-guess-python to ORPHANOPTS.
> 
> Martin-Éric

Bug#918755: Bug#978158: [upgrade-system] upgrade-system wants to delete package deluge and everything it depends on

[Rick Thomas]

It looks like the problem is in deborphan.  /etc/upgrade-system.conf has
ORPHANOPTS="--guess-all --libdevel"

and something about that combination leads deborphan to decide it doesn't need 
the package "python-cffi-backend", which is a lineal dependent of deborphan.  
The reason that upgrade-system wants to purge deluge is that with 
python-cffi-backend gone, deluge is missing a critical dependency.  This is all 
described Bug#918755 .

If I add "--no-guess-python" to the option list, deborphan no longer lists 
python-cffi-backend,  but I'm concerned that doing that will have wider 
side-effects.

Details:
rbthomas@monk:~$ deborphan --guess-all --libdevel
python-cffi-backend
rbthomas@monk:~$ deborphan --guess-all --no-guess-python --libdevel
rbthomas@monk:~$

Hope this helps!
Rick

On Sat, Dec 26, 2020, at 3:03 PM, Martin-Éric Racine wrote:
> la 26. jouluk. 2020 klo 21.30 Rick Thomas (rbtho...@rcthomas.org) kirjoitti:
> >
> > Package: upgrade-system
> > Version: 1.7.3.1
> > Severity: normal
> >
> > --- Please enter the report below this line. ---
> >
> > The package "deluge" is manually (i.e. not "auto") installed on my
> > system.  I use it daily. But when I try to run "upgrade-system" it lists
> > deluge and a bunch of other packages that deluge depends on as needing
> > to be removed.  Why is this?
> 
> Check the deborphan options you have configured in
> /etc/upgrade-system.conf for something that tries to purge python
> packages. To manually fine-tune this, you can run 'sudo deborphan'
> with different combinations of --guess options.
> 
> Martin-Éric
>

Bug#918755: [deborphan] deborphan --guess-all --libdevel wants to remove python-cffi-backend despite it being needed by deluge

[Rick Thomas]

Package: deborphan
Version: 1.7.31

--- Please enter the report below this line. ---

I have manually installed the "deluge" package, which after a chain of 
depends, requires python-cffi-backend.  However, as can be seen from the 
following script, deborphan thinks it's not needed.  WTF?


Details:

rbthomas@monk:~$ sudo deborphan -Ps --guess-all --libdevel
main/python   python-cffi-backend  optional

rbthomas@monk:~$ aptitude why python-cffi-backend
i   deluged Depends  deluge-common (= 1.3.15-2)
i A deluge-common   Depends python-openssl
i A python-openssl  Depends  python-cryptography (>= 2.3)
i A python-cryptography Depends  python-cffi-backend-api-min (<= 9729)
i A python-cffi-backend Provides python-cffi-backend-api-min

rbthomas@monk:~$ aptitude show python-cffi-backend
Package: python-cffi-backend
Version: 1.12.2-1
State: installed
Automatically installed: yes
Priority: optional
Section: python
Maintainer: Debian Python Modules Team 


Architecture: amd64
Uncompressed Size: 201 k
Depends: python (< 2.8), python (>= 2.7~), python:any (< 2.8), 
python:any (>= 2.7~), libc6 (>= 2.14), libffi6 (>= 3.0.4)

Breaks: python-cffi (< 1)
Replaces: python-cffi (< 1)
Provides: python-cffi-backend-api-9729, python-cffi-backend-api-max (= 
10495), python-cffi-backend-api-min (= 9729)

Description: Foreign Function Interface for Python calling C code - backend
 Convenient and reliable way of calling C code from Python.

 The aim of this project is to provide a convenient and reliable way of 
calling C code from Python. It keeps Python logic in
 Python, and minimises the C required. It is able to work at either the 
C API or ABI level, unlike most other approaches, that

 only support the ABI level.

 This package contains the runtime support for pre-built cffi modules.
Homepage: http://cffi.readthedocs.org/


--- System information. ---
Architecture:
Kernel: Linux 4.19.0-13-amd64

Debian Release: 10.7
500 stable-updates ftp-osl.osuosl.org
500 stable security.debian.org
500 stable ftp-osl.osuosl.org
500 oldstable deb.debian.org
100 buster-backports ftp-osl.osuosl.org

--- Package information. ---
Depends (Version) | Installed
==-+-===
libc6 (>= 2.14) | 2.28-10


Recommends (Version) | Installed
===-+-===
apt | 1.8.2.2
dialog | 1.3-20190211-1
gettext-base | 0.19.8.1-9


Package's Suggests field is empty.

Bug#978158: [upgrade-system] upgrade-system wants to delete package deluge and everything it depends on

[Rick Thomas]

Package: upgrade-system
Version: 1.7.3.1
Severity: normal

--- Please enter the report below this line. ---

The package "deluge" is manually (i.e. not "auto") installed on my 
system.  I use it daily. But when I try to run "upgrade-system" it lists 
deluge and a bunch of other packages that deluge depends on as needing 
to be removed.  Why is this?


Details:

rbthomas@monk:~$ aptitude search deluge
i   deluge  - bittorrent 
client written in Python/PyGTK
i A deluge-common   - bittorrent 
client written in Python/PyGTK (common files)
i   deluge-console  - bittorrent 
client written in Python/PyGTK (console ui)
i A deluge-gtk  - bittorrent 
client written in Python/PyGTK (GTK+ ui)
p   deluge-torrent  - bittorrent 
client (gtk ui transitional package)
i   deluge-web  - bittorrent 
client written in Python/PyGTK (web ui)
p   deluge-webui    - bittorrent 
client (web ui transitional package)
i   deluged - bittorrent 
client written in Python/PyGTK (daemon)


rbthomas@monk:~$ sudo upgrade-system
1) Updating package lists:
I: Package lists updated.
2) Checking for upgradable packages:
I: No upgradable package to install.
3) Checking for orphan packages:
I: Purging orphan packages...
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
  deluge* deluge-common* deluge-console* deluge-gtk* deluge-web* 
deluged* libboost-python1.67.0* libboost-random1.67.0*
  libglade2-0* libmad0* libmikmod3* libportmidi0* libsdl-image1.2* 
libsdl-mixer1.2* libsdl2-2.0-0* libtorrent-rasterbar9*
  python-asn1crypto* python-attr* python-automat* python-cffi-backend* 
python-chardet* python-click* python-colorama*
  python-constantly* python-cryptography* python-glade2* 
python-hyperlink* python-idna* python-incremental* python-ipaddress*
  python-libtorrent* python-mako* python-markupsafe* python-notify* 
python-openssl* python-pyasn1* python-pyasn1-modules*
  python-pygame* python-service-identity* python-six* 
python-twisted-bin* python-twisted-core* python-xdg*

  python-zope.interface*
0 upgraded, 0 newly installed, 44 to remove and 0 not upgraded.
After this operation, 43.5 MB disk space will be freed.
Do you want to continue? [Y/n] N




--- System information. ---
Architecture:
Kernel: Linux 4.19.0-13-amd64

Debian Release: 10.7
500 stable-updates ftp-osl.osuosl.org
500 stable security.debian.org
500 stable ftp-osl.osuosl.org
500 oldstable deb.debian.org
100 buster-backports ftp-osl.osuosl.org

--- Package information. ---
Depends (Version) | Installed
-+-===
apt (>= 0.7.0) | 1.8.2.2
deborphan (>= 1.7) | 1.7.31


Recommends (Version) | Installed
=-+-===
debsums | 2.2.3


Package's Suggests field is empty.

Bug#962921: apticron: Use of tempfile(1) produces a warning message

[Rick Thomas]

Package: apticron
Version: 1.2.3+nmu1
Followup-For: Bug #962921

Dear Maintainer,

This produces an email every time apticron runs.  Not useful.  Thanks for your 
attention!
Rick

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

Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apticron depends on:
ii  apt 2.1.11
ii  bzip2   1.0.8-4
ii  cron [cron-daemon]  3.0pl1-136
ii  dpkg1.20.5
ii  mailutils [mailx]   1:3.10-3
ii  ucf 3.0043

Versions of packages apticron recommends:
ii  apt-listchanges  3.22
ii  gpg  2.2.20-1
ii  iproute2 5.9.0-1

apticron suggests no packages.

-- no debconf information

Bug#971069: ntpsec: why does poll not go beyond 256 even though maxpoll is set to 10?

[Rick Thomas]

Package: ntpsec
Version: 1.1.9+dfsg1-4
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
I don't want to bother the national ntp pool servers more often than necessary.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Here are the server and pool statements from /etc/ntpsec/ntp.conf:
rbthomas@cube:~$ egrep '^(server|pool)' /etc/ntpsec/ntp.conf
server pips.rcthomas.org minpoll 3 maxpoll 8 iburst prefer
pool pool.rcthomas.org minpoll 3 maxpoll 8 prefer iburst
pool us.pool.ntp.org minpoll 6 maxpoll 10 iburst
server 127.127.1.1 iburst
The servers marked "rcthomas.org" are on the local home network.
pips.rcthomas.org is a local gps synchronized ntp server.
Everything else is from the us.pool.ntp.org national pool.

   * What was the outcome of this action?
After a delay the poll numbers all migrate up to 256, but seem to stop there.
Here's what I see:
rbthomas@cube:~$ ntpq -p
 remote   refid  st t when poll 
reach   delay   offset   jitter

===
*pips.rcthomas.org   .GPS.1 u  190  256 
 377   1.3438  -0.9604   0.5393
 pool.rcthomas.org   .POOL.  16 p-  256 
   0   0.   0.   0.0019
 us.pool.ntp.org .POOL.  16 p-  256 
   0   0.   0.   0.0019
 LOCAL(1).LOCL.  13 l-   64 
   0   0.   0.   0.0019
-173.0.48.220.reverse.wowrack.com192.168.10.254   2 u  517  512 
 377  15.2537  21.2694   1.0572
+triton.ellipse.net  128.252.19.1 2 u  146  256 
 177  58.6618   0.7304   5.0250
+ip7.nsg.sbbsnet.net 129.6.15.29  2 u  966  256 
  10  65.4259   5.3153   1.6917
+half.rcthomas.org   192.168.1.15 2 u  196  256 
 377   0.4804  -0.8793   0.2603
+sheeva.rcthomas.org 192.168.1.15 2 u  108  256 
 377   0.5064   0.4234   0.3130
+ultimate.rcthomas.org   192.168.1.15 2 u  158  256 
 377   0.5294  -0.7818   0.2372
+toshiba.rcthomas.org192.168.1.15 2 u  129  256 
 377   0.4931  -1.0025   0.3729


   * What outcome did you expect instead?
I expected to see the "us.pool.ntp.org" ".POOL." line showing poll at 1024, and 
see at least some of the
servers from that pool with pool values over 256.
However, the only one with a value over 256 is the wowrack.com server with 512.
But that is also the only server flagged with a "-" indicating that it is not 
in the running and will be
removed soon.

Is this a bug, or is there some sort of grand design that I'm not taking into 
account?

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


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

Kernel: Linux 5.8.0-2-armmp (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ntpsec depends on:
ii  adduser  3.118
ii  init-system-helpers  1.58
ii  libbsd0  0.10.0-1
ii  libc62.31-3
ii  libcap2  1:2.43-1
ii  libssl1.11.1.1g-1
ii  lsb-base 11.1.0
ii  netbase  6.1
ii  python3  3.8.2-3
ii  python3-ntp  1.1.9+dfsg1-4
ii  tzdata   2020a-1

Versions of packages ntpsec recommends:
ii  cron [cron-daemon]  3.0pl1-136
ii  systemd 246.6-1

Versions of packages ntpsec suggests:
ii  apparmor   2.13.4-3
pn  certbot
ii  ntpsec-doc 1.1.9+dfsg1-4
ii  ntpsec-ntpviz  1.1.9+dfsg1-4

-- Configuration Files:
/etc/default/ntpsec changed:
NTPD_OPTS="-g -N"
IGNORE_DHCP="yes"

/etc/ntpsec/ntp.conf changed:
driftfile /var/lib/ntpsec/ntp.drift
leapfile /usr/share/zoneinfo/leap-seconds.list
statsdir /var/log/ntpsec/
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
tos maxclock 11
tos minclock 7 minsane 5
server pips.rcthomas.org minpoll 3 maxpoll 8 iburst prefer
pool pool.rcthomas.org minpoll 3 maxpoll 8 prefer iburst
pool us.pool.ntp.org minpoll 6 maxpoll 10 iburst
server 127.127.1.1 iburst
fudge 127.127.1.1 stratum  13 # everybody else
restrict default kod nomodify nopeer noquery limited
restrict 127.0.0.1
restrict ::1
restrict 192.168.0.0  mask  

Bug#958649: installation-reports: On PowerMac G4 Debian-Ports installer fails to find PATA disks unless a USB drive is also present

[Rick Thomas]

Package: installation-reports
Followup-For: Bug #958649

I forgot to include the partion information...  Her it is:

rbthomas@grey:~$ sudo mac-fdisk -l /dev/sda ; lsblk
/dev/sda
#type name  length   base  ( 
size )  system
/dev/sda1 Apple_partition_map Apple 63 @ 1 ( 
31.5k)  Partition map
/dev/sda2 Apple_Bootstrap untitled  250001 @ 64
(122.1M)  NewWorld bootblock
/dev/sda3 Apple_UNIX_SVR2 untitled  51 @ 250065
(244.1M)  Linux native
/dev/sda4   Linux_LVM untitled   320922893 @ 750066
(153.0G)  Unknown
/dev/sda5  Apple_Free Extra  1 @ 321672959 (  
0.5k)  Free space

Block size=512, Number of Blocks=321672960
DeviceType=0x0, DeviceId=0x0

NAMEMAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda   8:00 153.4G  0 disk  
|-sda18:10  31.5K  0 part  
|-sda28:20 122.1M  0 part  /boot/grub
|-sda38:30 244.1M  0 part  /boot
|-sda48:40   153G  0 part  
| |-grey--vg-root   253:00  18.6G  0 lvm   /
| |-grey--vg-swap_1 253:10   976M  0 lvm   [SWAP]
| `-grey--vg-home   253:20  73.6G  0 lvm   /home
`-sda58:50   512B  0 part  
sdb   8:16   0 232.9G  0 disk  
|-sdb18:17   0  31.5K  0 part  
`-sdb28:18   0 232.9G  0 part  
  `-md127 9:127  0 232.9G  0 raid1 
sdc   8:32   0 232.9G  0 disk  
|-sdc18:33   0  31.5K  0 part  
`-sdc28:34   0 232.9G  0 part  
  `-md127 9:127  0 232.9G  0 raid1 
sdd   8:48   1   3.8G  0 disk  
`-sdd18:49   1   3.8G  0 part  
sr0  11:01  1024M  0 rom   

Bug#958649: installation-reports: On PowerMac G4 Debian-Ports installer fails to find PATA disks unless a USB drive is also present

[Rick Thomas]

Package: installation-reports
Severity: normal



-- Package-specific info:

Boot method: CD
Image version: 
https://cdimage.debian.org/cdimage/ports/2020-04-19/debian-10.0-powerpc-NETINST-1.iso
Date: Apr 22 18:44 PDT

Machine: PowerMac G4 Silver "PowerMac 3,5"
Partitions: 


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 media:   [o]
Load installer modules: [o]
Clock/timezone setup:   [o]
User/password setup:[o]
Detect hard drives: [e]  See notes below...
Partition hard drives:  [o]
Install base system:[o]
Install tasks:  [o]
Install boot loader:[o]
Overall install:[o]  But needed workaround for error noted below

Comments/Problems:



The CD booted fine.  I used the default install option.
All went well until it came time to partition the disk.
The machine has three IDE (Parallel ATA) drives.
Two are configured as a RAID1 array and the third is the boot disk.
But none of those disks were found by the installer's partitioning step!
So I couldn't continue with the installation.
Interestingly enough, when I switched to -F2 console and did "ls -l 
/dev/sd*",
all three of the disks seemed to be present.  Very strange!

So I thought maybe I could save the log files to a USB thumb-drive
(I had forgotten about the "save to the web" option).
I plugged in a USB drive and tried again.
This time it *found* all the disks (including the USB drive)
and kindly offered to partition them for me!

Wow!  "Curiouser and curiouser!"

So I disconnected the USB drive and tried again.
As expected, it did not find the disks this time.
So I saved the log files (having noticed the web option in a previous attempt).

Then I re-plugged the USB drive and tried the install with it in.
As expected, it found the disk drives and successfully partitioned the boot 
drive for me.
The rest of the install went fine, including installing Grub and rebooting into 
the newly installed system.
I saved the log files for comparison with the failed attempt.

I'm attaching to this email the two sets of log files as a single compressed 
tar.gz file.

Hope it helps!

-- 

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="11 (bullseye) - installer build 20200315"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux grey 5.5.0-2-powerpc #1 Debian 5.5.17-1 (2020-04-15) ppc 
GNU/Linux
lspci -knn: lspci: Unable to load libkmod resources: error -12
lspci -knn: :00:0b.0 Host bridge [0600]: Apple Inc. UniNorth 1.5 AGP 
[106b:002d]
lspci -knn: Kernel driver in use: agpgart-uninorth
lspci -knn: :00:10.0 VGA compatible controller [0300]: Advanced Micro 
Devices, Inc. [AMD/ATI] RV200 [Radeon 7500/7500 LE] [1002:5157]
lspci -knn: Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] RV200 [Radeon 
7500/7500 LE] [1002:5157]
lspci -knn: Kernel driver in use: radeonfb
lspci -knn: 0001:10:0b.0 Host bridge [0600]: Apple Inc. UniNorth 1.5 PCI 
[106b:002e]
lspci -knn: 0001:10:13.0 IDE interface [0101]: Silicon Image, Inc. PCI0680 
Ultra ATA-133 Host Controller [1095:0680] (rev 02)
lspci -knn: Subsystem: Silicon Image, Inc. PCI0680 Ultra ATA-133 Host 
Controller [1095:0680]
lspci -knn: Kernel driver in use: pata_sil680
lspci -knn: 0001:10:15.0 Ethernet controller [0200]: 3Com Corporation 3c905B 
100BaseTX [Cyclone] [10b7:9055] (rev 30)
lspci -knn: Subsystem: 3Com Corporation 3c905B 100BaseTX [Cyclone] 
[10b7:9055]
lspci -knn: Kernel driver in use: 3c59x
lspci -knn: 0001:10:17.0 Unassigned class [ff00]: Apple Inc. KeyLargo Mac I/O 
[106b:0022] (rev 03)
lspci -knn: Kernel driver in use: macio
lspci -knn: 0001:10:18.0 USB controller [0c03]: Apple Inc. KeyLargo USB 
[106b:0019]
lspci -knn: Kernel driver in use: ohci-pci
lspci -knn: 0001:10:19.0 USB controller [0c03]: Apple Inc. KeyLargo USB 
[106b:0019]
lspci -knn: Kernel driver in use: ohci-pci
lspci -knn: 0002:20:0b.0 Host bridge [0600]: Apple Inc. UniNorth 1.5 Internal 
PCI [106b:002f]
lspci -knn: 0002:20:0e.0 FireWire (IEEE 1394) [0c00]: LSI Corporation FW322/323 
[TrueFire] 1394a Controller [11c1:5811]
lspci -knn: Subsystem: LSI Corporation FW322/323 [TrueFire] 1394a 
Controller [11c1:5811]
lspci -knn: Kernel driver in use: firewire_ohci
lspci -knn: 0002:20:0f.0 Ethernet controller [0200]: Apple Inc. UniNorth GMAC 
(Sun GEM) [106b:0021] (rev 01)
lspci -knn: Kernel 

Bug#958527: installation-reports: Successful install of Debian Ports on PowerMac G5

[Rick Thomas]

Package: installation-reports
Severity: normal



-- Package-specific info:

Boot method: CD
Image version: 
https://cdimage.debian.org/cdimage/ports/2020-04-19/debian-10.0-ppc64-NETINST-1.iso
Date: 

Machine: PowerMac G5 "PowerMac7,3"
Partitions: 
rbthomas@kmac:~$ df -Tl | grep -v tmpfs
Filesystem Type 1K-blocksUsed Available Use% Mounted on
/dev/sdb3  ext4 235283576 1341840 221920328   1% /
/dev/sdb2  hfs 1249906522118468   6% /boot/grub
rbthomas@kmac:~$ lsblk
NAMEMAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda   8:00 931.5G  0 disk 
├─sda18:10  31.5K  0 part 
├─sda28:20   977K  0 part 
├─sda38:30 244.1M  0 part 
├─sda48:40 931.3G  0 part 
│ ├─kmac--vg-root   254:00   6.5G  0 lvm  
│ ├─kmac--vg-swap_1 254:10  11.4G  0 lvm  
│ └─kmac--vg-home   254:20 913.4G  0 lvm  
└─sda58:50  24.5K  0 part 
sdb   8:16   0 232.9G  0 disk 
├─sdb18:17   0  31.5K  0 part 
├─sdb28:18   0 122.1M  0 part /boot/grub
├─sdb38:19   0   229G  0 part /
├─sdb48:20   0   3.8G  0 part [SWAP]
└─sdb58:21   0  56.5K  0 part 
sdc   8:32   1  28.9G  0 disk 
└─sdc18:33   1  28.9G  0 part 
sr0  11:01  1024M  0 rom  



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 media:   [o]
Load installer modules: [o]
Clock/timezone setup:   [o]
User/password setup:[o]
Detect hard drives: [o]
Partition hard drives:  [o]
Install base system:[o]
Install tasks:  [o]
Install boot loader:[o]
Overall install:[o]

Comments/Problems:


Works great!  Congrats to Adrian!

-- 

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="11 (bullseye) - installer build 20200315"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux kmac 5.5.0-2-powerpc64 #1 SMP Debian 5.5.17-1 (2020-04-15) 
ppc64 GNU/Linux
lspci -knn: lspci: Unable to load libkmod resources: error -12
lspci -knn: :f0:0b.0 Host bridge [0600]: Apple Inc. U3H AGP Bridge 
[106b:0059]
lspci -knn: Kernel driver in use: agpgart-uninorth
lspci -knn: :f0:10.0 VGA compatible controller [0300]: Advanced Micro 
Devices, Inc. [AMD/ATI] RV350 [Radeon 9550/9600/X1050 Series] [1002:4150]
lspci -knn: Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] RV350 [Radeon 
9550/9600/X1050 Series] [1002:4150]
lspci -knn: 0001:00:00.0 Host bridge [0600]: Apple Inc. U3 HT Bridge [106b:0057]
lspci -knn: 0001:00:01.0 PCI bridge [0604]: Apple Inc. K2 HT-PCI Bridge 
[106b:0045]
lspci -knn: 0001:00:02.0 PCI bridge [0604]: Apple Inc. K2 HT-PCI Bridge 
[106b:0046]
lspci -knn: 0001:00:03.0 PCI bridge [0604]: Apple Inc. K2 HT-PCI Bridge 
[106b:0047]
lspci -knn: 0001:00:04.0 PCI bridge [0604]: Apple Inc. K2 HT-PCI Bridge 
[106b:0048]
lspci -knn: 0001:00:05.0 PCI bridge [0604]: Apple Inc. K2 HT-PCI Bridge 
[106b:0049]
lspci -knn: 0001:01:07.0 Unassigned class [ff00]: Apple Inc. K2 KeyLargo Mac/IO 
[106b:0041] (rev 60)
lspci -knn: Kernel driver in use: macio
lspci -knn: 0001:01:08.0 USB controller [0c03]: Apple Inc. K2 KeyLargo USB 
[106b:0040]
lspci -knn: Kernel driver in use: ohci-pci
lspci -knn: 0001:01:09.0 USB controller [0c03]: Apple Inc. K2 KeyLargo USB 
[106b:0040]
lspci -knn: Kernel driver in use: ohci-pci
lspci -knn: 0001:02:0d.0 Unassigned class [ff00]: Apple Inc. K2 ATA/100 
[106b:0043]
lspci -knn: Kernel driver in use: pata-pci-macio
lspci -knn: 0001:02:0e.0 FireWire (IEEE 1394) [0c00]: Apple Inc. K2 FireWire 
[106b:0042]
lspci -knn: Subsystem: Apple Inc. Device [106b:5811]
lspci -knn: Kernel driver in use: firewire_ohci
lspci -knn: 0001:03:0f.0 Ethernet controller [0200]: Apple Inc. K2 GMAC (Sun 
GEM) [106b:004c]
lspci -knn: Kernel driver in use: gem
lspci -knn: 0001:04:0c.0 IDE interface [0101]: Broadcom K2 SATA [1166:0240]
lspci -knn: Subsystem: Broadcom K2 SATA [1166:0240]
lspci -knn: Kernel driver in use: sata_svw
lspci -knn: 0001:05:01.0 Network controller [0280]: Broadcom Inc. and 
subsidiaries BCM4306 802.11b/g Wireless LAN Controller [14e4:4320] (rev 03)
lspci -knn: Subsystem: Apple Inc. Device [106b:004e]
lspci -knn: Kernel driver in use: 

Bug#924192: Is this fix going to make it into Buster any time soon?

[Rick Thomas]

> On Sep 21, 2019, at 12:13 PM, Richard Laager  wrote:
> 
> On 9/21/19 7:22 AM, Rick Thomas wrote:
>> I’d really like to see this fix make it into Debian Buster!
>> Any chance of that?
> 
> I dropped the ball on this before the Buster release, for lack of time.
> My intention is to try to get this into a point release. I'm intending
> on doing that tomorrow. So hopefully it will land in the next point release.
> 
> -- 
> Richard

Thanks!  I’m looking forward to it.  Will the .deb be available somewhere I can 
pick it up?  So I don’t have to wait for the next point release to install it…

Enjoy!
Rick

Bug#924192: Is this fix going to make it into Buster any time soon?

[Rick Thomas]

I’d really like to see this fix make it into Debian Buster!
Any chance of that?

Thanks!
Rick

Bug#934974: u-boot: usb start fails on sheevaplug in u-boot 2019.01

[Rick Thomas]

I have a sheevaplug that has been on the shelf for a couple years because it 
appeared to be bricked.  I decided to try to unbrick it to see if I could help 
with these tests.  Unfortunately when I plug it in and connect it to a PC 
running Debian Buster with the micro-USB cable, there is no device /dev/ttyUSB* 
.  I've tried the same thing with an OpenRD box and the device appears as 
expected then.

If I ignore that problem and try to connect with opencd, I get the following 
error messages:

$ openocd -f /usr/share/openocd/scripts/board/sheevaplug.cfg -s 
/usr/share/openocd/scripts
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To override use 
'transport select '.
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain 
connect_deassert_srst
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
adapter speed: 2000 kHz
dcc downloads are enabled
Warn : use 'feroceon.cpu' as target identifier, not '0'
sheevaplug_load_uboot
Error: no device found
Error: unable to open ftdi device with vid 9e88, pid 9e8f, description 
'SheevaPlug JTAGKey FT2232D B', serial '*' at bus location '*'

Can anybody help me figure out what to do next?

Thanks!
Rick

> On Sep 5, 2019, at 10:58 AM, Jan Hahne  wrote:
> 
> I was able to unbrick mine with these instructions:
> https://www.newit.co.uk/forum/index.php/topic,2835.0.html
> https://tadeubento.com/2018/sheevaplug-2018-unbrick/
> 

Bug#934040: tasksel: doesn't provide transitional package for task-print-server

[Rick Thomas]

I second this recommendation!
Rick

> On Aug 6, 2019, at 4:25 AM, Raphaël Halimi  wrote:
> 
> Package: tasksel
> Version: 3.54
> 
> Hi,
> 
> Following #696658, task-print-server was renamed to task-print-service.
> 
> Running "apt-get dist-upgrade" on current Sid tries to remove
> task-print-server, without installing task-print-service to replace it.
> 
> This could be a problem for inexperienced users in the future when
> Bullseye will be released and they upgrade from Buster.
> 
> I guess the best solution is to provide an updated version of tasksel
> which provides a transitional dummy package named task-print-server
> depending on task-print-service.
> 
> Regards,
> 
> -- 
> Raphaël Halimi
> 

Bug#924192: ntpsec: at boot ntpsec starts before DNS is available

[Rick Thomas]

Thanks, yes, that did the trick.

I’ve installed it on one of my test computers.  It seems to work fine.  I’ve 
tried a couple of things that should trigger the bug, if it’s still there.

In particular, rebooting the computer then examining the journal shows that it 
does get to poll all of the configured pools.

Another experiment I have tried is this:
Boot the computer and let everything settle.
un-plug the ethernet (RJ45)
restart ntpsec and watch the journal for evidence of attempts to 
contact the configured pools (which will fail, since the   ethernet is 
disconnected)
re-plug the ethernet and continue to watch the journal for attempts to 
contact the pools (which succeed this time).

In this experiment, I saw no evidence of the bug — i.e. no evidence of having 
forgotten all but one of the configured pools.

Thanks for all your help!
Rick


> On Mar 25, 2019, at 4:30 PM, Richard Laager  wrote:
> 
>> sudo apt update
>> sudo apt install build-essential devscripts
>> sudo apt build-dep ntpsec
>> apt source ntpsec
>> cd ntpsec-1.1.3+dfsg1
>> patch -p1 < ~/ntpsec_1.1.3+dfsg1-3~1.gbpdde9c0.debdiff
> 
> I missed a step here, as `apt source` applies the existing patches, so
> we apparently need to apply this patch too:
> 
> patch -p1 < debian/patches/0001-Fix-for-577-DNS-retry-sloth.patch
> 
>> debuild -uc -us
> If you can try this and confirm this patch as packaged fixes your
> problem, that would help me move forward with this.
> 
> -- 
> Richard

Bug#924192: ntpsec: at boot ntpsec starts before DNS is available

[Rick Thomas]

Hi Richard,

I’m sorry that I was not able to try that patch for you.  However, I was able 
to download and (with a lot of help from Hal Murray) build the latest git 
version.  It worked a treat and properly handled the time lag between ntpsec 
starting and dhcp finishing.

Let me know if there’s anything more I can do to help get this fix into 
production.

Thanks very much for all your help!

Enjoy!
Rick

> On Mar 19, 2019, at 10:18 AM, Richard Laager  wrote:
> 
> Attached is an untested debdiff. This is the upstream change refreshed
> to apply to the package. You should be able to apply it and build a
> package locally like this:
> 
> sudo apt update
> sudo apt install build-essential devscripts
> sudo apt build-dep ntpsec
> apt source ntpsec
> cd ntpsec-1.1.3+dfsg1
> patch -p1 < ~/ntpsec_1.1.3+dfsg1-3~1.gbpdde9c0.debdiff
> debuild -uc -us
> 
> Can you try that and see if it fixes the issue for you?
> 
> I'm sorry I'm short on time today and couldn't do further testing
> myself. I hope this helps.
> 
> -- 
> Richard
> 

Bug#924192: ntpsec: at boot ntpsec starts before DNS is available

[Rick Thomas]

> On Mar 19, 2019, at 10:18 AM, Richard Laager  wrote:
> 
> Attached is an untested debdiff. This is the upstream change refreshed
> to apply to the package. You should be able to apply it and build a
> package locally like this:
> 
> sudo apt update
> sudo apt install build-essential devscripts
> sudo apt build-dep ntpsec
> apt source ntpsec
> cd ntpsec-1.1.3+dfsg1
> patch -p1 < ~/ntpsec_1.1.3+dfsg1-3~1.gbpdde9c0.debdiff
> debuild -uc -us
> 
> Can you try that and see if it fixes the issue for you?
> 
> I'm sorry I'm short on time today and couldn't do further testing
> myself. I hope this helps.
> 
> -- 
> Richard
> 

Thanks for the simple and very clear instructions!

Unfortunately, here’s what I get when I do the above steps…

Did I miss a something?

Rick

> rbthomas@cube:~/make-ntpsec/ntpsec-1.1.3+dfsg1$ debuild -uc -us
>  dpkg-buildpackage -us -uc -ui
> dpkg-buildpackage: info: source package ntpsec
> dpkg-buildpackage: info: source version 1.1.3+dfsg1-3~1.gbpdde9c0
> dpkg-buildpackage: info: source distribution UNRELEASED
> dpkg-buildpackage: info: source changed by Richard Laager 
>  dpkg-source --before-build .
> dpkg-buildpackage: info: host architecture armhf
>  debian/rules clean
> dh clean --with apache2,python3
>debian/rules override_dh_auto_clean
> make[1]: Entering directory '/home/rbthomas/make-ntpsec/ntpsec-1.1.3+dfsg1'
> python3 waf clean || true
> --- cleaning host --- 
> The project was not configured: run "waf configure" first!
> rm -rf \
>   build \
>   .lock-waf_*_build \
>   ntpclients/ntp \
>   ntpd/version.h \
>   pylib/control.py \
>   pylib/magic.py \
>   pylib/version.py \
>   .waf* \
>   wafhelpers/autorevision.sh
> find -name "*.pyc" -delete
> make[1]: Leaving directory '/home/rbthomas/make-ntpsec/ntpsec-1.1.3+dfsg1'
>dh_clean
>  dpkg-source -b .
> dpkg-source: info: using source format '3.0 (quilt)'
> dpkg-source: info: building ntpsec using existing 
> ./ntpsec_1.1.3+dfsg1.orig.tar.gz
> dpkg-source: info: using patch list from debian/patches/series
> dpkg-source: warning: ignoring deletion of directory build
> dpkg-source: warning: ignoring deletion of directory build/main
> dpkg-source: warning: ignoring deletion of directory build/main/ntpd
> dpkg-source: warning: ignoring deletion of file build/main/ntpd/ntpd.8, use 
> --include-removal to override
> dpkg-source: warning: ignoring deletion of file build/main/ntpd/ntp.keys.5, 
> use --include-removal to override
> dpkg-source: warning: ignoring deletion of file build/main/ntpd/ntp.conf.5, 
> use --include-removal to override
> dpkg-source: warning: ignoring deletion of directory build/main/ntptime
> dpkg-source: warning: ignoring deletion of file build/main/ntptime/ntptime.8, 
> use --include-removal to override
> dpkg-source: warning: ignoring deletion of directory build/main/ntpfrob
> dpkg-source: warning: ignoring deletion of file build/main/ntpfrob/ntpfrob.8, 
> use --include-removal to override
> dpkg-source: warning: ignoring deletion of directory build/main/ntpclients
> dpkg-source: warning: ignoring deletion of file 
> build/main/ntpclients/ntpviz.1, use --include-removal to override
> dpkg-source: warning: ignoring deletion of file 
> build/main/ntpclients/ntpdig.1, use --include-removal to override
> dpkg-source: warning: ignoring deletion of file 
> build/main/ntpclients/ntpleapfetch.8, use --include-removal to override
> dpkg-source: warning: ignoring deletion of file 
> build/main/ntpclients/ntpmon.1, use --include-removal to override
> dpkg-source: warning: ignoring deletion of file build/main/ntpclients/ntpq.1, 
> use --include-removal to override
> dpkg-source: warning: ignoring deletion of file 
> build/main/ntpclients/ntptrace.1, use --include-removal to override
> dpkg-source: warning: ignoring deletion of file 
> build/main/ntpclients/ntpwait.8, use --include-removal to override
> dpkg-source: warning: ignoring deletion of file 
> build/main/ntpclients/ntpkeygen.8, use --include-removal to override
> dpkg-source: warning: ignoring deletion of file 
> build/main/ntpclients/ntploggps.1, use --include-removal to override
> dpkg-source: warning: ignoring deletion of file 
> build/main/ntpclients/ntpsnmpd.8, use --include-removal to override
> dpkg-source: warning: ignoring deletion of file 
> build/main/ntpclients/ntpsweep.1, use --include-removal to override
> dpkg-source: warning: ignoring deletion of file 
> build/main/ntpclients/ntplogtemp.1, use --include-removal to override
> dpkg-source: info: local changes detected, the modified files are:
>  ntpsec-1.1.3+dfsg1/ntpd/ntp_proto.c
> dpkg-source: error: aborting due to unexpected upstream changes, see 
> /tmp/ntpsec_1.1.3+dfsg1-3~1.gbpdde9c0.diff.6WnYJh
> dpkg-source: info: you can integrate the local changes with dpkg-source 
> --commit
> dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2
> debuild: fatal error at line 1182:
> dpkg-buildpackage -us -uc -ui failed
> 

Bug#924192: ntpsec: at boot ntpsec starts before DNS is available

[Rick Thomas]

Thanks!

I’ll give it a try tonight…

Rick

> On Mar 19, 2019, at 10:18 AM, Richard Laager  wrote:
> 
> Attached is an untested debdiff. This is the upstream change refreshed
> to apply to the package. You should be able to apply it and build a
> package locally like this:
> 
> sudo apt update
> sudo apt install build-essential devscripts
> sudo apt build-dep ntpsec
> apt source ntpsec
> cd ntpsec-1.1.3+dfsg1
> patch -p1 < ~/ntpsec_1.1.3+dfsg1-3~1.gbpdde9c0.debdiff
> debuild -uc -us
> 
> Can you try that and see if it fixes the issue for you?
> 
> I'm sorry I'm short on time today and couldn't do further testing
> myself. I hope this helps.
> 
> -- 
> Richard
> 

Bug#924192: ntpsec: at boot ntpsec starts before DNS is available

[Rick Thomas]

> On Mar 14, 2019, at 1:04 AM, Richard Laager  wrote:
> 
> I forwarded your bug upstream:
> https://gitlab.com/NTPsec/ntpsec/issues/577

Hi!  
I’m sorry to take so long getting back.  I wanted to re-do my experiments in a 
standard environment that your would be able to reproduce easily.  Here are the 
results.

The system is a Cubox-I4Pro (2 GB RAM, quad-core ArmHF processor)
The OS is fresh-out-of-the-box Debian Buster with a default “multi-user” text 
console configuration (i.e. no GUI).

Things I have done to show the problem:
1) I modified the /etc/ntpsec/ntp.conf to use only two of the four available 
“debian.pool.ntp.org” pools.  In my original use-case, one of these pools would 
be on the local intranet, while the other would be an internet pool to act as a 
ballast incase the local intranet pool has problems.
2) I further modified the ntp.conf to have “tos minclock 7 minsane 5”.  The 
reason for this is to force it to use some servers from the “backup” pool to 
allow a smooth transition in the above-mentioned failure case.

3) To monitor the behavior under this setup I run an “@reboot” cron job that 
consists of the following shell sript:

 cut here =
#!/bin/bash

for i in `seq 1 130`
do
echo -n "$i"; date; /usr/bin/ntpq -pn ; /usr/bin/ntpstat
echo
sleep 30
done > /tmp/monitor.$$.out 2>&1

journalctl -b | egrep 'ntp|eth' > /tmp/journal.$$.out
 cut here =

I have attached copies of the monitor and journal output files from this script.


Hi-lights of the results from the monitor file:

at 02:34:27 the script starts as part of the reboot process.  ntpsec has not 
started yet.

by 02:34:58 (31 seconds later) ntpsec has started and we have contacted four 
servers from one of the pools, but due to minsane=5 it is unable to 
synchronize.  Note that the time taken from the system’s hardware clock at 
reboot is about a half second off from network time from these servers.

at 02:38:32 (about the 4 minutes mark) this situation has continued unabated.  
The same four servers without any progress synchronizing.  System time is still 
a half second off from network time.

at 02:39:01 (29 seconds later) Something has happened to cause us to contact 
another group of 4 servers.  Also, the system clock has been stepped to pick up 
the half-second.

at 02:39:32 (about the 5 minute mark) We’re starting to get results from the 
(now) eight servers on our list, and we have finally achieved useful 
synchronization.


Hi-lights of the results from the journal file:

at 02:34:27 ntpd starts.  But DHCP hasn’t yet got an IP address for the 
ethernet port.

at 02:34:30 the ethernet link comes up.  In the next few seconds, ntpd 
unsuccessfully tries to contact first 0.debian.pool.ntp.org, then 
1.debian.pool.ntp.org (twice).

at 02:34:35 DHCP finally gets an answer and an IP address is assigned to the 
ethernet port.

at 02:34:36 ntpd tries 1.debian.pool.ntp.org for a third time (ignoring 
0.debian.pool.ntp.org for some reason)  This time it succeeds and gets four 
server addresses as we see in the monitor log at 02:34:58.

Nothing happens for about 4 and a half minutes.

at 02:38:52 ntpd tries 1.debian.pool.ntp.org again (still no mention of 
0.debian.pool.ntp.org) and gets four different server addresses because the 
timer at the DNS server expired and caused it to remix the server addresses.

at 02:38:58 ntpd steps the clock to pick up the missing half second.

Nothing happens for the next roughly 25 minutes, until the test period expires.


Observations:

The system spent it’s first 4.5 minutes of life with an unsynchronized clock.

ntpd never used the 0.debian.pool.ntp.org pool at all.  It seems to have been 
completely forgotten after the first failed attempt.


Conclusions (thinks I’d like to see in future versions):

As long as minsane or minclock are unsatisfied, I’d like to see it attempting 
to use all the servers and pools at its disposal, not just the single most 
recently seen one.

I’d also like to see it trying to contact DNS more frequently than once every 
4.5 minutes.

Enjoy!
Rick

Bug#924192: ntpsec: at boot ntpsec starts before DNS is available

[Rick Thomas]

Thanks Richard, I’ll see if I can set up that experiment(s) and report back 
ASAP.

Would unplugging/replugging the ethernet cable work for steps 2 and 4…

Enjoy!
Rick

> On Mar 11, 2019, at 2:53 PM, Richard Laager  wrote:
> 
> Can we narrow this down to a reproducer? It sounds like something like
> this would work:
> 
> 
> 
> 0) Configure two different pools where you can tell the servers apart.
> 1) Stop ntpd.
> 2) Break your DNS.
> 3) Start ntpd. Wait a few seconds for it to try to resolve and fail.
> 4) Fix your DNS.
> 
> Expected results:
> ntpd recovers (successfully resolves the pools' DNS records) relatively
> quickly. Most importantly, when ntpd recovers, it recovers for both
> pools equally.
> 
> Actual results:
> Only the last configured pool recovers right away. The other one takes 5
> or 10 minutes.
> 
> 
> 
> Can you try a few more things:
> 
> 1) Does deleting the nameservers in /etc/resolv.conf work for step 2, or
> more to the point, does putting them back in /etc/resolv.conf work for
> step 4?
> 
> 2) I doubt it matters, but can you set the poll intervals the same on
> the two pools, to eliminate that variable?
> 
> 3) If you reduce minsane to 4, what happens? Does it do the same thing,
> never spin up the second pool, or (far less likely) spin them both up
> normally? I wonder if ntpd is only "recovering" the second pool because
> it is below minsane.
> 
> -- 
> Richard

Bug#924192: ntpsec: at boot ntpsec starts before DNS is available

[Rick Thomas]

Hi Richard,

My observations follow your quote…

> On Mar 11, 2019, at 12:30 PM, Richard Laager  wrote:
> 
> On 3/10/19 4:11 AM, Rick Thomas wrote:
>> If ntpsec implemented the "preempt" option on "peer" directives, the
>> first "peer" would be revisited after a few minutes and all would be
>> well.  But it doesn't.  So the first "peer" is as if it never existed.
> 
> What leads you to this conclusion, specifically about preempt? The way
> pool directives work is that they are re-evaluated until it reaches
> maxclock:
> https://docs.ntpsec.org/latest/discover.html
> 
> I'm not 100% sure how multiple independent pools (like you have here)
> will intersect. It's possible that ntpd is spinning up all the
> associations from the public pool. If only for testing, what happens if
> you comment out the public pool? Does it behave correctly then?
> 
> On 3/11/19 2:46 AM, Rick Thomas wrote:
>> Edited /lib/systemd/system/ntpsec-systemd-netif.path
> 
> As you figured out, this is the wrong place. You want ntpsec.service.
> 
>>> Mar 11 00:23:51 cube ntpd[354]: DNS: dns_probe: us.pool.ntp.org, 
>>> cast_flags:8, flags:101
>>> Mar 11 00:23:51 cube ntpd[354]: DNS: dns_check: processing us.pool.ntp.org, 
>>> 8, 101
>>> Mar 11 00:23:51 cube ntpd[354]: DNS: dns_check: DNS error: -3, Temporary 
>>> failure in name resolution
>>> Mar 11 00:23:51 cube ntpd[354]: DNS: dns_take_status: 
>>> us.pool.ntp.org=>temp, 9
>>> Mar 11 00:23:52 cube ntpd[354]: DNS: dns_probe: pool.rcthomas.org, 
>>> cast_flags:8, flags:121
>>> Mar 11 00:23:52 cube ntpd[354]: DNS: dns_check: processing 
>>> pool.rcthomas.org, 8, 121
>>> Mar 11 00:23:52 cube ntpd[354]: DNS: dns_check: DNS error: -3, Temporary 
>>> failure in name resolution
>>> Mar 11 00:23:52 cube ntpd[354]: DNS: dns_take_status: 
>>> pool.rcthomas.org=>temp, 9
> 
> I agree with your conclusion that DNS is not ready when ntpd started.
> 
>>> Mar 11 00:23:56 cube ntpd[354]: IO: Listen normally on 4 eth0 
>>> 192.168.3.129:123
>>> Mar 11 00:23:56 cube ntpd[354]: IO: Listen normally on 5 eth0 
>>> [fe80::d263:b4ff:fe00:912f%2]:123
>>> Mar 11 00:23:56 cube ntpd[354]: DNS: dns_probe: pool.rcthomas.org, 
>>> cast_flags:8, flags:121
>>> Mar 11 00:23:56 cube ntpd[354]: DNS: dns_check: processing 
>>> pool.rcthomas.org, 8, 121
>>> Mar 11 00:23:56 cube ntpd[354]: DNS: Pool taking: 192.168.3.207
>>> Mar 11 00:23:56 cube ntpd[354]: DNS: Pool taking: 192.168.3.111
>>> Mar 11 00:23:56 cube ntpd[354]: DNS: Pool taking: 192.168.3.4
>>> Mar 11 00:23:56 cube ntpd[354]: DNS: Pool taking: 192.168.1.14
> 
> What about this, though? Those are private IP addresses, so I assume
> those are coming from pool.rcthomas.org.
> 
>>> Mar 11 00:23:56 cube ntpd[354]: DNS: dns_take_status: 
>>> pool.rcthomas.org=>good, 8
> 
> This sure looks like it resolved correctly.
> 
> What is the output from:
> ntpq -p
> 
> Also note that the definition of network-online.target can vary and may
> or may not represent what you actually want.
> https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
> 
> If there's a bug here, I'd like to get it reported upstream so it can be
> fixed.
> 
> However, I am very skeptical of the idea that ntpd should, by default,
> wait until the network is online before starting. That prevents useful
> configurations like local refclocks, with no advantage if ntpd simply
> retries the network connections periodically, which I believe it is
> supposed to do.
> 
> —
> Richard

You are correct that the private IP addresses are coming from 
“pool.rcthomas.org”
and the public addresses are from “us.pool.ntp.org”.

It may be worth noting that each of the two pools resolves (at any given time) 
to just four IP addresses, and the conf file specifies minsane 5 (so as to 
always have at least one sane server from each of the pools) and minclock 7 (to 
allow two spares if one or more of the servers goes insane).  If that’s not a 
good idea, please correct me.

I’ve tried various combinations and orders of the “pool” statements.

What always happens is that they both are initially rejected; then the last one 
(and only the last one — whether it’s the private one or the public one) 
resolves OK on the next attempt and ntpsec connects to those servers — It 
almost looks as if (for some reason) the first one, having been rejected, is 
forgotten about but (again, for some reason) the last one is remembered and 
retried.

The first pool statement is eventually retried, but not for a period of several 
minutes (5 or 10?)  Someth

Bug#924192: ntpsec: at boot ntpsec starts before DNS is available

[Rick Thomas]

> On Mar 11, 2019, at 12:46 AM, Rick Thomas  wrote:
> 
> Examining the journal carefully, (specifically the lines labeled “Mar 11 
> 00:23:44”,
> it looks like the [Install] stanza isn’t the right place to put the “After” 
> “Wants” lines.
> 
> I’ll keep looking for a more appropriate place.  If you have any suggestions, 
> please share them.

Hmmm… Something like those two lines are already present in the [Unit] section 
of /lib/systemd/system/ntpsec.service 
but they are looking for “network.target” rather than “network-online.target”

I tried changing network => network-online (and doing “update-initramfs -u”) 
but to no avail.
Same results, but without the complaint about them being in an inappropriate 
place.

We’ll keep trying.

Rick

Bug#924192: ntpsec: at boot ntpsec starts before DNS is available

[Rick Thomas]

Hi Tony!

I’m not sure if I’m doing it right, but here’s what I did and what happened…

What I did:

Edited /lib/systemd/system/ntpsec-systemd-netif.path
Here’s a diff
> rbthomas@cube:~$ diff -c2 /SAVE//lib/systemd/system/ntpsec-systemd-netif.path 
> /lib/systemd/system/ntpsec-systemd-netif.path
> *** /SAVE//lib/systemd/system/ntpsec-systemd-netif.path   Mon Mar 11 
> 00:20:38 2019
> --- /lib/systemd/system/ntpsec-systemd-netif.path Mon Mar 11 00:21:33 2019
> ***
> *** 7,9 
>   
>   [Install]
> ! WantedBy=network-pre.target
> --- 7,10 
>   
>   [Install]
> ! After=network-online.target
> ! Wants=network-online.target
> rbthomas@cube:~$ 


Then i did
> root@cube:~# update-initramfs -u

and rebooted.

What happened:

I still get only the servers from the last “path” statement
.
Here’s what the journal says:
> rbthomas@cube:~$ journalctl -b | grep ntp
> Mar 11 00:23:43 cube kernel: Mountpoint-cache hash table entries: 2048 
> (order: 1, 8192 bytes)
> Mar 11 00:23:44 cube systemd[1]: 
> /lib/systemd/system/ntpsec-systemd-netif.path:7: Unknown lvalue 'After' in 
> section 'Install', ignoring
> Mar 11 00:23:44 cube systemd[1]: 
> /lib/systemd/system/ntpsec-systemd-netif.path:8: Unknown lvalue 'Wants' in 
> section 'Install', ignoring
> Mar 11 00:23:48 cube kernel: audit: type=1400 audit(1552289028.492:6): 
> apparmor="STATUS" operation="profile_load" profile="unconfined" 
> name="/usr/sbin/ntpd" pid=297 comm="apparmor_parser"
> Mar 11 00:23:48 cube audit[297]: AVC apparmor="STATUS" 
> operation="profile_load" profile="unconfined" name="/usr/sbin/ntpd" pid=297 
> comm="apparmor_parser"
> Mar 11 00:23:49 cube ntpd[350]: INIT: ntpd ntpsec-1.1.3 2019-02-04T07:38:48Z: 
> Starting
> Mar 11 00:23:50 cube ntp-systemd-wrapper[345]: 2019-03-11T00:23:49 ntpd[350]: 
> INIT: ntpd ntpsec-1.1.3 2019-02-04T07:38:48Z: Starting
> Mar 11 00:23:50 cube ntp-systemd-wrapper[345]: 2019-03-11T00:23:49 ntpd[350]: 
> INIT: Command line: /usr/sbin/ntpd -p /run/ntpd.pid -c /etc/ntpsec/ntp.conf 
> -g -N -u ntpsec:ntpsec
> Mar 11 00:23:49 cube systemd[1]: ntpsec.service: Can't open PID file 
> /run/ntpd.pid (yet?) after start: No such file or directory
> Mar 11 00:23:49 cube ntpd[350]: INIT: Command line: /usr/sbin/ntpd -p 
> /run/ntpd.pid -c /etc/ntpsec/ntp.conf -g -N -u ntpsec:ntpsec
> Mar 11 00:23:49 cube ntpd[354]: INIT: precision = 1.667 usec (-19)
> Mar 11 00:23:49 cube systemd[1]: Starting Wait for ntpd to synchronize system 
> clock...
> Mar 11 00:23:50 cube ntpd[354]: INIT: successfully locked into RAM
> Mar 11 00:23:50 cube ntpd[354]: CONFIG: readconfig: parsing file: 
> /etc/ntpsec/ntp.conf
> Mar 11 00:23:50 cube ntpd[354]: CLOCK: leapsecond file 
> ('/usr/share/zoneinfo/leap-seconds.list'): good hash signature
> Mar 11 00:23:50 cube ntpd[354]: CLOCK: leapsecond file 
> ('/usr/share/zoneinfo/leap-seconds.list'): loaded, expire=2019-06-28T00:00Z 
> last=2017-01-01T00:00Z ofs=37
> Mar 11 00:23:50 cube ntpd[354]: INIT: Using SO_TIMESTAMPNS
> Mar 11 00:23:50 cube ntpd[354]: IO: Listen and drop on 0 v6wildcard [::]:123
> Mar 11 00:23:50 cube ntpd[354]: IO: Listen and drop on 1 v4wildcard 
> 0.0.0.0:123
> Mar 11 00:23:50 cube ntpd[354]: IO: Listen normally on 2 lo 127.0.0.1:123
> Mar 11 00:23:50 cube ntpd[354]: IO: Listen normally on 3 lo [::1]:123
> Mar 11 00:23:50 cube ntpd[354]: IO: Listening on routing socket on fd #20 for 
> interface updates
> Mar 11 00:23:50 cube ntpd[354]: INIT: This system has a 32-bit time_t.
> Mar 11 00:23:50 cube ntpd[354]: INIT: This ntpd will fail on 
> 2038-01-19T03:14:07Z.
> Mar 11 00:23:51 cube ntpd[354]: DNS: dns_probe: us.pool.ntp.org, 
> cast_flags:8, flags:101
> Mar 11 00:23:51 cube ntpd[354]: DNS: dns_check: processing us.pool.ntp.org, 
> 8, 101
> Mar 11 00:23:51 cube ntpd[354]: DNS: dns_check: DNS error: -3, Temporary 
> failure in name resolution
> Mar 11 00:23:51 cube ntpd[354]: DNS: dns_take_status: us.pool.ntp.org=>temp, 9
> Mar 11 00:23:52 cube ntpd[354]: DNS: dns_probe: pool.rcthomas.org, 
> cast_flags:8, flags:121
> Mar 11 00:23:52 cube ntpd[354]: DNS: dns_check: processing pool.rcthomas.org, 
> 8, 121
> Mar 11 00:23:52 cube ntpd[354]: DNS: dns_check: DNS error: -3, Temporary 
> failure in name resolution
> Mar 11 00:23:52 cube ntpd[354]: DNS: dns_take_status: 
> pool.rcthomas.org=>temp, 9
> Mar 11 00:23:56 cube ntpd[354]: IO: Listen normally on 4 eth0 
> 192.168.3.129:123
> Mar 11 00:23:56 cube ntpd[354]: IO: Listen normally on 5 eth0 
> [fe80::d263:b4ff:fe00:912f%2]:123
> Mar 11 00:23:56 cube ntpd[354]: DNS: dns_probe: pool.rcthomas.org, 
> cast_flags:8, flags:121
> Mar 11 00:23:56 cube ntpd[354]: DNS: dns_check: processing pool.rcthomas.org, 
> 8, 121
> Mar 11 00:23:56 cube ntpd[354]: DNS: Pool taking: 192.168.3.207
> Mar 11 00:23:56 cube ntpd[354]: DNS: Pool taking: 192.168.3.111
> Mar 11 00:23:56 cube ntpd[354]: DNS: Pool taking: 192.168.3.4
> Mar 11 00:23:56 cube ntpd[354]: DNS: Pool taking: 192.168.1.14
> Mar 11 00:23:56 cube ntpd[354]: DNS: 

Bug#924192: ntpsec: at boot ntpsec starts before DNS is available

[Rick Thomas]

Package: ntpsec
Version: 1.1.3+dfsg1-2
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
the /etc/ntpsec/ntp.conf file (attached) has two "pool" directives and no 
"server" directives.
So it requires DNS (hence network services) to find out the IP addresses it 
needs for servers.
DNS fails on the first "peer" and (for some reason) succeeds on the second 
"peer".
If ntpsec implemented the "preempt" option on "peer" directives, the first 
"peer" would be 
revisited after a few minutes and all would be well.  But it doesn't.  So the 
first "peer"
is as if it never existed.
   * What exactly did you do (or not do) that was effective (or ineffective)?
Wait several seconds after boot completes then issue "sudo service ntpset 
restart"
   * What was the outcome of this action?
This time around, it sees both sets of "peers".
   * What outcome did you expect instead?
I would have hoped that the systemd stuff would wait until DNS was available 
before starting up ntpsec.
Unfortunately, I don't know systemd configuration well enough to suggest a 
patch.

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

Systemd log files of a representative boot can be provided if necessary.


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

Kernel: Linux 4.19.0-2-armmp (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ntpsec depends on:
ii  adduser  3.118
ii  libc62.28-7
ii  libcap2  1:2.25-2
ii  libssl1.11.1.1a-1
ii  lsb-base 10.2018112800
ii  netbase  5.6
ii  python3  3.7.2-1
ii  python3-ntp  1.1.3+dfsg1-2
ii  tzdata   2018i-1

Versions of packages ntpsec recommends:
ii  cron [cron-daemon]  3.0pl1-132
ii  systemd 241-1

Versions of packages ntpsec suggests:
ii  apparmor   2.13.2-9
ii  ntpsec-doc 1.1.3+dfsg1-2
pn  ntpsec-ntpviz  

-- Configuration Files:
/etc/default/ntpsec changed:
NTPD_OPTS="-g -N"
IGNORE_DHCP="yes"

/etc/ntpsec/ntp.conf changed:
driftfile /var/lib/ntpsec/ntp.drift
leapfile /usr/share/zoneinfo/leap-seconds.list
statsdir /var/log/ntpsec/
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
tos minclock 7  minsane 5
pool pool.rcthomas.org minpoll 3 maxpoll 6 prefer iburst
pool us.pool.ntp.org minpoll 6 maxpoll 10 iburst
restrict default kod nomodify nopeer noquery limited
restrict 127.0.0.1
restrict ::1
restrict 192.168.0.0  mask  255.255.240.0 nomodify
restrict   2001:4978:02d2:0001::0 mask ::::::: 
nomodify


-- no debconf information

Bug#889290: If NTP is installed, then systemd-timesyncd should be disabled.

[Rick Thomas]

Hmmm…

It appears that the systemd package in stretch (9.5) has a patch for this:

/lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf

But this is not present in buster.

Curiouser and curiouser…


Package: systemd 
Version: 232-25+deb9u4
  has the file


Package: systemd 
Version: 239-11
  does not have the file

Enjoy!
Rick

> On Oct 31, 2018, at 3:07 AM, Rick Thomas  wrote:
> 
> Is it possible to disable systemd-timesyncd whenever ntp is installed?
> 
> Apparently, according to Jozsef’s contribution to this bug, the openntpd 
> package has figured out how to do this.  Can the same mechanism (whatever it 
> is) be used in the ntp package?
> 
> Thanks!
> Rick

Bug#889290: If NTP is installed, then systemd-timesyncd should be disabled.

[Rick Thomas]

Is it possible to disable systemd-timesyncd whenever ntp is installed?

Apparently, according to Jozsef’s contribution to this bug, the openntpd 
package has figured out how to do this.  Can the same mechanism (whatever it 
is) be used in the ntp package?

Thanks!
Rick

Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly

[Rick Thomas]

On Sep 9, 2018, at 1:59 AM, Wolfram Sang  wrote:

> On Sat, Sep 08, 2018 at 02:48:01PM -0700, Rick Thomas wrote:
>> Thanks!  Yes, I’ll give it a try.
> 
> Note: You can either build the v4.19-rc1 tar ball which has the patch
> already included. Or you can take your Debian kernel and add this patch:
> 
> http://patchwork.ozlabs.org/patch/960488/
> 
> You can download it as mbox there which gives you a file to apply.

Thank you!

Please remember, I’ve never done this before…  so I’ve still got a couple of 
questions:

How do I get a copy of the v4.19-rc1 tar ball, if I decide to go that way?  And 
once I’ve got it, which section of the kernel handbook do I look in for 
instructions to build it?

And supposing I decide to go the other way and add the patch to my current 
kernel (4.18.0-1-powerpc64) how do I get the patch in a form that I can add it 
to the kernel?  I’m assuming that section 4.2.2 “Simple patching and building” 
is where I go for instructions once I’ve got the patch?

Thanks, and really sorry for my ignorance!  
Rick

Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly

[Rick Thomas]

Thanks!  Yes, I’ll give it a try.

On Sep 8, 2018, at 6:51 AM, Salvatore Bonaccorso  wrote:

> Hi,
> 
> On Mon, Sep 03, 2018 at 11:38:32PM -0700, Rick Thomas wrote:
>> Hi Mathieu,
>> 
>> I’m sorry that I don’t have the expertise to apply a patch and build
>> a kernel.  However, if someone who does have that expertise can
>> build a “.deb’ file and tell me where to download it, I’ll be happy
>> to test and provide detailed feedback.
>> 
>> Another possibility, of course, would be for someone to provide me
>> with step-by-step instructions for building a ‘.deb’ and stand by to
>> answer the inevitable questions.
> 
> The kernel-handbook contains a section on simple patching and
> building, for the case of testing an extra patch, cf.
> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2
> .
> 
> Does this helps you on this?
> 
> Regards,
> Salvatore

Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly

[Rick Thomas]

Hi Mathieu,

I’m sorry that I don’t have the expertise to apply a patch and build a kernel.  
However, if someone who does have that expertise can build a “.deb’ file and 
tell me where to download it, I’ll be happy to test and provide detailed 
feedback.

Another possibility, of course, would be for someone to provide me with 
step-by-step instructions for building a ‘.deb’ and stand by to answer the 
inevitable questions.

Thanks!
Rick

On Sep 3, 2018, at 1:40 AM, Mathieu Malaterre  wrote:

> Hi Rick,
> 
> On Tue, Apr 12, 2016 at 12:08 PM Mathieu Malaterre  wrote:
>> 
>> Dear all,
>> 
>> I am looking for testers for the following patch:
>> 
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741663#20
>> 
>> Wolfram (CC here) is looking for feedback from users for this patch.
> 
> Wolfram is still looking for feedback from user on the patch applied
> recently upstream:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/macintosh/therm_windtunnel.c?id=3e7bed52719de4b5b5fb900869e293eae0bc3f3e
> 
> Could you give it a try ?
> 
> Thanks

Bug#615646: [installation-guide] How do I know which CD has the package I need?

[Rick Thomas]

On Jul 28, 2018, at 10:50 PM, Holger Wansing  wrote:

> +Also, keep in mind: if the CDs/DVDs you are using don't contain some packages
> +you need, you can always install that packages afterwards from your running
> +new Debian system (after the installation has finished). If you need to know,
> +on which CD/DVD to find a specific package, visit
> + url="https://cdimage-search.debian.org/;>https://cdimage-search.debian.org/.

Thanks, Holger,

That addresses my concern very well.

Rick

Bug#615646: [installation-guide] How do I know which CD has the package I need?

[Rick Thomas]

On Jul 28, 2018, at 10:44 AM, Holger Wansing  wrote:

> 
> Robert Cymbala  wrote:
>> QUESTION:  
>>   I burned the first fifteen (15) CD's and GNU/Emacs, which I want to 
>> install, 
>>   is not on them.  How do I find out which CDs I need to burn? (There are 37 
>>   more in cdimage.debian.org/debian-cd/6.0.0/i386/iso-cd/ and I used to burn 
>>   all the CDs for a release but am too lazy to burn all 52 discs this time, 
>>   I only burnt the first 15.)
> 
> Time has changed, we don't provide that big sets of CD images anymore. 
> So the above question is no longer that important.
> 
> However, I would like to add something like the following to chapter 4.1
> (https://d-i.debian.org/manual/en.amd64/ch04s01.html):
> 
> 
> 
> diff --git a/en/install-methods/official-cdrom.xml 
> b/en/install-methods/official-cdrom.xml
> index 512011690..f1f12554d 100644
> --- a/en/install-methods/official-cdrom.xml
> +++ b/en/install-methods/official-cdrom.xml
> @@ -30,6 +30,12 @@ the installation to download the remaining files or 
> additional CDs.
> 
> 
> 
> +Also, keep in mind: if the CD(s) you are using doesn't contain some packages
> +you need, you can always install that packages afterwards from your running
> +new Debian system (after the installation has finished).
> +
> +
> +
> If your machine doesn't support CD booting (only relevant
> on very old PC systems), but you do have a CD set,
> you can use an alternative strategy such as

For some people, getting packages via the Internet after installation is not an 
option.  For example, air-gapped high-security environments, or folks with very 
slow Internet connections (does anyone remember 9600 baud modems?).

Can we acknowledge such situations in the proposed changes?  For them, at 
least, the question in the subject line is still relevant (perhaps with “CD” 
changed to “DVD”, giving a nod to changing times).

Enjoy!
Rick

Bug#904525: release-notes: Links to buster release notes don't work

[Rick Thomas]

Package: release-notes
Severity: normal

Dear Maintainer,

On webpage
   https://www.debian.org/releases/buster/releasenotes
There are a bunch of links that are claimed to be for draft release notes for 
Buster.

Unfortunately, all of them wind up at “Page not found”.

Is this deliberate?  Or is it possibly a result of some recent change of 
servers, or the like?

Is release-notes the right package for this bug report?  If not, then what?

Thanks!
Rick

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

Kernel: Linux 4.17.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#901332: d-i: Offer to shut down / power off instead of reboot at the end

[Rick Thomas]

On Jun 12, 2018, at 8:56 PM, Ben Hutchings  wrote:

>> So, please, at the end, where it tells the reboot message, add
>> a third button that shuts down / powers off the system instead
>> of rebooting.
> 
> Still, I do agree that this would be useful in general.

Especially if it could be pre-seeded.

For example: Imagine setting up a bunch of machines all at once to be 
distributed to various locations after the install.  You can use pre-seeding to 
answer all the questions while you go off and get a cup of tea.  It might be 
better to have them all install then shutdown, rather than install then reboot 
— wasting power and requiring a manual shutdown before moving to the target 
location.

Rick

Bug#896638: debian-cd: Unable to build CD image with unsigned repository

[Rick Thomas]

On Apr 22, 2018, at 1:43 PM, Vagrant Cascadian  wrote:

> Package: debian-cd
> Severity: normal
> Tags: patch
> Control: block 879642 by -1
> 
> With recent changes to apt requiring signed repositories, simple-cdd is
> unable to build an image, as it dynamically generates an unsigned apt
> repository.
> 
> A patch below adds an option to apt to allow insecure repositories when
> ARCHIVE_UNSIGNED=1. An alternate approach would be to add [trusted=yes]
> on each of the sources.list entries.
> 
> I'm fairly sure this won't impact other parts of the build process, but
> not 100% sure.
> 
> live well,
>  vagrant
> 
> commit 9bbd627c7ff5abe006a3596d5d8a2cd8e24758ba
> Author: Vagrant Cascadian 
> Date:   Sun Apr 22 13:28:14 2018 -0700
> 
>Add boolean variable ARCHIVE_UNSIGNED, which configures apt to allow
>insecure repositories.
> 
>In general, use of this option should be avoided, but is useful when
>using a custom dynamically generated local repository, where a signed
>repository wouldn't necessarily add much in the way of security.
> 
> diff --git a/tools/apt-selection b/tools/apt-selection
> index 209e0c5..274e546 100755
> --- a/tools/apt-selection
> +++ b/tools/apt-selection
> @@ -44,6 +44,10 @@ options=" -q -o 
> Dir::State::status=$APTTMP/$THIS_PKGSET/status \
> -o APT::Architectures::=$ARCH \
> -o Acquire::Languages=none"
> 
> +if [ "$ARCHIVE_UNSIGNED"x = "1"x ]; then
> +options="$options -o Acquire::AllowInsecureRepositories=true"
> +fi
> +
> sections=main
> if [ "${NONFREE:-0}" != "0" ] || [ "${EXTRANONFREE:-0}" != "0" ] || [ 
> "${FORCE_FIRMWARE:-0}" != "0" ]; then
>   sections="$sections non-free"
> 

Maybe I’m misunderstanding how this works, but wouldn’t it be better to 
restrict the allowing to the particular repository we need it for, rather than 
allowing it for all repos.  I.e. Isn’t vagrant’s alternative solution a bit 
more secure?

Just my two cents…  trying to be helpful.
Rick

Bug#854822: marked as done (installation-report: U-boot not correctly installed when partitioning with "Guided - use entire disk")

[Rick Thomas]

Great!  Is there an installer image somewhere I can test this with on my 
Cubox-i4x4 ?

Thanks!
Rick

On Jul 15, 2017, at 3:21 PM, Debian Bug Tracking System  
wrote:

> Your message dated Sat, 15 Jul 2017 22:17:18 +
> with message-id 
> and subject line Bug#854822: fixed in partman-base 191+deb9u1
> has caused the Debian Bug report #854822,
> regarding installation-report: U-boot not correctly installed when 
> partitioning with "Guided - use entire disk"
> to be marked as done.
> 
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
> 
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
> 
> 
> -- 
> 854822: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854822
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
> 
> From: Gunnar Wolf 
> Subject: installation-report: U-boot not correctly installed when 
> partitioning with "Guided - use entire disk"
> Date: February 10, 2017 at 9:51:20 AM PST
> To: Debian Bug Tracking System 
> 
> 
> 
> 
> 
> From: Cyril Brulebois 
> Subject: Bug#854822: fixed in partman-base 191+deb9u1
> Date: July 15, 2017 at 3:17:18 PM PDT
> To: 854822-cl...@bugs.debian.org
> 
> 
> Source: partman-base
> Source-Version: 191+deb9u1
> 
> We believe that the bug you reported is fixed in the latest version of
> partman-base, 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 854...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
> 
> Debian distribution maintenance software
> pp.
> Cyril Brulebois  (supplier of updated partman-base 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: SHA256
> 
> Format: 1.8
> Date: Thu, 13 Jul 2017 09:45:14 +0200
> Source: partman-base
> Binary: partman-base partman-utils
> Architecture: source
> Version: 191+deb9u1
> Distribution: stretch
> Urgency: medium
> Maintainer: Debian Install System Team 
> Changed-By: Cyril Brulebois 
> Description:
> partman-base - Partition the storage devices (partman) (udeb)
> partman-utils - Utilities related to partitioning (udeb)
> Closes: 854822
> Changes:
> partman-base (191+deb9u1) stretch; urgency=medium
> .
>   [ Karsten Merker ]
>   * For systems that are known to have their boot firmware on an mmcblk
> device, protect the firmware area on all mmcblk devices (and not
> only on mmcblk0) from being clobbered during guided partitioning
> and add missing whitespace to the corresponding log output.
> (Closes: #854822)
> Checksums-Sha1:
> 65d49a15bd0ca3c01778311d6f5a597ae33dcd52 1873 partman-base_191+deb9u1.dsc
> ff82be90a39e977780dc3ff5580cd9fbca4752b0 173300 partman-base_191+deb9u1.tar.xz
> Checksums-Sha256:
> c78505be41fe4f5e3904c2e33f81782b12875c628448e935627e58d61455b784 1873 
> partman-base_191+deb9u1.dsc
> b03fa6f816e15279e3e87c7e3a7cd475671f65ca1f9f7121ff0ad02940533932 173300 
> partman-base_191+deb9u1.tar.xz
> Files:
> 9ad01e3de42d9034dff7f4705f6e99f0 1873 debian-installer standard 
> partman-base_191+deb9u1.dsc
> 3c0fb9f3270c7ce28bd79aeaec6297f0 173300 debian-installer standard 
> partman-base_191+deb9u1.tar.xz
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> 
> iQIcBAEBCAAGBQJZZzp2AAoJEP+RSvDCs1Ug18EP/RYg23ppH10l3J0U2zrA2G1I
> jLI6A1mWErWDNZW0iz4o5j1FtkuDIXq57ksEvHp5+O/t02WpL/7ad2o05rbK6pEQ
> gG3kxanAkEJGAvlrjFjcqeO7BNfYgfPVqpmBZNnyzWG1hDly6R1aqhZtZ+QjKHH0
> IFEPaSIqNk5FaFMhZbRjrFhr3pzHHvTZFtue0mqTeL/4rrbi6FFtsd1PW7vVWWup
> 0yBcAAlsU+JN1lpzXhZBn0LAXXdpawpH1eAvBm7opyjuPf640Xzfw3eu1G1wUv8q
> RwkdJk5fh4ZUMhjkl5Mvini04lq96GVhCusO7avRnQ+CfRJppyPBa+oRUlCWSmXS
> SpQIuUhDPBWj32ty5jC0WMymOgoK9dGTm51nuUCEMitXC7cdhh6V8YSAPlV8NYFE
> l7pm+XUg8vY3bOP6UfH6gi6ZMTBs3B3sahU/aF5R3B6B5foHIQv3ZTU4CWMZRsH1
> yQ9c8xDiEkhodTRKhumSEm/IVfWijn5FmtEoPrTqcQLHlOz3Cfljy4T9dE59y8/a
> F5f7q3S+Gm90mPrHq3k9TdyhChz5QZ49LEXz917myl7ZqozjKryX1YErwrTV6s9i
> EzEkONYfFT3rsCGC0MXXqLWAIja3NyNfOsLLld3ZhgDrV7x4MsZHhkrwrAoqu1AS
> dMDs2okWNxHJgYOZipMv
> =jdYg
> -END PGP SIGNATURE-
> 

Bug#854822: installation-report: U-boot not correctly installed when partitioning with "Guided - use entire disk"

[Rick Thomas]

On Feb 10, 2017, at 12:43 PM, Cyril Brulebois  wrote:

> Hi,
> 
> Karsten Merker  (2017-02-10):
>> when using the "Guided - use entire disk" option, partman by
>> default clobbers the boot sector and the area after it (where
>> u-boot is located) to make sure that there are no remains of old
>> partition tables.  We have code in partman-base that disables
>> this clobbering on systems of which we know that u-boot would be
>> damaged (which includes systems based on Freescale SoCs such as
>> your Cubox-i), but this doesn't work in your case as we currently
>> only disable the clobbering for /dev/mmcblk0 while your SD card
>> shows up as /dev/mmcblk1. I am not 100% sure about that, but IIRC
>> with older kernels the SD card in the cubox-i has shown up as
>> /dev/mmcblk0. 
>> 
>> The relevant code in partman-base can be seen here:
>> https://anonscm.debian.org/cgit/d-i/partman-base.git/tree/parted_server.c#n1377
>> 
>> The easiest solution would be to check for /dev/mmcblk instead of
>> /dev/mmcblk0. If nobody has objections against this change, I'll
>> modify partman-base accordingly and upload a new version (CCing the
>> partman-base uploaders Max Vozeler, Anton Zinoviev, Colin Watson and
>> Christian Perrier and Kibi as the d-i release manager).
> 
> That seems like a fair approach, feel free to go ahead; thanks.
> 
> 
> KiBi.

It appears that as of Stretch 9.0.0 this fix has not made it into the 
distribution.
Is there anything I can do to help make it happen?

Rick

Bug#834974: Info received (installation-reports: Stretch 9.0.0 on Cubox-i4Pro fails to boot after install)

[Rick Thomas]

Oooops!

syslog is mode 600, and I wasn’t root when I created the cpio archive.

Here is is



syslog.gz
Description: GNU Zip compressed data


Sorry!
Rick

On Jun 24, 2017, at 2:23 PM, Cyril Brulebois <k...@debian.org> wrote:

> Hi again,
> 
> Rick Thomas <rbtho...@pobox.com> (2017-06-24):
>> I did attach all the log files to one of my messages — as a gzipped cpio 
>> archive.
>> 
>> The log files are at:
>>   
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=834974;filename=installer-logs.cpio.gz;msg=77
>> 
>> The message itself with the attachment is at:
>>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834974#77
>> 
>> Let me know if you would like me to perform further tests.
> 
> There's no syslog in there?
> 
>$ zcat installer-logs.cpio.gz | cpio -it | sort
>127 blocks
>.
>cdebconf
>hardware-summary
>lsb-release
>status
> 
> 
> KiBi.

Bug#834974: Info received (installation-reports: Stretch 9.0.0 on Cubox-i4Pro fails to boot after install)

[Rick Thomas]

On Jun 24, 2017, at 8:41 AM, Cyril Brulebois <k...@debian.org> wrote:

> Hi Rick,
> 
> Rick Thomas <rbtho...@pobox.com> (2017-06-23):
>> I re-installed u-boot on the uSDcard.  And with that, it booted up a
>> treat.
>> 
>> So somehow the u-boot binary on the uSDcard is getting clobbered in
>> the installation process.
> 
> Thanks for your follow-ups.
> 
> Any chance you could attach the installer's syslog file? It should be
> stored under /var/log/installer.
> 
> 
> KiBi.

Hi KiBi,

I did attach all the log files to one of my messages — as a gzipped cpio 
archive.

The log files are at:
   
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=834974;filename=installer-logs.cpio.gz;msg=77

The message itself with the attachment is at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834974#77

Let me know if you would like me to perform further tests.

Hope that helps!
Rick

Bug#834974: Info received (installation-reports: Stretch 9.0.0 on Cubox-i4Pro fails to boot after install)

[Rick Thomas]

I re-installed u-boot on the uSDcard.  And with that, it booted up a treat.

So somehow the u-boot binary on the uSDcard is getting clobbered in the 
installation process.

Rick

Bug#834974: installation-reports: Stretch 9.0.0 on Cubox-i4Pro fails to boot after install

[Rick Thomas]

Package: installation-reports
Followup-For: Bug #834974

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
I was attempting a test installation of the new Stretch release.
   * What exactly did you do (or not do) that was effective (or ineffective)?
Followed instructions from 
  https://www.debian.org/releases/stretch/armhf/ch05s01.html.en
using SDcard image made from from
  
http://http.us.debian.org/debian/dists/stretch/main/installer-armhf/current/images/hd-media/SD-card-images/firmware.MX6_Cubox-i.img.gz
2017-06-15 08:34 205K
and
  
http://http.us.debian.org/debian/dists/stretch/main/installer-armhf/current/images/hd-media/SD-card-images/partition.img.gz
2017-06-15 08:34 19M
and the debian-9.0.0-armhf-DVD-1.iso installer image available on a USB stick 
formatted as ext2 to save network bandwidth.

   * What was the outcome of this action?
Installer ran as expected.  I installed to the SDcard all-in-one partition with 
separate /boot.
But when it got to the end and wanted to reboot, after I answered "yes" it just 
hung.
It appears that u-boot is not getting written to the front of the SDcard.  
There is a large area of zeros where I would expect
to see boot binaries.

A second observation is that the installer was unable to dhcp the IPv4 address 
for the device.
I had to manually configure the network.

   * What outcome did you expect instead?
I expected to see it be able to complete dhcp and get its network configuration 
automatically.
I also expected it to boot into the installed system.

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


-- Package-specific info:

Boot method: booted from uSD card with installer DVD .iso available on USB stick
Image version: 
http://http.us.debian.org/debian/dists/stretch/main/installer-armhf/current/images/hd-media/SD-card-images/firmware.MX6_Cubox-i.img.gz
Date: June 22nd, 2017

Machine: Cubox-i4Pro
Partitions: 
rbthomas@cube:~$ df -Tl /mnt /mnt/boot
Filesystem Type 1K-blocks   Used Available Use% Mounted on
/dev/sdc2  ext4  57804576 728992  54109568   2% /mnt
/dev/sdc1  ext2240972  24975203556  11% /mnt/boot
The machine is running an older installation (that does boot) right now with 
the SDcard mounted on /mnt and /mnt/boot


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

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

Comments/Problems:

See above.  I'm attaching the files /var/log/installer directory to this report.


-- 

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-logs.cpio.gz
Description: application/gzip

Bug#861326: ntp: please put ntp vers 1:4.2.8p10+dfsg-1 in jessie-backports. It has important security and bug fixes.

[Rick Thomas]

Package: ntp
Version: 1:4.2.6.p5+dfsg-7+deb8u2
Severity: wishlist

Dear Maintainer,

NTP versin 1:4.2.8p10+dfsg-1 has several important security and bug fixes. It 
should be available for jessie users.

Would it be possible to put it in jessie-backports?

Thanks!

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

Kernel: Linux 4.9.0-0.bpo.2-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 ntp depends on:
ii  adduser  3.113+nmu3
ii  dpkg 1.17.27
ii  libc62.19-18+deb8u7
ii  libcap2  1:2.24-8
ii  libedit2 3.1-20140620-2
ii  libopts251:5.18.4-3
ii  libssl1.0.0  1.0.1t-1+deb8u6
ii  lsb-base 4.1+Debian13+nmu1
ii  netbase  5.3

Versions of packages ntp recommends:
ii  perl  5.20.2-3+deb8u6

Versions of packages ntp suggests:
pn  ntp-doc  

-- Configuration Files:
/etc/ntp.conf changed:
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
tos minclock 7  minsane 5
pool us.pool.ntp.org iburst preempt
pool ntp.sixxs.net iburst preempt
server 127.127.1.1 iburst
fudge 127.127.1.1 stratum  13 # everybody else
restrict -4 default kod notrap nomodify noquery nopeer limited
restrict -6 default kod notrap nomodify noquery nopeer limited
restrict 127.0.0.1
restrict ::1
restrict source notrap nomodify
restrict 192.168.0.0  mask  255.255.240.0 nomodify
restrict   2001:4978:02d2:0001::0 mask ::::::: 
nomodify


-- no debconf information

Bug#856441: Please restore OpenRD support - works, yay! also on openrd ultimate

[Rick Thomas]

On 03/25/17 17:40, Rick Thomas wrote:



On 03/08/17 17:44, Vagrant Cascadian wrote:

On Feb 28, 2017, at 6:39 PM, Martin Michlmayr <t...@cyrius.com> wrote:

Debian introduced OpenRD images and later removed them because the
stopped working (see #837629).

A fix has now been posted upstream:
https://lists.denx.de/pipermail/u-boot/2017-February/282676.html


Grabbed the patch from upstream, included in and built some packages for
you to test:

  deb http://cascadia.debian.net/~vagrant/debian UNRELEASED main

Should have a u-boot for armel with the upstream patch applied, and the
openrd* boards enabled.

Please follow-up with how the tests went...



I would like to kindly request that the OpenRD images be restored
for stretch.  The reasons are:

* stretch will be the last release to include support for the armel
  architecture, so it would be good to get support for this device
  as complete as possible.
* While Debian can be installed with the default u-boot shipped on
  the OpenRD, the one provided by Debian is much more modern.

On the other hand, there are few OpenRD users, so this is not high
priority.

I haven't spoken to the release team but in the past they have been
supportive towards changes for hardware support.


If testing goes well, we'll see what the release team thinks...



Rick Thomas has offered to test on the OpenRD Ultimate and (I believe)
Client.


And Phil Hands too. Yay!


live well,
  vagrant



Sorry it took me so long to get to this test.
Real-life's a demanding mistress!

I'm now running
U-Boot 2016.11+dfsg1-4~20170308~1 (Mar 09 2017 - 01:27:49 +)
on my openrd client test machine.  It boots just fine.

I'm looking forward to seeing this in Jessie!

Thank you very much!

Rick


I just installed it on my openrd ultimate as well.  Works a treat!

Thanks!
Rick

Bug#856441: Please restore OpenRD support - works, yay!

[Rick Thomas]

On 03/08/17 17:44, Vagrant Cascadian wrote:

On Feb 28, 2017, at 6:39 PM, Martin Michlmayr <t...@cyrius.com> wrote:

Debian introduced OpenRD images and later removed them because the
stopped working (see #837629).

A fix has now been posted upstream:
https://lists.denx.de/pipermail/u-boot/2017-February/282676.html


Grabbed the patch from upstream, included in and built some packages for
you to test:

  deb http://cascadia.debian.net/~vagrant/debian UNRELEASED main

Should have a u-boot for armel with the upstream patch applied, and the
openrd* boards enabled.

Please follow-up with how the tests went...



I would like to kindly request that the OpenRD images be restored
for stretch.  The reasons are:

* stretch will be the last release to include support for the armel
  architecture, so it would be good to get support for this device
  as complete as possible.
* While Debian can be installed with the default u-boot shipped on
  the OpenRD, the one provided by Debian is much more modern.

On the other hand, there are few OpenRD users, so this is not high
priority.

I haven't spoken to the release team but in the past they have been
supportive towards changes for hardware support.


If testing goes well, we'll see what the release team thinks...



Rick Thomas has offered to test on the OpenRD Ultimate and (I believe)
Client.


And Phil Hands too. Yay!


live well,
  vagrant



Sorry it took me so long to get to this test.
Real-life's a demanding mistress!

I'm now running
U-Boot 2016.11+dfsg1-4~20170308~1 (Mar 09 2017 - 01:27:49 +)
on my openrd client test machine.  It boots just fine.

I'm looking forward to seeing this in Jessie!

Thank you very much!

Rick

Bug#856441: Please restore OpenRD support

[Rick Thomas]

On Mar 22, 2017, at 4:00 AM, Philip Hands <p...@hands.com> wrote:

> Rick Thomas <rbtho...@pobox.com> writes:
> 
>> On Mar 10, 2017, at 7:34 AM, Philip Hands <p...@hands.com> wrote:
>> 
>>> Vagrant Cascadian <vagr...@debian.org> writes:
>>> 
>>>>> On Feb 28, 2017, at 6:39 PM, Martin Michlmayr <t...@cyrius.com> wrote:
>>>>>> Debian introduced OpenRD images and later removed them because the
>>>>>> stopped working (see #837629).
>>>>>> 
>>>>>> A fix has now been posted upstream:
>>>>>> https://lists.denx.de/pipermail/u-boot/2017-February/282676.html
>>>> 
>>>> Grabbed the patch from upstream, included in and built some packages for
>>>> you to test:
>>>> 
>>>> deb http://cascadia.debian.net/~vagrant/debian UNRELEASED main
>>>> 
>>>> Should have a u-boot for armel with the upstream patch applied, and the
>>>> openrd* boards enabled.
>>>> 
>>>> Please follow-up with how the tests went...
>> 
>> I’m finally getting time to take a look at this…  (sigh, ain’t real life 
>> wonderful! /-: )
>> 
>> But before I do, I want to make sure I’ve got a clear retreat path incase it 
>> bricks my machine.
>> 
>> It’s currently running “U-Boot 2016.03+dfsg1-6 (Jun 28 2016 - 07:38:27 
>> +)” and I’d like to be able to re-install that version if I need to.
>> 
>> But I seem to have lost the .deb file with that version.  I obviously had it 
>> in the past, because I must have used it to install with, but it’s gone now.
>> 
>> Does anybody know where I can get old u-boot .deb files?
> 
> Would this be the one?
> 
>  http://snapshot.debian.org/package/u-boot/2016.03%2Bdfsg1-6/
> 
> Cheers, Phil.

Wow! Thanks, Phil!  I never knew about the snapshot repo.  Does it have 
everything that ever appeared in a debian distro?  What else does it have?

Thanks!
Rick

Bug#856441: Please restore OpenRD support

[Rick Thomas]

On Mar 10, 2017, at 7:34 AM, Philip Hands  wrote:

> Vagrant Cascadian  writes:
> 
>>> On Feb 28, 2017, at 6:39 PM, Martin Michlmayr  wrote:
 Debian introduced OpenRD images and later removed them because the
 stopped working (see #837629).
 
 A fix has now been posted upstream:
 https://lists.denx.de/pipermail/u-boot/2017-February/282676.html
>> 
>> Grabbed the patch from upstream, included in and built some packages for
>> you to test:
>> 
>>  deb http://cascadia.debian.net/~vagrant/debian UNRELEASED main
>> 
>> Should have a u-boot for armel with the upstream patch applied, and the
>> openrd* boards enabled.
>> 
>> Please follow-up with how the tests went...

I’m finally getting time to take a look at this…  (sigh, ain’t real life 
wonderful! /-: )

But before I do, I want to make sure I’ve got a clear retreat path incase it 
bricks my machine.

It’s currently running “U-Boot 2016.03+dfsg1-6 (Jun 28 2016 - 07:38:27 +)” 
and I’d like to be able to re-install that version if I need to.

But I seem to have lost the .deb file with that version.  I obviously had it in 
the past, because I must have used it to install with, but it’s gone now.

Does anybody know where I can get old u-boot .deb files?

Thanks!
Rick

Bug#856441: Please restore OpenRD support

[Rick Thomas]

For the record, and as Martin said, I have both an OpenRD Ultimate and a Client 
machine.  Both are available for testing new releases.

Rick

On Feb 28, 2017, at 6:39 PM, Martin Michlmayr <t...@cyrius.com> wrote:

> Package: u-boot
> Version: 2016.11+dfsg1-3
> Severity: wishlist
> 
> Debian introduced OpenRD images and later removed them because the
> stopped working (see #837629).
> 
> A fix has now been posted upstream:
> https://lists.denx.de/pipermail/u-boot/2017-February/282676.html
> 
> I would like to kindly request that the OpenRD images be restored
> for stretch.  The reasons are:
> 
> * stretch will be the last release to include support for the armel
>   architecture, so it would be good to get support for this device
>   as complete as possible.
> * While Debian can be installed with the default u-boot shipped on
>   the OpenRD, the one provided by Debian is much more modern.
> 
> On the other hand, there are few OpenRD users, so this is not high
> priority.
> 
> I haven't spoken to the release team but in the past they have been
> supportive towards changes for hardware support.
> 
> Rick Thomas has offered to test on the OpenRD Ultimate and (I believe)
> Client.
> 
> -- 
> Martin Michlmayr
> http://www.cyrius.com/

Bug#854946: ntp: please backport ntp version from stretch to jessie-backports

[Rick Thomas]

Package: ntp
Version: 1:4.2.8p9+dfsg-2.1
Severity: wishlist

Dear Maintainer,

It would sure be nice to have the 1:4.2.8p9 version of ntp available for Jessie.

Thanks for your consideration!

Bug#842040: Please add https support

[Rick Thomas]

On Nov 18, 2016, at 10:22 AM, Martin Michlmayr  wrote:

> * Philipp Kern  [2016-11-18 17:19]:
>>> Thanks for the CC.  I just added wget-udeb and it adds 345 KB,
>>> which breaks the orion5x-qnap image.  However, this image is really
>>> quite a special case and I don't want to block https support because
>>> of it.  I can always exclude wget-udeb from this particular image.
>> 
>> So how do we move forward here? Exclude wget-udeb from the orion5x-qnap
>> image and otherwise include it by default?
> 
> That should work.

Are there other machines that have equally sever size restrictions?

Rick

Bug#837629: OpenRD* with debian's u-boot 2016.09

[Rick Thomas]

On 11/02/16 10:38, Vagrant Cascadian wrote:

I've uploaded u-boot 2016.11~rc3 to the cascadia.debian.net
repository. I won't hold my breath, but give it a try...
Good thing you didn't hold your breath.  I tried it.  Same result as 
before:  No response after "reset".


I think I heard that support for armel will be withdrawn from Debian 
after Stretch.  If that's true,

there's not much percentage in expending any more effort on this project.

It was worth a try, I guess, but facts are facts and time marches on.

Let me know if there's anything else I can do that would be helpful. For 
example, I've got a couple of sheevaplug devices.  Has anything more 
recent than "2016.09-rc2+dfsg1-1 (Aug 30, 2016)" been

tested on a sheevaplug?

Rick

Bug#837629: OpenRD* with debian's u-boot 2016.09

[Rick Thomas]

On Nov 2, 2016, at 10:38 AM, Vagrant Cascadian  wrote:

> I've uploaded u-boot 2016.11~rc3 to the cascadia.debian.net
> repository. I won’t hold my breath, but give it a try...

I will.  No promises on the target date, but “soon”!  (-;

> Another option which might help debug the issue is to build u-boot
> mainline from source with an older GCC, such as what's shipped in
> jessie. You could then build the individual targets rather than the
> whole package, and it shouldn't take too long. Could also insert some
> printf statements in the early boot, maybe to figure out exactly where
> it is failing...

I’ve never done anything like that.  (Though I’m familiar with the usual UNIX 
software development tools, such as gnu-autoconf, gcc and make, etc.  And I’d 
be glad to learn what I don’t know.) Would you be willing to walk me through 
the steps?

Thanks!
Rick

Bug#837629: OpenRD* with debian's u-boot 2016.09

[Rick Thomas]

On Oct 5, 2016, at 1:26 PM, Vagrant Cascadian <vagr...@debian.org> wrote:

> On 2016-10-03, Rick Thomas wrote:
>> On Oct 1, 2016, at 3:39 PM, Vagrant Cascadian <vagr...@debian.org> wrote:
>>> On 2016-09-17, Rick Thomas wrote:
>>>> On Sep 16, 2016, at 3:19 PM, Vagrant Cascadian <vagr...@debian.org> wrote:
>>>>> https://bugs.debian.org/837629
> ...
>>> deb http://cascadia.debian.net/~vagrant/debian UNRELEASED main
>>> 
>>> The repository should be signed by my key, available in the
>>> debian-keyring package in the archive
>>> (F0ADA5240891831165DF98EA7CFCD8CD257721E9).
>>> 
>>> There were two critical fixes in 2016.09.01, *maybe* they fix the issue?
> 
> And now uploaded 2016.11~rc1 to my "UNRELEASED" repository, please test
> that...
> 
> 
>>> If not, I'll likely be removing OpenRD* from the packages on future
>>> uploads.
> ...
>> Sadly, it doesn’t look like it fixed the problem.  Still nothing after
>> installing the new u-boot.kwb and typing “reset”.
>> 
>> let me know if there’s anything more I can do to help…
> 
> If it's not fixed in 2016.11~rc1, the only thing left to try is git
> bisecting the issue...
> 
> 
> live well,
>  vagrant

Hi,

It’s been an “interesting” month (in the sense of the ancient curse: “May you 
live in interesting times!”)

Unfortunately testing u-boot on OpenRD fell by the wayside.
I gather that the current u-boot in experimental has OpenRD support removed?

But… as of now, all the “interesting” bits are temporarily under control.
Would you like me to test something?

Rick

Bug#837629: OpenRD* with debian's u-boot 2016.09

[Rick Thomas]

On Oct 5, 2016, at 1:26 PM, Vagrant Cascadian  wrote:

> And now uploaded 2016.11~rc1 to my "UNRELEASED" repository, please test
> that…

Will do. Sometime this weekend.

> 
>> let me know if there’s anything more I can do to help…
> 
> If it's not fixed in 2016.11~rc1, the only thing left to try is git
> bisecting the issue...

Are you located in the US?

If you think it would help, I could loan you one of the OpenRD devices,
as long as I can ship it without getting customs and immigration involved.

Rick

Bug#837629: OpenRD* with debian's u-boot 2016.09

[Rick Thomas]

On Oct 1, 2016, at 3:39 PM, Vagrant Cascadian <vagr...@debian.org> wrote:

> On 2016-09-17, Rick Thomas wrote:
>> On Sep 16, 2016, at 3:19 PM, Vagrant Cascadian <vagr...@debian.org> wrote:
>>> https://bugs.debian.org/837629
>>> 
>>> If it can't be fixed, I'll likely remove OpenRD ultimate at some point
>>> so that u-boot 2016.09 can migrate to stretch... but it would be more
>>> ideal to fix it, of course! :)
>> 
>> It looks like you’ll have to pull OpenRD support out of this version.
>> I tried 2016.09+dfsg-1 on my OpenRD “Client”.  I got the same result
>> with it as I got with 2016.09~rc2+dfsg1-1 on the “Ultimate”, no
>> response following u-boot “reset” command.
> 
> I've uploaded packages based on 2016.09.01 to:
> 
>  deb http://cascadia.debian.net/~vagrant/debian UNRELEASED main
> 
> The repository should be signed by my key, available in the
> debian-keyring package in the archive
> (F0ADA5240891831165DF98EA7CFCD8CD257721E9).
> 
> There were two critical fixes in 2016.09.01, *maybe* they fix the issue?
> 
> If not, I'll likely be removing OpenRD* from the packages on future
> uploads.
> 
> 
> live well,
>  vagrant

Sadly, it doesn’t look like it fixed the problem.  Still nothing after 
installing the new u-boot.kwb and typing “reset”.

let me know if there’s anything more I can do to help…

Rick

Bug#837629: OpenRD* with debian's u-boot 2016.09

[Rick Thomas]

OK.  I’ll give it a try.

More when I know more.

Rick

On Oct 1, 2016, at 3:39 PM, Vagrant Cascadian <vagr...@debian.org> wrote:

> On 2016-09-17, Rick Thomas wrote:
>> On Sep 16, 2016, at 3:19 PM, Vagrant Cascadian <vagr...@debian.org> wrote:
>>> https://bugs.debian.org/837629
>>> 
>>> If it can't be fixed, I'll likely remove OpenRD ultimate at some point
>>> so that u-boot 2016.09 can migrate to stretch... but it would be more
>>> ideal to fix it, of course! :)
>> 
>> It looks like you’ll have to pull OpenRD support out of this version.
>> I tried 2016.09+dfsg-1 on my OpenRD “Client”.  I got the same result
>> with it as I got with 2016.09~rc2+dfsg1-1 on the “Ultimate”, no
>> response following u-boot “reset” command.
> 
> I've uploaded packages based on 2016.09.01 to:
> 
>  deb http://cascadia.debian.net/~vagrant/debian UNRELEASED main
> 
> The repository should be signed by my key, available in the
> debian-keyring package in the archive
> (F0ADA5240891831165DF98EA7CFCD8CD257721E9).
> 
> There were two critical fixes in 2016.09.01, *maybe* they fix the issue?
> 
> If not, I'll likely be removing OpenRD* from the packages on future
> uploads.
> 
> 
> live well,
>  vagrant

Bug#837629: OpenRD* with debian's u-boot 2016.09

[Rick Thomas]

On Sep 16, 2016, at 3:19 PM, Vagrant Cascadian  wrote:

> There is at one report of an OpenRD ultimate that would not boot with
> the 2016.09~rc2 version of u-boot in debian. Uploaded 2016.09+dfsg-1 to
> unstable a few days ago. Would you be able to confirm if OpenRD variants
> that you have still work with the version in unstable?
> 
>  https://bugs.debian.org/837629
> 
> If it can't be fixed, I'll likely remove OpenRD ultimate at some point
> so that u-boot 2016.09 can migrate to stretch... but it would be more
> ideal to fix it, of course! :)
> 
> 
> live well,
>  vagrant

Sorry!

It looks like you’ll have to pull OpenRD support out of this version.  I tried 
2016.09+dfsg-1 on my OpenRD “Client”.  I got the same result with it as I got 
with 2016.09~rc2+dfsg1-1 on the “Ultimate”, no response following u-boot 
“reset” command.

Enjoy!
Rick

Bug#837629: u-boot 2016.09 in Debian

[Rick Thomas]

On Sep 15, 2016, at 10:43 PM, Vagrant Cascadian <vagr...@debian.org> wrote:

> Control: severity 837629 serious
> 
> On 2016-09-14, Rick Thomas wrote:
>> On Sep 14, 2016, at 5:31 PM, Vagrant Cascadian <vagr...@debian.org> wrote:
>> 
>>> Worst case, we have to remove it from stretch again if it really is that
>>> bad...
>> 
>> I’ll certainly do the test.  If it still doesn’t work on the OpenRD, I
>> would not remove it from stretch just yet.  Frankly, there just aren’t
>> that many OpenRD machines out there, and it works on everything else
>> we’ve tested it on — including my non-ESATA SheevaPlug.  If we can’t
>> fix it for OpenRD, we’ll have to put a warning in NEWS.Debian, but
>> IMHO that’s not a reason for denying its benefits to all the other
>> machine types.
> 
> No, a warning in NEWS.Debian is not good enough; I meant removing the
> targets that "brick" devices. There's no point in shipping something
> known to be broken in ways that cause boot failures.

That would work, too.

> At one point I disabled the OpenRD* targets as it was failing to
> build... now we're in a similar situation, only they fail to boot at all
> even though they build, which is considerably more dangerous...
> 
> Upgrading the severity to prevent migration to stretch, until we have
> a better handle on the situation…

OK.  I’ll do the test ASAP (probably Friday or Saturday).  Please let me know 
if there’s anything else I can do to help get this debugged.  I’ll also try it 
on my OpenRD “Client” machine, incase the problem is specific to that one 
device.

> live well,
>  vagrant

Bug#837629: u-boot 2016.09 in Debian

[Rick Thomas]

> On Sep 12, 2016, at 2:37 PM, Vagrant Cascadian  wrote:
> 
> On 2016-09-10, Karsten Merker wrote:
>> On Mon, Sep 05, 2016 at 09:22:23AM -0700, Vagrant Cascadian wrote:
>>> The current u-boot packages in Debian experimental (2016.09~rc2+dfsg1-1)
>>> appear to be working fine for the platforms I've tested, and I would
>>> like to upload 2016.09 to unstable in the next few weeks, which is
>>> scheduled to be released on September 12th:
> 
> And uploaded to Debian unstable just now…

in light of bug 837629 (u-boot 2016.09~rc2+dfsg1-1 bricks my openrd ultimate), 
is there enough difference between that and the version you just uploaded to 
unstable to warrant my trying the version from unstable?

Thanks!
Rick

Bug#837629: u-boot 2016.09 in Debian

[Rick Thomas]

On Sep 14, 2016, at 5:31 PM, Vagrant Cascadian  wrote:

> Worst case, we have to remove it from stretch again if it really is that
> bad...

I’ll certainly do the test.  If it still doesn’t work on the OpenRD, I would 
not remove it from stretch just yet.  Frankly, there just aren’t that many 
OpenRD machines out there, and it works on everything else we’ve tested it on — 
including my non-ESATA SheevaPlug.  If we can’t fix it for OpenRD, we’ll have 
to put a warning in NEWS.Debian, but IMHO that’s not a reason for denying its 
benefits to all the other machine types.

BTW, are there in fact any new features, or is it just a collection of bug 
fixes?

Enjoy!
Rick

Bug#837629: u-boot 2016.09~rc2+dfsg1-1 bricks my openrd ultimate

[Rick Thomas]

Package: u-boot
Version: 2016.09~rc2+dfsg1-1
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
As requested by Vagrant I'm testing u-boot 2016.09~rc2+dfsg1-1 on my OpenRD 
Ultimate machine.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I followed the instructions for upgrading u-boot on Martin's web page at
 https://www.cyrius.com/debian/kirkwood/openrd/uboot-upgrade/
   * What was the outcome of this action?
After telling u-boot to "reset", the machine went dead.  There was no output on 
the serial console, no answer to ping ... nothing.
   * What outcome did you expect instead?
I expected it to reset and reboot.  But it didn't do that.

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

I unbricked it follwing the instructions at
https://www.newit.co.uk/forum/index.php?topic=2835.0
and I'm writing this bugreport on it.  It boots using
U-Boot 2016.03+dfsg1-3 (Apr 04 2016 - 18:23:06 +)

Please advise what I can do to help debug this.


-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (900, 'stable-updates'), (900, 'testing'), (900, 'stable'), (50, 
'unstable')
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)

-- no debconf information

Bug#836925: u-boot: installation report for u-boot and u-boot-tools 2016.09~rc2+dfsg1-1

[Rick Thomas]

On Sep 12, 2016, at 2:30 PM, Vagrant Cascadian <vagr...@aikidev.net> wrote:

> Control: severity 836925 important
> 
> On 2016-09-07, Rick Thomas wrote:
>> I installed the new u-boot using the procedure in
>> /usr/share/doc/u-boot/README.Debian
>> 
>> The newly installed u-boot loaded and executed after a linux "reboot"
>> command.
>> 
>> Unfortunately it destroyed the u-boot environment, so it tried to boot
>> using the default env.  This failed to boot Linux.
> 
> What version of u-boot were you upgrading from?

I’m pretty sure it was “U-Boot 2016.01-rc3+dfsg1-3 (Jan 02 2016 - 23:19:11 
+)".  That’s the version on its twin.  I’m pretty sure I upgraded them both 
at the same time with the same version.

In case it matters, the /boot partition is on the SDcard.

> 
> The u-boot env values were changed somewhere around 2016.01, possibly:
> 
>  https://bugs.debian.org/781874
> 
> Or has the u-boot environment configuration changed again since then?

It seems likely that the environment configuration changed between 
2016.01-rc3+dfsg1-3 and 2016.09~rc2+dfsg1-1.  Would it be possible for you to 
check that?

> I went to Martin's page,
>> https://www.cyrius.com/debian/kirkwood/sheevaplug/install/ , and
>> followed the instructions there to restore the environment for booting
>> from the SD card.  I also had to restore the "ethaddr" u-boot
>> environment variable.
> 
>> After having restored the u-boot environment, I issued a "reset", and
>> it then happily booted as expected.
> 
>> I'd recommend that /usr/share/doc/u-boot/README.Debian give a warning
>> about needing to restore the u-boot environment, at least for the
>> sheevaplug.
> 
> Or NEWS.Debian, given that it can actually cause a failure to
> boot.

Yeah, you’re right.  NEWS.Debian would be the right place.

> If you could propose some text describing the issue, when it is
> encountered, and what to do about it, that would be helpful; the details
> of the issue are a bit unclear to me to start writing anything.

If you can verify exactly when the environment config changed, I’ll try to 
describe what I did to fix the problem.

> live well,
>  vagrant

Bug#836925: u-boot: installation report for u-boot and u-boot-tools 2016.09~rc2+dfsg1-1

[Rick Thomas]

Package: u-boot
Version: 2016.09~rc2+dfsg1-1
Severity: normal

I installed u-boot and u-boot-tools from the Debian experimental repo -- 
versions 2016.09~rc2+dfsg1-1

I installed the new u-boot using the procedure in 
/usr/share/doc/u-boot/README.Debian

The newly installed u-boot loaded and executed after a linux "reboot" command.

Unfortunatels it destroyed the u-boot environment, so it tried to boot using 
the default env.  This failed to boot Linux.

I went to Martin's page, 
https://www.cyrius.com/debian/kirkwood/sheevaplug/install/ , and followed the 
instructions there to restore the environment for booting from the SD card.  I 
also had to restore the "ethaddr" u-boot environment variable.

After having restored the u-boot environment, I issued a "reset", and it then 
happily booted as expected.

I'd recommend that /usr/share/doc/u-boot/README.Debian give a warning about 
needing to restore the u-boot environment, at least for the sheevaplug.

-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (900, 'stable-updates'), (900, 'testing'), (900, 'stable'), (50, 
'unstable')
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)

-- no debconf information

Bug#834974: Installation Report: Stretch Alpha 7 on Cubox-i4pro

[Rick Thomas]

On Sep 4, 2016, at 3:12 AM, Rick Thomas <rbtho...@pobox.com> wrote:

>> On Sep 2, 2016, at 5:12 PM, Vagrant Cascadian <vagr...@debian.org> wrote:
>> 
>>> I'd be curious if you re-install and delete each partition individually
>>> and re-create manually vs. using one of the auto-partitioning methods.
> 

Having messed up my first try at this (albeit in a way that shed some light on 
the problem), I resolved to try again.

I followed the standard script and did the Testing install.  This time I did 
the manual partitioning correctly, deleting the first (and only) partition on 
the uSD and creating two partitions in the resulting free space, i.e. /boot and 
root.

As expected, when it came time to reboot from the installer to the installed 
system, it hung and did not reboot.

However, when I un-plugged and re-plugged the Cubox, just to see what would 
happen, lo and behold, It booted! And the installed system appears to be intact.

The only unusual thing is that when it was starting up, u-boot remarked, “*** 
Warning - bad CRC, using default environment”.  What this seems to be saying is 
that the “make bootable” part of the installer is not putting the boot script 
(or, indeed, any of the u-boot environment) where u-boot is expecting to find 
it.

I wonder if it’s possible that the installer is using the wrong version of 
“/etc/fw_env.config”?

Maybe this is a clue — on my machine running testing, I have the following:

> rbthomas@cube:~$ cat /usr/share/doc/u-boot-tools/examples/mx6cuboxi.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
> /dev/mmcblk00x8 0x2000
> rbthomas@cube:~$ cat /etc/fw_env.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
> /dev/mmcblk00x8 0x2000
> rbthomas@cube:~$ ls -ld /dev/mmcblk* 
> brw-rw 1 root disk 179, 0 Jul 25 12:50 /dev/mmcblk1
> brw-rw 1 root disk 179, 1 Jul 25 12:50 /dev/mmcblk1p1
> rbthomas@cube:~$ 

I don’t know why the uSD card is called mmcblk1, not mmcblk0, but it would 
certainly explain what we’re seeing if the same phenomenon is present in the 
installer environment…

Just thinking,

Rick

Bug#834974: Installation Report: Stretch Alpha 7 on Cubox-i4pro

[Rick Thomas]

> On Sep 2, 2016, at 6:33 PM, Rick Thomas <rbtho...@pobox.com> wrote:
> 
> 
> On Sep 2, 2016, at 4:40 PM, Gunnar Wolf <gw...@debian.org> wrote:
> 
>> Can somebody confirm whether the Jessie
>> installer actually works reliably on this machine? (that is, whether
>> it's always been broken or we have a regression)
> 
> I’ll give that a try as well over the weekend.  Let you know what I find.
> 
> Rick

I tried it.  Jessie installs fine and boots into the installed system with no 
problems.

Here’s a .png of the partitions screen.

Rick

Bug#834974: Installation Report: Stretch Alpha 7 on Cubox-i4pro

[Rick Thomas]

On Sep 2, 2016, at 6:30 PM, Rick Thomas <rbtho...@pobox.com> wrote:

> 
> On Sep 2, 2016, at 5:12 PM, Vagrant Cascadian <vagr...@debian.org> wrote:
> 
>> I'd be curious if you re-install and delete each partition individually
>> and re-create manually vs. using one of the auto-partitioning methods.
> 
> I’ll give this a try over the weekend and report back what I find.
> 
> Is it possible that the auto-partitioning process during installation has 
> somehow clobbered the u-boot image on the SD card?  How would I test for that?
> 
> Rick

I did the experiment — manual partitioning did not help. But I sorta fumbled it 
in an interesting way that sheds some light on the question I asked in the 
quoted section above.

Here’s what I did:

1) Retrieved the installer and put it on a uSD card as described in

http://ftp.us.debian.org/debian/dists/stretch/main/installer-armhf/current/images/netboot/SD-card-images/README.concatenateable_images

2) Halted the CuBox-i4 and removed all external peripherals from it (including 
the uSD it boots from) and inserted the installer uSD.

3) Connected to the serial console and re-applied power.

4) Answered questions until it got to partitioning.

5) Chose “manual” partitioning.  Since there was no other storage peripherals 
it only offered me the uSD, which (as a result of 1, above) had a large free 
space.  I told it to use the free space for / and format that as ext2.  I 
failed to delete the installer partition.  (This is the sorta-fumble I 
mentioned earlier.)  

6) I did not create a /boot or swap partition.

I have attached a screen shot of the screen at the end of the process…



After proceeding and answering questions, I ended up with an uSD card with two 
partitions.  The second partition contains the installed system; the first 
partition still contains the installer.

When it got to the end of the installation, it tried to reboot — presumably 
into the newly installed system in partition 2, but did not succeed in 
rebooting.

It’s last words were:

> Sent SIGKILL to all processes
> Requesting system reboot
> [   39.132949] reboot: Restarting system

Then nothing.

This is what we were expecting.  The interesting part comes next.

I pulled the power plug and re-plugged.  It ran u-boot and booted — but not 
into the installed system.  Rather it booted into the installer — which, 
remember, was still present in partition 1.

From this I conclude that the u-boot environment is not getting updated by the 
installer.  And u-boot itself in not getting clobbered by anything in the 
installation process.

Bottom line — the problem is verifiably in the late stages of the installer 
when it’s trying to make the system bootable.  It’s not a problem with the 
auto-partitioning, and it’s not a problem with u-boot.

Hope it helps!
Rick

Bug#834974: Installation Report: Stretch Alpha 7 on Cubox-i4pro

[Rick Thomas]

On Sep 2, 2016, at 4:40 PM, Gunnar Wolf  wrote:

> Can somebody confirm whether the Jessie
> installer actually works reliably on this machine? (that is, whether
> it's always been broken or we have a regression)

I’ll give that a try as well over the weekend.  Let you know what I find.

Rick

Bug#834974: Installation Report: Stretch Alpha 7 on Cubox-i4pro

[Rick Thomas]

On Sep 2, 2016, at 5:12 PM, Vagrant Cascadian  wrote:

> I'd be curious if you re-install and delete each partition individually
> and re-create manually vs. using one of the auto-partitioning methods.

I’ll give this a try over the weekend and report back what I find.

Is it possible that the auto-partitioning process during installation has 
somehow clobbered the u-boot image on the SD card?  How would I test for that?

Rick

Bug#834974: Installation Report: Stretch Alpha 7 on Cubox-i4pro

[Rick Thomas]

For what it’s worth, I just tried booting with an HDMI monitor connected to see 
if the silence on the serial-port was just a matter of console messages being 
directed to the HDMI video port instead.  Still no go.  Silence all-round.

Rick

> On Aug 22, 2016, at 9:15 PM, Rick Thomas <rbtho...@pobox.com> wrote:
> 
> I can confirm this problem.  I just got thru running a “stretch” install on 
> my test Cuboxi4Pro with ingredients from:
> 
>> wget 
>> http://ftp.us.debian.org/debian/dists/stretch/main/installer-armhf/current/images/netboot/SD-card-images/partition.img.gz
>> wget 
>> http://ftp.us.debian.org/debian/dists/stretch/main/installer-armhf/current/images/netboot/SD-card-images/firmware.MX6_Cubox-i.img.gz
>> wget 
>> http://ftp.us.debian.org/debian/dists/stretch/main/installer-armhf/current/images/netboot/SD-card-images/README.concatenateable_images
> 
> To be absolutely clear which components:
>> -rw-r--r-- 1 rbthomas rbthomas  871 Jun 29 15:56 
>> README.concatenateable_images
>> -rw-r--r-- 1 rbthomas rbthomas   187261 Jun 29 15:56 
>> firmware.MX6_Cubox-i.img.gz
>> -rw-r--r-- 1 rbthomas rbthomas 24210806 Jun 29 15:56 partition.img.gz
> 
> I got the same results as Rainer.  System would not boot after installation.  
> There was nothing at all on serial-port the console.
> 
> I also tried power-cycling the device.  Nothing on the serial-port console.
> 
> Can somebody tell me how to find out if there is a bootable u-boot on the SD 
> card?  Maybe the u-boot is getting clobbered by something in the installation 
> process?
> 
> Let me know if you want log files, etc...
> 
> Rick
> 
>> On Aug 21, 2016, at 10:44 AM, Martin Michlmayr <t...@cyrius.com> wrote:
>> 
>> * Rainer Dorsch <m...@bokomoko.de> [2016-08-21 10:41]:
>>> The boot loader installation did not show an error, but the device did not 
>>> boot. 
>>> 
>>> The last "words" of the installer:
>>> 
>>> lqu Finishing the installation tqqk
>>> x x
>>> x   95%   x
>>> x x
>>> The system is going down NOW!ystem...   
>>> x
>>> Sent SIGKILL to all processes   
>>> x
>>> Requesting system 
>>> rebootj
>>>   [ 2730.956106] reboot: Restarting system
>> 
>> Can you 1) attach /var/log/installer/syslog from the SD card and b)
>> show the boot log (after the installer).
>> 
>> -- 
>> Martin Michlmayr
>> http://www.cyrius.com/
>> 
> 

Bug#834974: Installation Report: Stretch Alpha 7 on Cubox-i4pro

[Rick Thomas]

I can confirm this problem.  I just got thru running a “stretch” install on my 
test Cuboxi4Pro with ingredients from:

> wget 
> http://ftp.us.debian.org/debian/dists/stretch/main/installer-armhf/current/images/netboot/SD-card-images/partition.img.gz
> wget 
> http://ftp.us.debian.org/debian/dists/stretch/main/installer-armhf/current/images/netboot/SD-card-images/firmware.MX6_Cubox-i.img.gz
> wget 
> http://ftp.us.debian.org/debian/dists/stretch/main/installer-armhf/current/images/netboot/SD-card-images/README.concatenateable_images

To be absolutely clear which components:
> -rw-r--r-- 1 rbthomas rbthomas  871 Jun 29 15:56 
> README.concatenateable_images
> -rw-r--r-- 1 rbthomas rbthomas   187261 Jun 29 15:56 
> firmware.MX6_Cubox-i.img.gz
> -rw-r--r-- 1 rbthomas rbthomas 24210806 Jun 29 15:56 partition.img.gz

I got the same results as Rainer.  System would not boot after installation.  
There was nothing at all on serial-port the console.

I also tried power-cycling the device.  Nothing on the serial-port console.

Can somebody tell me how to find out if there is a bootable u-boot on the SD 
card?  Maybe the u-boot is getting clobbered by something in the installation 
process?

Let me know if you want log files, etc...

Rick

> On Aug 21, 2016, at 10:44 AM, Martin Michlmayr  wrote:
> 
> * Rainer Dorsch  [2016-08-21 10:41]:
>> The boot loader installation did not show an error, but the device did not 
>> boot. 
>> 
>> The last "words" of the installer:
>> 
>>  lqu Finishing the installation tqqk
>>  x x
>>  x   95%   x
>>  x x
>> The system is going down NOW!ystem...   x
>> Sent SIGKILL to all processes   x
>> Requesting system rebootj
>>[ 2730.956106] reboot: Restarting system
> 
> Can you 1) attach /var/log/installer/syslog from the SD card and b)
> show the boot log (after the installer).
> 
> -- 
> Martin Michlmayr
> http://www.cyrius.com/
> 

Bug#834376: ifupdown: boot console says 'Failed to start Raise network interfaces' yet interface is up

[Rick Thomas]

On Aug 17, 2016, at 12:09 AM, Guus Sliepen  wrote:

> What you then have to do is clean up after the
> kernel, by adding the following to /etc/network/interfaces:
> 
>   pre-up ip -6 a flush dev $IFACE mngtmpaddr
> 
> You can add this to either the inet or inet6 stanza.

Tried it.  This works as advertised.  Thanks!

Rick

Bug#834376: ifupdown: boot console says 'Failed to start Raise network interfaces' yet interface is up

[Rick Thomas]

It may be worth noting that after “updateinitramfs -u” I don’t see 
/etc/sysctl.conf in the new initrd file:

> root@sheeva:~# lsinitramfs -l /boot/initrd.img | grep sysctl
> -rwxr-xr-x 205 root root0 Apr 17 15:03 sbin/sysctl


So if the kernel is picking up the RA before switching out of the initrd, 
there’s no way for it to know that it should not be doing that…   /-:

Rick

Bug#834376: ifupdown: boot console says 'Failed to start Raise network interfaces' yet interface is up

[Rick Thomas]

On Aug 16, 2016, at 4:51 PM, Guus Sliepen <g...@debian.org> wrote:

> On Tue, Aug 16, 2016 at 03:56:56PM -0700, Rick Thomas wrote:
> 
>>> Another option is to add the following line to /etc/systl.conf:
>>> 
>>>  net.ipv6.conf.all.accept_ra=0
>> 
>> Do I understand correctly that I should use this if I want to assign a 
>> static IPv6 address that is *not* the same as the RA would hand out 
>> dynamically?  I have a couple of machines where that would apply, if true.
> 
> If you want to assign a different address then ifupdown will not
> conflict with the autoconfigured one, so in that case it is not
> necessary,

That works.  And no “failed” messages about bringing up networking.  As 
predicted, I have two IPv6 addresses, one the static address from 
/etc/network/interfaces and one assigned dynamically.

> but if you don't disable accept_ra you will end up with two
> addresses configured.

However, when I added …accept_ra=0 to /etc/sysctl.conf and ran 
“update-initramfs -u” then rebooted, I still have two IPv6 addresses.

> root@sheeva:~# sysctl net.ipv6.conf.all.accept_ra
> net.ipv6.conf.all.accept_ra = 0


> root@sheeva:~# ip -6 addr
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1
> inet6 ::1/128 scope host 
>valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
> inet6 2001:1234:2d2:1::111/64 scope global 
>valid_lft forever preferred_lft forever
> inet6 2001:1234:2d2:1:f2ad:4eff:fe00:3077/64 scope global mngtmpaddr 
> dynamic 
>valid_lft 85561sec preferred_lft 13561sec
> inet6 fe80::f2ad:4eff:fe00:3077/64 scope link 
>valid_lft forever preferred_lft forever

Any thoughts?  Have I misunderstood something?

Thanks!
Rick

Bug#834376: ifupdown: boot console says 'Failed to start Raise network interfaces' yet interface is up

[Rick Thomas]

> On Aug 16, 2016, at 1:57 PM, Guus Sliepen <g...@debian.org> wrote:
> 
> On Tue, Aug 16, 2016 at 01:07:15PM -0700, Rick Thomas wrote:
> 
>> Thanks Pascal!
> 
> Indeed thanks, now I have less explaining to do :)

And thank you Guus :)  Now I understand a lot more than I did.

> Another option is to add the following line to /etc/systl.conf:
> 
>   net.ipv6.conf.all.accept_ra=0

Do I understand correctly that I should use this if I want to assign a static 
IPv6 address that is *not* the same as the RA would hand out dynamically?  I 
have a couple of machines where that would apply, if true.

Thanks for all the help!
Rick

Bug#834376: ifupdown: boot console says 'Failed to start Raise network interfaces' yet interface is up

[Rick Thomas]

Thanks Pascal!

On Aug 16, 2016, at 12:59 AM, Pascal Hambourg <pas...@plouf.fr.eu.org> wrote:

> Le 16/08/2016 à 09:03, Rick Thomas a écrit :
>> 
>> Aug 14 17:02:41 sheeva systemd[1]: Starting Raise network interfaces...
>> Aug 14 17:02:46 sheeva ifup[893]: /sbin/ifup: waiting for lock on 
>> /run/network/ifstate.eth0
>> Aug 14 17:02:49 sheeva ifup[893]: RTNETLINK answers: File exists
> 
> "RTNETLINK answers: File exists" typically happens when you try to add an 
> address or a route which is already exists with "ip", which is the tool used 
> internally by ifup.
> 
>> However the interface *is* up:
> 
> Yes but the configuration may not be complete.

It happens that it is complete, but I understand that it might not be.

> 
>> - /etc/network/interfaces 
>> # This file describes the network interfaces available on your system
>> # and how to activate them. For more information, see interfaces(5).
>> 
>> # The loopback network interface
>> auto lo eth0
>> iface lo inet loopback
>> 
>> # The primary network interface
>> allow-hotplug eth0
>> iface eth0 inet static
>>  address 192.168.3.111
>>  netmask 255.255.240.000
>>  network 192.168.0.0
>>  broadcast 192.168.15.255
>>  gateway 192.168.1.1
> 
> Note that the network and broadcast options are not required. If missing, 
> they will be calculated from the address and net mask values.

Thanks.  I’ll keep that in mind for next time.  No harm in leaving them in 
though, right?

> 
>> iface eth0 inet6 static
>>   address 2001:1234:2d2:1:f2ad:4eff:fe00:3077
>>   netmask 64
> 
> This IPv6 address looks like an autoconfigured address calculated from the 
> MAC address. You should not statically assign this kind of address.

You are correct.  I assumed that when the IPv4 address needed to be static, the 
same was true for the IPv6 address as well.  I further assumed that declaring 
it to be inet6 static would prevent it from getting any address from the RA.  
Apparently not.

Why do you say that I should not statically assign this kind of address?  As 
long as it’s the same as it would be getting dynamically, is there any harm? 
(other than the one we’re observing here?)

> 
> If a router in your network sends IPv6 Router Advertisements (RA) with the 
> prefix 2001:1234:2d2:1::/64, then the kernel may autoconfigure the same 
> address, so this could be the duplicate.
> 
> “ip -6 addr" shows whether an IPv6 address was statically or dynamically 
> assigned.

It seems that it is getting a dynamic address from the RA (Yes, it’s the same 
address as I am statically assigning.)  Prior to the most recent Sid update, it 
did not get a dynamic address.  Is that a bug?  If so, is the bug in the 
previous behavior or the current behavior?  can someone explain what the 
purpose of the change was?

In any case, I commented out the inet6 stanza and now it boots without error.  
Also, IPv6 gets configured OK (dynamically).  

> 
> Note for Hans : the network and broadcast addresses are consistent with the 
> netmask.
> 

Yes, for historical reasons I have machines on this LAN whose IPv4 addresses 
have 3rd octets in the range 0-15.  The RFC1918 (192.168.xx.xx) address range 
is a true class B ( or “/16”, if you prefer cider notation) and it can be 
carved up any way you want.  It’s often used as a bunch of class Cs ( or 
“/24”s) but that’s not mandatory.

Rick

PS: I’d like to leave this bug open until we can be sure we understand the 
reason that the behavior changed.  This may be a hint that points to a timing 
glitch in the way systemd configures network interfaces that could cause more 
serious problems down the road.

Bug#832713: closed by Martin Pitt <mp...@debian.org> (Bug#832893: fixed in systemd 231-2)

[Rick Thomas]

On Aug 14, 2016, at 11:13 PM, Michael Biebl  wrote:

> Rick, if you comment out MemoryDenyWriteExecute=yes in your service
> files in /lib/systemd/system, is the problem gone?


Yeah, that seems to make the problem go away.
Rick

Bug#834376: ifupdown: boot console says 'Failed to start Raise network interfaces' yet interface is up

[Rick Thomas]

Package: ifupdown
Version: 0.8.13
Severity: normal

Dear Maintainer,

Updated to latest debian Sid
See attached screenlog of boot. note error message quoted in subject line

After boot is completed we see:

  rbthomas@sheeva:~$ systemctl status networking.service
  * networking.service - Raise network interfaces
 Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor 
preset: enabled)
Drop-In: /run/systemd/generator/networking.service.d
 `-50-insserv.conf-$network.conf
 Active: failed (Result: exit-code) since Sun 2016-08-14 17:02:50 PDT; 
39min ago
 Docs: man:interfaces(5)
   Main PID: 893 (code=exited, status=1/FAILURE)

  Aug 14 17:02:41 sheeva systemd[1]: Starting Raise network interfaces...
  Aug 14 17:02:46 sheeva ifup[893]: /sbin/ifup: waiting for lock on 
/run/network/ifstate.eth0
  Aug 14 17:02:49 sheeva ifup[893]: RTNETLINK answers: File exists
  Aug 14 17:02:49 sheeva ifup[893]: Failed to bring up eth0.
  Aug 14 17:02:50 sheeva systemd[1]: networking.service: Main process exited, 
code=exited, status=1/FAILURE
  Aug 14 17:02:50 sheeva systemd[1]: Failed to start Raise network interfaces.
  Aug 14 17:02:50 sheeva systemd[1]: networking.service: Unit entered failed 
state.
  Aug 14 17:02:50 sheeva systemd[1]: networking.service: Failed with result 
'exit-code'.

However the interface *is* up:

  rbthomas@sheeva:~$ /sbin/ifconfig
  eth0: flags=4163  mtu 1500
inet 192.168.3.111  netmask 255.255.240.0  broadcast 192.168.15.255
inet6 2001:4978:2d2:1:f2ad:4eff:fe00:3077  prefixlen 64  scopeid 
0x0
inet6 fe80::f2ad:4eff:fe00:3077  prefixlen 64  scopeid 0x20
ether f0:ad:4e:00:30:77  txqueuelen 1000  (Ethernet)
RX packets 6897  bytes 738138 (720.8 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 4556  bytes 427016 (417.0 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
device interrupt 85  

  lo: flags=73  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10
loop  txqueuelen 1  (Local Loopback)
RX packets 2  bytes 98 (98.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 2  bytes 98 (98.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


Here is a possibly relevant config file

- /etc/network/interfaces 
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo eth0
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 192.168.3.111
netmask 255.255.240.000
network 192.168.0.0
broadcast 192.168.15.255
gateway 192.168.1.1

iface eth0 inet6 static
address 2001:4978:2d2:1:f2ad:4eff:fe00:3077
netmask 64
- /etc/network/interfaces 




-- 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 ifupdown depends on:
ii  adduser  3.115
ii  init-system-helpers  1.42
ii  iproute2 4.6.0-2
ii  libc62.23-4
ii  lsb-base 9.20160629

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.3.4-1

Versions of packages ifupdown suggests:
pn  ppp 
pn  rdnssd  

-- no debconf information


screenlog.xz
Description: application/xz

Bug#832713: closed by Martin Pitt <mp...@debian.org> (Bug#832893: fixed in systemd 231-2)

[Rick Thomas]

Sorry, it’s not fixed in 231-2…  Please see attached boot log.

Rick





screenlog.xz
Description: Binary data

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