-
Notifications
You must be signed in to change notification settings - Fork 246
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
First boot after restore on FC21 fails trying to find UUID originally generated by mkfs before tune2fs changes it #851
Comments
I found a fix for this in the code. There is clearly something very wrong with first calling mkfs and then afterwards calling tune2fs, at least on Fedora there is something wrong with it. Trying to figure out how to create a pull request now... |
See small tutorial at https://yangsu.github.io/pull-request-tutorial/ On Sat, May 28, 2016 at 1:35 PM, jb notifications@github.com wrote:
|
I read docs and looked up a different tutorial URL but git tells me I On 5/30/2016 1:45 AM, gdha wrote:
|
@exedor you first need to fork rear to your own github account and do your modification on your fork. When done you can request a pull request. |
Ahhh, that was the missing link. Thank you! On 5/30/2016 9:17 AM, gdha wrote:
|
@exedor just applied your pull request - please try it out - let me know if it works well? |
It seems now it does no longer work on RHEL 5.10 |
@jsmeix perhaps it is wiser to revert this pull request and investigate why the |
@exedor Therefore we need to find another way. Regardless that I am not at all an expert in initrd issues First an unrelated side note regarding your USE_DHCLIENT=No means the same as if you set USE_DHCLIENT=yes_please_really_use_it because /usr/share/rear/conf/default.conf reads # PLEASE NOTE: ... # * Boolean variables can be set to anything as we only check wether the variable # is not empty. which matches the code in # check if we have USE_DHCLIENT=y, if not then we run 60/62 scripts [[ -z "$USE_DHCLIENT" ]] && return If you do not want to USE_DHCLIENT Now to the actual issue: I do not understand what you mean with This is only a problem on a system with an identical disk drive. I would assume (but I did not verify it) that In other words when the UUID is identical Could you explain in more detail how the issue happens. In particular what is the UUID on the original system, |
On 6/23/2016 3:01 AM, Johannes Meixner wrote:
When doing an "AUTOMATIC" restore to a system that has a hard drive with
The problem was that mkfs, when it creates the new filesystem generates As I said, I didn't have the time to keep digging to determine why I tested my revision so that instead of calling tune2fs after the file
|
Many thanks for your explanation. Curently I don't have a Fedora system for testing. I will try to install one and see how it behaves. But tomorrow I don't have time |
With #894 I tested it on SLE11 with ext3 and SLE12 with ext4. @exedor |
This is only a problem on a system with an identical disk drive. The initrd image of the restored system fails to boot after completing restore because it is still looking for the UUID's that were allocated when the filesystem was created and used prior to the call to tune2fs to change them back to what they were on the backed up system. This makes no sense unless something is monitoring the disk for changes and then automatically updating initrd but therein lies the mystery.
1: Let dracut go to its emergency shell (takes around 5 minutes)
2: Mount root file system somewhere
3: chroot to mounted root file system
4: mount /boot at its respective mount point
5: run dracut -f /boot/initrd_image_filename
6: reboot
The text was updated successfully, but these errors were encountered: