the new delivery form of JamulusOS is unfortunately much less attractive than before. Now I have to first download an Ubuntustudio from Sourceforge and put it on the stick, make the persistent and then download the main thing.
Many tutorials on the net about Jamulus OS have become obsolete by this change. Hopefully people don't throw in the towel now because they follow recipes that don't work anymore!
To make a stick with Jamulus OS must become very simple and fool-proof: Whoever wants to make (=duplicate) such a stick for his band, orchestra or choir, surely knows a little bit about Linux computers, otherwise he would rather go on the adventure of Jamulus on Windows. So such addressees most probably will be able to start a downloaded script if they don't have to write it by themselves.
Probably some lawyers are behind it to restrict Ubuntustudio to be downloaded separately from Jamulus. But then comes the crucial second step of downloading the Jamulus Install Package and installing it on the stick.
So I suggest to make a script that gathers all steps from downloading the components to assembling all parts on the stick.
In my first successful attempt, I finally managed (using UNetbootin) to store JamulusOS in the previous delivery form of a complete image unifying the OS plus the Jamulus software onto a 32GB USB 3.0 stick. On the stick is an 8 GiB vfat partition, to which I wrote the ISO image of the formerly all-inclusive version. Then I have another ext2 partition of about 20 GiB forcasper-rw. The whole thing boots from my sample stick on a Lenovo T430 in about one minute: as quickly as a normal OS from a hard drive!
To avoid the question about keyboard and country, I modified syslinux.cfg on the root of the stick: I replace "--- persistent" everywhere with "locale=de_DE bootkbd=de_DE console-setup/layoutcode=de --- persistent" (at the end I use two spaces to avoid recursion). This does not work for a stick created with Rufus, albeit making the casper-rw partition is much easier there.
A script to be written would have to contain the following steps:
ask for the language to be used for keyboard and language settings (e.g. de_de, fr_fr, ...)
*wget the Ubuntu-Studio image,
show lsblk -o Type,Name,Fstype,Size,Label,UUID,Mountpoint for all USB storage devices, grep the result by type to limit it to the USB devices, and if there is more than one, ask for the one to be used
check if the capacity of it is >= 16 GB (stop, if it is less)
ask the user if this is really the device to be used – it will be formatted then! - after a positive answer.
using fdisk or an appropriate sibling of it from the script wipe all partitions from the device and create an 8 GiB vfat partition with flag boot, additionally an ext2 partition casper-rw for everything else (the partition must not be ext3 or higher to prevent journalling, which is not good un flash devices,
install the downloaded image onto the vfat partition,
modify syslinux.cfg as described above,
chroot into the system on the stick (would that do the trick?, otherwise copy a script such that it works as autostart first downloading the installation program),
if possible on the taskbar install network monitor for the LAN and the WLAN and monitoring the system load (one has to isolate the adapter name from lshw, grepping for *-network. 6 lines below that there is something like Logischer Name:(language possibly depending on locale set, just checkt it) and then follows the name of the ethernet adapter to be used for the network monitor). Similarly one finds scanning for the next *-network. Again 6 lines below that there is something like Logischer Name: and after the colon the name of that device. What about such an approach? Due to the changed delivery form, the Sourceforge web pages for JamulusOS have become confusing: I have had to search longer for from where to download the installer: The link can be found, but as part of a text file derived from the readme file and typeset accordingly. And there is no hyperlink behind the URL, and when you are searching for the download location, you are looking for a blue underlined place!
You're probably not happy about the change in delivery method either, or maybe even frustrated. It's just stupid when someone throws a stick between your legs!
Last edit: Adalbert Hanßen 2021-04-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm so sorry for inconvenience and agree with you that the new delivery is suboptimal ... But it has been done very quickly to answer a user request that seemed to me founded.
What you suggest is interesting but to be usable, it would have to be set on Windows plateform and this is outside of my skills. Linux users would generally don't mind three additional command lines. May be even it could be achieve using graphical desktop routine.
An alternative approach would be to create a persistent USB stick ready for Jamulus with minimal size and share this minimal image to the end users. I don't know if rufus will wrote this kind of image (usb stick image) but if it does, the end user would start ubuntustudio ready for Jamulus like Jamulus OS. May be we can provide images in different sizes with default partition configuration or provide a simple configuration tool to resize the partition once the UbuntuStudio has been started on the usb stick. (there are only ideas and i don't know if this can be done. It would have to be investigated ...).
What are your thought about that ?
BR,
Laurent
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Laurent,
I appreciate your idea to create a persistent USB stick for Jamulus with minimal size, provided it is possible for the user to add (i.e. sudo apt install ...) other software using the persistent part of that? In the last few days I wasted much time trying to install Chromium on a persistent USB-3 stick: after each attempt, the stick was ruined (i.e. it did not pass file system checks any more. Fortunately I could verify with time sudo badblocks -b 512 -v -w -s -t random -t 0x55 -t 0xaa -t 0xff -t 0x00 -o badblock_errors.log /dev/sdb that the stick was physically ok. This check however costs some 5 hours for my 32GB Kingston DataTraveler 3.0 USB stick, which was attached to an USB3-port of my computer). Somehow the stick did not like the installation of Chromium, which is nowadays delivered as a snap image (I'd prefer a real apt package!) Do you have any idea why the installation of the snap image fails?
Further I found out, that running the jamulus-OS-v2.02-install.run is very very slow and it causes very much writing on the USB stick (which is adverse to its lifetime!) CPU and memory usage remain low, even the fan of my computer stays at very low speed - unlike my other experience with compile workload, which causes CPU and RAM usage to go up. Would it be possible to apply the modifications after doing all the compilation stuff first in the host computer running on Linux which is used to download and make the persistent USB stick? That would alleviate all the avoidable writing wear for temporary files which are necessary during all the compilation steps.
Last edit: Adalbert Hanßen 2021-04-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, i can create a little sized usb persistent stick with jamulus installation (4,1GiB) using virtualbox. And then use mkusb to create a clone on a other USB stick (even larger).
I used all defaults option in mkusb routine to create the usb persistent stick image. This way, i do not modify ubuntu iso file but i will be able to share an image with Jamulus preinstalled.
I'm going to make some further tests before providing this image to the community.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Laurent,
how can you test an image for a Linux stick on Windows? Or do you just want to test the Rufus step making the stick under Windows? Unfortunately, the syslinux.cfg created by Rufus does not have any line splash ... ---persistent. One has to modify these lines to preset the keyboard and language settings.
Kind regards
Adalbert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You can test an image without rebooting your computer using virtualbox. But my target is to write an image to usb stick with rufus and check that i can boot with that.
Kind Regards,
Laurent
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
compiling on the persistent stick seems to be not a very good idea. There ist lots of file writing and so on in that. I would prefer to do the compilation of the ./jamulus-OS-v2.02-install.run on a computer booted as normal and transfer the results to the stick after compilation is compleded. Would that be possible? What steps would be necessary to approach it this way?
(I tried it the recommended way. Compilation took endless time. According to htop, CPU or memory usage was not an issue. I guess compilation on the USB stick causes awful amount of write traffic and later deletion of intermediate files. That's not a good idea for flash memory with limited rewrite capability. I used only fresh and unused new USB3 sticks and of course I plugged them into USB3 sockets. But after compilation was finished, they showed file system inconsistencies. But checking them whith badblocks (with random, 0x55, 0xaa, 0xff and 0x00) showed no fault on them. The first step random guards one against fraudulent devices where one and the same memory block has multiple addresses, the other checks guard against bits sticking high or low or which also react wrong because of neighbouring bits... - . Probably the heavy usage during compilation caused the controller of the USB drive to malfunction. These pendrives are not really made for such heavy usage).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Laurent,
the new delivery form of JamulusOS is unfortunately much less attractive than before. Now I have to first download an Ubuntustudio from Sourceforge and put it on the stick, make the persistent and then download the main thing.
Many tutorials on the net about Jamulus OS have become obsolete by this change. Hopefully people don't throw in the towel now because they follow recipes that don't work anymore!
To make a stick with Jamulus OS must become very simple and fool-proof: Whoever wants to make (=duplicate) such a stick for his band, orchestra or choir, surely knows a little bit about Linux computers, otherwise he would rather go on the adventure of Jamulus on Windows. So such addressees most probably will be able to start a downloaded script if they don't have to write it by themselves.
Probably some lawyers are behind it to restrict Ubuntustudio to be downloaded separately from Jamulus. But then comes the crucial second step of downloading the Jamulus Install Package and installing it on the stick.
So I suggest to make a script that gathers all steps from downloading the components to assembling all parts on the stick.
In my first successful attempt, I finally managed (using UNetbootin) to store JamulusOS in the previous delivery form of a complete image unifying the OS plus the Jamulus software onto a 32GB USB 3.0 stick. On the stick is an 8 GiB
vfatpartition, to which I wrote the ISO image of the formerly all-inclusive version. Then I have anotherext2partition of about 20 GiB forcasper-rw. The whole thing boots from my sample stick on a Lenovo T430 in about one minute: as quickly as a normal OS from a hard drive!To avoid the question about keyboard and country, I modified
syslinux.cfgon the root of the stick: I replace "--- persistent" everywhere with "locale=de_DE bootkbd=de_DE console-setup/layoutcode=de --- persistent" (at the end I use two spaces to avoid recursion). This does not work for a stick created with Rufus, albeit making thecasper-rwpartition is much easier there.A script to be written would have to contain the following steps:
de_de,fr_fr, ...)*
wgetthe Ubuntu-Studio image,lsblk -o Type,Name,Fstype,Size,Label,UUID,Mountpointfor all USB storage devices,grepthe result bytypeto limit it to the USB devices, and if there is more than one, ask for the one to be usedfdiskor an appropriate sibling of it from the script wipe all partitions from the device and create an 8 GiBvfatpartition with flagboot, additionally anext2partitioncasper-rwfor everything else (the partition must not beext3or higher to prevent journalling, which is not good un flash devices,vfatpartition,syslinux.cfgas described above,chrootinto the system on the stick (would that do the trick?, otherwise copy a script such that it works as autostart first downloading the installation program),wgetthe installation program from https://sourceforge.net/projects/jamulus-os/files/JamulusOS/v2/install-package/jamulus-OS-v2.02-install.run/download,lshw, grepping for*-network. 6 lines below that there is something likeLogischer Name:(language possibly depending on locale set, just checkt it) and then follows the name of the ethernet adapter to be used for the network monitor). Similarly one finds scanning for the next*-network. Again 6 lines below that there is something likeLogischer Name:and after the colon the name of that device.What about such an approach? Due to the changed delivery form, the Sourceforge web pages for JamulusOS have become confusing: I have had to search longer for from where to download the installer: The link can be found, but as part of a text file derived from the
readmefile and typeset accordingly. And there is no hyperlink behind the URL, and when you are searching for the download location, you are looking for a blue underlined place!You're probably not happy about the change in delivery method either, or maybe even frustrated. It's just stupid when someone throws a stick between your legs!
Last edit: Adalbert Hanßen 2021-04-21
Hello;
I'm so sorry for inconvenience and agree with you that the new delivery is suboptimal ... But it has been done very quickly to answer a user request that seemed to me founded.
What you suggest is interesting but to be usable, it would have to be set on Windows plateform and this is outside of my skills. Linux users would generally don't mind three additional command lines. May be even it could be achieve using graphical desktop routine.
An alternative approach would be to create a persistent USB stick ready for Jamulus with minimal size and share this minimal image to the end users. I don't know if rufus will wrote this kind of image (usb stick image) but if it does, the end user would start ubuntustudio ready for Jamulus like Jamulus OS. May be we can provide images in different sizes with default partition configuration or provide a simple configuration tool to resize the partition once the UbuntuStudio has been started on the usb stick. (there are only ideas and i don't know if this can be done. It would have to be investigated ...).
What are your thought about that ?
BR,
Laurent
Hello Laurent,
I appreciate your idea to create a persistent USB stick for Jamulus with minimal size, provided it is possible for the user to add (i.e.
sudo apt install...) other software using the persistent part of that? In the last few days I wasted much time trying to install Chromium on a persistent USB-3 stick: after each attempt, the stick was ruined (i.e. it did not pass file system checks any more. Fortunately I could verify with timesudo badblocks -b 512 -v -w -s -t random -t 0x55 -t 0xaa -t 0xff -t 0x00 -o badblock_errors.log /dev/sdbthat the stick was physically ok. This check however costs some 5 hours for my 32GB Kingston DataTraveler 3.0 USB stick, which was attached to an USB3-port of my computer). Somehow the stick did not like the installation of Chromium, which is nowadays delivered as a snap image (I'd prefer a realaptpackage!) Do you have any idea why the installation of the snap image fails?Further I found out, that running the
jamulus-OS-v2.02-install.runis very very slow and it causes very much writing on the USB stick (which is adverse to its lifetime!) CPU and memory usage remain low, even the fan of my computer stays at very low speed - unlike my other experience with compile workload, which causes CPU and RAM usage to go up. Would it be possible to apply the modifications after doing all the compilation stuff first in the host computer running on Linux which is used to download and make the persistent USB stick? That would alleviate all the avoidable writing wear for temporary files which are necessary during all the compilation steps.Last edit: Adalbert Hanßen 2021-04-21
Well, i can create a little sized usb persistent stick with jamulus installation (4,1GiB) using virtualbox. And then use mkusb to create a clone on a other USB stick (even larger).
I used all defaults option in mkusb routine to create the usb persistent stick image. This way, i do not modify ubuntu iso file but i will be able to share an image with Jamulus preinstalled.
I'm going to make some further tests before providing this image to the community.
I have to test this image with rufus on windows.
Laurent,
how can you test an image for a Linux stick on Windows? Or do you just want to test the Rufus step making the stick under Windows? Unfortunately, the
syslinux.cfgcreated by Rufus does not have any linesplash ... ---persistent. One has to modify these lines to preset the keyboard and language settings.Kind regards
Adalbert
Hello Adalbert,
You can test an image without rebooting your computer using virtualbox. But my target is to write an image to usb stick with rufus and check that i can boot with that.
Kind Regards,
Laurent
Hello Laurent,
compiling on the persistent stick seems to be not a very good idea. There ist lots of file writing and so on in that. I would prefer to do the compilation of the ./jamulus-OS-v2.02-install.run on a computer booted as normal and transfer the results to the stick after compilation is compleded. Would that be possible? What steps would be necessary to approach it this way?
(I tried it the recommended way. Compilation took endless time. According to htop, CPU or memory usage was not an issue. I guess compilation on the USB stick causes awful amount of write traffic and later deletion of intermediate files. That's not a good idea for flash memory with limited rewrite capability. I used only fresh and unused new USB3 sticks and of course I plugged them into USB3 sockets. But after compilation was finished, they showed file system inconsistencies. But checking them whith badblocks (with random, 0x55, 0xaa, 0xff and 0x00) showed no fault on them. The first step random guards one against fraudulent devices where one and the same memory block has multiple addresses, the other checks guard against bits sticking high or low or which also react wrong because of neighbouring bits... - . Probably the heavy usage during compilation caused the controller of the USB drive to malfunction. These pendrives are not really made for such heavy usage).