Auto-updates for kernel, base modules, etc - TESTERS NEEDED

New features which should be implemented in Porteus; suggestions are welcome. All questions or problems with testing releases (alpha, beta, or rc) should go in their relevant thread here, rather than the Bug Reports section.
Post Reply
User avatar
Ahau
King of Docs
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

Post#1 by Ahau » 01 Oct 2012, 16:08

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!!
Please take a look at our online documentation, here. Suggestions are welcome!

User avatar
brokenman
Site Admin
Site Admin
Posts: 5456
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v3.2rcX all desktops
Location: Brazil
Contact:

Re: Auto-updates for kernel, base modules, etc - TESTERS NEE

Post#2 by brokenman » 02 Oct 2012, 02:34

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.

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
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.
How do i become super user?
Wear your underpants on the outside and put on a cape.

User avatar
brokenman
Site Admin
Site Admin
Posts: 5456
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v3.2rcX all desktops
Location: Brazil
Contact:

Re: Auto-updates for kernel, base modules, etc - TESTERS NEE

Post#3 by brokenman » 02 Oct 2012, 02:43

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!
How do i become super user?
Wear your underpants on the outside and put on a cape.

User avatar
Ahau
King of Docs
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

Post#4 by Ahau » 02 Oct 2012, 16:30

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:

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
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:

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
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....
Please take a look at our online documentation, here. Suggestions are welcome!

User avatar
brokenman
Site Admin
Site Admin
Posts: 5456
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v3.2rcX all desktops
Location: Brazil
Contact:

Re: Auto-updates for kernel, base modules, etc - TESTERS NEE

Post#5 by brokenman » 02 Oct 2012, 17:50

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.
How do i become super user?
Wear your underpants on the outside and put on a cape.

pizzar0
White ninja
White ninja
Posts: 28
Joined: 08 May 2011, 22:26
Location: Chritmas Island

Re: Auto-updates for kernel, base modules, etc - TESTERS NEE

Post#6 by pizzar0 » 15 Oct 2012, 14:57

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
call[run] your script with "exec". [man bash] E.g. exec myscript -options

User avatar
Ahau
King of Docs
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

Post#7 by Ahau » 16 Oct 2012, 16:22

Thanks, pizzar0!

I should have updated this thread, as we discussed this a bit on another thread, here: 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!

Post Reply