Content proposed to describe image files in x86_64 Wiki

#1

I would like to propose some adjustments to the page https://lede-project.org/docs/instructionset/x86_64 (last edit was made by @tmomas).

I've changed my mind before publishing my edits because I don't know if it should go through a revision/discussion phase before.

So basically I would have added a section about describing the different targets built (just before "Download Packages"):

Click here to view proposed modifications

===== Download firmwares and tools =====

| HTTP | [[https://downloads.lede-project.org/releases/17.01.0/targets/x86/64/]] |
| FTP | [[ftp://ftp.halifax.rwth-aachen.de/lede/releases/17.01.0/targets/x86/64/]] |

==== Meta-Files details* ====

^ File extension ^ Description ^
| packages/ | Directory of packages for trunk x86-64, opkg will pull packages from here |
| config.seed | The kernel config file for the vmlinuz kernel |
| lede-imagebuilder-(...).tar.xz | Image Builder for x86-64, to build custom images without compiling |
| lede-sdk-(...).tar.xz | SDK Toolchain for compiling single userspace packages |
| sha256sums | sha256 checksums of the files in this dir, so you can check the copies you downloaded are correct |

==== Image Files details* ====

^ File extension ^ Description ^
| combined-ext4.img.gz | disk image (compressed) containing the normal Linux ext4 filesystem which is read-write when booted. Any changes you make to the filesystem persist across boots. |
| combined-squashfs.img | similar to combined-ext4.img.gz, but partitions are squashfs instead of ext4. This is a compressed filesystem which, when booted is read-only but a second “overlay” read-write filesystem is mounted on top of that in order to store changes. Any changes you make persist across reboots. This is the method used on most “home router” embedded devices because their internal storage is very small and this allows much more to fit on the device. |
| generic-rootfs.tar.gz | tar.gz of filesystem image of LEDE root filesystem |
| rootfs-ext4.img.gz | ext4 filesystem image (compressed) of LEDE root filesystem, same contents as generic-rootfs.tar.gz |
| rootfs-squashfs.img | squashfs filesystem image of LEDE root filesystem, same contents as combined-ext4.img.gz plus /dev/console |
| vmlinuz | Linux kernel for x86-64 build |

Please excuse me if there is a way to make a "preview" or "pre-release" of such proposed modifications, I'm not familiar with all the features of the Wiki. I welcome any advice on how to proceed forward, or further adaptation of my proposed modifs.

0 Likes

#2

Hi DjiPi,

Then the information proposed should go to a target specific page, rather than a package-architecture page. Since there's no page for x86 yet, see ar71xx for example: https://lede-project.org/docs/targets/ar71xx

For x86, this would be https://lede-project.org/docs/targets/x86. Create this page if you like.

Regarding Meta-Files details / Image Files details:
Sounds more like a generic description, rather than a target-specific one. At least the meta-files description is true for all targets, therefore we should handle it accordingly and create this information only once, and re-use it on all pages where it is needed.

Regarding Image files: I once created an overview of all the different files for all the different targets, but can not find it right now. This could be a starting point for a page describing all the firmware images.

0 Likes

#3

Found it again: https://lede-project.org/playground/firmware_image_names

Please mind that this is not an exhaustive list, but rather stripped down to what is listed in the dataentries and assumed to be relevant for installation.

Is that something that we could build upon?

0 Likes

#4

Thank you @tmomas, and sorry for taking so long to reply.

Doh! instructionset is definitively not the place, my bad interpretation. :blush:

My initial goal was to explain for x86_64 what image files were used for because I couldn't find that anywhere in the Wiki (so other users). Your table surely would have helped then.

Maybe there is a way to come up with something a little bit more generic and easier to maintain ? Something like (what I initially wanted to do for x86, but maybe even more general to all target images, kind of a naming convention):

Images names like   || Usage || Notes
*combined-ext4*     || disk image (compressed) containing (...) || specific to x86_64 targets
*combined-squashfs* || similar to combined-ext4.img.gz, but (...) || specific to x86_64 targets
*generic-rootfs*    || filesystem image of LEDE root filesystem || specific to x86_64 targets
(...)
*squashfs*          || Generally speaking, when you see squashfs, (...)
*sysupgrade*        || This is to be used when upgrading from OpenWrt to LEDE or LEDE to LEDE || Do not preserve settings when not going from LEDE to LEDE
*vmlinuz*           || Linux kernel for the target build
*.tar.gz            || This image is compressed using the tar.gz format (...)
(...) and so on - please mind those as inaccurate examples

Maybe, that could probably go into the Preliminary Steps for Everyone under Find the Device Techdata page for your router/device as another "Naming convention: Image filenames naming convention is explained in more details here".

Unless I've overlooked and missed a place where those conventions are explained.

0 Likes

#5

These descriptions should be placed on a separate page, and not included in the preliminary steps, which is already a big frightening block.

0 Likes

#6

@tmomas I'm trying to come up with something draft on my spare time. Meanwhile, is there a guide or something on making a page in the sandbox version of the wiki to put the content there for revision?

0 Likes

#7

If you want to create a draft of a new page, you can create it in the playground:

https://lede-project.org/playground/yournewplaygroundpage

-> Edit / create page

0 Likes

#8

I forgot to mention:

replace the obvious with the pagename you want.

0 Likes

#9

Thank you very much for those infos, I'll have a look and start something soon.

0 Likes

#10

I think that this will have to wait after the merger, as the actions on the Wikis are still TBD. I also found something on OpenWrt Wiki that looks like a starting point of what I was proposing.

0 Likes

#11

No need to wait. We can pick what will be in the merged wiki.

0 Likes