..."cp -r /dev/ /tmp/RFS/dev/"? is wrong! Don't do that.
So, given all the above, I intend to proceed with:
cp -r /dev/ /tmp/RFS/dev/
chroot /tmp/RFS /usr/bin/bash
grub-install /dev/sda
sync
exit
reboot
after I've given people a bit of time to shout at me not to do that if something in what I've written above looks bad.
On 1/23/26 20:29, D. R. Evans wrote:
...
So, given all the above, I intend to proceed with:
cp -r /dev/ /tmp/RFS/dev/
chroot /tmp/RFS /usr/bin/bash
grub-install /dev/sda
sync
exit
reboot
after I've given people a bit of time to shout at me not to do that if something in what I've written above looks bad."cp -r /dev/ /tmp/RFS/dev/"ÿ is wrong! Don't do that.
Think about it, "cp" command will copy block devices such as /dev/sda like files into /tmp/RFS, basically into itself until it runs out of free space.
On Sat, Jan 24, 2026 at 04:09:12PM +0500, Alexander V. Makartsev wrote:Not special files, that's right, but it will "unfold" symlinks, attributes
On 1/23/26 20:29, D. R. Evans wrote:
...
So, given all the above, I intend to proceed with:
cp -r /dev/ /tmp/RFS/dev/
chroot /tmp/RFS /usr/bin/bash
grub-install /dev/sda
sync
exit
reboot
after I've given people a bit of time to shout at me not to do that if something in what I've written above looks bad."cp -r /dev/ /tmp/RFS/dev/"ÿ is wrong! Don't do that.
Think about it, "cp" command will copy block devices such as /dev/sda like files into /tmp/RFS, basically into itself until it runs out of free space.
No it will not. It will copy the block/character devices as files of type b & c, this will result in /tmp/RFS/dev/ being 100k or so.
Doing a 'mount --bind' is, however, better than my suggestion of copying.absolutely this.
"cp -r /dev/ /tmp/RFS/dev/"? is wrong! Don't do that.
Think about it, "cp" command will copy block devices such as /dev/sda like files into /tmp/RFS, basically into itself until it runs out of free space.
There's been a bit of conflicting advice here; so here's a new thread, describing where I am in Alain's original suggested sequence (some of this is a recap from earlier e-mails):
So, given all the above, I intend to proceed with:
cp -r /dev/ /tmp/RFS/dev/
chroot /tmp/RFS /usr/bin/bash
grub-install /dev/sda
sync
exit
reboot
after I've given people a bit of time to shout at me not to do that if something in what I've written above looks bad.
Alexander V. Makartsev wrote on 1/24/26 4:09 AM:It looks like these warnings appear when you try to install grub into
? ? ? grub-install --target=i386-pc /dev/sda? ? #Install grub stage 1
and
stage 2 MBR bootloader into /dev/sda and /boot
Produces the following message twice:
? grub-install: warning: Couldn't find physical volume '(null)'. Some modules may be missing from core image.
That is followed by:
? Installation finished. No error reported.
Should I be worried about the two warning messages. (And, if so, what
do I do about them).
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:
On Sat, Jan 24, 2026 at 16:09:12 +0500, Alexander V. Makartsev wrote:
"cp -r /dev/ /tmp/RFS/dev/"ÿ is wrong! Don't do that.
Think about it, "cp" command will copy block devices such as /dev/sda like >> files into /tmp/RFS, basically into itself until it runs out of free space.
A reasonable guess, but it's not correct.
hobbit:~$ mkdir d1
hobbit:~$ mkfifo d1/pipe
hobbit:~$ cp -r d1 d2
hobbit:~$ ls -l d1 d2
d1:
total 0
prw-rw-r-- 1 greg greg 0 Jan 24 09:25 pipe|
d2:
total 0
prw-rw-r-- 1 greg greg 0 Jan 24 09:25 pipe|
=============================
hobbit:~$ ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 Jan 14 18:21 /dev/null
hobbit:~$ sudo mknod d1/null c 1 3
[sudo] password for greg:
hobbit:~$ sudo rm -rf d2
hobbit:~$ sudo cp -r d1 d2
hobbit:~$ ls -l d1 d2
d1:
total 0
crw-r--r-- 1 root root 1, 3 Jan 24 09:27 null
prw-rw-r-- 1 greg greg 0 Jan 24 09:25 pipe|
d2:
total 0
crw-r--r-- 1 root root 1, 3 Jan 24 09:27 null
prw-r--r-- 1 root root 0 Jan 24 09:27 pipe|
=============================
Of course, the bind mount solution is better than the cp solution in
this case. But the cp solution isn't as wrong as you believed. One
would probably want to use -a instead of -r, though, to copy the
permissions and ownerships.
The documentation said:to type.
# 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
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.
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 problemon
the reflector, they both complained about unknown filesystems on the diskand
wouldn't let me do anything useful. That was the point at which I knew I needed help.
On 1/24/26 07:33, Greg Wooledge wrote:
On Sat, Jan 24, 2026 at 16:09:12 +0500, Alexander V. Makartsev wrote:
"cp -r /dev/ /tmp/RFS/dev/"ÿ is wrong! Don't do that.
Think about it, "cp" command will copy block devices such as /dev/sda like
files into /tmp/RFS, basically into itself until it runs out of free space.
I remember, a number of years ago, getting caught by exactly this, I believe on an earlier version of Debian.[...]
Considering that things might have changed since then, I tried it, with the following results:
root@dyson:~# mkdir /mnt/test
root@dyson:~# cp /dev/sda1 /mnt/test
root@dyson:~# du /mnt/test
173870 /mnt/test
root@dyson:~# ll /mnt/test
total 173861
-rw-r----- 1 root root 535822336 Jan 24 18:22 sda1
root@dyson:~# ll /mnt/test/sda1
-rw-r----- 1 root root 535822336 Jan 24 18:22 /mnt/test/sda1
Back then, long, long time ago, cp was the only available, so those recipes still float around in the intrawebs, like ghost ships.
Alexander V. Makartsev wrote on 1/24/26 1:48 PM:
It looks like these warnings appear when you try to install grub into
disk which contains RAID array in a degraded state. [1]
Try to boot from this disk now, if boot will be successful then you've
done with grub and the next step is to replace missing drive and resync
the array.
OK, boot was NOT successful:
I received the error message: disk mduuid<8d86...0aed> not found, andYour case is interesting enough so I spun up a VM to try to reproduce
then it dropped me to the "grub rescue>" prompt.
I expect that the named missing disk is the one that contained the
running system (sdb) [which is a non-RAID disk, created just for the
purpose of allowing me to boot and execute all these commands].
However, I get the above message when I try to boot from the failed
disk, regardless of whether the non-RAID disk is in the machine.
D. R. Evans wrote on 1/24/26 2:26 PM:
Alexander V. Makartsev wrote on 1/24/26 1:48 PM:
It looks like these warnings appear when you try to install grub into
disk which contains RAID array in a degraded state. [1]
Try to boot from this disk now, if boot will be successful then you've
done with grub and the next step is to replace missing drive and resync
the array.
OK, boot was NOT successful:
I received the error message: disk mduuid<8d86...0aed> not found, andthen it
dropped me to the "grub rescue>" prompt.
Alexander V. Makartsev wrote:
My first guess is that you are using that non-RAID disk which somehow
still contains MD array metadata on it. Maybe all this time we were
recovering wrong disk? Is it possible that sda and sdb devices were
mixed
up during boot time?
D. R. Evans wrote:
Nope, definitely not. I am very careful, each time I boot, to make
sure which
disk is which, because I am aware that the mapping between device name
and
physical drive can and does change, and one needs to be very, very
careful
when issuing commands that they are going to affect the correct disk.
I had just a few minutes, and thought it would be worthwhile to quickly check this by going through the entire procedure to write the MBR again, very carefully (hoping that somehow I had made a mistake the first time)
-- but the result is exactly the same: the RAID disk doesn't boot, with
the same error message.
I just wanted to confirm to you that the failure doesn't seem to be
caused by my skipping a step or mistyping something or confusing which
disk is which.
I have to go and do other stuff now for at least several hours, but will
try to get back to working on the problem later today.
ÿ Doc
...
It turns out that the BIOS on the computer doesn't seem to provide any
way to boot from USB. The best I can do, as far as I can tell, is to
create a live DVD and boot from that.
So I have booted from a live CD (which is very slow, but does
eventually succeed), and made sure that the only hard drive in the
machine is the RAID device that I am trying to fix.
...
_Exactly_ what chroot command do you want me to type at this point?
...Just some ideas, there are more options to try, but they are extremely
That's the next thing to try to do, now that I have Internet access
back so that I can download and study the documents.
Alexander V. Makartsev wrote on 1/28/26 10:55 AM:I think it does.
That is strange, how old is your hardware? When you mentioned 2013 I was
thinking 4th gen Intel CPU and Haswell-era hardware, which should
support USB-boot.
OK... on the basis of the fact that you expected USB boot to work, I
just went and spent some time messing with the boot options, and found
a way to make it work. What I had not realised was that it was not
enough to select "USB-HDD" from the BIOS list, but I also had to then
go and look at the hard drive boot order, where a new entry had
appeared (at a low priority). Once I saw that and changed its priority
so that it was the preferred boot device, the machine booted fine from
the USB drive.
All this, I'm sure, is very elementary stuff... but if one has never encountered it before, as I have not, none of it was obvious.
So the next bit of your e-mail (about the motherboard and booting) no
longer applies.
...I imagine you could type at grub rescue prompt something like this:
I'll pause there, so you have a chance to look at that, and I have a
chance to look at the grub rescue stuff ... and also try put out
another (unrelated) urgent fire.
OK... on the basis of the fact that you expected USB boot to work, I just went
and spent some time messing with the boot options, and found a way to make it
work. What I had not realised was that it was not enough to select "USB-HDD" from the BIOS list, but I also had to then go and look at the hard drive boot
order, where a new entry had appeared (at a low priority). Once I saw that and
changed its priority so that it was the preferred boot device, the machine booted fine from the USB drive.
All this, I'm sure, is very elementary stuff... but if one has never encountered it before, as I have not, none of it was obvious.
...His prefix "/boot/grub" and "/" is inside md array, so <TAB>-asking
Before moving on from the "ls" step, the OP needs to see some
output that ends in /grub, at least resembling:
Grub> ls (hdX,msdosY)/boot/
\u2026 \u2026 \u2026 \u2026 \u2026 \u2026 grub/ \u2026 \u2026 \u2026 \u2026 \u2026
Grub> ls (hdX,msdosY)/boot/grub/
\u2026 a list of Grub directories Grub> \u2026 \u2026 grub.cfg \u2026 \u2026
at which point, these commands should work:
Grub> set prefix=(hdX,msdosY)/boot/grub
Grub> set root=hdX,msdosY
Grub> insmod normal
Grub> normal
giving access to all of Grub's commands.
On Thu 29 Jan 2026 at 16:46:40 (-0000), Bigsy Bohr wrote:
On 2026-01-28, D. R. Evans <doc.evans@gmail.com> wrote:
OK... on the basis of the fact that you expected USB boot to work, I just went
and spent some time messing with the boot options, and found a way to make it
work. What I had not realised was that it was not enough to select "USB-HDD"
from the BIOS list, but I also had to then go and look at the hard drive boot
order, where a new entry had appeared (at a low priority). Once I saw that and
changed its priority so that it was the preferred boot device, the machine
booted fine from the USB drive.
All this, I'm sure, is very elementary stuff... but if one has never
encountered it before, as I have not, none of it was obvious.
In fact, that's not my experience with an old and buggy BIOS. There's a
preferred boot order; it looks first for a hard disk, then for an optical
device, failing that a USB dongle, etc. That order can be altered, which
is logical.
Your experience relates to BIOSes similar to those in standard Intel
desktop mobos (like Rhinestone/Endeavour/Atlanta/Tucson/Seattle)
that I've used in the past, or all the Dells I've used since:
a neat list of potential targets, in order, and even telling you
nowadays which are present and which not.
But the OP's priority-promotion behaviour is quite normal for, say,
a PhoenixBIOS. It's just a shame that the OP hadn't discovered that
when the machine was first obtained (and could be expected to work
to spec or have a manual, or whatever).
With the PhoenixBIOS in particular, there are other undocumented
wrinkles too. Any indication that the machine /can/ boot from USB
depends on your having inserted a stick before you turn it on.
IOW you can navigate all around the BIOS menus with no whisper
of the term USB.
Worse, the same is true if you boot /with/ a USB stick inserted. You
have to /know/ to navigate to Hard Drive and press Enter in order to
see the first mention of "USB".
Worse still, you get false negatives: not every USB stick will work
from a stack of sticks, even when identical images are installed on
them all. And those that work may not work in every USB socket?
particularly on laptops, where they're scattered about the mobo
and might have different specs.
Any lack of success (bad stick or absence) will reset the BIOS,
erasing any trace in the BIOS that USB booting had been possible.
All of the above can be demonstrated by my Acer Travelmate 3201xci.
Cheers,
David.
| Sysop: | Jacob Catayoc |
|---|---|
| Location: | Pasay City, Metro Manila, Philippines |
| Users: | 5 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 19:04:08 |
| Calls: | 117 |
| Calls today: | 117 |
| Files: | 367 |
| D/L today: |
540 files (253M bytes) |
| Messages: | 70,845 |
| Posted today: | 26 |