I did try forcing a fsck (+forced ext4 filesystem type) on the ext4 partition to be certain that some weirdness was not going on where it could be identified as ext2. Everything showed clean.
I've never looked into it but GRUB could probably handle the Windows situations, although to do so it would probably need to be in place prior to at least the installation of the second copy of Windows. Also it would need to be able to hide partitions from one another (I assume it has this capability) as Windows loves to mess with other versions of Windows, overwriting the MBR and other boot code during SETUP, SETUP placing boot files in an existing Windows partition rather than the current partition, "updating" NTFS so that older Windows can no longer read it, and probably other rubbish.
It would have been nice to figure out why copying the partition resulted in these problems, but since I'm running a non-standard setup who knows how long it could have taken to get anywhere. I'm inclined to blame GParted.. but I have no reproducible basis for that. Maybe sometime I will try again using System Commander to copy the partition in this configuration... I didn't use it in this case because it doesn't recognize ext4, only ext3 and prior, so I thought GParted would handle it better. Maybe not.
Anyway, thanks for trying to help me straighten it out.
]]>I have never seen two boot flags set on the same HDD so it still puzzles me, but I agree it is possible that System Commander is using it somehow. I have read though that it is only used to denote the first boot device and so I can't imagine the second flag will have any use. If you are going to re-install anyway why not try removing the boot flag (on Q4OS partition) just to see if it has any effect? I am fairly certain it is not needed by grub and It probably won't make a difference, but you never know...
]]>adminq@debian:~$ udevadm info /dev/sda | grep PART_TABLE_TYPE
E: ID_PART_TABLE_TYPE=dos
adminq@debian:~$
Decided to put the original HDD back in and run these commands on the installed system.
root@hpdv7:~# sudo blkid
/dev/sda1: SEC_TYPE="msdos" UUID="2536-0908" TYPE="vfat" PARTUUID="0e6aa963-01"
/dev/sda2: UUID="01D498ABD884D300" TYPE="ntfs" PARTUUID="0e6aa963-02"
/dev/sda3: UUID="01D498B682695D00" TYPE="ntfs" PARTUUID="0e6aa963-03"
/dev/sda5: UUID="ace9b733-1401-4063-877c-4d9b23437a4c" TYPE="ext4" PTTYPE="dos" PARTUUID="0e6aa963-05"
/dev/sda6: UUID="8ecd20a7-5a85-4624-a3a2-38653ed8cd46" TYPE="swap" PARTUUID="0e6aa963-06"
root@hpdv7:~#
root@hpdv7:~# udevadm info /dev/sda | grep PART_TABLE_TYPE
E: ID_PART_TABLE_TYPE=dos
root@hpdv7:~#
Looks like the original HDD structure has the same PTTYPE, and Q4OS is working there.
I will investigate the boot flag issue and report back about it; if that's also the same on the working system I believe I may just reinstall Q4OS on the SSD. I could have already done that by now and had this laptop project over with. lol
EDIT:
Looks like the original HDD partitions use the same flags. I assume (guessing!) this is because System Commander boots first in /dev/hda1 (hence its boot flag) and then it chainloads to whichever OS is chosen, setting a boot flag in the corresponding partition and allowing that OS's bootloader to take over. This process is unnecessary for Linux but it's very good at keeping Windows installations from "molesting" each other.
I think I will just start over and reinstall on the SSD; who knows how long this could take to sort out.
]]>udevadm info /dev/sda | grep PART_TABLE_TYPE
this will hopefully tell you the partition table type, I recall someone having an issue with a partition that had a pttype=dos but do not recall the exact problem and it might be unrelated but something that sounded a bell in my head.
From your earlier screenshot I can also see you have two boot flags set, I was under the impression that it was only possible to set it on one partition and this is another possible culprit for your issues.
adminq@debian:~$ sudo blkid
/dev/sr0: UUID="2018-11-05-07-11-43-00" LABEL="Q4OS Scorpion" TYPE="iso9660" PTUUID="4caf4769" PTTYPE="dos"
/dev/sda1: SEC_TYPE="msdos" UUID="5C34-BE6D" TYPE="vfat" PARTUUID="394d394c-01"
/dev/sda2: UUID="01D498ABD884D301" TYPE="ntfs" PARTUUID="394d394c-02"
/dev/sda3: UUID="01D498B682695D01" TYPE="ntfs" PARTUUID="394d394c-03"
/dev/sda5: UUID="ace9b733-1401-4063-877c-4d9b23437a4c" TYPE="ext4" PTTYPE="dos" PARTUUID="394d394c-05"
/dev/sda6: UUID="8ecd20a7-5a85-4624-a3a2-38653ed8cd46" TYPE="swap" PARTUUID="394d394c-06"
/dev/loop0: TYPE="squashfs"
adminq@debian:~$
Interesting... ext4 reported here as well.
$TARGET - yes, I actually verified all of those commands and put them in a text file so I can copy and paste them like a script.
]]>"installing for "i386-pc platform." is normal.
the ext2 warning is concerning though, could you post the output of
sudo blkid
although I expect it to show the same information that shows in the previous gparted screenshot...
Did you set the $TARGET correctly? it should have been /dev/sda5 for your case but wasn't shown in the previous terminal output.
]]>The root partition is /dev/sda5 and the swap partition is /dev/sda6. The other partitions contain the System Commander bootloader (DOS) /dev/sda1, Windows XP /dev/sda2, and Windows 7 /dev/sda3.
]]>This time there does not seem to be corruption (at least not in the same manner as before) and I can successfully chroot into the partition and run bash. But according to GRUB the filesystem is EXT2. The partition is EXT4... any idea about this weirdness?
adminq@debian:~$ sudo mkdir -p $TARGET
adminq@debian:~$ sudo mount /dev/sda5 $TARGET
adminq@debian:~$ sudo mount --bind /dev $TARGET/dev
adminq@debian:~$ sudo mount --bind /dev/pts $TARGET/dev/pts
adminq@debian:~$ sudo mount --bind /proc $TARGET/proc
adminq@debian:~$ sudo mount --bind /sys $TARGET/sys
adminq@debian:~$
adminq@debian:~$ /bin/bash --version
GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
adminq@debian:~$
adminq@debian:~$ /media/sda5/bin/bash --version
GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
adminq@debian:~$
adminq@debian:~$ sudo chroot $TARGET /bin/bash
root@debian:/# grub-install /dev/sda5
Installing for i386-pc platform.
grub-install: warning: File system `ext2' doesn't support embedding.
grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged..
grub-install: error: will not proceed with blocklists.
root@debian:/#
*Also noted the GRUB reports "installing for "i386-pc platform." I assume this is normal even on an x64 setup?
]]>That is some weird output!
I would suggest a re-install as I don't know how much corruption has been introduced, it would likely give you a better running system and I would always be concerned about other parts of the system still being corrupted if it were repaired (if possible).
Definitely agree; there's no knowing what else might have been affected. However I should be able to just recopy the partition from the original HDD again (all was working there) without having to completely reinstall yet.
At least there's not any important data to lose in either case; this was a new install and I had only added some packages and customized the themes and such. Annoying to lose but no real loss other than time spent.
More to experiment with later, it's 4AM here. Thanks guys!
]]>Are you able directly run bash from the live cd konsole ?
$ /bin/bash --version
$ /media/sda5/bin/bash --version
$ /media/sda5/bin/bash
Well, a picture is worth a thousand words. I do believe something got corrupted when the partition was copied to the SSD and/or when it was subsequently enlarged.
Here's looking at you, GParted! lol
Screenshots can be taken with PrtScr button and then right click on desktop (of file manager to save it somewhere) and select Paste Clipboard Contents and enter the name for your file.
One other thing came to mind... can you post the output of
sudo blkid
from the Live Session? I would have expected your machine HDD to be mounted as sdb but not 100% sure about that...
For some reason the PrtScr button is not working (nothing is pasted and Klipper sees an empty clipboard) on this laptop; may be some weird thing with the function keys.
I closed the Konsole after the screenshot above and it threw an error when I tried to open a new one. I think the problem is corruption based on the above shot but I've rebooted and can run that command if you still want to see the output.
]]>