Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Multiboot pi + recovery or update partition #146

Closed
wants to merge 2 commits into from

Conversation

mariyachanniwala
Copy link

Fix #124

@@ -0,0 +1,191 @@
/*Recovery Server for Companion*/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

server1.js is not a good name, can be more explicit ? Like recovery-webserver, or webpage.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How this file is being executed ? There is no modification in the screen script.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right now i havent added any modification in companion.rc. this file is executed simply by typing node server1.js. I havent added any explicit name because its just a trial version of the server. I will change the name.

app.get('/', function(req, res) {
res.render('index', {});
});
/*app.get('/socket.io-file-client.js', (req, res, next) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this necessary ? Is this a debug function ? Can add a comment why is this here.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no this is rendering the frontend liquid file.

res.send('Complete!');
});

/*var io = require('socket.io')(server);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same thing about commented code here.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the commented code is another way to implement the server that we can revert to. its just there for trial purposes. and will be removed in the future commits.

@@ -0,0 +1,4 @@
#!/bin/bash

sudo -H -u root bash -c "sed -i -e 's/\-03/\-02/' /boot/cmdline.txt"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a comment about what is happening here ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah sure. its basically just changing the partition id from 3 to 2 so that we can boot into the recovery partition


storage: multer.diskStorage({
destination: function(req,file,next) {
next(null, '/mnt/mainfs/home/pi/new_files');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are you going to store the files in the mainfs (not recovery) ? How are you going to read the .img file if this partition will be formatted ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the recovery partition does not have enough space to save a 1.4 gb file. thats why im storing it on the other partition where the update is supposed to happen. and once its saved we can just extract the image over existing partition using dd. so there will be no issues with accessing it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The "other partition" is the mainfs where webui runs or is a 3rd one that is used to store this files ?
if it's in mainfs, how dd will read the .img file while rewriting the mainfs ?

@mariyachanniwala mariyachanniwala force-pushed the issue124 branch 3 times, most recently from ec175e6 to 1a755f3 Compare August 10, 2018 20:30
@mariyachanniwala mariyachanniwala force-pushed the issue124 branch 2 times, most recently from 1c56396 to 6b03e78 Compare August 14, 2018 00:11
@mariyachanniwala
Copy link
Author

mariyachanniwala commented Aug 28, 2018

Multiboot / Recovery partition update:
Current branch works on the idea that the SD card has 4 partitions:
boot(~40 MB), Recovery(~4GB Running Companion for now), Imagefile(~4GB Empty), Companion(~7GB Running Companion)
Sizes are approximate. You can change them if you would like.

Steps to configure the partition fstabs and boot/cmdline.txt: (I did it how Patrick suggested in the beginning.)

  1. Take a blank SD card and flash a fresh companion Image on it using Etcher.
  2. Then go to gparted and make a new partition on the sd card of about 4GB in size.
  3. After that make another partition on the same SD card and assign it the remaining ~7GB of space.
  4. Now you should see four partitions on the SD card where the first one is boot. Label the next three partitions in this order, Recovery, Imagefile, Companion.
    image
  5. From the terminal, type "sudo blkid" and note your device id: /dev/sdX ('X'). Also make a note of the Part UUIDs of all the partitions.
  6. Close gparted and from the terminal, unmount all the partitions on /dev/sdX (Your device)
  7. Go to terminal and copy the image from partition 2 to partition 4 using sudo dd if=/dev/sda2 of=/dev/sda4
  8. Now, In the boot partition, edit the cmdline.txt file, and change Part UUID to the UUID of companion.
  9. Change /etc/fstab file in both recovery and companion partitions to change the rootfs Part UUID to their own UUIDs respectively. in this case 02 and 04. 03 is for the imagefile partition.
  10. Go to /etc/fstab in Recovery partition and add mount points for Imagefile and Companion Partition as follows;
    PARTUUID=Imagefile UUID /mnt/Imagefile ext4 defaults,noatime 0 2
    PARTUUID=Companion UUID /mnt/Companion ext4 defaults,noatime 0 3
  11. boot into companion and update to this branch. Then go to the webserver. You will see an option to boot into 'Recovery' partition.
  12. Once booted into the recovery partition update to this branch and run the recovery server at 192.168.2.2:3000. Before doing this, check in the /mnt directory to see if both the mount points are mounted.
  13. When you upload a file, make sure the size is less than 2GB. Apparently there is a limitation to how much socket.io-file can send. Even if on the website it says it can send without any size limit. You will see the update progress, final output file name and where it is stored.
  14. This file will be copied to the Imagefile partition.

I have successfully tested and verified the functionality until this point.

Current Stage: Now I am working on 'dd' command for writing the companion image to the companion partition from recovery partition but I have been facing some issues where dd is corrupting my sd card. I am working on it and hopefully should be done soon.

Commits:

Step 1: Added an option to boot into the recovery partition to companion web interface. Only use this button once you have followed the configuration steps above.
image

Step 2: Added the companion recovery server at 192.168.2.2:3000 which looks like this:
image

@jaxxzer
Copy link
Member

jaxxzer commented Aug 30, 2018

  • use fdisk and mkfs instead of gparted
  • use echo instead of nano
  • add labels to partitions after all dding is done (dd will copy label and uuid)
  • server does not start (fix expand_fs bug)
  • The recovery server and companion server should use the same port
  • Recovery server does not start after update
  • Take out updating to recovery server step
  • Recovery server cannot access partitions (fix permissions)
  • Create an image creation script
  • Upload a complete ready to go image to be dd'd onto a card

other goals:

  • make standalone recovery server program and image that is not dependent on companion (it should be far less than 3gb in size)
  • ship only boot and recovery
  • recovery image should take care of partitioning the rest of the disk
  • upload companion partition only to s3

@patrickelectric
Copy link
Member

@jaxxzer
Copy link
Member

jaxxzer commented Mar 4, 2020

We are looking at some alternative solutions like mender.io and swupdate.

@jaxxzer jaxxzer closed this Mar 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add multiboot + recovery/update partition
3 participants