I'm having trouble booting off my hard disk. I can boot off a flash drive then mount the hard disk and use it without trouble, but the directories are all off. Is there a way to remount, say /disk to / ? mount -o remount would seem to do this, but doesn't, possibly because / is already in use. I can execute individual commands with chroot, but the libraries are in the wrong place.

And not a backup in sight? /Sigh

You need to expand on: "The directories are all off."
If you can't simply rename these, say 32/64 bit libs incorrigibly mixed, one suggestion might be to boot on your live usb, and run from every relevant directory of the install dvd. It's simple to script this. I used this It spins some error when finished, but that's my PRIMITIVE scripting. You would need to add the '--reinstall' option after upgradepkg but before the filename. The usage is 'upgrade.sh /rootdir' and it will do the work in /rootdir. That should restore directory sanity.

Do you mean you can't access the directories?

Any encryption or other methods that is blocking the access on that HDD?

Booting how? LILO? Grub?

There are ways to fix problems like this but, if this is a fresh install that won't boot, it might be advisable to take B.K.'s suggestion and re-install. Take care to set up the boot device using the installation menu items. I hadn't used Slackware for years and botched that step the first time I ran the installer.

I read that as meaning that "/bin", "/usr", etc. are, after mounting the root partition, now seen as "/mnt/bin", "/mnt/usr", etc. (or whatever the mount point is/was). Nothing is going to work with that mess.

What is the exact issue, that will help give you proper guidance.
When system is booting (or trying to boot) from hard disk, do you see an error? You may have to press F2 to see the text.
Which OS and release?
Depending on issue, since you are able to boot to USB media and mount the hard disk, you need to backup your data first, and then figure out what is causing the issue.

Examine the chroot command. I see no reason why you should not boot off one drive, then use chroot to make the other drive your current root before starting any processes (or a gui desktop).

That said, all of this is a kludge. The more lasting option is to troubleshoot the problem, and correct whatever is causing the boot issue. You might need to replace the drive and reload your OS on new hardware, but only do that if the drive itself is failing. (Well, unless you like doing that for fun. In that case, go to and have fun!)

2 complete backups. I said nothing about data loss.

Booting is the problem, not data loss. The disk from which I am trying to boot was bootable when I removed it from the drive, so I am surprised that it won't boot now.



No. I can access everything, but because the only disk from which I can boot is a DVD or flash drive, and all my personal programs and data files are on the hard disk, they are now in /disk4/home/RandomTroll.

GRUB.

You read correctly.

Everything was already backed up. I didn't mention data loss; I have had none. I'm trying to figure out the problem. As it has been refractory, I asked if an imaginable stop-gap existed. I asked elsewhere about my boot problem. This is a separate question.

I call scripts: must I rewrite all of them to add chroot to their invocations of relocated executables?

duh

duh^2

It passes e2fsck -fcvy . This was my root drive for years. I replaced it with a larger drive but kept it for backup, so I'm surprised that it doesn't work

No one has asked, and you have not stated; is this disk formatted as MBR or GPT? Is the system its in now BIOS or EFI?

Picture is slightly clearer now. I presume your system was backed up from a live usb or similar as you don't want loads of XXX in /proc, /sys/, or any of the many places it turns up

I would check (fsck -fvy) the disks, if you believe nothing major is up with them. Poorly unmounted disks can have loads of Orphaned inodes, but that cleans up nicely. Then check grub is pointing approximately in the right place and set the disk/partition as /, turn off, change the hw so it is / and try for it.

IME, it's only when the disk is badly damaged that you need the 'c' option, which takes forever.

more clarity
You have removed the root drive from one location and installed it at another? If so, did you update grub to properly identify the new location? If not, that step may be all that is needed to make your drive boot properly.

If you use chroot to lock your session into the root of the desired drive, all scripts and processes run under that session will run in that environment. Only scripts that run from cron, at, batch, or other automation (outside that session environment) would have to be adjusted. Let us avoid that if we can. Check your grub configuration and see if you can fix that, making all of these other factors (including chroot) unnecessary.

In addition to the last comment, there's one niggle under chroot which stops you in odd places. Proc is absent. Toi remedy,

1 members found this post helpful.

With my recent install of Slackware I had the same problem, then I found that the root partition did not have a boot flag.

Installed a boot flag and the HDD boots problem free, so I can not help wondering if you are missing the boot flag.

Exactly how are you setting up the chroot? I find the following typically does what I need it to do:Possibly doing the same bind mount with /run might also be necessary with some of the newer systemd distros.