Testers needed nethserver-arm img

[rgmhtt (Robert Moskowitz)]

@mark_nl

The centos generic image has (IMHO) an insane partitioning:
1 fat with firmware and DTB’s (= mounted in /fw of partition 2)
2 ext3 with kernel and initramfs (=mounted in /boot of partition 4)
3 swap
4 ext4 with root_fs

The reason is to provide one image with the generic kernel for RPI (first boot stage in Vcore needs fat) and u-boot based devices. Do not know why the kernel has ext3, u-boot can handle ext4 or does grub(by) favor ext3? The the last two partions make sense to me…
(Although still haven’t lost the habit to set swap up in a file as was done in the day’s a swap partition wrecked your SD card.)

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.

[rgmhtt (Robert Moskowitz)]

@mark_nl

A heads up:

First boot of new generic armhfp image.

With the default centos kernel can not get a simple frame buffer up meaning it’s complletly headless… Also the driver for the wifi is missing; other than this al seems to be working at first trail…

Still doubting on the partitioning, cannot get why we need a boot and swap partition.
If someone can explain the benefits of this on a sd card (or ssd drive) you are welcome.

Current setup:

1. 700 MB boot ext4
2. 512 MB swap
3. 2GB for rootFS

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_nl (Mark Verlinde)]

@rgmhtt

I mean this is for a production server?

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.

@rgmhtt

As I think getting ext4 code loaded at this point in the boot process was an issue. May not be anymore.

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

@rgmhtt

In either case a swap partition is very nice to have

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

[rgmhtt (Robert Moskowitz)]

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.”

[rgmhtt (Robert Moskowitz)]

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_nl (Mark Verlinde)]

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

[rgmhtt (Robert Moskowitz)]

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_nl (Mark Verlinde)]

@rgmhtt

So, to an extent, I will work with whatever you build your image a

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

@rgmhtt

I am really a secure data communications standards guy. Check out my work in IETF and IEEE 802

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.

[rgmhtt (Robert Moskowitz)]

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

from /etc/fstab

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

[danb35 (Dan)]

It’d be interesting to try this on one of these:
https://www.hardkernel.com/main/products/prdt_info.php?g_code=G151505170472
OS on the SD card, mount the spinning disk at /var/lib/nethserver…

[dz00te]

@mark_nl

After you have unpacked the generic image to your SD card, you need to flash u-boot

Let’s suppose your board is an Orangepi Plus 2e :

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?
https://nethserver.globalcortex.net/mirror/nethserver-arm/7.5.1804/base/armhfp/Packages/nethserver-release-7-7arm.14.gff2a3f7.ns7.noarch.rpm

in the meanwhile, i’ll flash an SD for rpi3b+
this is the latest image to test, right?
https://nethserver.globalcortex.net/mirror/nethserver-arm/img/Nethserver-7.5.1804-Devel-RaspberryPi-img.raw.xz

tnx!

[mark_nl (Mark Verlinde)]

@dz00te

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?
https://nethserver.globalcortex.net/mirror/nethserver-arm/7.5.1804/base/armhfp/Packages/nethserver-release-7-7arm.14.gff2a3f7.ns7.noarch.rpm

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.

@dz00te

in the meanwhile, i’ll flash an SD for rpi3b+
this is the latest image to test, right?
https://nethserver.globalcortex.net/mirror/nethserver-arm/img/Nethserver-7.5.1804-Devel-RaspberryPi-img.raw.xz

Yep, thanx for testing!

[alefattorini (Alessio Fattorini)]

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

[mark_nl (Mark Verlinde)]

@danb35

It’d be interesting to try this on one of these:
https://www.hardkernel.com/main/products/prdt_info.php?g_code=G151505170472
OS on the SD card, mount the spinning disk at /var/lib/nethserver…

Maybe a fedora kernel will do the job:

https://fedoraproject.org/wiki/Architectures/ARM/exynos

https://blog.christophersmart.com/2018/04/28/fedora-on-odroid-hc1-mini-nas-armv7/

[mark_nl (Mark Verlinde)]

@alefattorini

How can we help?

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

[rgmhtt (Robert Moskowitz)]

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_nl (Mark Verlinde)]

@rgmhtt

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

Here is a start:

Zram on Centos 7 / Nethserver 7

Hi, here is a tiny little howto on installing zram as an alternative to swap: Background: I run Nethserver as a guest on Proxmox VE. Nethserver installs a swap disk within the virtual disk provided. In my case, I do have quite a lot of processors and overall CPUs load is still low. Additionally, CPUs are not dedicated to a guest within Proxmox but a shared resource. In contrast to this, a minimum amount of RAM has to be dedicated to each Proxmox guest. I am quite limited with ram and Proxmox …

[giacomo (Giacomo Sanchietti)]

@mark_nl

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

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
3. Root partition at end is good

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

[rgmhtt (Robert Moskowitz)]

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_nl (Mark Verlinde)]

@giacomo

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.

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

@rgmhtt

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

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.

@giacomo

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.

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.

@giacomo

We do not handle UEFI machines, so we do not need an extra boot partition.

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.
https://www.suse.com/media/article/UEFI_on_Top_of_U-Boot.pdf
FC29 moved to this too:
https://fedoraproject.org/wiki/Changes/uEFIforARMv7

@giacomo

Just copy what CentOS or Fedora do

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

@giacomo

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

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

@rgmhtt

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

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