Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disklayout have collecting problem #1491

Closed
Kolesar opened this issue Sep 13, 2017 · 4 comments
Closed

Disklayout have collecting problem #1491

Kolesar opened this issue Sep 13, 2017 · 4 comments
Labels
not ReaR / invalid The root cause is not in the ReaR code or ReaR is misused. support / question

Comments

@Kolesar
Copy link

Kolesar commented Sep 13, 2017

Relax-and-Recover (ReaR) Issue Template

Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):

  • rear version (/usr/sbin/rear -V): Relax-and-Recover 2.2 / 2017-07-20
  • OS version (cat /etc/rear/os.conf or lsb_release -a): CentOS Linux release 7.3.1611 (Core)
  • rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf): empty
  • Are you using legacy BIOS or UEFI boot? UEFI
  • Brief description of the issue:
    On each run rear -v mkrescue or rear -v savelayout /var/lib/rear/layout/disklayout.conf have different number of partitions. I have found where is problem in code, but I cannot understand why it happened.
    Command declare -a sysfs_paths=(/sys/block/$sysfs_name/$sysfs_name*) every time return different output, so this is really strange
  • Work-around, if any:
    Unfortunately at this moment I do not have work-around. If you have any idea I can try on my hardware and hopefully fix this issue.
@jsmeix
Copy link
Member

jsmeix commented Sep 19, 2017

@Kolesar
I am not at all an expert in this area but in general I assume
when running a particular command on commandline
results varying/unstable/unreliable output
the root cause is likely not inside ReaR but in that command
or even more likely somewhere in the environment
(in this case kernel/udev/whatever...).

Does it perhaps help to add an artificial 'sleep' e.g. like

sleep 30

in the script before that command is run in the hope
that then what there is in /sys/block/... got stabilized
so that the command output is also stable and reliable?

@jsmeix
Copy link
Member

jsmeix commented Sep 21, 2017

@Kolesar
you wrote "any idea I can try on my hardware"
but nobody can have such an idea because
nobody can know what your hardware is
because you did not tell that.

Is this issue here perhaps somehow related to you
#1460
which is about "Raid Level: container"
where you told "I have RAID 1 on my environment"
but not what your environment actually is.

@gdha
Copy link
Member

gdha commented Oct 27, 2017

@Kolesar Can you share an example of the differences please? What kind of disk devices do you have?

@gdha gdha added the not ReaR / invalid The root cause is not in the ReaR code or ReaR is misused. label Nov 17, 2017
@gdha
Copy link
Member

gdha commented Nov 17, 2017

@Kolesar As no evidence was delivered there is nothing we can do I'm afraid - will close it - you may re-open it when sufficient useful information is provided

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
not ReaR / invalid The root cause is not in the ReaR code or ReaR is misused. support / question
Projects
None yet
Development

No branches or pull requests

3 participants