Build
Build copied to clipboard
volumio
Support USB boot
I'd like to see volumio support post-install boot from USB flash drives.
The first part of the boot allows initramfs/init allows imgpart and imgfile to be specified from cmdline.txt (the kernel command line options).
Then the tail of the init process starts using /dev/mmcblk0p1, and /dev/mmcblk0p3. These are mentioned in two important contexts:
- During initial boot when the media needs to be repartitioned, etc.
- During subsequent boots when the installed application can be started immediately.
As present I'm interested in the second scenario. The static part of the overlay is already retargetable by using imgpart and imgfile.
I'm thinking that perhaps imgdata can be used to retarget the dynamic part of the overlay, replacing or to begin with optionally overriding the /dev/mmcblk0p3. Looking at the source, this would only need to affect the code after:
# 4) mount a filesystem for write access to the static image
What do you think of this approach?
I found another approach to running volumio2 from USB:
- Partition USB flash drive
- Copy the content of the volumio2 squash image into the USB flash partition
- Remove imgpart and imgfile from cmdline.txt
- Remove initramfs from config.txt
- Add root= and rootfstype= to cmdline.txt to use the root partition on the USB flash drive
- Add the root partition to /etc/fstab on the USB flash drive
Yes, of course that will work, for now.... As long as you realise, that you now have an incompatible Volumio image and will not be able to update.
It is an idea for a cloning plugin, moving a part of the system to usb (flash), but then it should be done in such a way, that it remains compatible. Do you have coding skills? You basically have three options on the commandline, identifying the squasfs file by UUID, by /dev or by label. perhaps we should locate the data partition is a similar we to be fully flexible (small change). The system would not care if squashfs or data part are on the SD card or somewhere else, as long as the device is online when running initramfs
I've re-opened this ticket because I think you are right that proper support would require that remote update stays functional.
I looked around for source code to understand how volumio-remote-updater works, but it does not seem to be available.
perhaps we should locate the data partition is a similar we to be fully flexible (small change).
This was my original line of thinking: introduce imgdata= to complement imgfile= and imgpart=.
While working on this, if you could lay-out a proper way to have Volumio2 work on Berryboot (which can support booting from USB), that would be awesome! New layout is not that different in principle with what Berryboot does, but it's sufficiently different to make it not straightforward (initramfs, cmdline.txt & config.txt modifications by Volumio, updates,...).
Really miss such Berrybootable version (was easy to make on Volumio 1.5).
Sorry, don't want to offend you but I have no time or interest to play around with Berryboot when there is no demand for it (except yours). We do not support Berryboot and have no plans in that direction either.
No offense @gkkpch :) and I really appreciate all your hard work on this project My comment was more directed to @earlchew as a possible option for USB boot, while he is making investigations: problems to be solved seem similar with what he intends into doing.
I won't advocate about the merits of Berryboot here, but it does have many adopters, some eventually use Volumio. Comparable projects such as LibreElec/OpenElec accommodate very well with it for instance (squashfs distribs, auto-update, etc). However, it is well understood it is not in Volumio Dev team plans.
@macmpi I obviously misunderstood and should perhaps choose my words more carefully next time ;) It was not meant as rude as it appears.
@gkkpch - Please have a look at https://github.com/earlchew/volumio2-Build/commit/44b82da8fc6c5009abdcdd7990ad62dbca0bd19.
I created partitions on my USB flash drive, then changed cmdline.txt to reflect the new boot location:
... imgpartopt=ro imgpart=UUID=282be28d-9c4c-4640-8421-bece7f928c10 imgfile=volumio.sqsh imgdata=UUID=a39a0b0a-2843-4c27-a0af-b720de98c906 ...
Great job Earl :bowing_man: On which board did you test this with, a PI? Also curious if you were able to catch errors and try the emergency shell. I will have a closer look at it this week to check how much we need to change in the build scripts to get this working as a default. We could use more of your work, care to join us? :grin:
@gkkpch - As you have probably figured out, I didn't test this out with a complete end-to-end build. A consequence of this is that I left off another commit that is required for this to work: https://github.com/earlchew/volumio2-Build/commit/13a953a29d8363efefc9ca27cd668ed51c01eec3
I am running this change on my rpi B (512MB, Ethernet, SD card).
While working out the obvious kinks in this change, I did have the chance to use the emergency shell :weary: No doubt, I've left all the non-obvious kinks for you to find.
Ok, thought findfs was in as default on arm, but obviously not... Interesting stuff Earl, really keen on trying this out. -- Gé --
Earl: any news on this, did you test initrd? I want to invest time to see if it can be integrated, but need a confirmation that the basics work.
@gkkpch I run that code on my deployment, but I must tell you that while I know the code works in my running appliance, I have not made a build to verify it builds and works correctly starting from scratch. So far I have spent my time working to make my appliance function correctly so that I can use it, and that meant working my way up to the GUI.
Probably the next thing I will try is to set up a build environment to construct a Raspberry Pi image, and then try to run that on a spare Raspberry Pi I have at home.
Hi,
is this topic still ongoing? I would be interested to continue this work. Is there anything that needs to be done for this to be completed? I started a similar approach by trying to make volumio boot from a USB stick, The reason I want to do this is that I have a RPI case where i can not easily access the SD-Card without disassembling a lot. Hence I would like to boot volumio completely from USB. By modifying the init script locally I managed to get volumio booting up to the UI, however I am not able to install any plugins, so I am wondering whether I missed something. Is there anybody interested in finishing this task around? If not I will let this rest on my private pi.
Thanks for all the hard work that went into volumio!
P.S.: Is there a reason why UUIDs are preferred over static device file names?
Hi, we are trying to avoid using UUID where we can, but while using device names currently works well on most arm devices, it is different on x86 machines. To correctly identify the correct partitions, a device name won't do as the user can basicly boot from any device depending on bios/uefi. On arm devices this is not the case yet, but may be changing soon when devices are starting to use mainline u-boot supporting usb or even spi
Thanks for the reply. Would it harm the project to make the data partition name also selectable via kernel cmdline as the imgpart already is? Is there a problem I don't see? For me this booted fine up to the ui on my raspberry pi, and if the default values are set properly to /dev/mmcblk0p3 if nothing is specified it should not harm any other device, or should it?
@DecayFi if you need it now on Pi, you may want to try this (unsupported) method on stock images: it comes with some minimal limitations of course...
Thanks, this looks very interesting. I was intending to remove the sdcard completely or just leave bootcode.bin on it, so that I can chose the distro to run by plugging a certain usb stick before boot. This works fine for Rasbian and I have my modifications already running with Volumio on my local rpi. All I had to change from the stock image was the init script in the initrd. The changes were only minimal and basically replaced hardcoded partition names with variables that default to the original values if not set explicitely in cmdline.txt. With these changes it should be possible to use all stock components including the kernel, it should still boot from sdcard as originally intended and all changes necessary can be done in cmdline.txt.
So I was wondering whether there was any interest into getting this into the main volumio tree. In this case I could cleanly implement the changes and test a bit more; if this is not desired I'll just keep my changes local and remain quiet.
The only thing I am unsure about is whether volumio has more hidden dependencies towards usb than I see, as I was not able to see any available plugins in the stock volumio ui when I ran my patched stock image. Everything else seemed to work fine.
Yes, that would be an interesting option. Please do the PR and we'll review it. It would be handy if we could switch to USB just by changing cmdline.txt param (or even by placing the squash image named usb-system.sqsh on the USB)
I thought that I had issued a merge request for these commits, but it seems I didn't. I was also waiting for feedback from I was waiting for feedback from @gkkpch.
In any case, in summary there are two commits:
- https://github.com/earlchew/volumio2-Build/commit/44b82da8fc6c5009abdcdd7990ad62dbca0bd19
- https://github.com/earlchew/volumio2-Build/commit/13a953a29d8363efefc9ca27cd668ed51c01eec3
These changes allowed the choice of partition to be made from cmdline.txt and support choice by:
- UUID
- LABEL
-
/dev/*
In the case of UUID and LABEL, the commit uses findfs(8) to locate the partition (which could in theory be on USB, SATA, etc).
@DecayFi asked:
P.S.: Is there a reason why UUIDs are preferred over static device file names?
The reason I use UUIDs (though LABELs would also work in this regard), is that it means that it avoids having to bake /dev/* names into the command line. Additionally, /dev/* names cannot be guaranteed to be stable (because of the way they are assigned by udev), so /dev/sda might not be what you think it is in the general case (YMMV). The other practical reason is that it allows the USB drive to be relocated, or co-located with multiple USB drives, etc.
@earlchew : Were you planning to adopt the resize script to UUID as well? I am still facing the problem that even after all modifications in the initrd being done, something still tries to mount mmcblk0p1 as /boot when volumio, Will have to keep looking into that, as I'm still having trouble installing plugins properly with my modifications.
@DecayFi What is the resize script/operation you're referring to? Is this when the partitions get actively resized on first boot?
something still tries to mount mmcblk0p1 as /boot when volumio
Hmm ... let me look into that on my installation. I don't recall what happened there.
Yes, I was referring to the initial resize. I know it can be done manually, I was just wondering whether this script can cause harm when the sdcard is used elsewhise. Can I take from your inital post that you exclude this scenario?
Also, I am wondering whether the /etc/inittab needs adjustments at runtime, as it will continue to mount /dev/mmcblk0p1 as /boot. Did you find a solution for this I am not seeing? I am worried that this will cause problems during plugin-install if one needs to add a device tree overly or something similar.
Hi, it is going to be nearly impossible to get a standard boot procedure, valid for not just pi but also other platforms, and automatic release/kernel updating when people have changed the image standard configuration files. It would require a major rework of initrd and update procedures, something I do not see happening in the near future.
However, adding additional device options to the kernel boot parameters is something we can easily do to make customizing easier, but please accept this will not cover update procedures, including installation of plugins etc. This would require that the update/install procedure are perfectly aware of what the user has changed in the configuration, we cannot cover that at the moment.
On 30 Aug 2017, at 23:14, earlchew [email protected] wrote:
@DecayFi What is the resize script/operation you're referring to? Is this when the partitions get actively resized on first boot?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
Though PI is the major arm platform, there are others which do not work with device tree overlay. This also needs to be considered, the boot configuration of supported images is very device dependent, a common solution may be more complex than we think just now, only looking at PI.
On 30 Aug 2017, at 23:49, DecayFi [email protected] wrote:
Yes, I was referring to the initial resize. I know it can be done manually, I was just wondering whether this script can cause harm when the sdcard is used elsewhise. Can I take from your inital post that you exclude this scenario?
Also, I am wondering whether the /etc/inittab needs adjustments at runtime, as it will continue to mount /dev/mmcblk0p1 as /boot. Did you find a solution for this I am not seeing? I am worried that this will cause problems during plugin-install if one needs to add a device tree overly or something similar.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
Hi, I think I get your point. If I understood this correctly, a solution that creates more flexibility but will default to the current behavior would be acceptable, even if it limits functionality for people manually activating it, right?
correct
On 31 Aug 2017, at 00:14, DecayFi [email protected] wrote:
Hi, I think I get your point. If I understood this correctly, a solution that creates more flexibility but will default to the current behavior would be acceptable, even if it limits functionality for people manually activating it, right?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
Hi,
I think this also needs to be solved as part of the ootb configuration for arm devices.
/dev/mmblk0 used to be coded fixed in initramfs, meanwhile it already became a little more flexible.
It still defaults to /dev/mmcblk0, but with newer images (> 2.246) can be overridden by boot parameter bootdev (which is not a partition!).
When we want to solve it along the line of what is being discussed here, the resize part should take the bootpart parameter into account.
Btw. automatic resizing on boot, e.g. after the data partition has been moved to a bigger partition, can always be achieved by dropping a empty file called “resize-volumio-datapart” into /boot.
I suggest, anyone interested in a more flexible solution, study the current version of the init script found in “build/scripts/initramfs”.
Gé
From: DecayFi [mailto:[email protected]] Sent: Wednesday, August 30, 2017 11:49 PM To: volumio/Build Cc: Gé Koerkamp; Mention Subject: Re: [volumio/Build] Support USB boot (#119)
Yes, I was referring to the initial resize. I know it can be done manually, I was just wondering whether this script can cause harm when the sdcard is used elsewhise. Can I take from your inital post that you exclude this scenario?
Also, I am wondering whether the /etc/inittab needs adjustments at runtime, as it will continue to mount /dev/mmcblk0p1 as /boot. Did you find a solution for this I am not seeing? I am worried that this will cause problems during plugin-install if one needs to add a device tree overly or something similar.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/volumio/Build/issues/119#issuecomment-326129214 , or mute the thread https://github.com/notifications/unsubscribe-auth/AMfAG1F_-HxEP7ghFFiurAHI_JG8QDr6ks5sddjogaJpZM4LaPZd . https://github.com/notifications/beacon/AMfAG1w6aWx32dE3AGRLo8zf2hjTjITKks5sddjogaJpZM4LaPZd.gif
I tried to study the the new init. If I read this correctly, this will still not allow to boot from usb as the new init will try to mount /dev/sdap1 instead of /dev/sda1 if bootdev is set to sda. So I am afraid that these recent changes will not allow usb boot. However I will try to create a PR once I tested my modifications of the new inoi a bit more, you can then decide whether my modifications go to far or not.
Independent of the initrd, fstab will still hardcode /dev/mmcblk0p1 so that when volumio is up /dev/mmcblk0p1 will be mounted as /boot with all the consequences mentioned above. I did not find the time yet to look into what can be done using systemd to resolve that.
I tested the initscript on both native sdcard and for usb-boot. I was able to boot completely from USB-Stick at https://github.com/DecayFi/Build/commit/e4ca246707f0f82cb349dea20acba4bf5c00da8f
The script will default to the same behavior as the original script. In order to boot from /dev/sda[1,2,3] one needs to add bootdev=sda dps= genpnames to the cmdline. It is important to place this after the imagepart setting or replace to change the imagepart accordingly or remove the imagepart. However, if a conflicting imagepart is specified after the genpnames it will be preferred over the bootdev setting.
I tested the initial resizing of the datapart which worked for sdcard and usb boot. However I did not test the usb update yet. I also disabled the usb update if the system boots from sda.
Regarding the systemd fstab issue I made the mount of /boot happen in the initrd and removed the boot line from fstab. This might lead to a problem if there is an usecase in Volumio where /boot needs to be mounted or unmounted at runtime. In addition, one should probably unmount /boot manually during shutdown, as I think systemd might not do it anymore if the mountpoint no longer is part of fstab.
If the hardcoded fstab stays in /etc/fstab, systemd will mount the hardcoded mmcblk0p1 over the already existing mount. Is this worth creating a PR or will this be rejected anyways?
Hi,
thank you very much for the excellent work and the time you invested to get the hardcoded stuff out of the way. Happy to have you on the team in case you are interested in doing additional OS work.
A quick glance at the code makes me believe it can be merged without causing any regression with other devices. I will have a closer look at it the beginning of next week and try it on e.g. Odroid C2 and XU4 (XU4 was the one for which I already started changing to BOOTDEV). Perhaps we can develop this further so it survives a kernel update as well, think about it...
-- Gé --
On 02/09/17 16:44, DecayFi wrote:
I tested the initscript on both native sdcard and for usb-boot. I was able to boot completely from USB-Stick at DecayFi/Build@e4ca246 https://github.com/DecayFi/Build/commit/e4ca246707f0f82cb349dea20acba4bf5c00da8f
The script will default to the same behavior as the original script. In order to boot from /dev/sda[1,2,3] one needs to add bootdev=sda dps= genpnames to the cmdline. It is important to place this after the imagepart setting or replace to change the imagepart accordingly or remove the imagepart. However, if a conflicting imagepart is specified after the genpnames it will be preferred over the bootdev setting.
I tested the initial resizing of the datapart which worked for sdcard and usb boot. However I did not test the usb update yet. I also disabled the usb update if the system boots from sda.
Regarding the systemd fstab issue I made the mount of /boot happen in the initrd and removed the boot line from fstab. This might lead to a problem if there is an usecase in Volumio where /boot needs to be mounted or unmounted at runtime. In addition, one should probably unmount /boot manually during shutdown, as I think systemd might not do it anymore if the mountpoint no longer is part of fstab.
If the hardcoded fstab stays in /etc/fstab, systemd will mount the hardcoded mmcblk0p1 over the already existing mount. Is this worth creating a PR or will this be rejected anyways?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/volumio/Build/issues/119#issuecomment-326748297, or mute the thread https://github.com/notifications/unsubscribe-auth/AMfAG6wuZYw3JZd7yIsMrH5VC7faZ0ikks5seWnKgaJpZM4LaPZd.
very interesting indeed.
Regarding the systemd fstab issue I made the mount of /boot happen in the initrd and removed the boot line from fstab. This might lead to a problem if there is an usecase in Volumio where /boot needs to be mounted or unmounted at runtime.
I think currently /boot needs to be mounted at runtime (on Pi at least), as Volumio2 app (or plugin) may read/modify config.txt
ah, and the hint regarding /boot is a good one too, this would avoid extra hacking with fstab. I think I can use that for X86 too and avoid fiddling with an fstab template (in order to edit the UUID in initrd)
yes, but when mounted in initrd it should survive switch-root and show up as /boot
anyway, going to test this as updates are changing files in /boot too (on all devices) ...
I tested the /boot mount as well, it does survive the switch_root. If there is an enrty in fstab also specifying boot, it seems to mount it twice if both mounts succeed. However the contents seem to be from the partition that has been mounted last.
So if the boot entry in fstab is disabled, I also verfied that the correct partition is mounted as /boot at runtime. However it could be tricky if a re-mount is needed at runtime or if the access permissions do not match.
Did another test run - took most recent stock image, wrote to usb stick. Placed modified volumio.initrd in /boot partition and changed kernel-cmdline to
splash quiet plymouth.ignore-serial-consoles dwc_otg.lpm_enable=0 dwc_otg.fiq_enable=1 dwc_otg.fiq_fsm_enable=1 dwc_otg.fiq_fsm_mask=0x3 console=serial0,115200 kgdboc=serial0,115200 console=tty1 imgpart=/dev/mmcblk0p2 imgfile=/volumio_current.sqsh bootdev=sda dps= genpnames elevator=noop rootwait smsc95xx.turbo_mode=N bootdelay=5 logo.nologo vt.global_cursor_default=0 loglevel=0
and put in raspberry pi 3. It did resize the partition just fine and come up to wifi hotspot mode. When ssh was enabled, the /boot partition was showing the contents of the sdcard as the stock image still has the hardcoded fstab. After manually unmounting /boot the contents of the sdcard boot partition was shown and I was able to install the touch display and youtube plugins just fine.
Found two issues with my code. I did not realize that I was not mounting /boot with the correct permissions, so that volumio failed to remember some settings over a reboot. In addition I changed the boot-opt parsing to prevent being depended on the cmd line order, which can lead to a fail in resizing. I guess I should still spend a few more days testing :-/
The resizing now seems to resize the filesystem as well. I was able to reliably configure my touch display with hifiberry dac+ and touch display from a scratch image with replacing the initrd and fstab. So I think the code now contains what I wanted it to be.
For records, just linking to related ongoing PR https://github.com/volumio/Build/pull/256