Trying to capture Ubuntu 18.04.1 and I get this.
-
File system specified during install was ext4. What does this mean exactly? -
@salted_cashews It means that the filesystem on /dev/sda1 seems unclean/to have an inconsistency. Is /dev/sda1 the root or boot partition?
You might just schedule anther capture task for the client but tick the checkbox for debug this time. Boot it up and hit ENTER twice to get to the shell. Now run
fsck.ext4 -f -v /dev/sda1and see what you get. Hope this will find issues and fix them. Maybe even run multiple times if it keeps returning with an inconsistency. When filesystem is clean just start the capture with commandfog… -
@Sebastian-Roth Whoa, this worked! Thanks, now correct me if I’m wrong but Fog is the one detecting, warning, cleaning, etc in this case right? I’m not doing anything with my Ubuntu install’s grub / os ?
As an aside, does making everything ext4 and mounting everything on the same mount point (/) best practice?
-
@Sebastian-Roth So after running that command it captures fine, but during deployment I get a similar error. If I try and capture again on a fresh base image, (different machine same OS/config) I get the same error.
Is this due to me having only 1 partition mounted via “/”? Is it something to do with Ext4? Image settings are:
-
@salted_cashews I would highly recommend not setting the compression level higher than 19. 20 - 22 are considered ultra and require a TON of memory. Unless you’re not seeing a problem here, I suppose this could be partly why you’re seeing issues too.
-
@Tom-Elliott I’ve moved the compression to the default of 6 and I received the same error. I’m also receiving an error directing me to /var/log/partclone.log but that doesn’t seem to exist. I appreciate the compression level info, I wasn’t aware.
-
@salted_cashews said in Trying to capture Ubuntu 18.04.1 and I get this.:
So after running that command it captures fine, but during deployment I get a similar error.
What error message do you get on deploy? I kind of doubt you see the same message. Please take another picture and post here.
If I try and capture again on a fresh base image, (different machine same OS/config) I get the same error.
This seems very strange. Sounds as if Ubuntu does not close the filesystem on shutdown properly. Can’t really imagine that but what do I know. When you run
fsck.ext4 ...does it actually fix an issue? Please take a picture of the output and post here as well. -
@Sebastian-Roth
On deploy (after successfully capturing thanks to fsck.ext4 fix):
On capture (after running the fsck.ext4 on the original machine image was built on):
-
@salted_cashews I cannot imagine what would cause the filesystem to not be clean all the time!? Does the machine shut down properly before you do the capture? Is it a VM or hardware machine?
-
@Sebastian-Roth It does, and it’s a hardware machine. What makes this weirder is we’ve had this issue in the past, forcing us to use Raw image type to capture. The weirder part is it’s a straight out-of-the-box Ubuntu 18.04.1 install, only adding xrdp, net-tools, and ssh.
Is it possible this is the result of mounting everything on one partition? The full capacity of the drive is also not being used, we’re only using 200gb of 500gb.
-
@salted_cashews Sorry for my late reply.
Is it possible this is the result of mounting everything on one partition?
I don’t think this can cause the issue. Trying to read up on this I found a bug report that kind of sounds like what you see: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1778140
Although I am still unsure if this can happen with the pre-resize test we do. But can you confirm you are installing on LVM? If unsure run
df -hon your Ubuntu system and post output here.EDIT: Reading a bit more I found another hint on there being an issue with resize2fs. Again this is on LVM but maybe it can happen on plain partitioning as well. This points us to a second launchpad bug report.
Would you mind trying to install Ubuntu without LVM and see if that fixes it. Although the patch was added to the official e2progs source in October 2018 it has not made it into buildroot which we use for FOG yet (as of now, last e2fsprogs update was in early 2018).
Which install ISO did you use? Desktop or Alternative installer? Just asking so I would setup the same test scenario…
-
@Sebastian-Roth That direct “Desktop” link is the exact one I used. I installed it without LVM the first time, but we’ve moved over to CentOS since then. I formatted a USB 3.0 device using Rufus (latest) and specified MBR - everything else was left at defaults. Sorry if I couldn’t be more help, it’s been a while since then.
-
@salted_cashews said in Trying to capture Ubuntu 18.04.1 and I get this.:
but we’ve moved over to CentOS since then
Means you don’t have a system to test anymore?
I formatted a USB 3.0 device using Rufus (latest) …
What do you mean by that? Using USB key as install media?
-
@salted_cashews I’ve just tried, clean Ubuntu 18.04.1 Desktop install (non LVM as default) and cannot replicate the issue. It’s capturing just fine.
As well I just noticed that you definitely have not had LVM as we see /dev/sda1 in the screenshots. I can’t see why this caused trouble for you. Maybe a disk error?!
Shall I mark this solved or keep it open?
-
@Sebastian-Roth If you could keep it open that’d be great, I’m now going to do some more testing with this on Ubuntu 16 as well as 18. I’ll keep you posted.
EDIT: Also am I understanding correctly that FoG/Partclone cannot use the “Single Disk Resizable” option on LVM partitions? We’ve had issues with LVM in the past and FoG/partclone and we ended up having to use RAW format.
-
@salted_cashews said in Trying to capture Ubuntu 18.04.1 and I get this.:
Also am I understanding correctly that FoG/Partclone cannot use the “Single Disk Resizable” option on LVM partitions? We’ve had issues with LVM in the past and FoG/partclone and we ended up having to use RAW format.
Yes, that is true. We hope to get that added to FOG but there aren’t enough people to work on those kind of things as we all do this in our free time at the moment and don’t have enough of that.
-
@salted_cashews Any news on this?
-
@Sebastian-Roth So far I’ve tried a fresh Ubuntu 16.04 install, and I’ve even used LVM and just captured as non-resizable with 0 issues. Now while this wasn’t Ubuntu 18, I did notice the machine I had the issue on originally is unable to install this OS due to something being wrong with the “file system” on the disk which for some odd reason it couldn’t format, delete, or write to. It is an SSD, and I couldn’t recreate this issue on any other box. I ran various SSD diagnostics with no errors being found so I’m stumped. I haven’t gotten to try with the exact iso posted above just yet - doing production stuff lately since I’m alone in IT currently.