Skip to content
This repository has been archived by the owner on Feb 27, 2023. It is now read-only.

Support Devuan 2.0 "ASCII" installation #515

Open
jaromil opened this issue Aug 21, 2018 · 22 comments
Open

Support Devuan 2.0 "ASCII" installation #515

jaromil opened this issue Aug 21, 2018 · 22 comments

Comments

@jaromil
Copy link

jaromil commented Aug 21, 2018

Hi there! any chances you may include also Devuan among the choices for an installed operating system? we provide Rpi* images among many others and build the Rpi3 for ARM 64bit on a native system. Value proposition is a lightweight and minimalist system without systemd (we support sysvinit or openrc) working pretty much like Debian. Latest release is here https://files.devuan.org/devuan_ascii/embedded/
cc: @parazyd (maintainer of Devuan's ARM builds)
cheers!

@XECDesign
Copy link
Contributor

@ghollingworth, what do you think? It's a Debian fork for people who think systemd is a bad thing.

@jaromil
Copy link
Author

jaromil commented Aug 22, 2018

if I may, it is a fork effort, it is free from systemd (we maintain sysvinit and openrc as preferred init systems) as well there is no Gnome and there is eudev and elogind to support a less entangled desktop system. Devuan also innovates on a number of things as infrastructure and build system. As a result, we provide more than 30 ARM targets off the same builds, visible from the link above. Therefore I believe that to define Devuan by a moral judgement on systemd is reductive if not misleading nowadays.

@ghollingworth
Copy link

First it would require someone create NOOBS compatible tarballs. Then we can think about adding to the json file

@jaromil
Copy link
Author

jaromil commented Aug 22, 2018

Sounds feasible! we can integrate their creation into our arm-sdk.
I assume this to be the latest up-to-date documentation for creating NOOBS compatible tarballs https://github.com/raspberrypi/noobs/wiki/Adding-custom-OS-version-examples please correct me if otherwise. Thanks for your consideration.

@procount
Copy link
Contributor

procount commented Aug 22, 2018

Yes it should be. Also look in github.com/procount/pinn in README_PINN.md and in its wiki for more information and examples.
(I would convert it myself but I'm away atm)
Edit- although in the long run it's better if the maintainer can host an up to date noobs version

@procount
Copy link
Contributor

I had a quick look at the existing tar.gz files.
You could leave these as they are and adapt the partition_setup.sh script to move the boot files across to the first partition after installing everything to the second partition.
OR you can split this file into 2 files - 1 for each partition (e.g. devuan_boot.tar.gz and devuan_root.tar.gz) and use a more conventional partition_setup.sh script. Follow the instructions in the readme.
If you have any "expand rootfs on initial boot" type scripts, these should be deleted as they are not needed with NOOBS. Again, you could do this before creating the tarballs, or you can delete them from the partition_setup.sh script, which NOOBS runs after initial installation, but before first boot of the OS.

@XECDesign
Copy link
Contributor

I would prefer to see separate archives to keep progress information accurate.

@procount
Copy link
Contributor

I agree, especially as it makes it more consistent with other OSes, and as the opportunity is here for them to adapt their production scripts, now is the time!
But I don't see how it makes the progress information inaccurate - it's the same amount of data, it's just moved from 1 partition to the other. It would take a bit longer for partition_setup script to run, but I think that's really minimal.

@XECDesign
Copy link
Contributor

When it says it's extracting boot files it would be lying, and then it would (ab)use partition_setup instead. Not a fan, but I won't insist either way.

@procount
Copy link
Contributor

I still agree with you 😉. But the boot partition would be of "empty_fs" type (or extract a README.txt" file at best), so it wouldn't be extracting any boot files and it wouldn't take any time to copy. So it's not really lying. The rootfs partition would be bigger and take longer, so the total time (which is what people are really interested in) would still be the same. It's only if they compared the final sizes of the partitions after installation with the individual times of each partition download that it would look skewed.
The biggest (ab)user of partition_setup.sh is Microsoft with their WinIoT.

But yes - splitting the archive is still the preferred way!

@XECDesign
Copy link
Contributor

Alright, I sit corrected.

@lurch
Copy link
Collaborator

lurch commented Aug 23, 2018

the total time (which is what people are really interested in) would still be the same

Well, if we're splitting hairs the total time would actually be longer, as it has to also copy the boot-files from the root to the boot partition 😜

@procount
Copy link
Contributor

procount commented Aug 27, 2018

I've done the basic conversion of the 3 versions of Devuan to NOOBS format.
You'll find them in
https://sourceforge.net/projects/pinn/files/testing/ as devuan1, devuan2 and devuan3.

Devuan3 seems to load ok on a RPi 3B.

They still need an icon and some marketing slides and checking for whether they work on USB boot/root.
There's some extra fields in the json files for PINN as well, but NOOBs will quite happily ignore them.
(And Yes, I went down the archive splitting route!)

EDIT: I added an icon file now.

@jaromil
Copy link
Author

jaromil commented Aug 29, 2018

First of all I'm impressed by the quality of replies and enthusiasm you have shown, NOOBs really seems to host an healthy community. Second, apologies for not following up: august is a vacation period for me and other volunteers at Devuan.
At this point I'm not sure what else we can do to help. Perhaps integrate your procedure and templates into https://ci.devuan.org/view/arm64/ to streamline the publication to NOOBs, if that is desirable and when we manage (WIP) to move the production of ARM images into the CI (we do them "by hand" now).

@procount
Copy link
Contributor

Well, there are quite a few things you can do to help 😉
I have only produced a quick conversion of your original images to show the principles of what is required and I only tested the arm64 version on a 3B.
One of the hardest and time consuming jobs to do is to maintain and test the distributions, so if you can automate the production of these files within your build system and host them, then that would be a great help. The details for creating the tar.xz files and all the other associated meta files is described in the README.md file. I created a bash script that does most of the hard work for me, so I can try and extract the parts for Devuan-type builds and share it if you like?

What I have not done, is still missing or could be improved is as follows:

  1. A 40x40 icon file for each version: devuan1.png, devuan2.png and devuan3.png. I took the 16x16 favorite.ico from your website and blew it up to 40x40. You could probably do something better.
  2. A set of (3 or 4?) .png images to be shown as slides to be shown during installation describing Devuan's main features or benefits, or how to install additional features etc. (approx 384x288 pixels).
  3. Check the release_notes.txt file - I just cut & pasted a readme/changelog that I found. Maybe some of that information is not relevant to a NOOBS install.
  4. I didn't check if you have any fs/partition expansion code on first boot. If there is, it needs to be removed for NOOBS. Otherwise the tar.xz images I created are probably ok.
  5. Check that all 3 images can be installed using NOOBS, from the internet and from a USB stick, to the SD card and to a USB drive, on all 4 types of RPi (0/1, 2B, 3B, 3B+).
  6. Add the "supports_usb_boot" & "supports_usb_root" options to os.json according to result of installing to USB.
  7. (Optional: Check that the autoboot.txt feature works with these builds)
  8. Automate creation of .tar.xz files in build system.
  9. Automate creation of meta files (to update file sizes & storage requirements etc.) in build system. (You can use the files I created as a template, or as a check to ensure your automation scripts work correctly).

Hope that helps.
Let me know if you need any further explanation of any part of the process.

@lurch
Copy link
Collaborator

lurch commented Sep 3, 2018

You might also find some of the scripts in https://github.com/RPi-Distro/pi-gen/tree/master/export-noobs useful.

@jaromil
Copy link
Author

jaromil commented Sep 3, 2018

many thanks guys amazing help. we are thinking of incorporating something in Devuan SDK along these lines... and beyond :-)

@procount
Copy link
Contributor

procount commented Sep 5, 2018

@lurch - I wish you'd told me about those scripts before 😉. However, they do look remarkably similar to mine, just that mine now have to support the conversion of 8 different formats of images for about 50 OSes! Nevertheless, I might pinch some ideas from those next time I update it.

@lurch
Copy link
Collaborator

lurch commented Sep 5, 2018

@lurch - I wish you'd told me about those scripts before

Sorry, I never realised I hadn't already pointed out pi-gen to you!

mine now have to support the conversion of 8 different formats of images for about 50 OSes

Keeps you busy I guess... 😉

@procount
Copy link
Contributor

Hi @jaromil,
I have partially complete (still need checking and slideshow) installation files for Devuan 2.0 sitting on my sourceforge. Do you still want to progress this?
I notice on your website there is now a version 2.1, but not yet available for ARM. Do you think this will happen soon, and will there be a version for the Pi4?

@jaromil
Copy link
Author

jaromil commented Jan 18, 2020

@procount yes I would like to go forward and yes 2.1 was only built on a testing repository. I'll update you on the timings, thanks for the ping I completely lost sight. Was a busy year for developers involved on Devuan ARM builds, perhaps due to success ;^) we all got distracted building derivatives (maemo-leste being the most advanced ARM one) but more people are coming to help.

@procount
Copy link
Contributor

V2.0 is virtually ready to go on PINN, subject to my checkpoint list above, so if you can provide or check the meta files that would be a big help.

Re step 4, if you can point me at any resizing script, I can adapt our setup script to remove it.

Going forward, it's best if you can generate all the meta files and tarballs from your build script and host them, but I've already done the basic conversion for 2.0 and can host it on sourceforge for you to get this one added to PINN in the meantime.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants