post install scripts on every reboot

[hegge]

Hi,

how can I disable the post install scripts? On every reboot I get following messages:

Starting LSB: Armbian gathering informations about hardware.
Starting LSB: PLEASE BE PATIENT AND DO NO DISTURB UNTIL FIRST REBOOT...
Resizing root filesystem.
Starting 128MB emergency swap area creation.
Starting SSH keys recreation.

So I have to delete also my ssh key when I want to connect via ssh on every reboot...

Thanks in advance,

hegge

[Igor]

There is a script which runs only once, at first boot. If you break this procedure it will repeat. 

 

If you get this on every reboot, something is wrong. Please supply more info - which build is this, kernel, self build or downloaded, ...

[hegge]

...it's Armbian_5.10_Lamobo-r1_Debian_jessie_4.5.2.raw, I had the same behavior with Armbian_5.10_Lamobo-r1_Debian_jessie_3.4.112.raw...

Thank you,

hegge

[Igor]

Strange. We made few tests, not just by me, and it was all fine. Will do it again when get to the office.

 

One possible explanation is bad SD media -> mounts root as read only ... and this way your first boot is always first

[tkaiser]

...it's Armbian_5.10_Lamobo-r1_Debian_jessie_4.5.2.raw, I had the same behavior with Armbian_5.10_Lamobo-r1_Debian_jessie_3.4.112.raw...

 

Please provide the output from 'sudo armbianmonitor -u' and next time please check 

dmesg | grep read
armbianmonitor -c $HOME

When dmesg already reports read-only filesystem then armbianmonitor obviously isn't able to check your SD card, otherwise it will try to walk through the whole capacity, writes random patterns on it and re-reads them to ensure you're not plagued by a broken/fake card.

[hegge]

Hi,

thank you so much for your replies... That's the url given by sudo armbianmonitor -u

http://sprunge.us/QTUX

Hope that helps...

@edit: all is working fine now except this messages and having to delete ssh keys anytime I rebooted. 

Kind regards and tyvm again,

hegge

[tkaiser]

thank you so much for your replies... That's the url given by sudo armbianmonitor -u

http://sprunge.us/QTUX

 

Thx, at least it's not a filesystem corruption issue. Can you please exchange the 1st line of /etc/init.d/firstrun with this (one additional line):

#!/bin/bash -x
exec 2 >>/var/log/firstrun.log

and then get back to us with the contents of /var/log/firstrun.log? Thx!

[hegge]

...after replacing the lines you order I don't have to remove the ssh key. And it's nothing inside your /var/log/firstrun.log...

@edit

that's the first lines looks like

#!/bin/bash -x
exec 2 >>/var/log/firstrun.log
### BEGIN INIT INFO
# Provides:          firstrun
# Required-Start:    $all
# Required-Stop:
# Should-Start:      armhwinfo
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: PLEASE BE PATIENT AND DO NOT INTERRUPT THE FIRST REBOOT
# Description:       Something needs to be done when  is
#                    starting at first time.
#                    regenerate ssh host key
### END INIT INFO

in case I've made a mistake...

[tkaiser]

...after replacing the lines you order I don't have to remove the ssh key. And it's nothing inside your /var/log/firstrun.log...

 

While I still have not the slightest idea what went wrong obviously it's both too late to debug and firstrun script successfully disabled itself. So either you start from scratch with the original image and do the modification to the script again to help us debug this problem or we'll have to wait for the next reporting the same problem...

[hegge]

...ou sry, I just noticed there was thrown an error:

[FAILED] Failed to start LSB: PLEASE BE PATIENT AND DO NOT DISTURB UNTIL FIRST REBOOT...

systemctl -l status firstrun.service gives:

â— firstrun.service - LSB: PLEASE BE PATIENT AND DO NOT INTERRUPT THE FIRST REBOOT
   Loaded: loaded (/etc/init.d/firstrun)
   Active: failed (Result: exit-code) since Mon 2016-05-02 06:23:42 CEST; 8min ago
  Process: 1137 ExecStart=/etc/init.d/firstrun start (code=exited, status=127)

May 02 06:23:42 lamobo-r1 firstrun[1137]: + exec 2
May 02 06:23:42 lamobo-r1 firstrun[1137]: /etc/init.d/firstrun: line 2: exec: 2: not found
May 02 06:23:42 lamobo-r1 systemd[1]: firstrun.service: control process exited, code=exited status=127
May 02 06:23:42 lamobo-r1 systemd[1]: Failed to start LSB: PLEASE BE PATIENT AND DO NOT INTERRUPT THE FIRST REBOOT.
May 02 06:23:42 lamobo-r1 systemd[1]: Unit firstrun.service entered failed state.

Tyvm,

hegge

[hegge]

Hi again,

after I changed the first lines of /etc/init.d/firstrun to

#!/bin/bash -x
exec &>>/var/log/firstrun.log

the firstrun script works again and gives an output to /var/log/firstrun.log:

+ '[' Xstart '!=' Xstart ']'
+ export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
+ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
+ cat
++ awk '-F ' '/^MemTotal/ {print $2}'
++ apt-cache policy ramlog
++ grep Installed
+ chmod +x /tmp/create_swap.sh
+ main
+ check_prerequisits
+ for needed_tool in fdisk parted partprobe resize2fs
+ which fdisk
+ for needed_tool in fdisk parted partprobe resize2fs
+ which parted
+ for needed_tool in fdisk parted partprobe resize2fs
+ which partprobe
+ for needed_tool in fdisk parted partprobe resize2fs
+ which resize2fs
+ collect_informations
++ uname -r
++ sed 's/\([0-9]\+\.[0-9]\+\)\..*/\1/'
+ CURKERNE=4.5
++ lsb_release -cs
+ DISTRIBUTION=jessie
++ awk '/Hardware/ {print $3}'
+ HARDWARE=Allwinner
+ '[' -f /proc/device-tree/model ']'
++ awk '/Hardware/ {print $4}'
+ HARDWARE=sun7i
+ case ${DISTRIBUTION} in
++ findmnt /
++ awk '-F ' '/\/dev\// {print $2"\t"$3}'
+ ROOTFS='/dev/mmcblk0p1	ext4'
+ set /dev/mmcblk0p1 ext4
+ root_partition=/dev/mmcblk0p1
+ rootfstype=ext4
+ set -e
+ [[ ext4 == \e\x\t\4 ]]
+ [[ ! -f /root/.no_rootfs_resize ]]
+ display_alert 'Resizing root filesystem.'
+ '[' jessie == wheezy ']'
+ '[' jessie == jessie ']'
+ echo -e '[\e[0;32m  OK  \x1B[0m] Resizing root filesystem.'
+ do_expand_rootfs
++ lsblk -idn -o NAME
++ grep -w mmcblk0
+ DEVICE=/dev/mmcblk0
+ '[' /dev/mmcblk0 = /dev/ ']'
++ echo /dev/mmcblk0
++ sed 's:/:\\\/:g'
+ QUOTED_DEVICE='\/dev\/mmcblk0'
++ grep -c mmcblk0p /proc/partitions
+ PARTITIONS=1
++ tail -1
++ cut -d: -f2
++ parted /dev/mmcblk0 unit s print -sm
++ sed s/s//
+ PARTSTART=32768
++ tail -1
++ parted /dev/mmcblk0 unit s print -sm
++ head -3
++ cut -d: -f3
++ sed s/s//
+ PARTEND=31438847
+ STARTFROM=31438848
+ [[ 1 == 1 ]]
+ STARTFROM=32768
+ '[' -f /root/.rootfs_resize ']'
++ parted /dev/mmcblk0 unit s print -sm
++ awk -F: '/^\/dev\/mmcblk0/ {printf ("%0d", $2 / ( 1024 / $4 ))}'
+ CAPACITY=15719424
+ '[' 15719424 -lt 4000000 ']'
+ fdisk /dev/mmcblk0
+ echo d
+ echo 1
+ echo n
+ echo p
+ echo
+ echo 32768
+ echo
+ echo w
1: unknown command
Re-reading the partition table failed.: Device or resource busy
+ true
+ s=0
+ fsck -f /dev/mmcblk0p1
+ true
+ partprobe /dev/mmcblk0
+ resize2fs /dev/mmcblk0p1
++ awk '/\// {print $(NF-2)}'
++ df -hm /
+ FREESIZE=13655
+ [[ jessie == \w\h\e\e\z\y ]]
+ [[ 0 != \0 ]]
+ [[ 13655 -lt 152 ]]
+ return 0
+ display_alert 'Starting 128Mb emergency swap area creation.'
+ '[' jessie == wheezy ']'
+ '[' jessie == jessie ']'
+ echo -e '[\e[0;32m  OK  \x1B[0m] Starting 128Mb emergency swap area creation.'
+ display_alert 'Starting SSH keys recreation.'
+ '[' jessie == wheezy ']'
+ '[' jessie == jessie ']'
+ echo -e '[\e[0;32m  OK  \x1B[0m] Starting SSH keys recreation.'
+ touch /tmp/firstrun_running
+ '[' Xsun7i = Xsun8i -o Xsun7i = Xsun7i ']'
+ autodetect_sunxi
+ /tmp/create_swap.sh
+ echo heartbeat
/etc/init.d/firstrun: line 117: /sys/class/leds/*red*/trigger: No such file or directory
+ echo heartbeat
/etc/init.d/firstrun: line 117: /sys/class/leds/*blue*/trigger: No such file or directory

I hope you can find the bug, since the problem with recreated ssh keys on every reboot is also back now...

Thanks again in advance,

hegge

[hegge]

Hi,

I just found the problem: the board has just a green led - no red one and no blue one, so the line (117)

echo heartbeat >/sys/class/leds/*red*/trigger 2>/dev/null || echo heartbeat >/sys/class/leds/*blue*/trigger 2>/dev/null

fails.

After I changed it to

echo heartbeat >/sys/class/leds/*green*/trigger 2>/dev/null || echo heartbeat >/sys/class/leds/*red*/trigger 2>/dev/null || echo heartbeat >/sys/class/leds/*blue*/trigger 2>/dev/null

it works like a charme: rebooted and not ran again.

Thanks again,

hegge

 

@edit: After the reboot the green led heartbeat blinking is gone - is this the aim?

[tkaiser]

I just found the problem: the board has just a green led - no red one and no blue one, so the line (117)

 

@edit: After the reboot the green led heartbeat blinking is gone - is this the aim?

 

Thanks for discovering the reason. Yeah, that's another example of our 'auto detection gone wrong' problem intrudoced when we started to support H3/sun8i. Should then also apply to these other sun7i board according to fex files (but we tested with some of these and no problems occured -- strange):

aw-som-a20.fex: green, yellow
bananapi.fex: green
bananapipro.fex: green
lamobo-r1.fex: green
lime2-emmc.fex: green
lime2.fex: green
orangepi.fex: green
pcduino3*.fex: none

And yes: On sun7i no blinking should happen after the 1st boot. A blinking red led was mostly meant for the more unexperienced H3 board users and since we expanded board autodetection also to sun7i (wrong idea) this firstrun blinking/problem has been introduced.

[RagnerBG]

I see, there is finally solution to my problem with all images and versions since 5.07 so far. As i explained it here - Armbian_5.07 jessie_3.4.111 not working everything i tried after 5.06, legacy version on my Lamobo R1, lead to the same first boot fail, freeze at the ssh key recreation. Today i tried latest prebuild image from download section of Jessie Server and it freeze too at the same point, along with my newly attempt to compile working image of new 5.11 version. So i think, it's better to remove those images since they are not workable.

The only way around i found for myself is little messy - first i install my working 5.06 version, change password, create account, etc. Then do update&&upgrade to the latest version and reboot. It ask me for some .verbose config, i choose N as default. In the meantime i compile kernel&headers debs only for latest version from source with CMA enabled (this is what i actually need) and apply debs on the updated image and this time system reboots without boot loop and seems to work.

 

But i wonder, can someone explain more in details, what should be done about this bug? Where is this line (117), from what file, to be modified?

 

Edit: Another strange thing is, during full image build from source, i saw at the beginning, some H3 patches to apply. Is this normal?

[RagnerBG]

Hi,

I just found the problem: the board has just a green led - no red one and no blue one, so the line (117)

echo heartbeat >/sys/class/leds/*red*/trigger 2>/dev/null || echo heartbeat >/sys/class/leds/*blue*/trigger 2>/dev/null

fails.

After I changed it to

echo heartbeat >/sys/class/leds/*green*/trigger 2>/dev/null || echo heartbeat >/sys/class/leds/*red*/trigger 2>/dev/null || echo heartbeat >/sys/class/leds/*blue*/trigger 2>/dev/null

it works like a charme: rebooted and not ran again.

Thanks again,

hegge

 

@edit: After the reboot the green led heartbeat blinking is gone - is this the aim?

I didn't read carefully. /etc/init.d/firstrun is to be modified. It's working now and i finally enjoy the new armbian builds. Thanks man .

I just wonder, if someone of developers will fix "firstrun" file and add this line for Lamobo-R1, in source and images in Download section, so me and others don't have to do it manually in the future ?

[RagnerBG]

Naaa, i was too hurry to celebrate. With this 5.11 version, even after firstboot succeed, constant crashes and freezes. This sounds like multiple issues with those new sources or patches or whatever. I don't have nor time, nor knowledge to investigate all this. I guess i have to stay with my latest, stable build for Lamobo-R1 and forget about system updates. Thats pitty .

 

Sorry, my bad. It's appeared i have power issues between my ubs hub/lan and usb wifi module. Although it was working that way for mounts i was borrow my hub for a while and it seems it's not been treated well. Never mined, i can confirm with this fix, newer version works fine.