Hi all,
I've written a script that generates modules to automate updates to the Porteus system. Rather than placing a module with updated configs into your /porteus/modules folder, which will override old files in the base system (modules in /porteus/base), these modules will run a script to insert or replace existing files and modules directly on your flash or hard drive. For example, we could automatically update the kernel, initrd, and 000-kernel.xzm module, so all the user needs to do is download and activate a single module which will walk them through the process.
I'd like some help in testing this, so please download the appropriate module for your install (V1.2 only, this won't work for 1.1 or earlier as it requires an sgn match):
32-bit Porteus 1.2: http://porteus-xfce.googlecode.com/file ... t-oct1.xzm
64-bit Porteus 1.2: http://porteus-xfce.googlecode.com/file ... t-oct1.xzm
Expected behavior:
When you download and activate the module, or if you place it in /porteus/modules and reboot, a gtkdialog interface should open telling you that you have downloaded an update module, and prompting you to proceed. It should then automatically find and dispaly (on the next screen) your /porteus and /boot folders. Please tell me if your porteus and boot folders are not found properly, as I want to automate this step for 95%+ of all setups. Once you have verified the folders, the system will need to reboot. It will shut down and as it shuts down (switching root back to initrd), it will copy all files from the update module onto your usb or hard drive, writing a log and keeping backups of any overwritten files if you check the box to keep backups.
When you restart, there will still be a module with the same name as the update module located in /porteus/modules, but this will be a 'dummy' module, only containing a file with a list of files that were updated. This module is in place so that the existing porteus update function will not download the update module again.
For testing purposes at this point, I've only included two files in the update: /boot/docs/cheatcodes.txt and /porteus/GNU_GPL. Following the update, those files should have an updated timestamp and contain a line of text at the very end of the file stating "update check file".
Once we get this tested and any kinks worked out, we can test with something more substantial, like a kernel upgrade.
One issue that I already know about is that if you run the update in text mode, you can't exit the update once you've said 'yes' to continue with the update. Ctrl+C and Ctrl+D don't exit out of the script. I'll find a way to fix or get around this (e.g. add an option for 'exit' wherever the read command prompts for user input).
Please test and let me know if you run into any issues, or if works as designed for you.
Thanks!!
Auto-updates for kernel, base modules, etc - TESTERS NEEDED
- Ahau
- King of Docs
- Posts: 1331
- Joined: 28 Dec 2010, 15:18
- Distribution: LXDE & Xfce 32/64-bit
- Location: USA
Auto-updates for kernel, base modules, etc - TESTERS NEEDED
Please take a look at our online documentation, here. Suggestions are welcome!
- brokenman
- Site Admin
- Posts: 6105
- Joined: 27 Dec 2010, 03:50
- Distribution: Porteus v4 all desktops
- Location: Brazil
Re: Auto-updates for kernel, base modules, etc - TESTERS NEE
First thoughts:
When i activated i got the autorun dialog generated from rc4. I didn't feel like rebooting at the time so i canceled thinking i would just activate it later and start again. After deactivating and reactivating i got no popup, and no obvious way to rerun the script again. I had removed the /tmp/porteus-1.2-i486-update_test-oct1 directory.
Of course running the update_entry script directly started the script but this wouldn't be immediately obvious to most users. testing the rest now.
When i activated i got the autorun dialog generated from rc4. I didn't feel like rebooting at the time so i canceled thinking i would just activate it later and start again. After deactivating and reactivating i got no popup, and no obvious way to rerun the script again. I had removed the /tmp/porteus-1.2-i486-update_test-oct1 directory.
Code: Select all
Adding new loop device: mknod /dev/loop23 b 7 23
Updating shared library links: /sbin/ldconfig
/etc/rc.d/init.d/porteus-1.2-i486-update_test-oct1-activate.sh: line 5: /tmp/porteus-1.2-i486-update_test-oct1/scripts/update_entry: No such file or directory
How do i become super user?
Wear your underpants on the outside and put on a cape.
Wear your underpants on the outside and put on a cape.
- brokenman
- Site Admin
- Posts: 6105
- Joined: 27 Dec 2010, 03:50
- Distribution: Porteus v4 all desktops
- Location: Brazil
Re: Auto-updates for kernel, base modules, etc - TESTERS NEE
Don't forget to remove double slashes from paths /mnt/sda5/os/porteus//boot ... although on my setup it worked ok.
After rebooting the expected outcome of updated cheatcodes.txt and GNU_GPL files were realized. Seems like it is working nicely. Congrats ... this will be very useful. Digging deeper into the rabbit hole, a dialog confirming that the update took place would be nice, perhaps by creating another autostart script 'on the fly' that checks for a different md5sum or timestamp on next boot and them magically self destructs.
Sheesh brokenman ... not asking for much!
After rebooting the expected outcome of updated cheatcodes.txt and GNU_GPL files were realized. Seems like it is working nicely. Congrats ... this will be very useful. Digging deeper into the rabbit hole, a dialog confirming that the update took place would be nice, perhaps by creating another autostart script 'on the fly' that checks for a different md5sum or timestamp on next boot and them magically self destructs.
Sheesh brokenman ... not asking for much!
How do i become super user?
Wear your underpants on the outside and put on a cape.
Wear your underpants on the outside and put on a cape.
- Ahau
- King of Docs
- Posts: 1331
- Joined: 28 Dec 2010, 15:18
- Distribution: LXDE & Xfce 32/64-bit
- Location: USA
Re: Auto-updates for kernel, base modules, etc - TESTERS NEE
Thanks, brokenman!
I reworked the autostart scripts a bit, but wasn't able to recreate your issue (will try again later, after re-reading your post, I think I wasn't following the correct order of events). Did you manually delete the file in /tmp? I'm not sure how you had the autoexec script in place without the update_entry being there to execute (which seems to be the problem you were having). I did find that starting in text mode and logging in to gui caused the script to try starting twice, so I've fixed that. I also added another filter to remove double slashes from the boot and porteus directories prior to displaying them to the user.
I can add some explanation to the 'text mode' version to tell the user to run /tmp/$modname/scripts/update_entry if they cancel out of it, and I could also add something for gui mode -- a desktop icon (not my favorite idea because I'd have to add it to each user, including those that are not root or guest, which means autodetecting them and creating files which could hang around in saved changes) or a .desktop file in /usr/share/applications (less visible but would leave when the module is deactivated).
I do like your idea for a dialog stating that the update completed successfully. It's not without pitfalls, though. For example, a user could apply the update on one machine, shut down, pull the stick and not use it again until they put it on another machine (or start it with different cheatcodes), where for example, the stick is now sdc instead of sdb. To cover that potential, I can't just pass established values to the new script, I'd need to re-establish the /porteus and /boot directories to check the md5sums and replace the "1st dummy" module (containing the confirmation dialog) with a "2nd dummy" module.
Would you be sassified with a colored text notification just prior to reboot? There's already a message that says "Finished applying updates. System rebooting in five seconds." But it's plain white text and doesn't stay there very long. There's already an md5 check function prior to copying the data:
Reading through that, I think I didn't add checks for the data in /porteus! I'll add that in.
There is also a check during the copy process:
so I think most of the bases are covered....last thing that is missing is actual verification of the md5 after the copy. Maybe I could copy the md5sum utility + libs into /mnt/live/usr/ so I can do this all at shutdown....
I reworked the autostart scripts a bit, but wasn't able to recreate your issue (will try again later, after re-reading your post, I think I wasn't following the correct order of events). Did you manually delete the file in /tmp? I'm not sure how you had the autoexec script in place without the update_entry being there to execute (which seems to be the problem you were having). I did find that starting in text mode and logging in to gui caused the script to try starting twice, so I've fixed that. I also added another filter to remove double slashes from the boot and porteus directories prior to displaying them to the user.
I can add some explanation to the 'text mode' version to tell the user to run /tmp/$modname/scripts/update_entry if they cancel out of it, and I could also add something for gui mode -- a desktop icon (not my favorite idea because I'd have to add it to each user, including those that are not root or guest, which means autodetecting them and creating files which could hang around in saved changes) or a .desktop file in /usr/share/applications (less visible but would leave when the module is deactivated).
I do like your idea for a dialog stating that the update completed successfully. It's not without pitfalls, though. For example, a user could apply the update on one machine, shut down, pull the stick and not use it again until they put it on another machine (or start it with different cheatcodes), where for example, the stick is now sdc instead of sdb. To cover that potential, I can't just pass established values to the new script, I'd need to re-establish the /porteus and /boot directories to check the md5sums and replace the "1st dummy" module (containing the confirmation dialog) with a "2nd dummy" module.
Would you be sassified with a colored text notification just prior to reboot? There's already a message that says "Finished applying updates. System rebooting in five seconds." But it's plain white text and doesn't stay there very long. There's already an md5 check function prior to copying the data:
Code: Select all
# verify data was not corrupted in download:
unset failmd5
pushd /tmp/$modname/data/porteus 1>/dev/null
for a in `find ../boot -type f` `find . -type f`; do
curmd5=`md5sum $a|cut -d " " -f1`
chkmd5=`grep $a /tmp/$modname/data/update_md5.txt|cut -d " " -f1`
if [ "$curmd5" != "$chkmd5" ]; then
failmd5=`echo $failmd5 $a`
fi
done
popd 1>/dev/null
if [ "$failmd5" ]; then
if [ "$DISPLAY" ]; then
gtk_message "This update has failed because the md5sum for the file(s) $failmd5 do not match. Please delete this update module and download it again, as your data may have been corrupted in transfer. Press OK to exit." 500 gtk-yes && exit
else
echo "This update has failed because the md5sums for the files $failmd5 do not match. Please delete this update module and download it again, as your data may have been corrupted in transfer. Press Enter to exit."
read
exit
fi
fi
There is also a check during the copy process:
Code: Select all
## copy files if everything has been ok so far
echo "Copying updated files onto your device..."
# copy everything but the .sgn file
for item in `ls $mntdir/tmp/$modname/data/porteus/ |grep -v "\.sgn"`; do
cp -ar $mntdir/tmp/$modname/data/porteus/$item $portdir
if [ $? -ne 0 ]; then
echo "error copying data file $item to $portdir" >> $logfile
echo "" >> $logfile
problems=true
fi
done
cp -ar $mntdir/tmp/$modname/data/boot/* $bootdir
if [ $? -ne 0 ]; then
echo "error copying boot data into $bootdir" >> $logfile
echo "" >> $logfile
problems=true
fi
## warn the user if there were copy problems...
if [ "problems" = "true" ]; then
echo "ERROR: Some error occurred while copying data! Please read the"
echo "log file at $logfile after rebooting for more information."
echo ""
echo "Rebooting in 10 seconds..."
sleep 10
fi
Please take a look at our online documentation, here. Suggestions are welcome!
- brokenman
- Site Admin
- Posts: 6105
- Joined: 27 Dec 2010, 03:50
- Distribution: Porteus v4 all desktops
- Location: Brazil
Re: Auto-updates for kernel, base modules, etc - TESTERS NEE
Did you manually delete the file in /tmp?
Yes.
My machine is dual boot and after rebooting (after the update) i booted into windows ... then came back later into porteus to verify the updates. All good.
I guess there is no fool proof way to do it. I think most people would be rebooting directly back into porteus after the update but to be sure you could grab the UUID of the device and drop it into the boot folder for verification after boot. I'd be happy with a colored text informing of success. I didn't see the text message, but then i stopped reading the shutdown messages long ago and wasn't expecting it.
Yes.
My machine is dual boot and after rebooting (after the update) i booted into windows ... then came back later into porteus to verify the updates. All good.
I guess there is no fool proof way to do it. I think most people would be rebooting directly back into porteus after the update but to be sure you could grab the UUID of the device and drop it into the boot folder for verification after boot. I'd be happy with a colored text informing of success. I didn't see the text message, but then i stopped reading the shutdown messages long ago and wasn't expecting it.
How do i become super user?
Wear your underpants on the outside and put on a cape.
Wear your underpants on the outside and put on a cape.
Re: Auto-updates for kernel, base modules, etc - TESTERS NEE
call[run] your script with "exec". [man bash] E.g. exec myscript -optionsOne issue that I already know about is that if you run the update in text mode, you can't exit the update once you've said 'yes' to continue with the update. Ctrl+C and Ctrl+D
- Ahau
- King of Docs
- Posts: 1331
- Joined: 28 Dec 2010, 15:18
- Distribution: LXDE & Xfce 32/64-bit
- Location: USA
Re: Auto-updates for kernel, base modules, etc - TESTERS NEE
Thanks, pizzar0!
I should have updated this thread, as we discussed this a bit on another thread, here: http://forum.porteus.org/viewtopic.php?f=81&t=1560
Even calling with 'exec', Ctrl-C won't work. For now, I'm going to try moving this script so that it starts earlier in the boot-up process (rc.S), as I can't implement the fix that was developed in the other thread for this case.
I should have updated this thread, as we discussed this a bit on another thread, here: http://forum.porteus.org/viewtopic.php?f=81&t=1560
Even calling with 'exec', Ctrl-C won't work. For now, I'm going to try moving this script so that it starts earlier in the boot-up process (rc.S), as I can't implement the fix that was developed in the other thread for this case.
Please take a look at our online documentation, here. Suggestions are welcome!