My expectation with a JeOS install image is that it would be a rather minimal server image. I typically use raspberry pi for pure headless applications, and I had used debian, raspian, and alpine, in the past. The JeOS arm/pi images, by comparison are rather humongous, weighing in at over 2g unpacked (buster images by comparison are around 1g, and well, alpine is in a class by itself). I do note these JeoS images include yast and X libs, avahi, etc, but my gut feeling is anything that calls itself JeOS should not do so and be a more true minimal server with “just enough” for ssh, as anything else could then be added on top after. I suppose I would have to go all the way to kiwi to get a more true minimal server image or if I wanted to create a custom image for a product, but to just test and get used to deploying opensuse on devices I would prefer starting from a true minimal baseline. I guess my real question is why are they built so large…what was the thinking behind it?
Hello,
I see this is one of your first posts: Welcome to the opernSUSE forums.
I am very sorry, but I tried to find the meaning of “humongous” in dictionaries (Englsih is not my first language, the same as for may here), I even ended up in Google Translate, but failed.
In any case, thses are the openSUSE forums so when there isn’t any better answer then mine to your JeOS question, be assured that that is out of lack of knowledge and not out of lack of williness to help you.
You can roughly take it to mean “absurdly large”. Yes, the word probably started as slang.
And it seems then that that “largety” is measured in weight (2g vs. 1g).
Well, maybe not absurdly, but I felt at 2 gigabytes+, it seemed rather large for a “JeOS” image, and it seemed to have a lot of extra packages, too. I was simply wondering and trying to understand why.
Thank you.
I should have considered that it is not as obvious to non-english speakers. I of course mean very large in disk space use for the initial install image on arm (raspberry pi), and I was working with the JeOS image for Leap (15.1). The idea of JeOS, at least to me, was “just enough” OS to get something booted and accessible. 2 gigabytes+ for the initial image (when uncompressed and copied to a sd card) seemed rather much for that definition of JeOS. The arm/raspberry pi JeOS image also had yast, a bunch of X libs, and other things, which I am sure contributes to its large size.
You may be correct about the size of the system as offered (remember that SI units and their prefixes are case dependent, like Unix/Linux), but I doubt you will find here anybdody who has any influence on the decissions what to put into it or not and can defend them. The forums members are by a far majority openSUSE users, not developers.
Hi Henk,
if you think this should be moved to/reposted in a different forum, I would be happy to do so, perhaps also with a better title. I was at this point simply trying to understand why it is so large in disk space, although I do clearly have an opinion on this, too :). I also did not know which forum to pick for this kind of question as it is not a support question.
I think I do understand what you mean and why you are curious.
I searched a bit and see that SUSE offers a JeOS (and that is the one you are talking about), but on the SUSE forums site, I only see referencses to SLES and SLED, not to JeOS.
I still hope that someone here will chime in andhave an idea about where to go, or whom to caontact.
HCL:Raspberry Pi2 - openSUSE Wiki is a good starting place. I choose the JeOS image from there because I use my Pi headless, and so I assumed that would be a very minimal image. It is a small download as a .xz, but when you uncompress, it expands to a 2 Gigabyte+ filesystem, which is about twice as large as a default Debian Buster image for the Raspberry Pi, or the Raspian one.
Yes,
I noticed the incredibly large difference in size when I first started using JeOS from various distros in Docker… Typically a Debian JeOS (a favorite of many) was about 80MB while an openSUSE was rarely less than 550MB at the time. Since then, a few openSUSE JeOS have been shrunk down to about 350MB but of course that’s vastly larger than the commonly used Debian JeOS.
Although I’ve only looked into this a little bit,
IMO the reason is because we make YaST a standard part of every openSUSE image including JeOS, after all it’s a major way openSUSE distinguishes itself from other distros.
And, YaST requires a full Ruby subsystem… all the libraries and a at least a small assortment of default and essential components. That adds up to quite a bit, Ruby is not small.
Other reasons for the size are harder to identify,
There does not seem to be any kind of centralized effort to work on a standardized JeOS for every technology… A JeOS from Kiwi will be very different than a JeOS, and will be very different from the JeOS made available for numerous image-based installs like ARM devices. When there is no centralized effort, then you get wide variation because there is so much duplicated and inefficient effort… so some might have had only a cursory effort long ago while some might have been shrunk very recently.
When you install a JeOS, I recommend paying close attention to what is in it, do a few searches for “extra” things like network tools, system tools, things in /usr/sbin and more. Ideally you shouldn’t even be able to PING, the idea in a JeOS is that all you should need is a working package installer, and from that you can install anything you want or need.
HTH,
TSU
As noted in my previous post,
I doubt that any JeOS image from anywhere is as large as you’ve described (>1G).
Our openSUSE text only “server” install is about 1G, but should never be be considered a JeOS.
If you’re looking at what an openSUSE DVD install creates, that is never a JeOS.
I’ve never seen an “installed” JeOS, all the JeOS I’ve seen are run time images which are copied byte by byte to the target storage.
If you want to use a “better” JeOS, I’d recommend Docker, although I’m not familiar with all JeOS (how can anyone be?), I know that the Docker JeOS was refactored relatively recently… maybe 3 years ago. You may find that convenient since if you’re building distributable Servers, Docker is a good way to do that.
TSU
Hi
The user seems to be talking about the expanded image, not the downloaded image…
On my RPi3’s one with Leap 15.0 the other with SLES 15.0 I see;
openSUSE Leap 15.0
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk0 179:0 0 14.9G 0 disk
├─mmcblk0p1 179:1 0 16M 0 part /boot/efi
├─mmcblk0p2 179:2 0 14.3G 0 part /
└─mmcblk0p3 179:3 0 485.5M 0 part [SWAP]
df -kh
Filesystem Size Used Avail Use% Mounted on
devtmpfs 318M 0 318M 0% /dev
tmpfs 476M 0 476M 0% /dev/shm
tmpfs 476M 328K 475M 1% /run
tmpfs 476M 0 476M 0% /sys/fs/cgroup
/dev/mmcblk0p2 15G 3.0G 11G 23% /
/dev/mmcblk0p1 16M 4.6M 12M 29% /boot/efi
tmpfs 96M 0 96M 0% /run/user/0
SLES 15.0
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk0 179:0 0 14.9G 0 disk
├─mmcblk0p1 179:1 0 16M 0 part /boot/efi
├─mmcblk0p2 179:2 0 13.9G 0 part /
└─mmcblk0p3 179:3 0 980.5M 0 part [SWAP]
df -kh
Filesystem Size Used Avail Use% Mounted on
devtmpfs 436M 0 436M 0% /dev
tmpfs 476M 12K 476M 1% /dev/shm
tmpfs 476M 48M 428M 11% /run
tmpfs 476M 0 476M 0% /sys/fs/cgroup
/dev/mmcblk0p2 14G 2.9G 11G 22% /
/dev/mmcblk0p2 14G 2.9G 11G 22% /var
/dev/mmcblk0p1 16M 4.0M 13M 25% /boot/efi
/dev/mmcblk0p2 14G 2.9G 11G 22% /usr/local
/dev/mmcblk0p2 14G 2.9G 11G 22% /boot/grub2/arm64-efi
/dev/mmcblk0p2 14G 2.9G 11G 22% /root
/dev/mmcblk0p2 14G 2.9G 11G 22% /srv
/dev/mmcblk0p2 14G 2.9G 11G 22% /home
/dev/mmcblk0p2 14G 2.9G 11G 22% /tmp
/dev/mmcblk0p2 14G 2.9G 11G 22% /opt
/dev/mmcblk0p2 14G 2.9G 11G 22% /.snapshots
tmpfs 96M 0 96M 0% /run/user/473
tmpfs 96M 0 96M 0% /run/user/0
I noticed,
And I hope I allowed for downloaded vs expanded by
-
Noting that many, most or nearly all JeOS images have not been refactored and shrunk since… well, almost never. They might have or even likely were last reviewed/refactored “never” in the SysVinit era, and were simply migrated forward with the introduction of systemd.
-
AFAIK there has been no concerted effort by SUSE/openSUSE to focus on making our JeOS images “better” which IMO is a major reason why our JeOS is never considered by Developers working with other distros. Debian is a favorite for many reasons, IMO a primary reason is its size. The docker JeOS I referred to likely was an individual’s effort purely on his own initiative (I’ve forgotten his name but can look it up). Unfortunately he never responded to my attempts to communicate with him to discover his methods, so his work is a one-off and isn’t available to be applied to improving other JeOS. If there is another effort to improve our JeOS images, I highly recommend that it be more of a community rather than an individual effort, properly organized to cover as many many images as possible.
-
IIRC I’m sure I’m referring to “expanded” image size, there is no such thing as “compressed” when you apply an image and read its size afterwards. As I described, the openSUSE JeOS I’ve worked with in Kiwi and docker before it was improved was about 550MB. If the image is twice that size, then I suspect that it could be a bunch of packages supporting hardware added to a base JeOS(AFAIK there are plenty of x86 device drivers in the standard kernel, but zero ARM related hardware which have to be loaded as a kind of loadable modules, but not in the same way we are used to in x86/x64), and maybe left a bunch of Dev tools that were used for building the image for convenience. Of course, leaving all those extra components in a JeOS makes the image not a JeOS any more, no matter what you choose to call it.
Not without saying,
Of course for anyone reading Malcolm’s last post, focus entirely on disk usage and exclude everything that is tmpfs, which is actually mounted in memory.
TSU
Hi
If I really want a specific image, I just use kiwi based on the default and tweak as required… I can pull any package from any repo on OBS to meet my needs, just add it and set to false. I think it’s a generic image to cover all users.
Even using Kiwi images,
Based on what was done for the Docker JeOS, there is a suspicion that you still have at least approximately 200MB of “fluff.”
For those who are serious about redistributable builds,
This is very significant.
JeOS are generally always used as a foundation for building something with custom functionality, and if complex and over time as the image is modified and updated, the size will increase very quickly… Which is a main reason for starting with something as small as possible in the first place.
I wouldn’t expect anything to happen overnight, but if SUSE/openSUSE is serious about its position into the future as a container and clustered platform, fixing its JeOS images should be on the road map somewhere…
IMO,
TSU
Hi
MicroOS and from the SLE installer can select a minimal install.
And actually, well, outside of a JeOS context, YaST is one reason I really do like openSUSE, and that it is now in Ruby, as I do love using ruby for system scripting and things like web services with sinatra. So for me, I definitely see it as a positive elsewhere and a runtime I would normally install anyway.
Yep, consider…:
-rw-r–r-- 1 dyfet dyfet 2339373056 Sep 28 15:46 openSUSE-Leap-15.1-ARM-JeOS-raspberrypi3.aarch64-2019.05.17-Snapshot1.41.raw
-rw-r–r-- 1 dyfet dyfet 2008023040 Sep 28 15:48 openSUSE-Leap-15.1-ARM-JeOS-raspberrypi2.armv7l-2019.05.17-Snapshot1.41.raw
The funny thing is that the Buster unofficial pi2/pi3 images actually have a slightly larger download size, but expand into a much smaller raw image. If you loop mount the raw image / partition for pi2, you will find something like over 1.7g used, so it’s not like a bunch of free space is in there, either, though there is some. So you can see why this caused some initial surprise to me, especially given that I have no prior history of working with suse JeOS images at all.
Indeed, and this is why I had already come to adopt AlpineLinux for those uses. I wish OBS had Alpine as a supported distro.