ISO Importing Results in .img Files
-
That's weird, are they ISO in the first place? Because we import in raw format. An ISO should stays as an ISO
Can you reproduce it? -
@olivierlambert Yes, they are in ISO format to start with.
I just tested it, again with a Ubuntu 22.04 file, extension on it is .iso, imported that into my ISO repository on XOA, the file ended up as: 1e10bdc1-8b53-4a6c-9493-4ebb958afa59.img instead of the file name and extension I had it as before uploading.
The XOA I am using is fully updated on the "latest" branch, also seeing the same thing on a freshly built from the sources one in my home lab.
-
Can you try with another ISO file? What's the result of
file youriso.isoon your computer?Also, can you provide screenshot on how you import it in XOA?
-
@olivierlambert Yes, I have tried this with about 15 different ISO files, Ubuntu, Debian, Windows 11, Windows Server, CentOS, etc.... and still seeing the same thing. Also seems to happen regardless of if my ISO SR is on local storage or a NAS over SMB.
If I run the file command I get:
ISO 9660 CD-ROM filesystem data 'Ubuntu-Server 22.04.3 LTS amd64' (bootable)
This is the upload page I used and I get that UUID.img file instead of just the ISO file.
-
That's weird
Can you try with "Import from URL" and give an URL pointing to this ISO to see if it's different?
Also try with this URL and see if you have an img or an ISO: https://s3-us.vyos.io/rolling/current/vyos-1.4-rolling-202308180646-amd64.iso
-
@olivierlambert I will try with a URL on this ISO in specific later, but I tried the vyOS one you linked and got this (it's from my TrueNAS CLI but also is what the XCP-ng host sees):
The vyOS one got imported as the long UUID.img and doing a file command ont hat shows it's that ISO.
-
That's very weird, I can't reproduce here
-
@olivierlambert Interesting, so it just shows up as the filename.iso for you?
I can say this is happening in 2 different environments and 3 different XO installs, 1 is a full enterprise supported XOA, another is the free version of XOA, and the 3rd is a built from the sources XOCE.
I'll see if I can think of anything else to test, definitely an odd one.
-
Yes, "filename.iso"
-
@olivierlambert Hmmm odd, I'll keep testing to see if I can find a pattern, but so far I've never had it do a .ISO file.
Maybe a bug of some kind?
It shouldn't have anything to do with XCP-ng itself right, this is all handled by XO? Either way I'm on fully patched 8.2
-
I can't tell as long I can't reproduce it. Anyone else having the same behavior?
-
@olivierlambert So far I haven't seen anyone else running across this, but maybe people aren't using the feature a ton? Normally I just move my ISOs to the SMB share manually but decided to use this feature for it instead and then noticed it created all the .img files.
It may be worth noting that whatever host that manages the SR I select, can indeed use the .img files to boot, but other hosts using the same ISO SR won't see them until I rename the files to .iso of some sort.
-
I will try to use this option as well, although I don't like that the files are stored as UUID.iso, I prefer to have them as names.
I prefer to have RockyLinux.9.2.iso than to have 89c425b6-42b7-11ee-be56-0242ac120002.iso.
If I can no longer recover the metadata, these UUIDs are of no use. You must identify them first. -
@Gheppy Yeah I agree, and I think what @olivierlambert is saying is that they should import as raw so in theory the name shouldn't change right?
Thanks for helping test this out!
-
I can confirm that the file *.iso importing is converted to *.img
Importing
File on share is
File on XOCE, commit 3baa37846e6dbe775a8891f51f7eaebbbb28bea6
-
@Gheppy This is good to know, thank you!
So at least I know I'm not just super unlucky haha.
So far I haven't been able to get it to do a .iso properly, but I will keep trying various things.
-
O olivierlambert moved this topic from Xen Orchestra on
-
Looks like this is still happening on the latest XO version, any ideas/updates @olivierlambert ?
@Gheppy you still seeing this as well?
Fix is easy enough for me for now, just rename to .iso and everything is good, just a bit odd.
-
Can you check if there's a diff between a local ISO SR and a shared NFS ISO SR?
-
The problem is the same with all form of ISO SR: local, cifs (smb), nfs. On all I have *.img
-
I've only tested local and SMB so far but both did the same thing.
