Jump to content

HexOS - accessibility considerations

Let me start off by saying that I'm well aware of this being an edge case. Based on past experiences, answers either don't exist, aren't given, or such posts just are ignored.

 

My problem is this: I accidentally bricked my readynas ultra 6 (without me even knowing I did so until I went to restore radiator 4.x and got stuck). So, finally free of the netgear shackles, I went hunting for nas os alternatives. Obviously, I couldn't use truenas (high ram), unraid worked but was horrably slow and thus caused a lot of frustrations when trying to copy about 6 tb of data taking a century... Because I'm completely blind, I have to rely on screen reading technology to get things done, and wouldn't you know it, once I set up a vm to see if I could even get anything installed, the answer was simply (no, duh, of course you can't). Unraid was fine since it used a windows app to allow media creation, but as stated wasn't really helpful.

 

What caused the biggest "frustrations" was that os's like scale as Debian derivative simply nuked all accessibility components out of the default Debian thing, while omv doesn't allow the cdrom / isofile to be unmounted to install to a usb pendrive to boot off the nas, in short everything that could be an obstacle was one. I kind of found a workaround by using the Debian netboot to install omv onto a volume group (i believe it was called that, has been a while so am uncertain) but that in its turn caused configuration to be hell and back. At this point in time, it works, but it's not a sollution that gives a lot of confidence.

 

So, if there's one thing I'd like to ask the HexOS devs, then it's this: please add in anything that would help people with disabilities (brltty), or people needing to perform headless installs (install over ssh), (auto answer files), (just about anything will do), so I could finally stop hitting os walls just because things are left out or work differently than the core it was based on. The moment I can independently install my NasOS, and perform maintenance / rescue all by myself, I'm scrapping the netgear box, pick up all the drives or buy new ones, and heck find myself a good machine to backup data... I did sign up for the beta release, out of hope / desperation to see if there was any consideration for non-standard installation methods... So, I'll be curiously waiting and watching...

 

Edited by SansVarnic
Edited for easier reading...
Link to comment
Share on other sites

Link to post
Share on other sites

Adding the url below as proof that I've been trying real hard to get anywhere, but as you'll discover, those scale ears are scaled up good...
 
lack-of-accessibility-options-in-the-sca

Link to comment
Share on other sites

Link to post
Share on other sites

Sadly it seems like accessibility is seldom a priority in FOSS projects, even the large ones. Is it easier if the initial setup can be done via web UI, or by SSH?

 

Pinging @HexOS_Jon to weigh in.

I sold my soul for ProSupport.

Link to comment
Share on other sites

Link to post
Share on other sites

@HexOS_Jon

Tagging the one person I know of who might be able to help.

 

 

Also, the link from OP's second post:

https://www.truenas.com/community/threads/lack-of-accessibility-options-in-the-scale-installer.101576/

Current Network Layout:

Current Build Log/PC:

Prior Build Log/PC:

Link to comment
Share on other sites

Link to post
Share on other sites

Using ssh or a webUI to do setup might work, but upto a certain degree: the moment someone can't use dhcp for whatever reason, that person would probably be stuck (if that person has no sight to rely on to configure the network). If I were completely egoistic, I'd be all too happy with either ssh or WebUi, but there's always that small chance it could exclude people with different network configurations, or no network for the initial setup (drivers or whatever else).
 

Link to comment
Share on other sites

Link to post
Share on other sites

2 hours ago, criticview said:

Obviously I couldn't use truenas (high ram)

This isn’t exactly pertinent to your question, but Truenas “doesn’t have high RAM requirements”, and its RAM needs would be the same on hexOS. 
 

The need for RAM is based on the ZFS file system, and this “need” is often very overblown especially for home users. 
 

Again, I know this doesn’t really help you since this doesn’t solve the problem your asking about, but just wanted to clarify you can run Truenas, or eventually hexOS, on 16GB of RAM no problem. Technically you can run it on 8GB, but I wouldn’t recommend it, that is a little to low. 
 

A potential alternative might be using Debian and nothing fancy on-top of it? You can spin up ZFS arrays in debian and then share them via SMB. It sounds like your stating vanilla Debian does have support for the accessibility tools you require, would this not be an option? 

Rig: i7 13700k - - Asus Z790-P Wifi - - RTX 4080 - - 4x16GB 6000MHz - - Samsung 990 Pro 2TB NVMe Boot + Main Programs - - Assorted SATA SSD's for Photo Work - - Corsair RM850x - - Sound BlasterX EA-5 - - Corsair XC8 JTC Edition - - Corsair GPU Full Cover GPU Block - - XT45 X-Flow 420 + UT60 280 rads - - EK XRES RGB PWM - - Fractal Define S2 - - Acer Predator X34 -- Logitech G502 - - Logitech G710+ - - Logitech Z5500 - - LTT Deskpad

 

Headphones/amp/dac: Schiit Lyr 3 - - Fostex TR-X00 - - Sennheiser HD 6xx

 

Homelab/ Media Server: Proxmox VE host - - 512 NVMe Samsung 980 RAID Z1 for VM's/Proxmox boot - - Xeon e5 2660 V4- - Supermicro X10SRF-i - - 128 GB ECC 2133 - - 10x4 TB WD Red RAID Z2 - - Corsair 750D - - Corsair RM650i - - Dell H310 6Gbps SAS HBA - - Intel RES2SC240 SAS Expander - - TreuNAS + many other VM’s

 

iPhone 14 Pro - 2018 MacBook Air

Link to comment
Share on other sites

Link to post
Share on other sites

Posted (edited)

I ment high ram, for the readynas at least. In modern terms it's average, but 16 gigs of ddr2 ... As for debian and zfs, if I knew what I would be doing, if it's a set and forget thing, if smb folder sharing is within a wizzard or so, then sure, I could run debian the way you proposed.

I mainly used the readynas as a jumpingboard to spend money responsibly: if it works proppery there, or if I can install and rescue the system independantly, then I can think of buying licences or supporting the company behind it the software I'd be using.

Edited by criticview
weard text added due to writing on mobile and not correctly deleting.
Link to comment
Share on other sites

Link to post
Share on other sites

1 hour ago, criticview said:

Using ssh or a webUI to do setup might work, but upto a certain degree: the moment someone can't use dhcp for whatever reason, that person would probably be stuck (if that person has no sight to rely on to configure the network). If I were completely egoistic, I'd be all too happy with either ssh or WebUi, but there's always that small chance it could exclude people with different network configurations, or no network for the initial setup (drivers or whatever else).
 

What do you think of initial setup solutions like Synology's "Web Assistant", where you browse to a known URL and it automatically redirects to the NAS? (I think they use mDNS / Bonjour.) That would at least help the discoverability issue, then hand you off to a web UI that should be navigable anyway.

I sold my soul for ProSupport.

Link to comment
Share on other sites

Link to post
Share on other sites

If it can solve the issue of not being able to install the software, and if it would work after the first system bootup so you don't have to go through your router to find the ip or some such, then why not. But then, what if for whatever reason hexos servers would go down, wouldn't that mean you're stuck? A sinoligy might not be as volatile as a new player in the market...

Link to comment
Share on other sites

Link to post
Share on other sites

Hi all,

 

After Linus mentioned us on the WAN show back in June when we launched our website, it didn't take long for us to get a message from David Redmond, a visually impaired individual.  He connected us with a firm that specializes in helping companies like ours address accessibility and we will be working with them in the future as we get closer to 1.0.  That said, we are already doing some basic things in Javascript to help with accessibility.

 

Question for you though:  how do you currently install ANY operating system to bare metal?  Creating the OS installation media seems easy enough as you have Windows or Mac accessibility tools to navigate that obstacle.  But once you get to booting bare metal, entering the BIOS to configure settings, navigating the installer, etc.  What do you do?

 

There are limits to what we can do to help the process of installing to bare metal.  We don't have any control over hardware-level configuration (BIOS settings, etc.) and while I can commit us to building a media creation tool like Windows does, you still have to boot from that media and install to bare metal.  We will have the ability to make some changes to the installer itself, but I don't think there are any solutions for accessibility at that level (screen reader, etc.)

On 8/6/2024 at 8:15 AM, criticview said:

Using ssh or a webUI to do setup might work, but upto a certain degree: the moment someone can't use dhcp for whatever reason, that person would probably be stuck (if that person has no sight to rely on to configure the network). If I were completely egoistic, I'd be all too happy with either ssh or WebUi, but there's always that small chance it could exclude people with different network configurations, or no network for the initial setup (drivers or whatever else).

Once the OS is booted for the first time, even with a DHCP address, connecting to and managing your server is as simple as navigating to deck.hexos.com.  No port forwarding on routers or firewalls required.  No looking up hostnames via the DHCP reservation list either.  It just...freaking...works...  Even changing IP addresses (LAN or WAN) is no biggie because we can confirm those changes worked the second the server reconnects to us and if your LAN IP change doesn't, just change it back to the last known working config.

 

A solution we could potentially offer customers like yourself would be to sell pre-installed storage devices with HexOS so users like yourself could buy one and when it arrives, you just slap it in and boot.  From there, everything is configured via a browser where we can go to great lengths to support the visually impaired.  How would that suit you as a solution?

 

While we cannot do things to affect areas we don't control, we'll do what we can in the areas we do control.

Link to comment
Share on other sites

Link to post
Share on other sites

Booting bare metal can be as easy as putting in a thumbdrive and having luck, or as frustrating as asking a sighted person either in person or through initiatives such as "seeing ai" or "be my eyes" to spend several minutes until you get it right. I usually try to make sure that only the os drive is connected and that the drive is completely blank, so that bios doesn't desire to boot from it anyway. Since this doesn't only count for HexOS but also windows and linux, I feel safe in saying that this isn't the issue of any individual os / software, so that can be safely skipped. Where os / software support starts playing a role is the moment the installation media, or the os itself takes over. From that moment on, the software decides. So, in debians case, having brltty installed and the system capable of detecting devices, after a while, the text console pops up on my braille display and I can install the whole os through braille alone. If I fancy linux mint (mate edition) i can use speech through espeak to get the os installed, and to use it afterwards. And this is where HexOS can make the difference: having brltty within the installer as well as the os, potentially only install when a braille display is detected would be an incredible step. Since I'm blind, I can't say what would work best for people with low sight, but I'm pritty sure some background / font changes with some shortcut keys could do miracles for them too.
In short: it's mainly the accessibility withint the installer and the os people would lean on, and thus where you could make the difference. As said before, everything outside that area needs external help anyway, unless uefi / bios makers suddanly start caring...

 

Link to comment
Share on other sites

Link to post
Share on other sites

Since I couldn't suppress my inner tinkerer, I just spun up a vm after downloading the latest scale iso. Using "screen OCR" I seem to find 4 options: install, shell, reboot and shutdown. Going for shell, first typing /bin/bash to get pc speaker beeps to indicate console is ready and empty... I then tryed to
"apt-get update"  and
"apt-get -y install brltty"
but alas, no such package, so on to the next step:
"curl -O debian.org/debian/pool/main/b/brltty/brltty_6.6-5~bpo12+1_amd64.deb" followed by
"dpkg -i brltty_6.6-5~bpo12+1_amd64.deb"  but there were way to much dependencies to fill so I just gave up.
I did read in this post on
https://www.reddit.com/r/truenas/comments/lgf75w/scalehowto_split_ssd_during_installation/?rdt=53379
that scale seems to be using a fairly simple script or some such to install, making me even more hopeful that a sollution can be as simple as integrating a few programs into the installer and os... but we'll see what the future holds.

 

Link to comment
Share on other sites

Link to post
Share on other sites

Great feedback @criticview.  I think our approach to accessibility will have to come in phases and stages.  The area that we can impact the most right now is in our web-based UI/UX.  While we are going to be producing our own ISO, it is ultimately the same installer as TrueNAS with our HexOS connector to the Command Deck and we're not planning on making sweeping changes to it prior to 1.0.  In addition, eventually offering HexOS pre-installed storage devices would be a stop-gap solution to make things easier, though I can appreciate your desire to not need this.  And even longer-term, having pre-configured hardware optimized for the use-case and pre-installed with HexOS could make it even easier. 

 

Bottom line:  know that you have an advocate in us.  We do care.  It may take us a while to get everything just right, but accessibility is important to us and we don't intend to sweep it under the rug.

 

 

Link to comment
Share on other sites

Link to post
Share on other sites

I'm sincerely happy to hear that swiping under the rug is not an option, that's very good news to hear indeed. Here's an interesting conundrum to consider though: how would I be able to evaluate the webUI accessibility, if I have no means of installing? I understand you might not want to make drastic changes to the installer, but in reality it's just putting back what was ripped out. Why scale decided to make life several times more difficult by removing the brltty components from the debian installer, honestly confuses me by a lot. Even if it were 10 or so megs extra, it probably doesn't hurt anyone by its presence, does it? I am not a developer, so I actually don't even know how hard it would be to add nuked items to the installer again. But if it only would be half an hour or so, or if there's documentation I could follow to make a custom installer, I would like to ask to at least consider those points. (it's not reinventing the wheel, only adding one for extra support)

Link to comment
Share on other sites

Link to post
Share on other sites

2 hours ago, criticview said:

I'm sincerely happy to hear that swiping under the rug is not an option, that's very good news to hear indeed. Here's an interesting conundrum to consider though: how would I be able to evaluate the webUI accessibility, if I have no means of installing? I understand you might not want to make drastic changes to the installer, but in reality it's just putting back what was ripped out. Why scale decided to make life several times more difficult by removing the brltty components from the debian installer, honestly confuses me by a lot. Even if it were 10 or so megs extra, it probably doesn't hurt anyone by its presence, does it? I am not a developer, so I actually don't even know how hard it would be to add nuked items to the installer again. But if it only would be half an hour or so, or if there's documentation I could follow to make a custom installer, I would like to ask to at least consider those points. (it's not reinventing the wheel, only adding one for extra support)

Very good point, actually.  These are all the things that I as an able-bodied person just don't consider in my day to day life.  Not trying to virtue signal or anything like that, but these truly are valued insights.

 

On the UI evaluation, we could eventually create a version of our UI that is essentially just a "mock-up" online that you could play with to see how the user interface would work and flow, but honestly that might be more of an engineering effort than just solving the problem you're asking me to solve.

 

All I can ask on this is for your patience.  We have it on the roadmap to take a closer look at the installer after we get past the initial beta phase which would be the more appropriate time to examine this issue.

Link to comment
Share on other sites

Link to post
Share on other sites

I will probably use vmware to install the beta on a drive to then put in a machine, since I can use screen ocr to hopefully figure out enough to get through the install. If that doesn't work, I'll ask sighted assistance for installing, just because of the "positive attitude": this way reports can come in faster or earlier and ]hat could be good for a beta, I would assume. I'm not afraid to get my hands dirty, with the understanding it is pre release and stuff, so can't wait. This way I can hopefully contribute to the " current accessibility workflow" while waiting for the next steps. 

Link to comment
Share on other sites

Link to post
Share on other sites

Send me a DM with your email address you used to sign up for the newsletter. I'll put you in a group of test users for accessibility testing when we are ready. The fact you are taking this much time to communicate and you have more than the average techie IT skills is a valuable perspective for us to have. 

Link to comment
Share on other sites

Link to post
Share on other sites

Before I begin: I am writing this in wordpad to copy paste afterwards. I have no idea how this is going to come out of the forum, so hopefully it's not going to be too much of a mess. If it is a mess though, I do apologize: since I haven't used the "advanced features" of the rich text editor of the forum before,  I'm not completely sure on how to best aproach it.
It is only by stumbling accidentally on the first of my sources listed below that I decided to continue my endeavor. Keep in  mind that everything is derived from the sources, with some small adjustments along the way. This means that I have no idea about the potential security and integrity implications.
I'm writing this down mainly for my own reference, but also in the hopes that anyone having the same needs as I have, and not afraid to getting their hands dirty, might find this useful. My secondary motive is to also find out if and where I could improve this for the future, because I simply don't know how obtimal this is...

 

Braillifying the scale installer
----------

Sources:
https://gparted.org/add-packages-in-gparted-live.php
(used to prepare the squashfs file, needs few additions)
https://www.reddit.com/r/Ubuntu/comments/1cxotah/going_mad_cant_get_options_for_xorriso_to_work/
(used to figure out how to create a bootable iso file, since the link above used an older method no longer available)

 

Getting to work
----------

 

Step 1: get a debian vm up and running.
As was stated in the "gparted" doc, we need a debian vm to make this work. After downloading the debian dvd iso, performing the installation, logging in as root, adding sudo to the system and adding my user to the sudo group, I could then presede with my normal user.
I used the following commands to get all packages needed:
$ sudo apt-get install curl
$ sudo apt-get install p7zip-full
$ sudo apt-get install squashfs-tools isolinux xorriso

 

Step 2: obtaining scale media, adding directories, extracting the scale iso and preparing the chroot environment
Now that we have our user correctly configured, and all needed packages are installed, it's time to prepare the system to allow us to modify the installation media to add packages. This time, it's a lot of commands:
- downloading the scale media:
curl -O https://download.sys.truenas.net/TrueNAS-SCALE-Dragonfish/24.04.2/TrueNAS-SCALE-24.04.2.iso
- creating and entering the directory to extract the iso file:
$ mkdir scale-iso
$ cd scale-iso/
$ 7z x ../TrueNAS-SCALE-24.04.2.iso
- Leaving the extracted files alone, and creating a squashfs working directory:
$ cd ..
$ mkdir scale-squashfs
- entering the squashfs directory to extract the squashfs image:
$ cd scale-squashfs/
$ sudo unsquashfs ../scale-iso/live/filesystem.squashfs
- Mounting / binding several important system directories to the extracted squashfs image:
$ sudo mount --bind /proc squashfs-root/proc/
$ sudo mount --bind /sys squashfs-root/sys/
$ sudo mount --bind /dev squashfs-root/dev/

 

Step 3: adding the brltty package to the live filesystem
Now that all files are prepared, we can use chroot to enter the live system that will run on the dvd, and do what needs to be done to get braille working.
- Chrooting:
$ sudo chroot squashfs-root/
(Now inside the chrooted system):
- Add dns so the system can propperly connect to the internet:
$ echo "nameserver 1.1.1.1" > /etc/resolv.conf
- Update apt repositories:
$ apt-get update
- install brltty:
$ apt-get install brltty
- Leave the chrooted environment, we're done here:
$ exit
(back in our regular system)
- For safe keeping, rename the current live filesystem:
$ mv ../scale-iso/live/filesystem.squashfs ../scale-iso/live/filesystem.squashfs.old
- Add several steps the sources omitted, needed so creating the new squashfs doesn't throw errors:
$ sudo umount squashfs-root/dev
$ sudo umount squashfs-root/proc
$ sudo umount squashfs-root/sys
- Creating the new squashfs filesystem:
$ sudo mksquashfs squashfs-root ../scale-iso/live/filesystem.squashfs -b 1024k -comp xz -Xbcj x86 -e boot
- Leaving the scale-squashfs directory, and returning to scale-iso
$ cd ..
$ cd scale-iso

 

step 4: creating a bootable iso file
This, by far, was the most difficult step to get right. This means that, there's a good chance that it can be done better. For now though, this is wat made it work:
- Get as much info as possible out of the scale iso, to be used in creating the new iso file:
$ xorriso -indev ../TrueNAS-SCALE-24.04.2.iso -report_el_torito as_mkisofs
(I did append > ../isoinfo.txt to the above command so I could download the entire info, and rework it for the command below)
- Creating the iso file, using the info we obtained from the command above, modifying TrueNAS-SCALE-24.04.2.iso into BrailleScale.iso so it corresponded with the disk image I was trying to make (it's a very long command, so make sure you select everything):
$ sudo xorriso -as mkisofs -V 'BrailleScale' --modification-date='2024070817355300' --grub2-mbr --interval:local_fs:0s-15s:zero_mbrpt,zero_gpt,zero_apm:'../BrailleScale.iso' --protective-msdos-label -partition_cyl_align off -partition_offset 0 -partition_hd_cyl 98 -partition_sec_hd 32 -efi-boot-part --interval:local_fs:308d-10507d::'../BrailleScale.iso' -apm-block-size 2048 -hfsplus -c '/boot.catalog' -b '/boot/grub/i386-pc/eltorito.img' -no-emul-boot -boot-load-size 4 -boot-info-table --grub2-boot-info -eltorito-alt-boot -e '/efi.img' -no-emul-boot -boot-load-size 5760 ./ > ~/BrailleScale.iso

 

Step 5: downloading the new iso file off the vm and trying it out:
I did use FileZilla pro to download the new iso file via sftp. Then, shut down the debian vm, and spun up my iso testing machine and wouldn't you know it, I had to wait a while, but my braille display was activated and I could read the four options:

1. install,

2. shell,

3. reboot system, and

4. shutdown System.

 

Mission accomplished

Link to comment
Share on other sites

Link to post
Share on other sites

3 hours ago, criticview said:

Before I begin: I am writing this in wordpad to copy paste afterwards. I have no idea how this is going to come out of the forum, so hopefully it's not going to be too much of a mess. If it is a mess though, I do apologize: since I haven't used the "advanced features" of the rich text editor of the forum before,  I'm not completely sure on how to best aproach it.

It's perfectly legible, all the commands have line breaks between them. 🙂 

I sold my soul for ProSupport.

Link to comment
Share on other sites

Link to post
Share on other sites

Disclaimer: everything was performed on a vm, meaning I can just chuck it in the bin and start over, doing whatever you find below on a production system is NOT, and I mean really NOT, something you should be doing...
With that out of the way: here are my preliminary testing results using my braillified installer
Yes, I could read and go through the entire installation process, having no issues what so ever. Using navigation keys on the display itself, the entire screen was readable, and at no point in time did I have the impression I got stuck. After rebooting though..... (and this is where having braille is really going to help out a lot)
Trying to find ip addresses with ocr is hell, I can tell you that much. I got extremely lucky because it correctly showed the last 2 numbers of the ip, and the rest I knew by heart, so was able to get into the WebUI. There, with googles help, I did enable ssh for easy command copy paste. Then (DON'T DO THIS ON PRODUCTION STUFF) I did enable developer mode
by running:
$ install-dev-tools
After that, I did add debians deb definitions for the sources.list file, to then finally get brltty installed. One reboot later, and I can confirm that the console setup screen is perfectly readable (will mess with it some more after I'm done writing), so I consider this a success.
In very short: yes, adding brltty seems doable, and yes, it will help out blind people to read info like the ip to connect to, not to mention use the console setup menu to fix issues if they arise.
This is all the info I can provide so far. I leave things now in official hands to do with this information as they please.

 

Link to comment
Share on other sites

Link to post
Share on other sites

Whoa...  Seriously impressed at the level of work you've done here.  Bookmarking this to revisit when we get deeper into making changes to the installer itself.  I don't think I could have asked for a more thorough write up.  Great work.

Link to comment
Share on other sites

Link to post
Share on other sites

Who said I was done... 🙂

I have a feeling that now is the time I might hit some walls, sadly. As I suspected, the file TrueNAS-SCALE.update is another squashfs thingy. But then, to make my life even more miserable, there's a rootfs.squashfs in there. So, extracted that, and jackpot: the entire scale os in all its glory. Of course, they had to block dpkg and all of that, so after some digging and poking I found

$ /usr/local/libexec/disable-rootfs-protection --force

Lo and behold, no more restriction. Now that those obstacles were cleared up, I could finally copy the packages I grabbed from the scale vm, and drop them in here, to then use dpkg to install them... NO more apt-get updates and so on, wich technically should result in an overall cleaner system. After that was done, I ran:

$ /usr/local/libexec/disable-rootfs-protection --no-force

and then followed the rest of my steps to unmount the 3 special folders, to then create the rootfs.squashfs, to afterwards create the TrueNAS-SCALE.update file using the command previously used in the braillify installer. To end on a happy note though, here's the list of packages the system pulled in, and that were successfully installed with:

$ dpkg -i *

packages are:

liblouis20_3.24.0-1_amd64.deb

libpcre2-32-0_10.42-1_amd64.deb

liblouis-data_3.24.0-1_all.deb

libbluetooth3_5.66-1+deb12u2_amd64.deb

brltty_6.5-7+deb12u1_amd64.deb

 

Now I think I'm done. I don't feel entirely comfortable since turning off the rootfs-protection threw an error, and there's also a good chance that using the command I previously used to create the squashfs image is not the right one for the update file etc... If only the scale devs would have added more documentation to figure out where(when building from source) one would add packages and stuff, ...

 

 

Link to comment
Share on other sites

Link to post
Share on other sites

I finally got it all working! I now  have braille output during the installation process, as well as when the system reboots. I'll do a write up of the second part in a bit, but thought I'd share the happy news first.
I did use all packages mentioned in my previous post, and with the commands
$ sudo mksquashfs squashfs-root rootfs.squashfs -b 1024k -comp xz -Xbcj x86
$ sudo rm -rf squashfs-root/
$ cd ..
$ sudo mv ../scale-iso/TrueNAS-SCALE.update ../scale-iso/TrueNAS-SCALE.update.old
$ sudo mksquashfs squashfs-root/ ../scale-iso/TrueNAS-SCALE.update -b 1024k -comp xz -Xbcj x86
I was able to get the base system to extract and install without issues.
There's a few remarks that need writing down:
1. Since I couldn't get the "developer mode" flags removed from the root filesystem with
$ /usr/local/libexec/disable-rootfs-protection --no-force
(because it threw errors)
I am now potentially facing "no sir, we can not offer you support because you have a customized system". For the HexOS beta I'm not worryed about that, because it's a beta and that rarely means official support anyway. However, for production systems this is not ideal, so any movement to try and get this official both in HexOS and even upstream would be benificial.
2. I tryed taking shortcuts to braillify the installer by using prefetched packages, but that seemed to fail. This means that there, for now, might be no other way to aproach the integration of brltty in the installer
Now, as a positive end note, my first "console setup" experiences:
Everything was perfectly readable. I could change network interface configurations, change network settings like hostname, enter and use the linux shell etc. So, I'm definitely considering this a great success. Now I can finally go to the next step and that's deploying this on a test machine, with some old crappy laptop drives and all of that to discover what the "trueNAS: experience is all about.

Link to comment
Share on other sites

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×