#3178 Issue closed: rear does not recognize nvme when trying to format it with "rear format"¶
Labels: enhancement, fixed / solved / done, ready-to-close?
xwhitebeltx opened issue at 2024-03-12 15:22:¶
- ReaR version ("/usr/sbin/rear -V"):
Relax-and-Recover 2.7-git.5396.573f7f01.master / 2024-03-08
-
If your ReaR version is not the current version, explain why you can't upgrade:
-
OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):
PRETTY_NAME="Ubuntu 22.04.4 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.4 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy
- ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
OUTPUT=USB
BACKUP=NETFS
BACKUP_URL=usb:///dev/disk/by-label/REAR-000
ONLY_INCLUDE_VG=( "system" )
USB_UEFI_PART_SIZE="1000"
KERNEL_CMDLINE="noip unattended"
USER_INPUT_TIMEOUT=15
USB_RETAIN_BACKUP_NR=1
COPY_AS_IS+=( /usr/local/bin )
- Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR):
HP ProLiant DL385 Gen11
- System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
x86 compatible
- Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
UEFI
GRUB
- Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
2xlocal Micron 960GB NVMe SSD
- Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):
NAME KNAME PKNAME TRAN TYPE FSTYPE LABEL SIZE MOUNTPOINT
/dev/loop0 /dev/loop0 loop squashfs 63.3M /snap/core20/1879
/dev/loop1 /dev/loop1 loop squashfs 63.9M /snap/core20/2182
/dev/loop2 /dev/loop2 loop squashfs 111.9M /snap/lxd/24322
/dev/loop3 /dev/loop3 loop squashfs 87M /snap/lxd/27428
/dev/loop4 /dev/loop4 loop squashfs 70.2M /snap/powershell/264
/dev/loop5 /dev/loop5 loop squashfs 53.2M /snap/snapd/19122
/dev/loop6 /dev/loop6 loop squashfs 39.1M /snap/snapd/21184
/dev/nvme1n1 /dev/nvme1n1 nvme disk 894.3G
|-/dev/nvme1n1p1 /dev/nvme1n1p1 /dev/nvme1n1 nvme part vfat 1G /boot/efi
|-/dev/nvme1n1p2 /dev/nvme1n1p2 /dev/nvme1n1 nvme part ext4 2G /boot
`-/dev/nvme1n1p3 /dev/nvme1n1p3 /dev/nvme1n1 nvme part LVM2_member 891.2G
`-/dev/mapper/system-root /dev/dm-0 /dev/nvme1n1p3 lvm ext4 891.2G /
/dev/nvme0n1 /dev/nvme0n1 nvme disk ext4 894.3G
- Description of the issue (ideally so that others can reproduce it):
executing "rear -v format -- --efi /dev/nvme0n1" returns this error:
Relax-and-Recover 2.7-git.5396.573f7f01.master / 2024-03-08
Running rear format (PID 24112 date 2024-03-12 15:15:12)
Using log file: /var/log/rear/rear-avpukr.log
Running workflow format on the normal/original system
ERROR:
====================
BUG in /usr/share/rear/format/USB/default/200_check_usb_layout.sh line 28:
Unable to determine raw device for /dev/nvme0n1
--------------------
Please report it at https://github.com/rear/rear/issues
and include all related parts from /var/log/rear/rear-avpukr.log
preferably the whole debug information via 'rear -D format'
====================
Use debug mode '-d' for some debug messages or debugscript mode '-D' for full debug messages with 'set -x' output
Aborting due to an error, check /var/log/rear/rear-avpukr.log for details
Exiting rear format (PID 24112) and its descendant processes ...
Running exit tasks
Terminated
- Workaround, if any:
nothing that i could find
- Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):
[rear-avpukr.log](https://github.com/rear/rear/files/14574841/rear-avpukr.log)
You can drag-drop log files into this editor to create an attachment
or paste verbatim text like command output or file content
by including it between a leading and a closing line of
three backticks like this:
verbatim content
gdha commented at 2024-03-18 16:46:¶
@xwhitebeltx Why do you want to treat a Micron 960GB NVMe SSD as an USB
device? I guess you want to make a bootable UEFI device? Remember, a
local SSD device is not safe to keep ReaR archives on.
@rear/contributors This is something we haven't foreseen so far (I
think, but could be wrong [again])?
pcahyna commented at 2024-03-18 16:53:¶
@gdha in real use this is indeed unusual. For testing it is useful
though to treat NVMe as any other disk device - you can take a machine
with a secondary NVMe device, make a backup to it as if it were USB, and
boot from it for recovery.
(yes, it is more realistic to test on a machine with a secondary USB
disk, or at least a SCSI or SATA disk since it also presents itself as a
sd* block device, but a machine with NVMe may be the only thing you
have)
schlomo commented at 2024-03-18 17:07:¶
Any thoughts why we can't use find_device here?
https://github.com/rear/rear/blob/2073e77f1ed213653bbf846d67bef346a9f65da9/usr/share/rear/format/USB/default/200_check_usb_layout.sh#L12-L13
It seems to me like our code simply doesn't handle the nvme use case
yet, it assumes a sysfs device path like
/devices/pci0000:00/0000:00:10.0/host2/target2:0:1/2:0:1:0/block/sdb/sdb1
whereas in your example we have
devices/pci0000:c0/0000:c0:03.3/0000:c5:00.0/nvme/nvme0/nvme0n1
@xwhitebeltx have you tried creating a partition and specifying that instead of the whole disk?
xwhitebeltx commented at 2024-03-18 17:52:¶
thank you all for your responses!
@gdha - we do as @pcahyna suggested, i have 2 local NVMes:
- OS
- backup drive i can boot from and restore the OS back to its original
state
in this case the main purpose is not backup of critical data, it is to be able to "reset" the server anytime we want with an automated boot + restore process, in places where PXE is banned.
@schlomo - it works fine when the SSD is SATA, first time i'm trying
that on an NVMe,
i have not tried creating a partition, i'll try tomorrow morning and
update =)
xwhitebeltx commented at 2024-03-19 07:33:¶
well, it worked but it ignored the partition(which is totally good for me), the initial state was this:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 63.3M 1 loop /snap/core20/1879
loop1 7:1 0 63.9M 1 loop /snap/core20/2182
loop2 7:2 0 111.9M 1 loop /snap/lxd/24322
loop3 7:3 0 87M 1 loop /snap/lxd/27428
loop4 7:4 0 70.2M 1 loop /snap/powershell/264
loop5 7:5 0 53.2M 1 loop /snap/snapd/19122
loop6 7:6 0 39.1M 1 loop /snap/snapd/21184
nvme1n1 259:0 0 894.3G 0 disk
├─nvme1n1p1 259:2 0 1G 0 part /boot/efi
├─nvme1n1p2 259:3 0 2G 0 part /boot
└─nvme1n1p3 259:4 0 891.2G 0 part
└─system-root 253:0 0 891.2G 0 lvm /
nvme0n1 259:1 0 894.3G 0 disk
└─nvme0n1p1 259:6 0 894.3G 0 part
after i executed "rear -v format -- --efi /dev/nvme0n1p1" i got this output:
root@avpukr:~# rear -v format -- --efi /dev/nvme0n1p1
Relax-and-Recover 2.7-git.5396.573f7f01.master / 2024-03-08
Running rear format (PID 222220 date 2024-03-19 06:56:31)
Using log file: /var/log/rear/rear-avpukr.log
Running workflow format on the normal/original system
USB or disk device /dev/nvme0n1p1 is not formatted with ext2/3/4 or btrfs filesystem
Formatting /dev/nvme0n1p1 will remove all currently existing data on that whole device
Type exactly 'Yes' to format /dev/nvme0n1p1 with ext3 filesystem
(default 'No' timeout 15 seconds)
Yes
Repartitioning /dev/nvme0n1
Creating partition table of type gpt on /dev/nvme0n1
Making an EFI bootable device /dev/nvme0n1
Creating EFI system partition /dev/nvme0n11 with size 1000 MiB aligned at 8 MiB
Setting 'esp' flag on EFI partition /dev/nvme0n11
Creating ReaR data partition /dev/nvme0n12 up to 100% of /dev/nvme0n1
Setting 'legacy_boot' flag on ReaR data partition /dev/nvme0n12
Creating vfat filesystem on EFI system partition on /dev/nvme0n1p1
Creating ext3 filesystem with label 'REAR-000' on ReaR data partition /dev/nvme0n1p2
Adjusting filesystem parameters on ReaR data partition /dev/nvme0n1p2
Exiting rear format (PID 222220) and its descendant processes ...
Running exit tasks
and then the disk structure is as following:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 63.3M 1 loop /snap/core20/1879
loop1 7:1 0 63.9M 1 loop /snap/core20/2182
loop2 7:2 0 111.9M 1 loop /snap/lxd/24322
loop3 7:3 0 87M 1 loop /snap/lxd/27428
loop4 7:4 0 70.2M 1 loop /snap/powershell/264
loop5 7:5 0 53.2M 1 loop /snap/snapd/19122
loop6 7:6 0 39.1M 1 loop /snap/snapd/21184
nvme1n1 259:0 0 894.3G 0 disk
├─nvme1n1p1 259:2 0 1G 0 part /boot/efi
├─nvme1n1p2 259:3 0 2G 0 part /boot
└─nvme1n1p3 259:4 0 891.2G 0 part
└─system-root 253:0 0 891.2G 0 lvm /
nvme0n1 259:1 0 894.3G 0 disk
├─nvme0n1p1 259:5 0 1000M 0 part
└─nvme0n1p2 259:6 0 893.3G 0 part
i've performed a backup with "rear -v mkbackup"
and i've restored it successfully!
there's one unexpected screen which i'm not sure yet what's happening
there and if it's related to rear or not,
actions i took:
- reboot
- F11 for boot menu
- choose the REAR-000 NVMe Drive
- this screen pops up:
and then the rear grub menu, from there it all seems to be working fine
thanks for the workaround! is this something you would consider implementing in future releases? treating NVMe devices as USB?
jsmeix commented at 2024-03-19 08:22:¶
@xwhitebeltx
that "unexpected screen" was implemeted by me via
https://github.com/rear/rear/commit/a0a6429119bc284fcf93775bd579bcd74d1c3b40
see also
https://github.com/rear/rear/pull/3025#issuecomment-1634068353
Actually there is no new screen.
It is a timeout delay on the normal initial GRUB screen
(without timeout it shows up only for a fraction of a second)
before GRUB replaces it with its boot menu screen.
With the timeout delay you can see and even read
what GRUB shows (in particular possible error messages)
which helps to understand why GRUB fails when it fails
(e.g. it fails when a wrong 'root' device is used).
xwhitebeltx commented at 2024-03-19 09:32:¶
@jsmeix oh, nice =)
thank you very much,
i'm sorry for the silly question but this is my first time reporting a
bug in github,
please tell me should i close it as resolved (workaround provided) or do
you want to leave it open until it is fixed?
what is the proper conduct?
jsmeix commented at 2024-03-19 09:38:¶
@xwhitebeltx
don't worry how you may close it "correctly".
Leave that "problem" to us.
Personally I would like to fix it but unfortunately
too often I don't find the needed time for it,
too much other stuff elsewhere :-(
I would like to keep it open for some time,
hope dies last :-)
github-actions commented at 2024-05-19 02:11:¶
Stale issue message
github-actions commented at 2024-07-21 02:25:¶
Stale issue message
gdha commented at 2024-09-05 08:16:¶
@rear/contributors milestone is still 'ReaR v2.8' - please adjust as you think it best fits (v3.0 or v3.1). Thanks.
gdha commented at 2024-09-10 11:52:¶
@xwhitebeltx with PR #3312 merged could you perform a test within your environment so we are sure it works as it should?
xwhitebeltx commented at 2024-09-11 06:58:¶
of course, i'd be honored to !
seems to be working fine, see attached picture:
jsmeix commented at 2024-09-11 07:15:¶
@xwhitebeltx
thank you for your prompt test and in particular
for your screenshot that shows us how things
behave on your particular system!
To be a bit more on the safe side:
Could you please also test that
with your new formatted NVMe disk
"rear mkbackup" still works for you?
Thank you in advance!
To be really on the safe side
you would also have to test
on separated test hardware with UEFI
that you can boot the ReaR recovery system
from your new formatted NVMe disk
with your new "rear mkbackup" on it
and that then also "rear recover" works.
The problem here is that you would have
to remove the NVMe disk from the current hardware
and place it into the separated test hardware
so I think this test cannot be done in practice
with reasonable effort?
But in general you must do a "rear recover" test,
cf. the section "No disaster recovery without testing
and continuous validation" in
https://en.opensuse.org/SDB:Disaster_Recovery
In
https://github.com/rear/rear/issues/3178#issuecomment-2004573795
you wrote
the main purpose is not backup of critical data,
it is to be able to "reset" the server
Perhaps you have more such server machines
so that you have a separated test server
where you can verify that the whole
"rear format" "rear mkbackup" "rear recover"
process works for you as you need it?
xwhitebeltx commented at 2024-09-11 14:08:¶
yes, i have the setup you are describing, many identical physical
servers,
my next update cycle is ~2 weeks away,
using the latest rear version from github - i will format the NVMe
drive, backup the OS, take the drive to a different physical server and
try to restore, i will update when done =)
do you need any of the logs from that process?
jsmeix commented at 2024-09-12 07:36:¶
@xwhitebeltx
when all works well for you I don't need logs.
But in particular when "rear recover" fails
or when the recreated system fails to boot,
then see the section
"Debugging issues with Relax-and-Recover" in
https://en.opensuse.org/SDB:Disaster_Recovery
what info and logs help to find the root cause
in addition to what we usually ask for via our
https://github.com/rear/rear/blob/master/.github/ISSUE_TEMPLATE.md
When your only intent is to "reset" the server
(i.e. recreate it on its exact same hardware),
then you may only verify that this works.
But when you also intend to recreate on replacement hardware,
you should also verify that it also works when you remove
the ReaR NVMe drive from the original server hardware and
place it into replacement hardware.
To be more on the safe side that "rear recover"
can work without unexpected issues, see the section
"Prepare replacement hardware for disaster recovery" in
https://en.opensuse.org/SDB:Disaster_Recovery
In current ReaR there is DISKS_TO_BE_WIPED
(see its description in usr/share/rear/conf/default.conf)
which mitigates possible issues for "rear recover"
on already used disks (which happen in particular when
"rear recover" is run on the original system hardware)
but DISKS_TO_BE_WIPED cannot fully clean used disks
(because that needs too much time during "rear recover").
For some background information see
https://raw.githubusercontent.com/rear/rear/master/usr/share/rear/layout/recreate/default/README.wipe_disks
xwhitebeltx commented at 2024-10-01 01:36:¶
Hello again =)
today i downloaded the latest rear, and attempted a backup & restore
process from one server to a different server with the same hardware
layout, the backup drive in this test is not NVMe, it is a SATA drive,
but still i wanted to share some issues i encountered:
lsblk output, i use /dev/sda as my backup drive, nvme0n1 is the OS drive
and nvme1n1 should be irrelevant for this process:
although the lsblk output of the second server is identical, in the rear
recovery environment the drives were "swapped",
nvme0n1 was the 3.5TB drive and nvme1n1 was the 960GB drive,
so rear tried to recover the system to the 3.5TB drive instead of the
960GB drive (see the attempted partitions):
and see the rear recovery disk state + error:
i used the rear menu to edit the disk configuration layout, used
:%s/nvme0n1/nvme1n1/g to substitute all strings,
resumed recovery,
got another error which i cannot find in the logs,
resumed recovery again by clicking option "8 - Confirm what is currently
on the disks and continue 'rear recover' " - and then it was successful,
i double checked to make sure identical means identical, both servers
show this in the bios screen:
is there an unattended way to handle such a scenario where disks get
swapped in the recovery stage ?
are you perhaps using modified udev rules for rear recovery environment?
another minor issue is:
using USE_RESOLV_CONF="no" is not working (neither for the format nor
the mkbackup) although documentation suggests that it should accept this
value , after several attempts USE_RESOLV_CONF=("no") seemed to work,
is that the correct way?
/etc/rear/local.conf + error message:
in the upcoming days i will be performing the same routine for servers with NVMe, and i will post the results here as well =)
xwhitebeltx commented at 2024-10-06 23:51:¶
Hi @jsmeix ,
i started the backup/restore for the server with the NVMe using the
latest rear version and i think there's something wrong with the format,
OS version:
Kernel version: 5.15.0-25-generic
i usually use the command:
rear -v format -- --efi /dev/nvme0n1
when nvme0n1 had the pre-defined partitions (see below lsblk output):
the format worked fine,
but i wanted to extend the test, so i performed:
mkfs.ext4 /dev/nvme0n1
in order to make the SSD blank as if it was new,
so now my lsblk output looks like this:
after that the same rear format command does not work:
this is the entire content of /var/log/rear/reartest.log (i'm sorry for
the screenshots but my environment makes it hard for me to copy/paste
text):
output of "rear -v -s format -- --efi /dev/nvme0n1" :
/etc/rear/local.conf was empty when i tested,
i also tried adding DISKS_TO_BE_WIPED="/dev/nvme0n1" in case it
somehow matters,
please let me know if you need any more inputs/logs,
xwhitebeltx commented at 2024-10-07 11:01:¶
update:
performing "wipefs -a /dev/nvme0n1" before the "rear format" command
seemed to do the trick,
below screenshot shows how it's not working before, and working after, i
don't know if this is intended or not:
i will resume the restore process on different server with the same hardware and update results here,
schlomo commented at 2024-10-07 11:07:¶
@xwhitebeltx very interesting screenshot. ReaR seems to fail without clearly indicating a failure or error, which might be an additional problem that you happened to uncover.
xwhitebeltx commented at 2024-10-07 11:13:¶
@schlomo indeed, and it is easy to reproduce, just mkfs.ext4 on the NVMe drive and try to format it with rear =)
can you comment about the disk swapping in the rear recover environment? do you think is it a rear issue or an OS/HW issue?
schlomo commented at 2024-10-07 12:33:¶
@xwhitebeltx sorry, no idea about the NVMe disk ordering problem, I
guess you could try to see what is going on via digging deeper into the
/sys paths for both devices and looking for the proverbial difference.
Udev related troubles could also show up in udevadm info, especially
when comparing the device IDs.
In the end, however, it is most likely a case of "works as designed", see also https://www.reddit.com/r/archlinux/comments/15qah19/nvme_drives_constantly_swapping_names_at_each/ for more details.
xwhitebeltx commented at 2024-10-11 23:14:¶
Thanks @schlomo,
an update:
with the latest rear - i performed a backup of a server into an NVMe
drive, and successfully restored to a different server with the same
hardware (restore was done from an NVMe as well),
thanks!
gdha commented at 2025-01-15 13:54:¶
@xwhitebeltx Will try it out tomorrow (https://github.com/rear/rear/issues/3178#issuecomment-2396602455) and see what happens.
gdha commented at 2025-01-20 15:24:¶
Device /dev/nvme7n1 was previously already format with 2 partitions - when we try to format we get:
#-> rear -vD format -- --efi /dev/nvme7n1
Relax-and-Recover 2.6 / 2020-06-17
Running rear format (PID 567867)
Using log file: /var/log/rear/rear-AWSABLIRLL000K.log
Running workflow format on the normal/original system
USB or disk device /dev/nvme7n1 is not formatted with ext2/3/4 or btrfs filesystem
Formatting /dev/nvme7n1 will remove all currently existing data on that whole device
UserInput -I USB_DEVICE_CONFIRM_FORMAT needed in /usr/share/rear/format/USB/default/200_check_usb_layout.sh line 78
Type exactly 'Yes' to format /dev/nvme7n1 with ext3 filesystem
(default 'No' timeout 300 seconds)
Yes
UserInput: No choices - result is 'Yes'
Exiting rear format (PID 567867) and its descendant processes ...
Running exit tasks
You should also rm -Rf --one-file-system /var/tmp/rear.xuMRgBI3sFEFzwT
[root@AWSABLIRLL000K:/home/gdhaese1]#
#-> parted /dev/nvme7n1 print
Model: Amazon Elastic Block Store (nvme)
Disk /dev/nvme7n1: 10.7GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 8389kB 1082MB 1074MB fat32 primary boot, esp
2 1082MB 10.7GB 9654MB ext3 primary legacy_boot
And, the log file contains:
2025-01-20 16:48:39.913783119 Including format/USB/default/200_check_usb_layout.sh
2025-01-20 16:48:39.915427625 Entering debugscript mode via 'set -x'.
+ source /usr/share/rear/format/USB/default/200_check_usb_layout.sh
++ test /dev/nvme7n1
++ test -b /dev/nvme7n1
+++ readlink -f /dev/nvme7n1
++ REAL_USB_DEVICE=/dev/nvme7n1
++ test -b /dev/nvme7n1
+++++ my_udevinfo -q path -n /dev/nvme7n1
+++++ has_binary udevadm
+++++ for bin in $@
+++++ type udevadm
+++++ return 0
+++++ udevadm info -q path -n /dev/nvme7n1
+++++ return 0
++++ dirname /devices/pci0000:01/0000:01:00.0/0000:02:00.0/0000:03:03.1/0000:1d:00.0/nvme/nvme7/nvme7n1
+++ basename /devices/pci0000:01/0000:01:00.0/0000:02:00.0/0000:03:03.1/0000:1d:00.0/nvme/nvme7
++ TEMP_USB_DEVICE=nvme7
++ [[ nvme7 == \b\l\o\c\k ]]
++ [[ -n nvme7 ]]
++ [[ -b /dev/nvme7 ]]
++ [[ -n nvme7 ]]
++ [[ -d /sys/block/nvme7 ]]
++ [[ -z nvme7 ]]
+++ lsblk -r -o NAME,KNAME,TYPE,PKNAME
+++ grep part
++++ basename /dev/nvme7n1
+++ grep nvme7n1
++ [[ -n nvme7n1p1 nvme7n1p1 part nvme7n1
nvme7n1p2 nvme7n1p2 part nvme7n1 ]]
+++ lsblk -r -o NAME,KNAME,TYPE,PKNAME
++++ basename /dev/nvme7n1
+++ awk '{print $4}'
+++ grep part
+++ uniq
+++ grep nvme7n1
++ RAW_USB_DEVICE=/dev/nvme7n1
++ test -b /dev/nvme7n1
++ USB_FORMAT_ANSWER=
++ case "$USB_DEVICE_FILESYSTEM" in
++ :
+++ file -sbL /dev/nvme7n1
++ local 'file_output=DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 20971519 sectors, extended partition table (last)'
so, it works fine with the ReaR master code (aka 2.8)
xwhitebeltx commented at 2025-01-22 07:41:¶
Hi @gdha ,
this was not the issue,
to replicate it please do the following:
- execute "mkfs.ext4 /dev/nvme7n1" to create an ext4 filesystem on the NVMe drive (thus removing the existing partitions)
- try to format using "rear -v format -- --efi /dev/nvme7n1"
this is what gave the weird result,
EDIT: i've taken the time to replicate the issue with latest rear v2.8
Stage 1: i have a partitioned disk /dev/nvme1n1 , i'm executing mkfs.ext4 on it:
Stage 2: i show the new lsblk output and try to execute rear format:
as you can see, the disk was not formatted and REAR did not output any
error,
this is the additional problem @schlomo said i uncovered by accident
https://github.com/rear/rear/issues/3178#issuecomment-2396615039
gdha commented at 2025-01-27 15:18:¶
@xwhitebeltx You are absolutely right! I could reproduce the issue. We
should give an error when partition 1 is already formatted with ext*
file system and give some advise. Secondly, noticed that the label
script also has a minor issue. I will fix this together after we release
ReaR v2.9 (soon to fix an upgrade issue with ReaR 2.8).
gdha commented at 2025-01-27 15:29:¶
Prepare the test with a device with partition 1 with fs ext4 type:
#-> mkfs.ext4 /dev/nvme7n1
mke2fs 1.46.5 (30-Dec-2021)
Found a gpt partition table in /dev/nvme7n1
Proceed anyway? (y,N) y
Creating filesystem with 2621440 4k blocks and 655360 inodes
Filesystem UUID: 26f02685-01dd-469b-b38a-585929e75fda
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
Allocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done
Try to format it for EFI booting and with a ReaR data partition (REAR-000):
#-> usr/sbin/rear -D format -- --efi /dev/nvme7n1
Relax-and-Recover 2.8 / 2024-12-19
Running rear format (PID 3210846 date 2025-01-27 16:20:56)
Command line options: usr/sbin/rear -D format -- --efi /dev/nvme7n1
Using log file: /home/gdhaese1/projects/rear/var/log/rear/rear-AWSABLIRLL000K.log
Using build area: /var/tmp/rear.7dfZFihq4lvXfJw
Setting TMPDIR to ReaR's '/var/tmp/rear.7dfZFihq4lvXfJw/tmp' (was unset when ReaR was launched)
Running 'init' stage ======================
Running workflow format on the normal/original system
Running 'format' stage ======================
ERROR: USB or disk device /dev/nvme7n1 is already formatted as ext4. Add option "--yes" to override.
Some latest log messages since the last called script 200_check_usb_layout.sh:
2025-01-27 16:20:57.553722678 Entering debugscript mode via 'set -x'.
Aborting due to an error, check /home/gdhaese1/projects/rear/var/log/rear/rear-AWSABLIRLL000K.log for details
Exiting rear format (PID 3210846) and its descendant processes ...
Running exit tasks
To remove the build area you may use (with caution): rm -Rf --one-file-system /var/tmp/rear.7dfZFihq4lvXfJw
Terminated
And now with extra --yes option:
#-> usr/sbin/rear -D format -- --efi /dev/nvme7n1 --yes
Relax-and-Recover 2.8 / 2024-12-19
Running rear format (PID 3215265 date 2025-01-27 16:21:03)
Command line options: usr/sbin/rear -D format -- --efi /dev/nvme7n1 --yes
Using log file: /home/gdhaese1/projects/rear/var/log/rear/rear-AWSABLIRLL000K.log
Using build area: /var/tmp/rear.0m1epE7oNK8ufiY
Setting TMPDIR to ReaR's '/var/tmp/rear.0m1epE7oNK8ufiY/tmp' (was unset when ReaR was launched)
Running 'init' stage ======================
Running workflow format on the normal/original system
Running 'format' stage ======================
Repartitioning /dev/nvme7n1
Creating partition table of type gpt on /dev/nvme7n1
Making an EFI bootable device /dev/nvme7n1
Creating EFI system partition 1 on device /dev/nvme7n1 with size 1024 MiB aligned at 8 MiB
Setting 'esp' flag on EFI partition 1 on device /dev/nvme7n1
Creating ReaR data partition 2 on /dev/nvme7n1 up to 100% of /dev/nvme7n1
Setting 'legacy_boot' flag on ReaR data partition 2 on device /dev/nvme7n1
Creating vfat filesystem on EFI system partition on /dev/nvme7n1p1
Creating ext3 filesystem with label 'REAR-000' on ReaR data partition /dev/nvme7n1p2
Adjusting filesystem parameters on ReaR data partition /dev/nvme7n1p2
Data partition /dev/nvme7n1p2 has filesystem label 'REAR-000'
Exiting rear format (PID 3215265) and its descendant processes ...
Running exit tasks
To remove the build area you may use (with caution): rm -Rf --one-file-system /var/tmp/rear.0m1epE7oNK8ufiY
Are the labels properly created?
#-> blkid -s LABEL -o value /dev/nvme7n1p1
REAR-EFI
#-> blkid -s LABEL -o value /dev/nvme7n1p2
REAR-000
[Export of Github issue for rear/rear.]