After a fresh install using v4.5.6 leap 15.4 version everything work perfectly. At least until next reboot. Then the system refuses to load. Every work without problem using v4.1.
If more info is needed please ask.
EDIT: Tested again with UEFI and without UEFI, same behaviour. Dont know if related but boot disk always get in GPT no mather of what. Everything works ok, UI, pool loading, samba sharing, until reboot. v4.1 boots without troubles and reload pool correctly.
@alex6dj Hello there, and welcome the the Rockstor community forum.
The boot message indicates a fail of the system file system (Label: ROOT). And given this happens only on reboot I’m wondering if this is just a space issue. Our installer defaults to boot to snapshot, even if there is not enough root to support it. That way we ensure this capability exists. However if the is in fact insufficient room for these snapshots to be taken it may very well fail in this way.
Does your system drive conform to the current:
Minimum system requirements: Quick start — Rockstor documentation
When we moved to our “Built on openSUSE” base we increased it. But as of v4.5.4, our first Poetry based build where we basically build many of our dependencies upon install, our install and resulting install, takes a lot more space:
V4.5+ Testing Channel Changelog - #4 by phillxnet
The existing recommendation for minimum system disk should be enough however.
Let us know if this possible cause may be relevant in your case. I.e. what is the size of the system disk you are experiencing this failure on. Also could the dive have hardware failures later on in its surface that are only provoked, similarly, by our now much larger install. Our pre Poetry installers were around 600 MB, but we are now at around 900 MB!! The modern nature of our newer build is definitely worth the space but I was a little disappointed with such a jump.
There are memory and drive testing tips in our:
Pre-Install Best Practice (PBP): Pre-Install Best Practice (PBP) — Rockstor documentation
Another caveat that may be relevant here, if you have used a different system disk for the v4.5.6-0 install but left the existing v4.1.0-0 disk attached, that’s not going to work. We basically fail in such a scenario according to:
https://github.com/rockstor/rockstor-installer/issues/29
But that look different to what you have described. And from the report, and memory, it fails the install. However I have seen a reboot (after successful install) be affected by a prior existing system disk, such that the reboot then failed due to conflicts.
Another caveat is that on install (first run on rockstor-pre) our Postgres database is established, at in turn creates yet more space requirement.
Installed and setup before first reboot:
localhost:~ # btrfs fi usage /mnt2/ROOT | grep 'Device allocated:'
Device allocated: 2.52GiB
And after the first reboot the allocated remains unchanged but the “Used:” element is around 10 MB or so larger.
Used: 2.09GiB
Used: 2.10GiB
So all in still fairly manageable, but once the ROOT snapshots start mounting, especially after changes (OS updates) up this can increase significantly.
All pending updates to our 4.5.6-0 based downloadable installer (rockstor-4.5.7-0 not included), once installed, push the Allocated and Used to:
Device allocated: 3.52GiB
Used: 2.39GiB
There is a kernel update in there so that’s fairly large. Note we have an additional Chunk (1GB) allocation having taken place now.
Could it also be that there was some data transferred to the system pool (via a share created on the ROOT pool) prior to the first reboot after install. Our installer does a kexec (kernel switch) from that of the installer to that of the installed image during the first boot. But on reboot the installed image kernel is first to kick things off.
Hope that helps, and let us know some more info and if the system drive is failing later on its usable area or the like. We may also take up more memory now I think, but again not much more.
Hi, thanks for the fast support. First my native language is not english. I know this is important, Im a linux virgin. Right now I have a working NAS (Server 2022). The idea for this setup is for a backup server, so just testing right now. The good thing about Rockstor is tha it is almost fire and forget. It will be used as a plain NAS, no Rockons. And in the future maybe I can migrate my old server to BTRFS too. Thanks to the developers of BTRFS because RAID5/6 is getting some love latelly (I cant afford now the extra RAID1 space).
I know that BTRFS needs some care, this is why Im testing. Already test several things like failed disk, bad sectors and even ENOSPC in the boot disk and after some care It recover without problems. So I loved. Im still waiting the new 4.5.7 iso if any to test the new version.
The minimum system requirements, I dont thinks this is the problem. The same machine was running Windows 11 until last week (i3, 500 gb HDD, 8gb RAM). So following your recommendations I will wipe the boot disk and will test from another boot disk. Memtest already done without problems, I check this every few months in all my machines. If something changes after trying new disks I’ll let you know. Thanks again.
@alex6dj Glad you’ve made some progress.
Re:
There may not be one, it’s not a large update, and the 4.5.7-0 bit only relates to the ‘rockstor’ package version which is already available via the testing channel.
Once we are closer, or have reached, the next stable version we will release a new installer with that included. But it’s not worth re-rolling the installers just yet I think. They are barely a month old currently.
Agreed, but good to mention as it can be the cause of a reboot failure if a small system drive is used.
Keep us posted as the failure you report is not normal. So any more info on what lead to it can only help.
Cheers.
A quick reply, bussy day. Already tested with several drives, same behaviuor. Tested the 4.5.6 with Leap 5.3 version and same error after reboot, but in this case the web gui dont even started. Later will try to test with an old board I have getting dust, just to be sure. If this change works will try with several bios changes just in case there are any setting wrong, but I dont think this is the case.