Can't boot - self inflicted wound

I updated from Leap 15.2 to 15.3 a few months back following instructions found here. That all went well but for a grub “quirk” - I was able to boot to “Rockstor NAS, with Linux 5.3.18-lp152…” but nothing labeled “…150300.59…”.


So I basically ignored the problem, thinking I’ll need to figure that out and fix it one of these days. Following a recent install of updates, that day has come - there are no more “…lp52…” options available and the system won’t boot. Self-inflicted wound.

I do have a backup of the data and some of the linux directories (including etc and rockons).

Rather than dig into the bowels of Suse, it will probably be faster for me to just reinstall. I’ve seen instructions here in the past but of course I can’t find clear ones now. So is this the right approach?

  1. Disconnect my data drives.
  2. Install Rockstor.
  3. Recreate my users.
  4. Reconnect the drives and import the pools (I recall I can do that through the UI?)
  5. Restore my config (I have a backup from March that should work)
  6. Reinstall rockons

I think that should cover it - correct?

Thanks, everyone.

@wdc that is a strange one regarding you having only the older kernels. But yes, a re-install may do it.

Regarding re-installing we do have a new HowTo that is intended for those migrating from v3 to v4 but does have some relevant info in:

The config restore should be able to do this.


Restore config is also able to do this, if it was made by a v4. But only if your rockons-root share wasn’t on the system drive. Althought it can take some time and is the newest (read least tested) config back-up/restore feature.

Hope that helps.

Still puzzled by you kernel not having been moved to the newer Leap 15.3 one. I did test for this in the HowTo when I wrote it. Maybe there was a caveat I overlooked that you ran into.


That will help - thank you, Phil.
And I will capture some of the journal before I reinstall; it seems to be something in the startup scripts that ends in a dracut initqueue timeout; I’ll gather some more if it will help you for the future.

1 Like

I didn’t see anything in the log (journalctl) nor rdsosreport.txt that seemed helpful. I also tried mounting a usb stick to copy them onto but the Dracut emergency shell didn’t want to mount a fat, ext4, nor ext3 formatted stick :roll_eyes:

The reinstall worked and the BTRFS import worked. I was also able to restore a config backup and after about an hour, all my rockons and services are back. I’m still waiting for my Samba exports to appear in the UI although the “real” shares are working after copying /etc/samba files from a backup. Maybe they’ll appear tonight after Rockstor has cranked on it a bit longer. If not, I have the smb.conf to use as reference to recreate them in Rockstor and “put Rockstor back in control” of them.

Thank you for your help - it is appreciated, as always.


@wdc Glad the re-install went roughly OK, bar the samba export restore!

The exports are usually restored almost instantly, only the Rock-on restore take any significant time due to the download and install time involved, so you may want to just re-create them as they were from the Web-UI.


Regarding the failure of the kernel to move over from 15.2 to 15.3 we may just have to leave that be untill we have more info, or a reproducer. I didn’t see that behaviour while developing the howto but likely there was a grub update issue of sorts so it got stuck on older kernels. Good to have a note of this happening here though so we know to look out for this on other’s instances where they have distribution updated from 15.2 to 15.3.

Glad to hear you are now on a fresh install and working OK. You can thank @Flox for the Rock-ons restore procedure. It was quite the piece of magic as it goes. All, as always, in development so bug reports; ideally with reproducers, always welcome.

Regarding the failed samba exports restore. It may well be we ran out of workers or timed out some how on our Huey tasks when in combination with the long running Rock-ons restore. We have some work to do there regarding the move to Python 3 so we, and our Huey tasks, can leverage the threading capability better. But this move has begun already in the testing channel via our on-going Django update to facilitate the Python 2->3 move. No rpm releases yet but all in good time hopefully.



Yes, sorry that I was unable to provide anything more useful. If I notice after a future update, I’ll pay attention to it (as I’ve been known to tell my kids more than once) and get something useful for you.


Well done, @Flox!! It worked like a champ!