could not map attribute 0x80 in inode FOG 1.5.9
-
I have finally been able to install FOG images with UEFI boot, however, now I receive an could not map attribute 0x80 in inode FOG error when trying to capture an image off the same computer.
I have run chkdsk /f/r/x, I have turned off quick boot. Yet I get this error.
I would revert back to legacy, but now a new Lenovo laptop E14, has no legacy boot option. This is occurring only on Lenovo laptops as that’s what I’m currently updating and imaging.
I’m trying to capture Windows 10 imagesThanks
-
Well, I did the exact same update and capture to the next new Lenovo, out of the box, and it captured fine. Perhaps, CHkDSK does not completely repair NVME drives.
Anyway…
-
I have exactly the same problem in FOG 1.5.0.
10 Lenovo machines with 256GB Crucial MX500 SSDs, all same setup, all same settings.
8 capture fine, 2 get this error.- no dirty bit
- chkdsk shows no errors
- no smart errors or other errors shown in crucial storage executive
buggy SSD? The machines are working fine.
Any suggestions how to fix this error?
-
@Noseman said in could not map attribute 0x80 in inode FOG 1.5.9:
I have exactly the same problem in FOG 1.5.0.
I hope you mean 1.5.10!?
Now on your issue, made sure fast boot is disabled??
-
@Sebastian-Roth said in could not map attribute 0x80 in inode FOG 1.5.9:
@Noseman said in could not map attribute 0x80 in inode FOG 1.5.9:
I have exactly the same problem in FOG 1.5.0.
I hope you mean 1.5.10!?
Now on your issue, made sure fast boot is disabled??
Hi @Sebastian-Roth ,
thank you for answering.
You mentioned right, it is 1.5.10.
I said, no dirty bit set, so this means also no fast boot to me,
After my post I was fiddling around:
- Testing RAM, not with included memtest over pxe, because it does not work, I tried the memtest86 (6.x) included in the proxmox iso, uefi booted via ventoy. - RAM OKAY
- Taking an image with Trueimage, no errors - works
- Changing to a new SSD, and deploying the Trueimage image onto. - works
- After that capturing the machine via fog. - works without errors
- Deploying the captured image in the old (not captureable) SSD - works
- Capturing this again, from the (not captureable) SSD works now flawlessly.
- Tested this on both machines several times, works absolutely fine.
- On the other machine I tried deploying the image from trueimage directly onto the “not captureable” ssd, which saves some time and works also with capturing from fog afterwards.
I would call this a workaround, and it did the trick, but WTF was the problem?
Happy
sunday! -
@Noseman The tools used within FOS (FOG OS doing all the hard work when capturing and deploying) are no official Microsoft certified software products but from open source community. They work in 99% of cases but I can imagine there can be special states of the filesystem or certain edge cases those tools simply cannot handle (yet).
Great you found a workaround!