#137 Issue closed: rear recover does not label disk partitions

Labels: enhancement, documentation, waiting for info, won't fix / can't fix / obsolete

cal-s opened issue at 2012-07-26 14:43:

Net certain if this affects only md->sd restores or sd->sd as well

disklabels are collected in layout/prepare/GNU/Linux/13_include_filesystem_code.sh but isn't subsequently being used during restore-time filesystem creation. This affects grub.conf and fstab, which can describe partitions as labels but not as UUIDs (CentOS5). Rear does collect and restore UUIDs from disklayout.conf:

fs /dev/sda1 /boot ext2 uuid=996f046e-7da7-4c7e-8c70-1c1cdfc16037 label= blocksize=1024 reserved_blocks=5% max_mounts=27 check_interval=180d bytes_per_inode=4092 options=rw

blkid /dev/sda1
/dev/sda1: LABEL="/boot" UUID="996f046e-7da7-4c7e-8c70-1c1cdfc16037" TYPE="ext2"

The disklabel was hand-applied using tune2fs

cal-s commented at 2012-08-10 13:53:

Ah, i see that a label can be added in the 'fs' lines of disklayout.conf. this is not wildly intuitive, but once known, works fine.

dagwieers commented at 2012-08-12 22:26:

Shouldn't the label be set correctly in the disklayout.conf file automatically to begin with ? So I am reopening because I don't understand...

cal-s commented at 2012-08-13 10:36:

Sorry - in my haste, i should have fessed-up that this was in a mdraid->sda recovery scenario, so of course ReaR (currently) has no idea what to do with mostly anything from the source disklayout map, but i think there's another open issue for discussion of that.

cheers

dagwieers commented at 2012-08-21 22:09:

@jhoekx Your opinion is valued here ;-) Not sure if the current code can handle manual modifications to labels and uuids in grub.conf and fstab, or whether other known (related) issues should be considered for the issue-tracker.

jhoekx commented at 2012-08-22 06:45:

I don't think we handle modifications to labels/uuids. It's also hard to implement, so out of scope for now.

gdha commented at 2012-10-12 12:22:

To @dagwieers and @jhoekx : what we want to achieve with keeping this issue open? If it is out of scope shouldn't we add it into our release notes?

dagwieers commented at 2012-10-12 12:38:

@gdha @schlomo By keeping this open it remains more visible for users, and we can re-assess the need for implementing this. If we close these issues, we risk never looking at them again and it makes it harder to find them in a growing set of closed issues.

So the way I have managed this up to now is for issues that lack feedback and are clearly support issues, I leave them tagged as support feedback but I may close them asking to reopen and provide more information if the issue still exists. Especially if we think this has been fixed in a newer release. If issues have no feedback after 4 weeks, they get closed like this.

But improvements that have no-one assigned (so no-one currently is interested to fix it) stay open, but may get moved to 'Rear future' milestone. We never discussed this, it's just something I have been doing. I am open to discuss other approaches though.

dagwieers commented at 2012-10-12 12:41:

And yes, items like these should get mentioned in the documentation. Maybe not as much in the release-notes because it's not something specific to some release. It probably depends on the probability of users running into this. If the probability is high, I rather see this fixed instead of mentioned in the release notes ;-)

gdha commented at 2015-09-23 11:36:

fills up the queue and nothings has been done - so better close it for now

[Export of Github issue for rear/rear.]