Re: [lustre-discuss] [EXTERNAL] Cannot mount MDT after upgrading from Lustre 2.12.6 to 2.15.3

[Mohr, Rick via lustre-discuss]

Typically after an upgrade you do not need to perform a writeconf.  Did you 
perform the writeconf only on the MDT?  If so, that could be your problem.  
When you do a writeconf to regenerate the lustre logs, you need to follow the 
whole procedure listed in the lustre manual.  You can try that to see if it 
fixes your issue.

--Rick

On 9/23/23, 2:22 PM, "lustre-discuss on behalf of Tung-Han Hsieh via 
lustre-discuss" mailto:lustre-discuss-boun...@lists.lustre.org> on behalf of 
lustre-discuss@lists.lustre.org > wrote:


Dear All,


Today we tried to upgrade Lustre file system from version 2.12.6 to 2.15.3. But 
after the work, we cannot mount MDT successfully. Our MDT is ldiskfs backend. 
The procedure of upgrade is




1. Install the new version of e2fsprogs-1.47.0
2. Install Lustre-2.15.3
3. After reboot, run: tunefs.lustre --writeconf /dev/md0




Then when mounting MDT, we got the error message in dmesg:




===
[11662.434724] LDISKFS-fs (md0): mounted filesystem with ordered data mode. 
Opts: user_xattr,errors=remount-ro,no_mbcache,nodelalloc
[11662.584593] Lustre: 3440:0:(scrub.c:189:scrub_file_load()) chome-MDT: 
reset scrub OI count for format change (LU-16655)
[11666.036253] Lustre: MGS: Logs for fs chome were removed by user request. All 
servers must be restarted in order to regenerate the logs: rc = 0
[11666.523144] Lustre: chome-MDT: Imperative Recovery not enabled, recovery 
window 300-900
[11666.594098] LustreError: 3440:0:(mdd_device.c:1355:mdd_prepare()) 
chome-MDD: get default LMV of root failed: rc = -2
[11666.594291] LustreError: 
3440:0:(obd_mount_server.c:2027:server_fill_super()) Unable to start targets: -2
[11666.594951] Lustre: Failing over chome-MDT
[11672.868438] Lustre: 3440:0:(client.c:2295:ptlrpc_expire_one_request()) @@@ 
Request sent has timed out for slow reply: [sent 1695492248/real 1695492248] 
req@5dfd9b53 x1777852464760768/t0(0) 
o251->MGC192.168.32.240@o2ib@0@lo:26/25 lens 224/224 e 0 to 1 dl 1695492254 ref 
2 fl Rpc:XNQr/0/ rc 0/-1 job:''
[11672.925905] Lustre: server umount chome-MDT complete
[11672.926036] LustreError: 3440:0:(super25.c:183:lustre_fill_super()) llite: 
Unable to mount : rc = -2
[11872.893970] LDISKFS-fs (md0): mounted filesystem with ordered data mode. 
Opts: (null)







Could anyone help to solve this problem ? Sorry that it is really urgent.




Thank you very much.




T.H.Hsieh





___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

Re: [lustre-discuss] [BULK] Re: [EXTERNAL] Re: Data recovery with lost MDT data

[Andreas Dilger via lustre-discuss]

Probably using "stat" on each file is slow, since this is getting the file size 
from each OST object. You could try the "xstat" utility in the lustre-tests RPM 
(or build it directly) as it will only query the MDS for the requested 
attributes (owner at minimum).

Then you could split into per-date directories in a separate phase, if needed, 
run in parallel.

I can't suggest anything about the 13M entry directory, but it _should_ be much 
faster than 1 file per 30s even at that size. I suspect that the script is 
still doing something bad, since shell and GNU utilities are terrible for doing 
extra stat/cd/etc five times on each file that is accessed, renamed, etc.

You would be better off to use "find -print" to generate the pathnames and then 
operate on those, maybe with "xargs -P" and/or run multiple scripts in parallel 
on chunks of the file?

Cheers, Andreas

On Sep 25, 2023, at 17:34, Vicker, Darby J. (JSC-EG111)[Jacobs Technology, 
Inc.]  wrote:


I’ve been attempting to move these lost+found files into subdirectories by user 
and date but I’m running into issues.

My initial attempt was to loop through each file in .lustre/lost+found, stat 
the file and then move it to a subdirectory.  However, both the stat and the 
move command are each taking about 30 seconds.  With 13 million files, this 
isn’t going to work as that would be about 25 years to organize the files. :)  
If it makes a difference, the bash script is simple:



source=/scratch-lustre/.lustre/lost+found/MDT
dest=/scratch-lustre/work

# Cd to the source
cd $source

# Loop through files
for file in * ; do
echo "file: $file"

echo "   stat-ing file"
time read -r user date time <<< $( stat --format "%U %y" $file )
echo "   user='$user' date='$date' time='$time'"

# Build the new destination in the user's directory
newdir=$dest/$user/lost+found/$date
echo "   newdir=$newdir"

echo "   checking/making direcotry"
if [ ! -d $newdir ] ; then
time mkdir -p $newdir
time chown ${user}: $newdir
fi

echo "   moving file"
time mv $file $newdir
done


I’m pretty sure the time to operate on these files is due to the very large 
number of files in a single directory.  But confirmation of that would be good. 
 I say that because I know too many files in a single directory can cause 
filesystem performance issues.  But also, the few files I have moved out of 
lost+found, I can stat and otherwise operate on very quickly.

My next attempt was to move each file into pre-created subdirectories (this 
eliminates the stat).  But again, this was serial and each move is 
(unsurprisingly) taking 30 seconds.  “Only” 12.5 years to move the files.  :)

I’m currently attempting to speed this up by getting the entire file list (all 
13e6 files) and moving groups of (10,000) files into a subdirectory at once 
(i.e. mv file1 file2 … fileN subdir1).  I’m hoping a group move is faster and 
more efficient than moving each file individually.  Seems like it should be.  
That attempt is running now and I’m waiting for the first command to complete 
so I don’t know if this is faster yet or not.  (More accurately, I’ve written 
this script in perl and I think the output is buffered so I’m waiting to the 
the first output.)

Other suggestions welcome if you have ideas how to move these files into 
subdirectories more efficiently.


From: lustre-discuss  on behalf of 
"Vicker, Darby J. (JSC-EG111)[Jacobs Technology, Inc.] via lustre-discuss" 

Reply-To: "Vicker, Darby J. (JSC-EG111)[Jacobs Technology, Inc.]" 

Date: Monday, September 25, 2023 at 8:56 AM
To: Andreas Dilger 
Cc: "lustre-discuss@lists.lustre.org" 
Subject: Re: [lustre-discuss] [BULK] Re: [EXTERNAL] Re: Data recovery with lost 
MDT data

Our lfsck finished.  It repair a lot and we have over 13 million files in 
lost+found to go through.  I'll be writing a script to move these to somewhere 
accessible by the users and grouped by owner and probably date too (trying not 
to get too many files in a single directory).  Thanks again for the help with 
this.


For the benefit of others, this is how we started our lfsck:

[root@hpfs-fsl-mds1 hpfs3-eg3]# lctl set_param printk=+lfsck
[root@hpfs-fsl-mds1 hpfs3-eg3]# lctl lfsck_start -M scratch-MDT -o
Started LFSCK on the device scratch-MDT: scrub layout namespace
[root@hpfs-fsl-mds1 hpfs3-eg3]#



It took most of the weekend to run.  Here are the results.



[root@hpfs-fsl-mds1 ~]# lctl lfsck_query -M scratch-MDT

layout_mdts_init: 0

layout_mdts_scanning-phase1: 0

layout_mdts_scanning-phase2: 0

layout_mdts_completed: 1

layout_mdts_failed: 0

layout_mdts_stopped: 0

layout_mdts_paused: 0

layout_mdts_crashed: 0

layout_mdts_partial: 0

layout_mdts_co-failed: 0

layout_mdts_co-stopped: 0

layout_mdts_co-paused: 0

layout_mdts_unknown: 0

layout_osts_init: 0

layout_osts_scanning-phase1: 0

layout_osts_scanning-phase2: 0

layout_osts_completed: 22

layout_osts_failed: 0

layout_osts_stopped: 0

Re: [lustre-discuss] [BULK] Re: [EXTERNAL] Re: Data recovery with lost MDT data

[Vicker, Darby J. (JSC-EG111)[Jacobs Technology, Inc.] via lustre-discuss]

I’ve been attempting to move these lost+found files into subdirectories by user 
and date but I’m running into issues.

My initial attempt was to loop through each file in .lustre/lost+found, stat 
the file and then move it to a subdirectory.  However, both the stat and the 
move command are each taking about 30 seconds.  With 13 million files, this 
isn’t going to work as that would be about 25 years to organize the files. :)  
If it makes a difference, the bash script is simple:



source=/scratch-lustre/.lustre/lost+found/MDT
dest=/scratch-lustre/work

# Cd to the source
cd $source

# Loop through files
for file in * ; do
echo "file: $file"

echo "   stat-ing file"
time read -r user date time <<< $( stat --format "%U %y" $file )
echo "   user='$user' date='$date' time='$time'"

# Build the new destination in the user's directory
newdir=$dest/$user/lost+found/$date
echo "   newdir=$newdir"

echo "   checking/making direcotry"
if [ ! -d $newdir ] ; then
time mkdir -p $newdir
time chown ${user}: $newdir
fi

echo "   moving file"
time mv $file $newdir
done


I’m pretty sure the time to operate on these files is due to the very large 
number of files in a single directory.  But confirmation of that would be good. 
 I say that because I know too many files in a single directory can cause 
filesystem performance issues.  But also, the few files I have moved out of 
lost+found, I can stat and otherwise operate on very quickly.

My next attempt was to move each file into pre-created subdirectories (this 
eliminates the stat).  But again, this was serial and each move is 
(unsurprisingly) taking 30 seconds.  “Only” 12.5 years to move the files.  :)

I’m currently attempting to speed this up by getting the entire file list (all 
13e6 files) and moving groups of (10,000) files into a subdirectory at once 
(i.e. mv file1 file2 … fileN subdir1).  I’m hoping a group move is faster and 
more efficient than moving each file individually.  Seems like it should be.  
That attempt is running now and I’m waiting for the first command to complete 
so I don’t know if this is faster yet or not.  (More accurately, I’ve written 
this script in perl and I think the output is buffered so I’m waiting to the 
the first output.)

Other suggestions welcome if you have ideas how to move these files into 
subdirectories more efficiently.


From: lustre-discuss  on behalf of 
"Vicker, Darby J. (JSC-EG111)[Jacobs Technology, Inc.] via lustre-discuss" 

Reply-To: "Vicker, Darby J. (JSC-EG111)[Jacobs Technology, Inc.]" 

Date: Monday, September 25, 2023 at 8:56 AM
To: Andreas Dilger 
Cc: "lustre-discuss@lists.lustre.org" 
Subject: Re: [lustre-discuss] [BULK] Re: [EXTERNAL] Re: Data recovery with lost 
MDT data

Our lfsck finished.  It repair a lot and we have over 13 million files in 
lost+found to go through.  I'll be writing a script to move these to somewhere 
accessible by the users and grouped by owner and probably date too (trying not 
to get too many files in a single directory).  Thanks again for the help with 
this.


For the benefit of others, this is how we started our lfsck:

[root@hpfs-fsl-mds1 hpfs3-eg3]# lctl set_param printk=+lfsck
[root@hpfs-fsl-mds1 hpfs3-eg3]# lctl lfsck_start -M scratch-MDT -o
Started LFSCK on the device scratch-MDT: scrub layout namespace
[root@hpfs-fsl-mds1 hpfs3-eg3]#



It took most of the weekend to run.  Here are the results.



[root@hpfs-fsl-mds1 ~]# lctl lfsck_query -M scratch-MDT

layout_mdts_init: 0

layout_mdts_scanning-phase1: 0

layout_mdts_scanning-phase2: 0

layout_mdts_completed: 1

layout_mdts_failed: 0

layout_mdts_stopped: 0

layout_mdts_paused: 0

layout_mdts_crashed: 0

layout_mdts_partial: 0

layout_mdts_co-failed: 0

layout_mdts_co-stopped: 0

layout_mdts_co-paused: 0

layout_mdts_unknown: 0

layout_osts_init: 0

layout_osts_scanning-phase1: 0

layout_osts_scanning-phase2: 0

layout_osts_completed: 22

layout_osts_failed: 0

layout_osts_stopped: 0

layout_osts_paused: 0

layout_osts_crashed: 0

layout_osts_partial: 2

layout_osts_co-failed: 0

layout_osts_co-stopped: 0

layout_osts_co-paused: 0

layout_osts_unknown: 0

layout_repaired: 38587653

namespace_mdts_init: 0

namespace_mdts_scanning-phase1: 0

namespace_mdts_scanning-phase2: 0

namespace_mdts_completed: 1

namespace_mdts_failed: 0

namespace_mdts_stopped: 0

namespace_mdts_paused: 0

namespace_mdts_crashed: 0

namespace_mdts_partial: 0

namespace_mdts_co-failed: 0

namespace_mdts_co-stopped: 0

namespace_mdts_co-paused: 0

namespace_mdts_unknown: 0

namespace_osts_init: 0

namespace_osts_scanning-phase1: 0

namespace_osts_scanning-phase2: 0

namespace_osts_completed: 0

namespace_osts_failed: 0

namespace_osts_stopped: 0

namespace_osts_paused: 0

namespace_osts_crashed: 0

namespace_osts_partial: 0

namespace_osts_co-failed: 0

namespace_osts_co-stopped: 0

namespace_osts_co-paused: 0

namespace_osts_unknown: 0

namespace_repaired: 1429495

Re: [lustre-discuss] [BULK] Re: [EXTERNAL] Re: Data recovery with lost MDT data

[Vicker, Darby J. (JSC-EG111)[Jacobs Technology, Inc.] via lustre-discuss]

Our lfsck finished.  It repair a lot and we have over 13 million files in 
lost+found to go through.  I'll be writing a script to move these to somewhere 
accessible by the users and grouped by owner and probably date too (trying not 
to get too many files in a single directory).  Thanks again for the help with 
this.


For the benefit of others, this is how we started our lfsck:

[root@hpfs-fsl-mds1 hpfs3-eg3]# lctl set_param printk=+lfsck
[root@hpfs-fsl-mds1 hpfs3-eg3]# lctl lfsck_start -M scratch-MDT -o
Started LFSCK on the device scratch-MDT: scrub layout namespace
[root@hpfs-fsl-mds1 hpfs3-eg3]#



It took most of the weekend to run.  Here are the results.



[root@hpfs-fsl-mds1 ~]# lctl lfsck_query -M scratch-MDT

layout_mdts_init: 0

layout_mdts_scanning-phase1: 0

layout_mdts_scanning-phase2: 0

layout_mdts_completed: 1

layout_mdts_failed: 0

layout_mdts_stopped: 0

layout_mdts_paused: 0

layout_mdts_crashed: 0

layout_mdts_partial: 0

layout_mdts_co-failed: 0

layout_mdts_co-stopped: 0

layout_mdts_co-paused: 0

layout_mdts_unknown: 0

layout_osts_init: 0

layout_osts_scanning-phase1: 0

layout_osts_scanning-phase2: 0

layout_osts_completed: 22

layout_osts_failed: 0

layout_osts_stopped: 0

layout_osts_paused: 0

layout_osts_crashed: 0

layout_osts_partial: 2

layout_osts_co-failed: 0

layout_osts_co-stopped: 0

layout_osts_co-paused: 0

layout_osts_unknown: 0

layout_repaired: 38587653

namespace_mdts_init: 0

namespace_mdts_scanning-phase1: 0

namespace_mdts_scanning-phase2: 0

namespace_mdts_completed: 1

namespace_mdts_failed: 0

namespace_mdts_stopped: 0

namespace_mdts_paused: 0

namespace_mdts_crashed: 0

namespace_mdts_partial: 0

namespace_mdts_co-failed: 0

namespace_mdts_co-stopped: 0

namespace_mdts_co-paused: 0

namespace_mdts_unknown: 0

namespace_osts_init: 0

namespace_osts_scanning-phase1: 0

namespace_osts_scanning-phase2: 0

namespace_osts_completed: 0

namespace_osts_failed: 0

namespace_osts_stopped: 0

namespace_osts_paused: 0

namespace_osts_crashed: 0

namespace_osts_partial: 0

namespace_osts_co-failed: 0

namespace_osts_co-stopped: 0

namespace_osts_co-paused: 0

namespace_osts_unknown: 0

namespace_repaired: 1429495

[root@hpfs-fsl-mds1 ~]# lctl get_param -n mdd.scratch-MDT.lfsck_layout

name: lfsck_layout

magic: 0xb1732fed

version: 2

status: completed

flags:

param: all_targets,orphan

last_completed_time: 1695615657

time_since_last_completed: 35014 seconds

latest_start_time: 1695335260

time_since_latest_start: 315411 seconds

last_checkpoint_time: 1695615657

time_since_last_checkpoint: 35014 seconds

latest_start_position: 15

last_checkpoint_position: 1015668480

first_failure_position: 0

success_count: 2

repaired_dangling: 22199282

repaired_unmatched_pair: 0

repaired_multiple_referenced: 0

repaired_orphan: 13489715

repaired_inconsistent_owner: 2898656

repaired_others: 0

skipped: 0

failed_phase1: 0

failed_phase2: 1798679

checked_phase1: 369403698

checked_phase2: 15

run_time_phase1: 82842 seconds

run_time_phase2: 0 seconds

average_speed_phase1: 4459 items/sec

average_speed_phase2: 15 objs/sec

real_time_speed_phase1: N/A

real_time_speed_phase2: N/A

current_position: N/A

[root@hpfs-fsl-mds1 ~]# lctl get_param -n mdd.scratch-MDT.lfsck_namespace

name: lfsck_namespace

magic: 0xa06249ff

version: 2

status: completed

flags:

param: all_targets,orphan

last_completed_time: 1695419689

time_since_last_completed: 231012 seconds

latest_start_time: 1695335262

time_since_latest_start: 315439 seconds

last_checkpoint_time: 1695419689

time_since_last_checkpoint: 231012 seconds

latest_start_position: 15, N/A, N/A

last_checkpoint_position: 1015668480, N/A, N/A

first_failure_position: N/A, N/A, N/A

checked_phase1: 315743757

checked_phase2: 231782

updated_phase1: 1429495

updated_phase2: 0

failed_phase1: 0

failed_phase2: 0

directories: 15911850

dirent_repaired: 0

linkea_repaired: 1429495

nlinks_repaired: 0

multiple_linked_checked: 1983873

multiple_linked_repaired: 0

unknown_inconsistency: 0

unmatched_pairs_repaired: 0

dangling_repaired: 0

multiple_referenced_repaired: 0

bad_file_type_repaired: 0

lost_dirent_repaired: 0

local_lost_found_scanned: 0

local_lost_found_moved: 0

local_lost_found_skipped: 0

local_lost_found_failed: 0

striped_dirs_scanned: 0

striped_dirs_repaired: 0

striped_dirs_failed: 0

striped_dirs_disabled: 0

striped_dirs_skipped: 0

striped_shards_scanned: 0

striped_shards_repaired: 0

striped_shards_failed: 0

striped_shards_skipped: 0

name_hash_repaired: 0

linkea_overflow_cleared: 0

agent_entries_repaired: 0

success_count: 2

run_time_phase1: 82885 seconds

run_time_phase2: 1542 seconds

average_speed_phase1: 3809 items/sec

average_speed_phase2: 150 objs/sec

average_speed_total: 3742 items/sec

real_time_speed_phase1: N/A

real_time_speed_phase2: N/A

current_position: N/A

[root@hpfs-fsl-mds1 ~]#


And on a client, the resulting lost+found directory:



[root@hpfs-fsl-lmon0 MDT000

Re: [lustre-discuss] [EXTERNAL] [BULK] mds and mst are lost

[Vicker, Darby J. (JSC-EG111)[Jacobs Technology, Inc.] via lustre-discuss]

Sorry to hear this.  We are dealing with MDT data loss right now as well and 
its no fun.  Please look at my posts to the list from last week for some more 
information about what we are doing to recover.  Our situation is not as bad as 
yours, we only lost part of our MDT data (the last 3 months of a filesystem 
we’ve had in service for over 7 years).  If you get to the point where you can 
get the OST’s attached to a functioning lustre filesystem, you might be able to 
run an lfsck to move all of your files into lost+found.  We started our lfsck 
as follows:

[root@hpfs-fsl-mds1 hpfs3-eg3]# lctl lfsck_start -M scratch-MDT -o


When finished, this is on a client:


[root@hpfs-fsl-lmon0 MDT]# \ls | head
[0x2bdbe:0x1eae1:0x0]-R-0
[0x2bdeb:0x12c3e:0x0]-R-0
[0x20001f801:0x296f:0x0]-R-0
[0x20001f801:0x57:0x0]-R-0
[0x20001f801:0x58:0x0]-R-0
[0x20001f805:0x1000:0x0]-R-0
[0x20001f805:0x100:0x0]-R-0
[0x20001f805:0x1001:0x0]-R-0
[0x20001f805:0x1002:0x0]-R-0
[0x20001f805:0x1003:0x0]-R-0
[root@hpfs-fsl-lmon0 MDT]# ls -l [0x2bdbe:0x1eae1:0x0]-R-0
-r 1 damocles_runner damocles 3162 Sep 24 14:45 
[0x2bdbe:0x1eae1:0x0]-R-0
[root@hpfs-fsl-lmon0 MDT]# pwd
/scratch-lustre/.lustre/lost+found/MDT
[root@hpfs-fsl-lmon0 MDT]#

From: lustre-discuss  on behalf of 
Sergey Astafyev via lustre-discuss 
Reply-To: Sergey Astafyev 
Date: Monday, September 25, 2023 at 4:27 AM
To: "lustre-discuss@lists.lustre.org" 
Subject: [EXTERNAL] [BULK] [lustre-discuss] mds and mst are lost

CAUTION: This email originated from outside of NASA.  Please take care when 
clicking links or opening attachments.  Use the "Report Message" button to 
report suspicious messages to the NASA SOC.



Hello.

Please help.

It doesn’t really matter how, but MDS and MDT servers are  lost.

I connected old OSTs to the new lustre, but I don’t see any information.

lfs find tells me cannot get lov name : inappropriate ioctl for device

Is there any mechanism for recovering information from orphaned OST partitions?

best regards

S.Astafev


___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

[lustre-discuss] mds and mst are lost

[Sergey Astafyev via lustre-discuss]

Hello.
Please help.
It doesn’t really matter how, but MDS and MDT servers are  lost.
I connected old OSTs to the new lustre, but I don’t see any information.
lfs find tells me cannot get lov name : inappropriate ioctl for device

Is there any mechanism for recovering information from orphaned OST partitions?

best regards

S.Astafev
___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

Re: [lustre-discuss] Install instructions for Rocky 8.8

[Xinliang Liu via lustre-discuss]

Hi Jan,

On Mon, 25 Sept 2023 at 17:52, Jan Andersen  wrote:

> I'm having some trouble installing lustre - this is on Rocky 8.8. I
> downloaded the latest (?) source:
>
> git clone git://git.whamcloud.com/fs/lustre-release.git
>
> and I managed to compile and create the RPMs:
>
> make rpms
>
> I now have a directory full of rpm files:
>
> [root@rocky8 lustre-release]# ls -1 ?*rpm
> kmod-lustre-2.15.58_42_ga54a206-1.el8.x86_64.rpm
> kmod-lustre-debuginfo-2.15.58_42_ga54a206-1.el8.x86_64.rpm
> kmod-lustre-osd-ldiskfs-2.15.58_42_ga54a206-1.el8.x86_64.rpm
> kmod-lustre-osd-ldiskfs-debuginfo-2.15.58_42_ga54a206-1.el8.x86_64.rpm
> kmod-lustre-tests-2.15.58_42_ga54a206-1.el8.x86_64.rpm
> kmod-lustre-tests-debuginfo-2.15.58_42_ga54a206-1.el8.x86_64.rpm
> lustre-2.15.58_42_ga54a206-1.el8.x86_64.rpm
> lustre-2.15.58_42_ga54a206-1.src.rpm
> lustre-debuginfo-2.15.58_42_ga54a206-1.el8.x86_64.rpm
> lustre-debugsource-2.15.58_42_ga54a206-1.el8.x86_64.rpm
> lustre-devel-2.15.58_42_ga54a206-1.el8.x86_64.rpm
> lustre-iokit-2.15.58_42_ga54a206-1.el8.x86_64.rpm
> lustre-osd-ldiskfs-mount-2.15.58_42_ga54a206-1.el8.x86_64.rpm
> lustre-osd-ldiskfs-mount-debuginfo-2.15.58_42_ga54a206-1.el8.x86_64.rpm
> lustre-resource-agents-2.15.58_42_ga54a206-1.el8.x86_64.rpm
> lustre-tests-2.15.58_42_ga54a206-1.el8.x86_64.rpm
> lustre-tests-debuginfo-2.15.58_42_ga54a206-1.el8.x86_64.rpm
>
> This is what I get when I, somewhat naively, try to simply install the
> lot with:
>
> [root@rocky8 lustre-release]# dnf install ?*rpm
> Last metadata expiration check: 0:12:59 ago on Mon 25 Sep 2023 09:29:52
> UTC.
> Error:
>   Problem 1: conflicting requests
>- nothing provides ldiskfsprogs >= 1.44.3.wc1 needed by
> kmod-lustre-osd-ldiskfs-2.15.58_42_ga54a206-1.el8.x86_64
>   Problem 2: conflicting requests
>- nothing provides ldiskfsprogs > 1.45.6 needed by
> lustre-osd-ldiskfs-mount-2.15.58_42_ga54a206-1.el8.x86_64
>   Problem 3: package lustre-2.15.58_42_ga54a206-1.el8.x86_64 requires
> lustre-osd-mount, but none of the providers can be installed
>- conflicting requests
>- nothing provides ldiskfsprogs > 1.45.6 needed by
> lustre-osd-ldiskfs-mount-2.15.58_42_ga54a206-1.el8.x86_64
>   Problem 4: package lustre-devel-2.15.58_42_ga54a206-1.el8.x86_64
> requires liblnetconfig.so.4()(64bit), but none of the providers can be
> installed
>- package lustre-devel-2.15.58_42_ga54a206-1.el8.x86_64 requires
> liblustreapi.so.1()(64bit), but none of the providers can be installed
>- package lustre-devel-2.15.58_42_ga54a206-1.el8.x86_64 requires
> lustre = 2.15.58_42_ga54a206, but none of the providers can be installed
>- package lustre-2.15.58_42_ga54a206-1.el8.x86_64 requires
> lustre-osd-mount, but none of the providers can be installed
>- conflicting requests
>- nothing provides ldiskfsprogs > 1.45.6 needed by
> lustre-osd-ldiskfs-mount-2.15.58_42_ga54a206-1.el8.x86_64
>   Problem 5: package
> lustre-resource-agents-2.15.58_42_ga54a206-1.el8.x86_64 requires lustre,
> but none of the providers can be installed
>- package lustre-2.15.58_42_ga54a206-1.el8.x86_64 requires
> lustre-osd-mount, but none of the providers can be installed
>- conflicting requests
>- nothing provides ldiskfsprogs > 1.45.6 needed by
> lustre-osd-ldiskfs-mount-2.15.58_42_ga54a206-1.el8.x86_64
>   Problem 6: package lustre-tests-2.15.58_42_ga54a206-1.el8.x86_64
> requires liblnetconfig.so.4()(64bit), but none of the providers can be
> installed
>- package lustre-tests-2.15.58_42_ga54a206-1.el8.x86_64 requires
> liblustreapi.so.1()(64bit), but none of the providers can be installed
>- package lustre-tests-2.15.58_42_ga54a206-1.el8.x86_64 requires
> lustre = 2.15.58_42_ga54a206, but none of the providers can be installed
>- package lustre-2.15.58_42_ga54a206-1.el8.x86_64 requires
> lustre-osd-mount, but none of the providers can be installed
>- conflicting requests
>- nothing provides ldiskfsprogs > 1.45.6 needed by
> lustre-osd-ldiskfs-mount-2.15.58_42_ga54a206-1.el8.x86_64
>
>
> Clearly there is something I haven't done yet, but what am I doing wrong?
>

You may need to add ldiskfsprogs rpm repo and enable ha and powertools repo
first.

sudo dnf config-manager --add-repo
https://downloads.whamcloud.com/public/e2fsprogs/latest/el8/
sudo dnf config-manager --set-enabled ha
sudo dnf config-manager --set-enabled powertools

Best,
Xinliang


>
> /jan
>
> ___
> lustre-discuss mailing list
> lustre-discuss@lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
>
___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

[lustre-discuss] Install instructions for Rocky 8.8

[Jan Andersen]

I'm having some trouble installing lustre - this is on Rocky 8.8. I 
downloaded the latest (?) source:


git clone git://git.whamcloud.com/fs/lustre-release.git

and I managed to compile and create the RPMs:

make rpms

I now have a directory full of rpm files:

[root@rocky8 lustre-release]# ls -1 ?*rpm
kmod-lustre-2.15.58_42_ga54a206-1.el8.x86_64.rpm
kmod-lustre-debuginfo-2.15.58_42_ga54a206-1.el8.x86_64.rpm
kmod-lustre-osd-ldiskfs-2.15.58_42_ga54a206-1.el8.x86_64.rpm
kmod-lustre-osd-ldiskfs-debuginfo-2.15.58_42_ga54a206-1.el8.x86_64.rpm
kmod-lustre-tests-2.15.58_42_ga54a206-1.el8.x86_64.rpm
kmod-lustre-tests-debuginfo-2.15.58_42_ga54a206-1.el8.x86_64.rpm
lustre-2.15.58_42_ga54a206-1.el8.x86_64.rpm
lustre-2.15.58_42_ga54a206-1.src.rpm
lustre-debuginfo-2.15.58_42_ga54a206-1.el8.x86_64.rpm
lustre-debugsource-2.15.58_42_ga54a206-1.el8.x86_64.rpm
lustre-devel-2.15.58_42_ga54a206-1.el8.x86_64.rpm
lustre-iokit-2.15.58_42_ga54a206-1.el8.x86_64.rpm
lustre-osd-ldiskfs-mount-2.15.58_42_ga54a206-1.el8.x86_64.rpm
lustre-osd-ldiskfs-mount-debuginfo-2.15.58_42_ga54a206-1.el8.x86_64.rpm
lustre-resource-agents-2.15.58_42_ga54a206-1.el8.x86_64.rpm
lustre-tests-2.15.58_42_ga54a206-1.el8.x86_64.rpm
lustre-tests-debuginfo-2.15.58_42_ga54a206-1.el8.x86_64.rpm

This is what I get when I, somewhat naively, try to simply install the 
lot with:


[root@rocky8 lustre-release]# dnf install ?*rpm
Last metadata expiration check: 0:12:59 ago on Mon 25 Sep 2023 09:29:52 UTC.
Error:
 Problem 1: conflicting requests
  - nothing provides ldiskfsprogs >= 1.44.3.wc1 needed by 
kmod-lustre-osd-ldiskfs-2.15.58_42_ga54a206-1.el8.x86_64

 Problem 2: conflicting requests
  - nothing provides ldiskfsprogs > 1.45.6 needed by 
lustre-osd-ldiskfs-mount-2.15.58_42_ga54a206-1.el8.x86_64
 Problem 3: package lustre-2.15.58_42_ga54a206-1.el8.x86_64 requires 
lustre-osd-mount, but none of the providers can be installed

  - conflicting requests
  - nothing provides ldiskfsprogs > 1.45.6 needed by 
lustre-osd-ldiskfs-mount-2.15.58_42_ga54a206-1.el8.x86_64
 Problem 4: package lustre-devel-2.15.58_42_ga54a206-1.el8.x86_64 
requires liblnetconfig.so.4()(64bit), but none of the providers can be 
installed
  - package lustre-devel-2.15.58_42_ga54a206-1.el8.x86_64 requires 
liblustreapi.so.1()(64bit), but none of the providers can be installed
  - package lustre-devel-2.15.58_42_ga54a206-1.el8.x86_64 requires 
lustre = 2.15.58_42_ga54a206, but none of the providers can be installed
  - package lustre-2.15.58_42_ga54a206-1.el8.x86_64 requires 
lustre-osd-mount, but none of the providers can be installed

  - conflicting requests
  - nothing provides ldiskfsprogs > 1.45.6 needed by 
lustre-osd-ldiskfs-mount-2.15.58_42_ga54a206-1.el8.x86_64
 Problem 5: package 
lustre-resource-agents-2.15.58_42_ga54a206-1.el8.x86_64 requires lustre, 
but none of the providers can be installed
  - package lustre-2.15.58_42_ga54a206-1.el8.x86_64 requires 
lustre-osd-mount, but none of the providers can be installed

  - conflicting requests
  - nothing provides ldiskfsprogs > 1.45.6 needed by 
lustre-osd-ldiskfs-mount-2.15.58_42_ga54a206-1.el8.x86_64
 Problem 6: package lustre-tests-2.15.58_42_ga54a206-1.el8.x86_64 
requires liblnetconfig.so.4()(64bit), but none of the providers can be 
installed
  - package lustre-tests-2.15.58_42_ga54a206-1.el8.x86_64 requires 
liblustreapi.so.1()(64bit), but none of the providers can be installed
  - package lustre-tests-2.15.58_42_ga54a206-1.el8.x86_64 requires 
lustre = 2.15.58_42_ga54a206, but none of the providers can be installed
  - package lustre-2.15.58_42_ga54a206-1.el8.x86_64 requires 
lustre-osd-mount, but none of the providers can be installed

  - conflicting requests
  - nothing provides ldiskfsprogs > 1.45.6 needed by 
lustre-osd-ldiskfs-mount-2.15.58_42_ga54a206-1.el8.x86_64



Clearly there is something I haven't done yet, but what am I doing wrong?

/jan

___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org