Testers needed nethserver-arm img


(Robert Moskowitz) #61

I kind of remember this coming up in Centos6 release. Why was the boot partition still ext3? The answer was ext4 introduced overhead not needed for /boot. ext3 was perfectly adequate for /boot. As I think getting ext4 code loaded at this point in the boot process was an issue. May not be anymore.

Or something like that. Years ago that C6 came out.

(Robert Moskowitz) #62

I will need to test this image next week, but you ask about swap on an SSD. How is your SSD connected, sata or usb? In either case a swap partition is very nice to have. With uSD, you may have to throw some memory for a temp swap, but then you will need a lot of memory…

(Mark Verlinde) #63

That is the goal, we are close to it but as the name suggest (Devel) we are not completely there yet. Not due to know issues just a matter of testing and getting feedback.

ext4 landed in u-boot just a few years ago…

Why?.. x86_64 uses an LVM volume and not a partition

(Robert Moskowitz) #64

I just got this from the Fedora-arm list on what they are doing with swap as of F29:

“we use zram for swap in F-29, it preserves the mSD card due to
wear, and is much faster, this isn’t the problem. Basically up to a
max of 50% of the RAM will be allocated to swap using lz4 compression and we generally see a 4-5 times compression ratio.”

(Robert Moskowitz) #65

I would suggest you ask Johnny Hughes on both the Centos and Centos-arm team why ext3 survived into Centos7.

He is pretty good at replying.

(Mark Verlinde) #66

Thank you for the feedback and research!

Now i have some directions to pursuit.

BTW, It’s likely good to know i’m a hardware guy, not a sys admin or software developer…
Therefore have my doubts about partitioning non magnetical HDD’s. Partition tables are just a convenient way to interact with a OS, on a hardware level all byte’s are written all over the place to even-out wear.
As an matter of fact on SSD’s and large SD’s the data and allocation is encrypted to be able to wipe a drive. Due to the wear algorithms it’s impossible to write the hole drive with random data; an simple update of the key’s completely wipes out the SSD / SD drive

(Robert Moskowitz) #67

First I would like to point to the 30MB FAT16 partition on the front of the uSD image. I would have to do some digging, but I think that is there for RPi, and is carried as an artifact for the generic image. But don’t quote me on that. Search back on the centos-arm list or ask.

I am not even a hardware guy. I am really a secure data communications standards guy. Check out my work in IETF and IEEE 802. I have tried to keep my hands in using Linux and running my own stuff. I can’t do a build consistantly and have gotten yelled at on a lot of mailing lists over the years. But I am use to that in standards meetings; got my Kevlar suit hanging in my closet.

So, to an extent, I will work with whatever you build your image as. I was thinking that I can install your image then yum groupinstall gnome-desktop, or whatever the exact group is.

The other advantage of partitions is you can put different partitions on different drives. Again with the drives we have these days, that is less an issue. And LVM is not used in the Centos-arm issue, so expanding across drives is not ‘out of the box’.

(Mark Verlinde) #68

Note it’s a community effort, and therefore your feedback is appreciated and I will make what ever the community decides :sweat_smile:

I read / saw your work and been in some norm commissions myself; kind of know the drill… Just imagine to try getting the British’s (BS) and Germans (DIN) to agree and translate the content to a Dutch NEN norm. Pretty sure at CEN they do not mourn about the Brexit. :wink:

(Robert Moskowitz) #69

Oh, that 30MB vfat partition is /boot/fw

from /etc/fstab

UUID=1279-99A4 /boot/fw vfat defaults,noatime 0 0

(Dan) #70

It’d be interesting to try this on one of these:
OS on the SD card, mount the spinning disk at /var/lib/nethserver…


i’m sorry, the only one I have for armhfp (apart from old rpi) is an hc1 but I do not think there is the uboot-image (i’ve tried with the one of xu3 but it didn’t work)

i have an old sd with centos 7.4 updated to 7.5 for the hc1, can i use this to install ns7 on it?

in the meanwhile, i’ll flash an SD for rpi3b+
this is the latest image to test, right?


(Mark Verlinde) #72

Yes, just as befor. After installing nethserver-release run nethserver-install
I think @danb35 is interested to…

Will look into the HC1/. I think we need a newer or vendor kernel for this.
My HC1 is running on an arch linux arm (alarm) kernel.

Yep, thanx for testing!

(Alessio Fattorini) #73

Such a great discussion here. Thanks all for your effort. How can we help?

(Mark Verlinde) #74

Maybe a fedora kernel will do the job:



(Mark Verlinde) #75

you could ask the sys-admins @nethesis about the pro’s and con’s of having a boot and swap partition.

Important to get in to the equation is:

  • The sizes are predefined because we do not know the size of sd /hdd the image we be flashed to.
  • As an consequence the RootFS will be on last partition for easy resizing/growing.
  • U-boot favors to boot the kernel from the first partition although there are way around this: define the UUID where the kernel is located.

Thanx in advance

(Robert Moskowitz) #76

More information on zram:

“It’s created as part of the zram-swap service. The swapon (no options) will show swap details, the zramctl cmd (no options) will show you size, utiliation, compression ratios etc.”

Of course is the zram-swap service even in Centos or would we have to back-port it?

(Mark Verlinde) #77

Here is a start:

(Giacomo Sanchietti) #78

We have similar constraints inside our NethBOX (Nethesis appliances with NethServer). Our partition schema is:

  • vda1: boot 500MB (kernel_limit should be set to 2)
  • vda2: swap 1GB
  • vda3: grow to end of disk
  1. About the RAM, I back @rgmhtt idea to go with ZRAM. Eventually, the user can switch to a SWAP file if needed. To start a 512MB zram should be fine.
  2. First partition should be a simple boot partition. We use XFS both for root and boot, but I think you can choose everything you want. My advice is to choose the same FS type for both partitions.
    We do not handle UEFI machines, so we do not need an extra boot partition.
    Just copy what CentOS or Fedora do :wink:
  3. Root partition at end is good

I’d like to publish a beta ARM image when 7.6 will be out! :smile:

(Robert Moskowitz) #79

Would a ZRAM of 512MB be acceptable with a 1GB ram arm board? Eventually I can test this on my Cubieboard2s.

The referenced howto is beyond my skills. I would need something much easier to set up. I am going to dig into what F29 is doing. I suspect they are running it as a systemd service.

As for Centos 7.6: Do you know of an anticipated availability date? Particularly for the arm image?

(Mark Verlinde) #80

Oke, zram swap is the first option to pursuit. Do not know it and will investigate.

As said must get familiar with zram, but one of the motivating reasons to get rid of the swap partition is to be able to alter the swap size at will.

Oke we will keep the boot partition with a little bit of reluctance because still have found no arguments why it is preferred. Note most distributions do not use a boot partition in conjunction with u-boot.

In future it would be a preferred goal for me to boot all arm devices trough UEFI. This would make the boot process uniform for all architectures. Except (limited) UEFI functionality is provided by u-boot.

FC29 moved to this too:

I’ll guess you mean how fedora/cantos do it on x86-64. As said on arm it quite different and to my like.

That sounds like a plan, so we go for it! :+1:

If we are done before the centos-arm 7.6 nothing will stop us to release beta based on 7.5.1804 centos.