David wrote on 1/24/26 11:03 AM:
(I am re-sending the message below, because I mistakenly sent it privately to Doc 18 hours ago, instead of to the list, and we both agree that it's better to keep all disussion on the list)
Likewise, below is what I sent David privately at the time. The issue about cp v. mount seems to have been decided by people who understand these things in favour of the latter, so that's what I did, as shown in e-mail <[email protected]>.
---- David wrote on 1/23/26 4:09 PM: > > Hi, thanks for making the effort to communicate well. I do try, even though I don't always succeed. > I'm not going to shout at you because I'm not that kind of person. > Just wanted to respond briefly ... > > I've never used 'cp /dev' command to setup 'chroot', I think 'mount --bind' > is the modern and safer method. > Yes, I'm thinking about doing that; I've been kind of waiting to see whether Alain has a comment on that particular line. Stefan originally said, when introducing the idea of the "mount --bind" command: > AFAIK nowadays `/dev` is normally stored in another filesyste, > dynamically populated. So you don't want to copy it to your > root filesystem. But then, if I understood him correctly, Alain gave the fact of the dynamic population (because it's a udev filesystem) as the reason why it's safe to perform the copy: > >> So here I have a question. This looks like it will try to copy the /dev/ >> from the running OS (i.e., the non-RAID drive) and overwrite the /dev that >> is on the RAID disk. >> >> Why would one do that? The /dev that was on the RAID disk worked fine until >> the other drive of the pair failed; so why does it need to be overwritten by >> the >> /dev from the running system? > > If you type the following it will tell you that /dev is a udev file system: > > df -h > > This is where device files are created on the fly as needed. > > You need /dev/sda* and a few others - the easiest way is to copy from the live > system. When you reboot into your recovered system the contents that you copy > should be wiped out (or mounted over). > He seems very sure that his way will work and is reasonable. I'm not in a position to judge the merits of one way (bind) over the other (cp). But I must say that "mount --bind" _looks_ safer than a copy. > I'm also not going to checking through the rest of the above because > it looks like pointless effort, unless you find that grub-rescue does > not work for you, as I wrote previously. Fixing this kind of situation I looked at the documentation to which you pointed, and I found it basically incomprehensible. Unless I missed something, it certainly didn't seem to give a step-by-step procedure for doing what needs to be done. The documentation said: > # Inspect the current prefix (and other preset variables): > set > # Find out which devices are available: > ls > # Set to the correct value, which might be something like this: > set prefix=(hd0,1)/grub > set root=(hd0,1) > insmod normal > normal Saying "set to the correct value, which might be something like" leaves me just shaking my head, and not having any idea what I'm actually supposed to type. If I try to boot from the RAID disk, which drops me into grub rescue, then type "ls", it responds with: (hd0) (fd0) If I type "set", it responds with: prefix='(hd0)/BOOT/debain@/grub' root='hd0' which is basically a pair of magic incantations to me. > But, I don't mind what you do, have fun with it, let us know how > it works out 🙂 "fun" is not a word that springs immediately to my mind 🙁 When I used a couple of seemingly-well-regarded rescue disks that are supposed to make this easy (supergrub2 and rescatux), before I posted the problem on the reflector, they both complained about unknown filesystems on the disk and wouldn't let me do anything useful. That was the point at which I knew I needed help. Doc -- Web: http://enginehousebooks.com/drevans
