Re: chroot into a debootstrap filesystem and the numerous problems

On 9/6/25 16:24, John Paul Adrian Glaubitz wrote:
> Hi,
> 
> On Sat, 2025-09-06 at 15:08 -0400, Dennis Clarke wrote:
>> Well firstly I am thankful for the documentation. This is a highly
>> functional maillist lately. Well, the debootstrap process went amazingly
>> smooth :
> 
> You're welcome. I'm only answering briefly for today because I have backpain
> and need some rest for the remainder of the day.
> 

I can relate. This whole "age" thing has a long term cost.


>> [   23.133458] Kernel panic - not syncing: VFS: Unable to mount root fs
>> on unknown-block(0,0)
>> [   23.242118] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted
>> 6.12.3-sparc64-smp #1  Debian 6.12.3-1+sparc64
>> [   23.370232] Call Trace:
>> [   23.402325] [<0000000000ef8e70>] dump_stack+0x8/0x18
>> [   23.467584] [<0000000000eeb430>] panic+0xf4/0x398
>> [   23.529407] [<00000000013af7f4>] mount_root_generic+0x1cc/0x268
>> [   23.607236] [<00000000013afa1c>] mount_root+0x18c/0x19c
>> [   23.675914] [<00000000013afc4c>] prepare_namespace+0x220/0x25c
>> [   23.752597] [<00000000013af218>] kernel_init_freeable+0x284/0x29c
>> [   23.832713] [<0000000000ef9c08>] kernel_init+0x18/0x12c
>> [   23.901390] [<00000000004060c8>] ret_from_fork+0x1c/0x2c
>> [   23.971217] [<0000000000000000>] 0x0
>> [   24.018204] Press Stop-A (L1-A) from sun keyboard or send break
>> [   24.018204] twice on console to return to the boot prom
>> [   24.164596] ---[ end Kernel panic - not syncing: VFS: Unable to mount
>> root fs on unknown-block(0,0) ]---
> 
> Skimming through the messages, it does not look like the kernel has any
> block devices drivers loaded, so it doesn't see your disks. I'm also not
> seeing the kernel message about unpacking the initramfs, so that's not
> surprising.

I saw that also. I rebuilt the initrd with every driver I could find.

> 
> It should look like this (with a different timestamp, of course):
> 
> [    0.960540] Trying to unpack rootfs image as initramfs...
> 
> Did you verify that the symbolic links in silo.conf point to the correct
> vmlinux and initrd images?
> 
> You have:
> 
> # cat  silo.conf
> root=/dev/sdb4
> partition=1
> default=Linux
> read-only
> timeout=100
> 
> image=/vmlinux
>           label=Linux
>           initrd=/initrd.img
> 
> root=UUID=61ac8441-3afa-4ed1-99b6-8278877bda12
> 
> Notice that you specified "root=" twice. Try putting the one with the UUID
> into line 1.
>

I was very careful with that. Over and over and over. I can boot the
3.2.0 Linux stuff no problem. I have been trying all manner of
combinations with silo.conf and generally I see a "Fast Data MMU miss"
error or I see some other silo early boot problem.


> Also, where do /vmlinux and /initrd.img point to? They need to point to the kernel
> and initrd image that you want to load. Please make sure those are not dangling
> symlinks.
> 

I was very careful with that.

>> I suspect that silo.conf can not actually use the UUID data.
>> Just a guess.
> 
> You can also try to pass the command on the kernel command line:
> 
> boot: Linux initrd=/boot/initrd.img-6.12.3-sparc64-smp root=UUID=61ac8441-3afa-4ed1-99b6-8278877bda12
> 

Now that looks like a great idea !