Kanu
Mission Specialist
Mission Specialist
  • 392 Views

Stratis failed

Jump to solution

Hi everyone,

Does someone know if  there is a solution for stratis command failure? Having browsed on the internet I could not find out an answer. Please, click on the link below to have a look at screenshot with full Traceback.   Stratis Error 

Thanks in advance.

Best regards,
Kanatbek

 

 

Labels (2)
0 Kudos
2 Solutions

Accepted Solutions
Tracy_Baker
Starfighter Starfighter
Starfighter
  • 332 Views

Try this:

From the Lab Environment tab:

Click the Action drop down next to serverb

Choose Reset

1.JPG

Program Lead at Arizona's first Red Hat Academy, est. 2005
Estrella Mountain Community College

View solution in original post

0 Kudos
Tracy_Baker
Starfighter Starfighter
Starfighter
  • 284 Views

This is going to happen if you do not make the configuration changes to /etc/fstab correctly - either for Stratis or VDO.

For Strais that's Step 7.4
UUID=9825...d6ca /labstratisvol xfs defaults,x-systemd.requires=stratisd.service 0 0

(You DO NOT use 9825...d6ca; instead, use the UUID you got from Step 7.3)

For VDO, that's Step 7.11.5
UUID=ef8c...39b1 /labvdovol xfs defaults,x-systemd.requires=vdo.service 0 0

(You DO NOT use ef8c...39b1; instead, use the UUID you got from Step 7.11.4)

If either of those steps are not done exactly right, the serverb will not properly boot up, and you'll not be able to connect via SSH.

You can, however, connect to serverb's console and fix the problem without having to redo the entire lab.

1.JPG

If the console doesn't open, and it says active, you'll want to contact Red Hat because you have another problem altogether, unrelated to Stratis or VDO.

This kind of problem is exactly why you want to reboot your systems after making changes to files like /etc/fstab. Fixing an /etc/fstab error from emergency mode is a skill you'll want to have.

Incidentally: If you make a change to /etc/fstab, you should always used the mount -av afterwards to ensure that the volume will mount.

However, this doesn't always catch issues with Stratis or VDO if the problem is with the x-systemd.requires=stratisd.service or x-systemd.requires=vdo.service options in /etc/fstab.

The reason is that those services are typically already started and enabled by you earlier on in the lab. As a result, they don't need to be started when mount -av tries to mount the volumes. However, when the system boots, they aren't already started, so, when /etc/fstab is processed, it has to wait until they are.

If it so happens that the name of the service is misspelled, maybe x-systemd.requires=stratisd.service is spelled as x-systemd.requires=stratis.service (the d is missing), then, because there is no "stratis.service" service, the system times out trying to mount the the volume and into emergency mode you go.

Program Lead at Arizona's first Red Hat Academy, est. 2005
Estrella Mountain Community College

View solution in original post

0 Kudos
6 Replies
Tracy_Baker
Starfighter Starfighter
Starfighter
  • 379 Views

I'm guessing you are doing the end-of-chapter lab for RH134, Chapter 8.

The screenshot doesn't really have enough information. But:

1. did you run the lab's setup command (lab advstorage-review start)?

2. did you start stratisd (systemctl enable --now stratisd)?

3. Did you make certain stratisd was running (systemctl status stratisd)?

4. did you verify that /dev/vdc exists (fdisk -l)?

5. If it is the end-of-chapter lab for RH134 chapter 8, the command should have been
(stratis pool create labpool /dev/vdb /dev/vdc)

Program Lead at Arizona's first Red Hat Academy, est. 2005
Estrella Mountain Community College
0 Kudos
Kanu
Mission Specialist
Mission Specialist
  • 373 Views

Good day Tracy,

Many thanks for your reply.  

As you provided in your answer the possible solution for the issue, I firstly, followed the course materials and coded in the same way, then there are hidden answers too, in case students stuck.  Nevertheless, the lab system got corrupted after the issue I posted and everytime when I restart the lab it starts with Failures. (screenshot below)
Screenshot 2022-09-21 11.09.07.png   

Any ideas how the lab might get this issue too?

Kind regards,
Kanatbek

0 Kudos
Tracy_Baker
Starfighter Starfighter
Starfighter
  • 333 Views

Try this:

From the Lab Environment tab:

Click the Action drop down next to serverb

Choose Reset

1.JPG

Program Lead at Arizona's first Red Hat Academy, est. 2005
Estrella Mountain Community College
0 Kudos
Kanu
Mission Specialist
Mission Specialist
  • 315 Views

Hi Tracy, 

The reset the serverb  resolved the issue "failure" on lab advstorage-review, however, there is still persisting some issue I can barely figure out the reason as a user. 

The new issue is now the serverb cannot be reached to grade and close the lab advstorage-review. All the issues are happening after rebooting the serverb machine at the end of the lab.  
Screenshot 2022-09-24 17.02.19.png

Screenshot 2022-09-24 17.01.52.png

From this lab the remaining labs throwing tracebacks when you want to grade your exercise. 

Kind reagrds,
Kanatbek

0 Kudos
Tracy_Baker
Starfighter Starfighter
Starfighter
  • 285 Views

This is going to happen if you do not make the configuration changes to /etc/fstab correctly - either for Stratis or VDO.

For Strais that's Step 7.4
UUID=9825...d6ca /labstratisvol xfs defaults,x-systemd.requires=stratisd.service 0 0

(You DO NOT use 9825...d6ca; instead, use the UUID you got from Step 7.3)

For VDO, that's Step 7.11.5
UUID=ef8c...39b1 /labvdovol xfs defaults,x-systemd.requires=vdo.service 0 0

(You DO NOT use ef8c...39b1; instead, use the UUID you got from Step 7.11.4)

If either of those steps are not done exactly right, the serverb will not properly boot up, and you'll not be able to connect via SSH.

You can, however, connect to serverb's console and fix the problem without having to redo the entire lab.

1.JPG

If the console doesn't open, and it says active, you'll want to contact Red Hat because you have another problem altogether, unrelated to Stratis or VDO.

This kind of problem is exactly why you want to reboot your systems after making changes to files like /etc/fstab. Fixing an /etc/fstab error from emergency mode is a skill you'll want to have.

Incidentally: If you make a change to /etc/fstab, you should always used the mount -av afterwards to ensure that the volume will mount.

However, this doesn't always catch issues with Stratis or VDO if the problem is with the x-systemd.requires=stratisd.service or x-systemd.requires=vdo.service options in /etc/fstab.

The reason is that those services are typically already started and enabled by you earlier on in the lab. As a result, they don't need to be started when mount -av tries to mount the volumes. However, when the system boots, they aren't already started, so, when /etc/fstab is processed, it has to wait until they are.

If it so happens that the name of the service is misspelled, maybe x-systemd.requires=stratisd.service is spelled as x-systemd.requires=stratis.service (the d is missing), then, because there is no "stratis.service" service, the system times out trying to mount the the volume and into emergency mode you go.

Program Lead at Arizona's first Red Hat Academy, est. 2005
Estrella Mountain Community College
0 Kudos
Kanu
Mission Specialist
Mission Specialist
  • 280 Views

Many thanks Tracy.   

I accepted your answers as proven solution to the issues I encountered on the lab, chapter 8. 
I think, I am going to continue the RH134 course without grading the exercises.  

Best regards,
Kanatbek

0 Kudos
Join the discussion
You must log in to join this conversation.