Unable to boot after transfer to SSD/resized partition

LoneCrusader · 2019-01-09 00:20

Hello,

I had set up Scorpion 2.6 (updated to 2.7) on a HDD in a multi-boot setup with Windows XP and Windows 7. Multi-boot setup is managed by System Commander (no OS is aware of any other OS), which chainloads to GRUB which is installed to the Q4OS root partition (this step is probably not necessary, but it was working fine).

I decided to upgrade the HDD with a larger SSD. Copied all of the partitions over, resizing them as necessary. GParted checked the Q4OS partition for errors and found none.

Now however, when I try to boot into Q4OS I am dropped into a black screen with a blinking cursor and GRUB never loads.

I've loaded the live CD and mounted the Q4OS partition. Now where do I go from here? lol

Thanks in advance!

Dai_trying · 2019-01-09 01:17

Are the Windows installations booting ok?

One thing that might be causing a problem is the named location of the filesystem according to grub, you might need to chroot into the Q4OS installation (from a live-USB is easiest) and in the chroot re-install grub and update it so it can collect and store the proper information.

LoneCrusader · 2019-01-09 03:50

Dai_trying wrote:

Are the Windows installations booting ok?

Well.. technically one is and one is not, but that's a whole different story. Windows 7 is working. I think Windows XP and the SSD are not getting along because after the boot logo screen is displayed a BSOD is thrown and the machine resets within a fraction of a second before it can be read. However it IS executing the boot process, so I think it may be a driver issue there.

In the case of Q4OS, GRUB is never even reached. System Commander exits to a black screen with a blinking cursor where normally the GRUB menu would appear, and nothing happens.

I downloaded a tool called "Super Grub2 Disk" that claimed it could help boot into systems otherwise inaccessible but it didn't help. It does seem to recognize that a GRUB installation exists on the correct partition, but choosing to boot it gives an error about a "magic number" and needing to "load the kernel" first. (I should have written it down, don't remember the exact wording offhand.)

Based on the "magic number" bit I did some searching and reinstalling GRUB was suggested on one forum. I tried to do this from the LiveCD but another error was thrown (I assume I did not have all of the correct switches or parameters for the command.)

Dai_trying · 2019-01-09 10:11

You cannot just install grub from a Live-Cd but you need to create a chroot environment in order to install (and update) grub from that, some instructions can be found in this post you may need to adjust it slightly to suit your system, and if you are using a UEFI system (without legacy mode or csm enabled) you will also need to mount the esp partition but as you have not mentioned it I'm not sure it is what you are using.
Pay particular attention to where you want grub to be installed as you have your machine in a non default setup, that is you are using system commander for initial boot selection.
HTH

LoneCrusader · 2019-01-09 19:35

I'm not using a UEFI system. The real annoying "quirk" I've found with this system (my girlfriend's laptop actually) is that the SATA controller is locked in AHCI mode with no BIOS option but AHCI is not even truly "active." This created hassles when installing XP (need F6 floppy) or booting to DOS with CDROM support (requires a custom driver). But neither of these are relevant to the problem here. Q4OS handled it all without a hitch until I transferred to the SSD and resized the partitions.

OK, trying your instructions from the other thread.
I get to this point:

sudo chroot $TARGET /bin/bash

And then I get an error,

chroot: failed to run command '/bin/bash': Exec format error

Now what?

EDIT:
Some searching for the error returns a lot of comments about mismatched environment architecture (x86 vs x64). I'm using Scorpion x64 and I'm using the same LiveCD now that I used to install the system originally.

Last edited by LoneCrusader (2019-01-09 20:25)

Dai_trying · 2019-01-10 00:21

I would think that you have mounted the wrong partition or not mounted it at all, I have used those instructions on many occasions and never had that error and I'm not sure if it is saying bash is not there or there is some other problem executing it....

When you are in the Live session check that the partitions are identified as you expect, using

sudo blkid

should give you a listing with relevant info. Remember to set $TARGET to the correct partition, /dev/sda1 as shown in the example might not be the right one for your machine.

LoneCrusader · 2019-01-10 02:48

I'm confident the correct partition was mounted (/dev/sda5 in this case). I had mounted it manually before I posted here looking for GRUB files that I could examine and see if I could find the problem. When I tried out your instructions I also was able to browse the partition in Konqueror at the mounted location.

Image isn't great, but if you view it full size you can see the details.

Last edited by LoneCrusader (2019-01-10 03:09)

Dai_trying · 2019-01-10 08:18

It looks like you are using STARGET and not $TARGET in that screenshot? are you using the dollar sign?

q4osteam · 2019-01-10 08:25

Verify that you are using the right Live CD. For example, verify you are not using a 32bit CD instead of a 64bit CD. You need a 64bit kernel to run 64bit code, so check your architecture.

Assuming you mounted your system to be chrooted in /media/sda1, to determine the architecture you can:
$ ls /media/sda5/*

if you see lib64 in the output, it's probably a 64bit system.

LoneCrusader · 2019-01-10 08:30

Dai_trying wrote:

It looks like you are using STARGET and not $TARGET in that screenshot? are you using the dollar sign?

Yes
It was even harder to read until I changed the color scheme. The dollar sign at the end of the prompt looks the same.

BTW does the LiveCD have a means for taking/saving screenshots? This would have made for a better image.

q4osteam wrote:

Verify that you are using the right Live CD. For example, verify you are not using a 32bit CD instead of a 64bit CD. You need a 64bit kernel to run 64bit code, so check your architecture.
Assuming you mounted your system to be chrooted in /media/sda1, to determine the architecture you can:
$ ls /media/sda5/*
if you see lib64 in the output, it's probably a 64bit system.

I'm using the same 64bit LiveCD that I used to install the system. I don't have a 32bit CD for Scorpion.

q4osteam · 2019-01-10 08:39

Are you able directly run bash from the live cd konsole ?
$ /bin/bash --version
$ /media/sda5/bin/bash --version
$ /media/sda5/bin/bash

Dai_trying · 2019-01-10 08:43

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...

LoneCrusader · 2019-01-10 09:10

q4osteam wrote:

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

Dai_trying wrote:

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.

Dai_trying · 2019-01-10 09:40

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).

LoneCrusader · 2019-01-10 10:04

Dai_trying wrote:

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!

Dai_trying · 2019-01-10 10:49

Just a not on copying partitions, I have done it with a good success rate, but I would do a simple copy and then configure your system before any resizing, just to eliminate the possibility of introducing errors, if it gets configured ok and then you resize and it borks the system you would have narrowed down where the error came from.

LoneCrusader · 2019-01-10 22:20

Looks like there is definitely a problem when GParted is copying the partition.
I decided to copy the partition and try to boot the system first without resizing it (thought about this around the same time Dai posted it, lol).

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?

Dai_trying · 2019-01-10 23:46

You need to mount the esp partition (possibly /dev/sda1 but not too sure) to $TARGET/boot/efi (as stated in #4) and install grub-efi and don't forget to update grub, what you have just done is to try to install normal grub to the MBR

LoneCrusader · 2019-01-11 01:04

esp partition? I don't have any other Linux partitions on the drive other than the /root partition and the /swap partition. This is not a UEFI machine.

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.

Last edited by LoneCrusader (2019-01-11 01:04)

Dai_trying · 2019-01-11 01:31

My Bad! getting threads mixed up

"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.

LoneCrusader · 2019-01-11 02:01

No problem. Side effect of an active forum.

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.

Dai_trying · 2019-01-11 11:35

I think this may have something to do with gpt/dos partitioning, could you check the partition table for sda

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.

LoneCrusader · 2019-01-12 04:53

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.

Last edited by LoneCrusader (2019-01-12 05:22)

Dai_trying · 2019-01-12 08:22

You could always try using grub to chainload your Windows installs too, I have never used more than one version of Windows on a machine but I would guess grub could do that without an issue, and yes a fresh install definitely would be the quick and easy solution and if you have a external HDD enclosure you could mount your HDD to copy any data files across easily.

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...

LoneCrusader · 2019-01-13 04:32

I had actually already nuked the existing partitions and proceeded with the reinstall.
I doubt the flag had anything to do with the issue though given that the original HDD setup used it too.

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.

Q4OS Forum

#1 2019-01-09 00:20

Unable to boot after transfer to SSD/resized partition

#2 2019-01-09 01:17

Re: Unable to boot after transfer to SSD/resized partition

#3 2019-01-09 03:50

Re: Unable to boot after transfer to SSD/resized partition

#4 2019-01-09 10:11

Re: Unable to boot after transfer to SSD/resized partition

#5 2019-01-09 19:35

Re: Unable to boot after transfer to SSD/resized partition

#6 2019-01-10 00:21

Re: Unable to boot after transfer to SSD/resized partition

#7 2019-01-10 02:48

Re: Unable to boot after transfer to SSD/resized partition

#8 2019-01-10 08:18

Re: Unable to boot after transfer to SSD/resized partition

#9 2019-01-10 08:25

Re: Unable to boot after transfer to SSD/resized partition

#10 2019-01-10 08:30

Re: Unable to boot after transfer to SSD/resized partition

#11 2019-01-10 08:39

Re: Unable to boot after transfer to SSD/resized partition

#12 2019-01-10 08:43

Re: Unable to boot after transfer to SSD/resized partition

#13 2019-01-10 09:10

Re: Unable to boot after transfer to SSD/resized partition

#14 2019-01-10 09:40

Re: Unable to boot after transfer to SSD/resized partition

#15 2019-01-10 10:04

Re: Unable to boot after transfer to SSD/resized partition

#16 2019-01-10 10:49

Re: Unable to boot after transfer to SSD/resized partition

#17 2019-01-10 22:20

Re: Unable to boot after transfer to SSD/resized partition

#18 2019-01-10 23:46

Re: Unable to boot after transfer to SSD/resized partition

#19 2019-01-11 01:04

Re: Unable to boot after transfer to SSD/resized partition

#20 2019-01-11 01:31

Re: Unable to boot after transfer to SSD/resized partition

#21 2019-01-11 02:01

Re: Unable to boot after transfer to SSD/resized partition

#22 2019-01-11 11:35

Re: Unable to boot after transfer to SSD/resized partition

#23 2019-01-12 04:53

Re: Unable to boot after transfer to SSD/resized partition

#24 2019-01-12 08:22

Re: Unable to boot after transfer to SSD/resized partition

#25 2019-01-13 04:32

Re: Unable to boot after transfer to SSD/resized partition

Board footer