From: IT Superhack <itsuperhack@web.de>
To: development@lists.ipfire.org
Subject: Re: Question about Pakfire Update process
Date: Tue, 24 Mar 2015 18:33:26 +0100 [thread overview]
Message-ID: <55119FE6.8060808@web.de> (raw)
In-Reply-To: <1427204502.14172.171.camel@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 6315 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Michael Tremer:
> Hi,
>
> On Mon, 2015-03-23 at 18:14 +0100, IT Superhack wrote:
>> Michael Tremer:
>>> Hi Timmothy,
>>>
>>> On Sun, 2015-03-22 at 10:43 +0100, IT Superhack wrote:
>>>> Hi everybody,
>>>>
>>>> I am currently working on bug #10767.
>>>
>>> thanks for looking into this.
>>>
>>>> During the last week, I wrote a shell script which compares
>>>> the running kernel to the installed kernel files
>>>> (/boot/...). If they are different, it recreates the files
>>>> "boot.script" and "boot.scr". Because of that, the user
>>>> doesn't have to do this after every kernel update.
>>>
>>> I do not really get what this script is supposed to do. In
>>> case of an update, the boot.script file will be overwritten any
>>> way. The version with the binary header can then be created at
>>> build time.
>> The installation manual
>> (http://wiki.ipfire.org/en/hardware/arm/wandboard/wandboardquad)
>> says: "Please note, after each kernel update the boot.script
>> needs to be adjusted and the convert_bootscript.sh or the
>> containing command needs to be executed." Thereof, the steps of
>> adjusting boot.script and running mkimage seem to be necessary
>> after each kernel update. They don't seem to be done by the
>> update mechanism itself at the moment.
>
> *What* needs to be adjusted?
According to the URL above, the files
/boot/boot.script
/boot/boot.scr
need to be updated after each kernel update.
The background is: A kernel update usually changes the version number.
The two boot.scr* files above contain the boot instructiones for the
Wandboard.
(Note that the board actually only reads boot.scr, but boot.script is
the template for this, please see the installation manual for details.)
In my case, the boot.script file currently looks like this:
fatload mmc 0:1 0x11500000 zImage-ipfire-multi
fatload mmc 0:1 0x32000000 uInit-ipfire-multi
fatload mmc 0:1 0x11200000 dtb-3.14.33-ipfire-multi/imx6q-wandboard.dtb
setenv bootargs console=ttymxc0,115200n8 smsc95xx.macaddr=$usbethaddr
root=/dev/mmcblk0p3 ro
bootz 0x11500000 0x32000000 0x11200000
As you can see, in line 3 it says
"dtb-3.14.33-ipfire-multi/imx6q-wandboard.dtb". Now assume a kernel
update takes place. Then the version number of the kernel changes,
right? This means that there will be another "dtb-<version
number>-ipfire-multi" directory, the old one
("dtb-3.14.33-ipfire-multi") will be deleted.
And here is the problem. The upgrading process does not adjust the
boot.scr* files. So, after the update, line 3 in boot.script points to
a directory which has been deleted.
As I already mentioned, the board reads boot.scr, which seems to be
sort of compiled. The compiling command is
mkimage -A arm -T script -d boot.script boot.scr
and creates the boot.scr file which contains basically the lines in
boot.script.
After a reboot (which is required after a kernel update), the
Wandboard reads boot.scr and tries to read the directory listed in
boot.scr. But the update process deleted it. So, after some retries,
the board will crash. That's what I'm trying to fix and to avoid this,
the boot.script and boot.scr files need to be adjusted _automatically_
after a kernel update.
>
>>>
>>> What are you exactly trying to solve here?
>>>
>> This is what I'm trying to provide: A script that can be
>> executed by Pakfire after an update. It checks wether it runs on
>> a wandboard and if it does, it updates the boot.script stuff.
>
> *What* does it "update" with *what*?
The script should solve the issue above.
It performs some checks (correct architecture, do the boot.scr* files
exist? and so on) so it would not run on a normal system (i586).
After that, it reads the running kernel (via uname -r) and the file
names in /boot/, which look like
vmlinuz-3.14.33-ipfire-multi.
Then it extracts the version number from one of those files and
compares it with the running kernel version.
If they are not equal, it means that an update has deleted the old
files and wrote some new. The system is still running with the old
kernel and has not been rebooted yet.
Now the script creates the boot.script file and inserts the kernel
version of the stored files.
Then, it overwrites the more important boot.scr file by executing the
"mkimage" command above. If those steps were successful, it quits.
After the script is done, everything is prepared for a reboot. The
Wandboard reads the boot.scr file and finds the new dtb-... directory.
It boots up normally and everything is fine.
>
>>>> However, the script needs to be triggered after a kernel
>>>> update took place. (Of course, I could copy it into
>>>> /etc/cron.hourly/, but in my opinion, this is not a good
>>>> solution.) I guess it needs to be triggered by Pakfire after
>>>> the update process is done.
>>>
>>> Cron is never the solution.
>>>
>>>> Now comes my question: How do I do this? How can I tell
>>>> Pakfire to run a custom shell script after an update?
>>>>
>>>> I would be very greatful if you could mail me some hints.
>>>>
>>>> Best regards, Timmothy Wilson
>>>> _______________________________________________ Development
>>>> mailing list Development(a)lists.ipfire.org
>>>> http://lists.ipfire.org/mailman/listinfo/development
>>
>> EDIT: Sorry, I mixed up the destination addresses and send the
>> mail to Michael and not into the development list.
>>
>> _______________________________________________ Development
>> mailing list Development(a)lists.ipfire.org
>> http://lists.ipfire.org/mailman/listinfo/development
>>
>>
>> _______________________________________________ Development
>> mailing list Development(a)lists.ipfire.org
>> http://lists.ipfire.org/mailman/listinfo/development
I hope it is now clear what the script does and what I'm trying to fix.
Best regards,
Timmothy Wilson
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCgAGBQJVEZ/mAAoJEOyLa1C5EazrHXgH+QEAXJmvu/wBGI7GwZb2KMLd
ggEZk3EEVwgih8YXj9RcHXwlCPGxjv5KtBuVUTa3sAYtYdB3CY5S/Pp1S3c2MnJr
fNqgDqurddGTnpDeX0PRcGa2ZI0pL+mHttGoypao6zNr3HtVWnzPDJywSNmGmA9j
5GVATb5s6hm+i+zZwuA8cmZJuTX6rGS2/CM1sWzYX+NCa+l+HjaG4LJ6jrriC6Yg
qD4xRM++jAWw+5Oi2DVSg12eV9RJ2io4NR2LjRacisROn34Z0MS8jcqqpb5W0V9v
ckIVGt//PYzxUnywH1k6DABynvqYI80tbBla6ZuRNzT2Od0Qp529nDs3fB7nezY=
=ts6J
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2015-03-24 17:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-23 17:14 IT Superhack
2015-03-24 13:41 ` Michael Tremer
2015-03-24 17:33 ` IT Superhack [this message]
-- strict thread matches above, loose matches on Subject: below --
2015-03-22 9:43 IT Superhack
2015-03-22 21:35 ` Michael Tremer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55119FE6.8060808@web.de \
--to=itsuperhack@web.de \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox