You are not logged in.
Pages: 1
I can't figure this out. I have a USB caddy with an NvME drive, using syslinux to boot, intended to be a portable install. It works just fine.
The Drive in the caddy is 256Gb. For reasons, I wanted to move this to a different drive (I have a specific reason for wanting top repurpose this smaller drive), so I used clonezilla to clone the drive to a 512Gb NvME drive, also in an external caddy.
fstab, and syslinux.cfg are configured with UUIDs (not drive /dev/sdxX) assignments. Clonezilla has successfully retained the UUIDs.
However, when I boot using the newly created drive, it fails that it can't find /dev/sde1. I have no idea what is causing it to look for /dev/sdxX at all.
syslinux is only used on the portable drive. My main machine uses grub, and I have an entry in there to boot directly to my portable drive, but again, grub is configured with the UUID.
Possibly related, but although the portable drive is set as bootable, it isn't directly available to boot from anymore. This is both the original, and the clone. I used to be able to select the original as a boot device.
I'm stumped now, and can't proceed with my repurpose of the smaller drive until I fix this.
Any ideas?
Let me know if you need info. I can chroot into the original and the clone drives with no problem, and I can boot the original from grub on my desktop no problem.
Ryzen 5900X 12 core/24 thread - RTX 3090 FE 24 Gb, Asus B550-F Gaming MB, 128Gb Corsair DDR4, Cooler Master N300 chassis, 5 HD (2 NvME PCI, 4SSD) + 1 x optical.
Linux user #545703
/ is the root of all problems.
Offline
First thing, you changed hardware, so boot the fallback initramfs.
Offline
is there a reason you stuck to syslinux instead of using something more modern? or is the hardware about as old (10+ years)?
also: don't expect a 1-to-1 copy behave as such - obviously something is different - how about just wipe the drive and start from scratch?
Offline
how about just wipe the drive and start from scratch?
Why do you keep going there for things that are potentially trivial to fix? That should be a last resort, not something you suggest for every little problem.
Offline
I haven't changed any hardware apart from the installation drive, and the UUID on the old and new drive are identical. I can't seem to boot anything on the cloned drive.
syslinux is used precisely because this is a portable installation, intended to be plugged in to any computer and boot from it. The original drive works just fine for this purpose.
I just don't know why it's looking for /dev/sde1 (in this case). Literally nothing that I can see references the drives by the /dev/XXX assignment.
Ryzen 5900X 12 core/24 thread - RTX 3090 FE 24 Gb, Asus B550-F Gaming MB, 128Gb Corsair DDR4, Cooler Master N300 chassis, 5 HD (2 NvME PCI, 4SSD) + 1 x optical.
Linux user #545703
/ is the root of all problems.
Offline
However, when I boot using the newly created drive, it fails that it can't find /dev/sde1. I have no idea what is causing it to look for /dev/sdxX at all.
If you're seeing something like "/dev/sde1" then you're already past the boot loader and are booting something.
Post the exact message that you see.
Possibly related, but although the portable drive is set as bootable, it isn't directly available to boot from anymore.
How exactly did you "set it as bootable"?
Since you can chroot, I quick way to try a fix would be to wipe the drive's MBR bootstrap code area with dd (be very careful and check that you're targeting the correct drive with the of= parameter), then mount your partitions and reinstall the syslinux bootloader (e.g. using syslinux-install_update -iam).
Offline
cryptearth wrote:how about just wipe the drive and start from scratch?
Why do you keep going there for things that are potentially trivial to fix? That should be a last resort, not something you suggest for every little problem.
because it's the path of least resistance - and given the stuff you seem to refer to could had prevent the pittfalls if used in the first place
OP stated they used clonezilla
ok - so I don't know clonezilla and hence can only rely on public available information that it is able to do a 1-to-1 block copy and hence also clone partition information
the fact that the cloned drive failed hints towards this low-level clone either failed or wasn't requested and hence the partition information has changed leading to the reported issue
if OP would had already started by just wiping the second drive and do a fresh install of both arch and the chosen bootloader chances are higher that this would have worked right the first time
instead OP wasted time to figure out clonezilla - seem to have failed with that approach - and now requesting others to solve this which in turn requires additional time and effort to first analyze OPs current situation
yes, I am well aware that linux is by far more simpler to fix than windows - bit about 20 years of experience having imaged dozens of systems backs me up here: sometimes the simplest solution is also the fastest one: just start over from scratch - which would also had been true here
I'm just the asshole comming upfront with the sledgehammer right away instead of wasting time and effort with a pair of pliers
yes, maybe a simple "regenerate the initrd" could be a possible solution - but if I had encountered that issue I wouldn't have even bothered with starting a topic - let alone the cloning in the first place - I would had gone straight
wipefs
cfdisk
pacstrap
grub-install
and ha a working medium in less than it would haven taken me to start this topic
time is money after all - even my free time
Offline
Pages: 1