Firmware needs to be updated.

[lukasmalkmus]

Hi,
I think some files need to be updated in order to make the installer work properly again. Here is what I observed:
I got a fleet of RPI 2 B+ models. I use the ua-netinst with a costum script to set up a Raspbian installation that fits my needs on every new PI. Yesterday I got a new B+. But when powering it up, nothing happend. Instead the ACT LED flashed eight times. This means ´SDRAM not recognised. You need newer bootcode.bin/start.elf firmware.´. It seems that they ship new B+ models which are not able to work with older firmware.

To solve this issue I just overwrote bootcode.bin, start.elf, start_cd.elf and start_x.elf with the corresponding files from https://github.com/raspberrypi/firmware/tree/master/boot. At least it is booting know, but still not installing becasue it can't validate the release.

Can someone confirm this issue?

[diederikdehaas]

When the installation fails, it writes a log file to /boot/, can you share that?
Make sure that you edit out private stuff (like passwords) before sharing.

I'm not aware of RPI 2 B+ that won't boot though. It might be that newer batches use a different hardware config, but I'd be surprised if that were the case.
Which installer version did you use?

[lukasmalkmus]

I'm using the latest v1.0.8.1 installer.
There is no log file in /boot/. The Pi doesn't event start.
When replacing the files as described I get a log file like this:

=================================================
raspbian-ua-netinst
=================================================
Revision git~e3bc3ab
Built on vr dec 25 02:02:39 CET 2015
Running on Raspberry Pi version 1
=================================================
https://github.com/debian-pi/raspbian-ua-netinst/
=================================================
Copying boot files... OK

Network configuration:
  ip_addr = dhcp
  online_config = 

Waiting for eth0... Configuring eth0 with DHCP... 192.168.179.58
Failed to set time using ntpdate!
Failed to set time using timeserver 'time.nist.gov'.
Failed to set time using timeserver 'time.nist.gov'.
Failed to set time using timeserver 'nist1.symmetricom.com'.
Failed to set time using timeserver 'nist-time-server.eoni.com'.
Failed to set time using timeserver 'utcnist.colorado.edu'.
Failed to set time using timeserver 'nist1-pa.ustiming.org'.
Failed to set time using timeserver 'nist.expertsmi.com'.
Failed to set time using timeserver 'nist1-macon.macon.ga.us'.
Failed to set time using timeserver 'wolfnisttime.com'.
Failed to set time using timeserver 'nist.time.nosc.us'.
Failed to set time using timeserver 'nist.netservicesgroup.com'.
Failed to set time using timeserver 'nisttime.carsoncity.k12.mi.us'.
Failed to set time using timeserver 'nist1-lnk.binary.net'.
Failed to set time using timeserver 'ntp-nist.ldsbc.edu'.
Failed to set time using timeserver 'utcnist2.colorado.edu'.
Failed to set time using timeserver 'nist1-ny2.ustiming.org'.
Failed to set time using timeserver 'wwv.nist.gov'.
FAILED to set the date, so things are likely to fail now ...
Make sure that rdate port 37 is not blocked by your firewall.

Installation started at Thu Jan  1 00:00:22 UTC 1970.


Installer configuration:
  preset = server
  packages = 
  mirror = http://mirrordirector.raspbian.org/raspbian/
  release = jessie
  hostname = pi
  domainname = 
  rootpw = raspbian
  cdebootstrap_cmdline = --flavour=minimal --include=linux-image-rpi-rpfv,cpufrequtils,kmod,libpam-systemd,fake-hwclock,ifupdown,net-tools,ntp,openssh-server,vim-tiny,iputils-ping,wget,ca-certificates,rsyslog,cron,dialog,locales,less,man-db,isc-dhcp-client
  bootsize = +128M
  rootsize = 
  boot_volume_label = 
  timeserver = time.nist.gov
  cmdline = dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 elevator=deadline
  usbroot = 
  rootdev = /dev/mmcblk0
  rootpartition = /dev/mmcblk0p2
  rootfstype = ext4
  rootfs_mkfs_options = 
  rootfs_install_mount_options = noatime,data=writeback,nobarrier,noinit_itable
  rootfs_mount_options = errors=remount-ro,noatime

Waiting for /dev/mmcblk0... OK
Applying new partition table... OK
Initializing /boot as vfat... OK
Copying /boot files in... OK
Initializing / as ext4... OK
Mounting new filesystems... OK
Starting install process...
P: Retrieving Release
P: Retrieving Release.gpg
P: Validating Release
E: Couldn't validate Release!

Oh noes, something went wrong!
You have 10 seconds to hit ENTER to get a shell...

[Mausy5043]

This:

Waiting for eth0... Configuring eth0 with DHCP... 192.168.179.58
Failed to set time using ntpdate!

...seems to indicate that the RPi does not have access to the internet.
What is between your Pi and the outside world? I'm assuming you have it connected by cable to your modem/router. Correct? (Anything inbetween?)
If that is the case, have you checked the firewall(s)?

Make sure that rdate port 37 is not blocked by your firewall.

[lukasmalkmus]

Yeah I know, but that's not the actual issue. My router configuration is perfectly fine.
To make it a little bit clearer: I have two Raspberry Pi 2 B+ models. One I ordered last year and one I orderer this week. The ua-netinstaller works fine on the older one, but won't even boot on the new one. I even tried an Raspbian installation which was created using this installer last year. It works one the old Pi, but fails to boot on the new Pi. Same issue: ACT LED flashes eight times. To solve this I had to perform rpi-upgrade one the old Pi in order to make the installation work on the new Pi.

That the installer even boots on the new Pi is due to my efforts of replacing some files with newer ones from the firmware repository. But since I don't have a clue what I'm actually doing it's a wonder that my modified installer even booted. I'm 100% sure the not working ethernet is a result of my experiment.

As @diederikdehaas said It might be that newer batches use a different hardware config, but I'd be surprised if that were the case. I think my observations underline this statment and I would appreciate if someone can check that.

Is there some kind of serial number on my Pi I can provide to find out which batch it is from? Or the production date?

[kpfleming]

I know it sounds silly, but it sounds like you have a Pi3, not a Pi2.

[diederikdehaas]

Is there some kind of serial number on my Pi I can provide to find out which batch it is from? Or the production date?

cat /proc/cpuinfo should give you, among other things, the serial.
But I'd be REALLY surprised if the firmware version would have anything to do with it.

@Mausy5043 give you the exact cause (IMO) of the failed installation. For verifying the gpg keys, it needs the proper time and that seemed to have failed with you. Hence the message:
FAILED to set the date, so things are likely to fail now ...
The fact that it couldn't contact the ntp pool and neither the bunch of rdate servers strongly indicates a network/firewall issue.

@kpfleming's remark makes a lot of sense too as you'd need newer firmware for the Pi3, but (likely) not the Pi2. And if you bought the Pi's not too long ago, it seems more likely you'd get a Pi3 than a Pi2.

[lukasmalkmus]

@kpfleming It is definitely not a Pi3. But I might have caused a bit of confusion when I merged two models together: I have a new Raspberry Pi B+ not at Pi2 B+ (because that model doesn't even exist). To be a bit more specific, the engraving on the board says Raspberry Pi Model B+ V1 2 and the second line (c) Raspberry Pi 2014. However, that shouldn't be a problem since the installer supports the model.

I also checked it again: The installer boots on the Pi I ordered in 2015 (also a B+), but doesn't boot on the Pi I ordered this week. Same model, same engraving, same SD-Card, same installer.
I know why the installation fails, but this isn't my problem. The installer doesn't boot, that's my problem. It only booted after some weird modifications I did.

[diederikdehaas]

Can you post the full output of cat /proc/cpuinfo? That would gives as a clue as to whether there is indeed a new build number.

[lukasmalkmus]

Ups, sorry. Missed that. There you go:

processor       : 0
model name      : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS        : 697.95
Features        : half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xb76
CPU revision    : 7

Hardware        : BCM2708
Revision        : 900032
Serial          : 00000000362c0a59

[diederikdehaas]

That does indeed look like a new revision of the board :-/
It is not listed in http://elinux.org/RPi_HardwareHistory#Board_Revision_History
And in code I wrote recently which uses the Revision field to detect the Pi version it is missing as well (which is not surprising as I used the table from elinux.org).

Damn 😞

[diederikdehaas]

Features : half thumb fastmult vfp edsp java tls

The java feature is sth I haven't seen before.
So this is a Pi 1B(+), right? Single core or did you leave out the output of the other cores?
Can you post the output of dmesg | grep model and/or (better even) dmesg | head -n 15 ?

[lukasmalkmus]

Yep, Pi 1 B+. Single Core board.

dmesg | grep model:

[    0.000000] Machine model: Raspberry Pi Model B Plus Rev 1.2

dmesg | head -n 15

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 4.4.11+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #888 Mon May 23 20:02:58 BST 2016
[    0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.000000] Machine model: Raspberry Pi Model B Plus Rev 1.2
[    0.000000] cma: Reserved 8 MiB at 0x1b400000
[    0.000000] Memory policy: Data cache writeback
[    0.000000] On node 0 totalpages: 114688
[    0.000000] free_area_init_node: node 0, pgdat c0880270, node_mem_map db010000
[    0.000000]   Normal zone: 1008 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 114688 pages, LIFO batch:31

This is a fresh raspbian lite installation btw.

[diederikdehaas]

This is rather shocking to me ... comparing your data with my 'old' RPi 1B+:

# cat /proc/cpuinfo 
processor       : 0
model name      : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS        : 697.95
Features        : half thumb fastmult vfp edsp java tls 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xb76
CPU revision    : 7

Hardware        : BCM2708
Revision        : 0010
Serial          : 000000009dee0f68

# dmesg | grep model
[    0.000000] Machine model: Raspberry Pi Model B Plus Rev 1.2

# dmesg | head -n 15
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 4.4.0-1-rpi ([email protected]) (gcc version 4.9.2 (Raspbian 4.9.2-10) ) #1 Debian 4.4.6-1+rpi14 (2016-05-05)
[    0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.000000] Machine model: Raspberry Pi Model B Plus Rev 1.2
[    0.000000] cma: Reserved 8 MiB at 0x1b000000
[    0.000000] Memory policy: Data cache writeback
[    0.000000] On node 0 totalpages: 114688
[    0.000000] free_area_init_node: node 0, pgdat c08ecfc0, node_mem_map dac10000
[    0.000000]   Normal zone: 1008 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 114688 pages, LIFO batch:31

Notice the difference (apart from kernel/gcc version and Serial)?
Yes, that's right. They are identical, EXCEPT for the Revision field in /proc/cpuinfo

😞

(and apparently it also has hardware java support)

[Mausy5043]

(and apparently it also has hardware java support)
@diederikdehaas so has yours.

[diederikdehaas]

My wording was rather poor, but I tried to say that :-P

[Mausy5043]

@lukasma : Could you try building the installer from the v1.1.x branch? I think that will work.

[diederikdehaas]

The solution I had in mind was indeed applying the kernel-4.4-support PR to v1.0.x

[diederikdehaas]

I've applied the kernel-4.4 update to the v1.0.x branch and I've uploaded the resulting images here:
https://cknow.org/rpi/ and select one of the images fitting the pattern raspbian-ua-netinst-20160809-kernel-4.4-v1.0.*

If you could test whether that works for you, that would be appreciated.

[lukasmalkmus]

Yes I will test it.

[diederikdehaas]

Done. It wasn't a direct link, but a pattern, but the way I had posted it it rendered it as a (direct) link.

[lukasmalkmus]

Yup did that in the end. I thought * was a pattern to be replaced with 8.1 to get version 1.0.8.1 ^^

[lukasmalkmus]

And it is booting and installing :) Passed the step where it faild last time (validating release). Will look for errors but can't imagine it will fail now...

[diederikdehaas]

Great 👍
If it indeed completes successfully, I'll submit the change I made to the v1.0.x branch.

[lukasmalkmus]

It worked :) Thanks!!

[diederikdehaas]

Changes have been merged, thus closing the issue.
Thanks for reporting it 👍