Hi all, thinking about the current state of CRUX-ARM, I had some ideas that I'll try to explain as best I can. When we started this project we had a few devices and they also lacked the ability to boot from a medium (e.g. SD card) and to install CRUX on a different medium (such as an SSD). There were days when we had to use a flash card and the installation process was limited to unzip our file release (rootfs) in the root partition. Now we have some efikamx smarttop/smartbook devices (thanks to Genesi CEO) that have an SSD inside and allow to use a bootable either from an SD card, or perhaps a USB-CDROM, USB stick, etc. That is why I think we've reached the point where we can think of using an installer as is done in CRUX. I propose some ideas: - Use a initrd or initramfs image with a similar init script like the one in system/iso.git (CRUX), which should search for and mount the crux media - Use a 'setup' script to perform the installation on the user selected media. a) the script could be written in 'dialog' like upstream CRUX, but we must add 'dialog' to our initrd/initramfs b) for now we can live with a simple shell script Anyways we must add(*) 'pkgadd' to our initrd/initramfs (*) is not posible to just decompress the rootfs like we did in the past, so people should be able to select individual packages - Use a directory structure similar to upstream where we could find a directory called crux/ which contains: - a dir per collection of packages (core, opt, xorg) - the kernel directory for sources - tools, etc. - Also we could think in use an external tool to customize installer images with the number of packages we want, etc. I have some other ideas (taken from my own modifications to the original installer of CRUX) but I believe that for now we could at least to implement a basic installer. Naturally there are many things that could have explained in more detail, but I'd rather get a first impression of your ideas. What do you think? -- Jose V Beneyto | http://sepen.mine.nu
* Jose V Beneyto (sepen@crux-arm.nu) wrote:
Hi all,
Hello sepen,
thinking about the current state of CRUX-ARM, I had some ideas that I'll try to explain as best I can. When we started this project we had a few devices and they also lacked the ability to boot from a medium (e.g. SD card) and to install CRUX on a different medium (such as an SSD). There were days when we had to use a flash card and the installation process was limited to unzip our file release (rootfs) in the root partition. Now we have some efikamx smarttop/smartbook devices (thanks to Genesi CEO) that have an SSD inside and allow to use a bootable either from an SD card, or perhaps a USB-CDROM, USB stick, etc. That is why I think we've reached the point where we can think of using an installer as is done in CRUX.
Sounds great, some more work to the list.
I propose some ideas:
- Use a initrd or initramfs image with a similar init script like the one in system/iso.git (CRUX), which should search for and mount the crux media
- Use a 'setup' script to perform the installation on the user selected media. a) the script could be written in 'dialog' like upstream CRUX, but we must add 'dialog' to our initrd/initramfs b) for now we can live with a simple shell script Anyways we must add(*) 'pkgadd' to our initrd/initramfs (*) is not posible to just decompress the rootfs like we did in the past, so people should be able to select individual packages
- Use a directory structure similar to upstream where we could find a directory called crux/ which contains: - a dir per collection of packages (core, opt, xorg) - the kernel directory for sources - tools, etc.
- Also we could think in use an external tool to customize installer images with the number of packages we want, etc.
I have some other ideas (taken from my own modifications to the original installer of CRUX) but I believe that for now we could at least to implement a basic installer.
A basic installer can be a good start point. This should be added to the TODO27 list and give time to it to see how things go. If you think that any idea you have could be interesting, try to share it here.
Naturally there are many things that could have explained in more detail, but I'd rather get a first impression of your ideas. What do you think?
I like the idea. We can keep track of it and try to put hand on the installer bit by bit, like always. Really could be great to get some opinions or feedback from another people. Regards, Victor. --- Learning bit by bit Victor Martinez | http://lokalix.dyndns.org
On 05/27/11 11:35, Victor Martinez wrote:
* Jose V Beneyto (sepen@crux-arm.nu) wrote:
Hi all, Hello sepen, [...] A basic installer can be a good start point. This should be added to the TODO27 list and give time to it to see how things go. If you think that any idea you have could be interesting, try to share it here.
Well I try to describe the scenario: 1 - the bootloader load the kernel image and contents from the initrd/initramfs are loaded onto ram 2 - once running from ram the first script executed in the linuxrc script from busybox (which acts as init script) 3 - when the linuxrc finished we have a login prompt and we should do some steps manually (or at least for now): (I described the steps for the efikamx but could be shared for other devices too) 3.1 - mount the installation media (e.g. SD card): # mkdir /media # mount /dev/mmcblk0p1 /media 3.1 - prepare the installation target (e.g. SSD): # fdisk /dev/sda # mkfs.ext3 /dev/sda1 # mkswap /dev/sda2 3.2 - mount the installation target: # mount /dev/sda1 /mnt 3.3 - run the 'setup' script # setup 3.4 - copy the bootloader stuff for your device (uImage, boot.scr, boot.efikamx.script) # cp /media/crux/kernel/efikamx/* /mnt/boot 3.5 - configure some files (/etc/rc.conf, /etc/fstab, /etc/rc.d/net, ...) # vi /mnt/etc/fstab ... (optional) Compile your own kernel 3.6 - pivot to newroot and compile the kernel # setup-chroot bash$ cd /usr/src/linux bash$ make menuconfig; make; make uImage; make modules_install ... ** to build your own kernel and generate the boot.scr you'll need uboot-mkimage so we could have this as opt/package ... bash$ mkimage -A arm -O linux -a 0 -e 0 -T script -C none \ -n "EfikaMX Boot Script" -d /boot/boot.efikamx.script /boot/boot.scr ... some considerations: - The initrd/initramfs is basically a bunch of busybox's applets, so we should finetune our busybox build to satisfy all requeriments to perform the installation (chroot, fdisk, mount tools, etc. etc.) - The upstream setup script uses some dialog calls to show a fancy UI and that requires to have a dialog in our initrd/initramfs a) there is no busybox's applet for 'dialog', so we need to compile 'dialog' as a static arm binary an put them inside our initrd/initramfs b) we could write a tiny setup script as a replacement which don't use 'dialog' calls (I've in mind the 'fake-setup' script we made for the 'safe-env' project)
Naturally there are many things that could have explained in more detail, but I'd rather get a first impression of your ideas. What do you think
Same again, opinions?
I like the idea. We can keep track of it and try to put hand on the installer bit by bit, like always. Really could be great to get some opinions or feedback from another people.
Thanks for your comments. Best regards, -- Jose V Beneyto | http://sepen.mine.nu
* Jose V Beneyto (sepen@crux-arm.nu) wrote:
On 05/27/11 11:35, Victor Martinez wrote:
* Jose V Beneyto (sepen@crux-arm.nu) wrote:
Hi all, Hello sepen, [...] A basic installer can be a good start point. This should be added to the TODO27 list and give time to it to see how things go. If you think that any idea you have could be interesting, try to share it here.
Well I try to describe the scenario:
1 - the bootloader load the kernel image and contents from the initrd/initramfs are loaded onto ram
2 - once running from ram the first script executed in the linuxrc script from busybox (which acts as init script)
3 - when the linuxrc finished we have a login prompt and we should do some steps manually (or at least for now): (I described the steps for the efikamx but could be shared for other devices too)
Let's pick the smarttop as an example and I'll fix/comment some things.
3.1 - mount the installation media (e.g. SD card): # mkdir /media # mount /dev/mmcblk0p1 /media
3.1 - prepare the installation target (e.g. SSD): # fdisk /dev/sda # mkfs.ext3 /dev/sda1 # mkswap /dev/sda2
Well, let's see some comments: - first partition: /boot to put there uImage and boot.scr - second partition: / to install there the media selected - third partition: swap In this sense we follow the same as is provided. (this is only a comment to clarify the example)
3.2 - mount the installation target: # mount /dev/sda1 /mnt
3.3 - run the 'setup' script # setup
3.4 - copy the bootloader stuff for your device (uImage, boot.scr, boot.efikamx.script) # cp /media/crux/kernel/efikamx/* /mnt/boot
Comments following the above "corrections/clarifications": # mount /dev/sda2 /mnt # mount /dev/sda1 /mnt/boot Then we can make the copy.
3.5 - configure some files (/etc/rc.conf, /etc/fstab, /etc/rc.d/net, ...) # vi /mnt/etc/fstab ...
(optional) Compile your own kernel
3.6 - pivot to newroot and compile the kernel # setup-chroot bash$ cd /usr/src/linux bash$ make menuconfig; make; make uImage; make modules_install ... ** to build your own kernel and generate the boot.scr you'll need uboot-mkimage so we could have this as opt/package ... bash$ mkimage -A arm -O linux -a 0 -e 0 -T script -C none \ -n "EfikaMX Boot Script" -d /boot/boot.efikamx.script /boot/boot.scr ...
(keeping in mind that this is optional, I comment about it) This can be hard. We need to provided sources, which will be different based on the device. I would put this step in a side and focus directly in the install media and scripts.
some considerations:
- The initrd/initramfs is basically a bunch of busybox's applets, so we should finetune our busybox build to satisfy all requeriments to perform the installation (chroot, fdisk, mount tools, etc. etc.)
- The upstream setup script uses some dialog calls to show a fancy UI and that requires to have a dialog in our initrd/initramfs a) there is no busybox's applet for 'dialog', so we need to compile 'dialog' as a static arm binary an put them inside our initrd/initramfs b) we could write a tiny setup script as a replacement which don't use 'dialog' calls (I've in mind the 'fake-setup' script we made for the 'safe-env' project)
All these options are great. I think we can give a try to the static dialog build and verify if it work¡s right before putting hands on a new little script based on the fake-setup (which is a good idea too).
Naturally there are many things that could have explained in more detail, but I'd rather get a first impression of your ideas. What do you think
Same again, opinions?
I like the idea. We can keep track of it and try to put hand on the installer bit by bit, like always. Really could be great to get some opinions or feedback from another people.
Thanks for your comments. Best regards,
Learning bit by bit Victor Martinez | http://lokalix.dyndns.org
participants (2)
-
Jose V Beneyto
-
Victor Martinez