brolin_empey | Long story short, I have a 512-GB mSATA SSD with Debian GNU+Linux 10 (buster) with KDE 5 for x86-64 using MBR that boots and works on a Core 2 tower computer with this motherboard: | 06:40 |
---|---|---|
brolin_empey | https://www.gigabyte.com/Motherboard/GA-EP45-DS3R-rev-10/sp#sp | 06:40 |
brolin_empey | This motherboard uses literal BIOS, not EFI. | 06:40 |
brolin_empey | I used HDClone 9 for Windows to clone the mSATA SSD onto a USB 3 SSD and allowed HDClone to change the disk signature and maybe something else that makes the cloned drive different from the original drive but that I thought should not matter for booting GNU+Linux. When I try to boot the Core 2 tower computer from the USB SSD with the mSATA SSD disconnected, the boot process initially looks the same as when booting from the SATA drive but is much slower | 06:40 |
brolin_empey | because the computer only has USB 2 connectivity so the USB SSD only uses High-speed, not SuperSpeed but then Debian stops booting with this ACPI error: | 06:40 |
brolin_empey | https://lh3.googleusercontent.com/-cQPtPX1iE2M/X4EtoQI-ThI/AAAAAAAAEvM/fzVDl-FUtKUQ0juAA16Hh7agEgbBCbMvgCK8BGAsYHg/s0/2020-10-09.jpg | 06:40 |
brolin_empey | Apparently the result is the same after I power-cycled the computer and tried booting again so it does not seem to be a problem only on the first boot of the cloned drive. I have not yet searched the Internet about this message because I am still at work at 21:30 on Friday and I realise that this channel is not focused on Debian but does anyone have a suggestion of how to fix this problem? Does it matter that the disk signature and maybe something else was | 06:40 |
brolin_empey | changed when the drive was cloned? The partitions and the volumes within them have been resized too because the USB drive is only 240 GB instead of 512 GB but I do not think that matters in this case considering how far the boot process gets before it stops. | 06:40 |
Maxdamantus | brolin_empey: my guess would be that the ACPI error is probably not relevant to the problem. | 06:52 |
Maxdamantus | brolin_empey: it's booted to a busybox shell, so Debian simply isn't able to find the root filesystem. | 06:53 |
Maxdamantus | brolin_empey: probably because it's missing the relevant drivers (since you said you're trying to boot it from USB whereas it used to just boot from SATA) | 06:54 |
Maxdamantus | brolin_empey: I suspect Debian probably creates an initramfs containing the particular drivers needed to boot your system, so if you change the installation media, you'd probably need to regenerate the initramfs. | 06:55 |
brolin_empey | Maxdamantus: Thank you for the quick reply but how do I regenerate the initramfs? | 07:05 |
Maxdamantus | brolin_empey: I've tended to just maintain my own kernel when using debian, but from Googling, I think it should work if you're able to get it to boot manually from the USB and then run `update-initramfs` from the running system. | 11:06 |
Maxdamantus | brolin_empey: I would probably try getting into the initramfs of a live USB system, then instead of letting it continue to boot into the live USB, mount your own root filesystem instead (eg, something like `mount -o ro /dev/sdb1 /mnt`), then boot into it using `exec chroot /mnt /sbin/init` | 11:08 |
Maxdamantus | Since the live USB initramfs will very likely have all the relevant drivers (particularly: usb, usb-storage and a module for whatever filesystem you're using) | 11:10 |
Maxdamantus | brolin_empey: seems that to boot to initramfs from the livecd, you go to "Help" at the boot menu, then use a boot command like `install init=/bin/sh` | 11:23 |
Maxdamantus | brolin_empey: then you should be able to run the commands I wrote above (you'll need to figure out what your actual root device is; my command assumes it's "/dev/sdb1") | 11:24 |
dogdjgift | hello | 11:30 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!