Botspot / vdesktop

Run a second instance of Raspbian inside Raspbian.
GNU General Public License v3.0
125 stars 21 forks source link

When booting old images of raspberry pi, why does it seem the new kernel is running? #34

Closed mikedorin closed 2 years ago

mikedorin commented 2 years ago

When I boot an old version of raspberry pi. Everything looks fine, but when I do a uname -a, it seems installed kernel is running, not the kernel from the old version. I would like a VM with the old kernel running. Is that not possible?? Thank you, -Mike

starbasessd commented 2 years ago

Curiosity, do you run sudo apt update & sudo apt upgrade before checking uname?

mikedorin commented 2 years ago

Curiosity, do you run sudo apt update & sudo apt upgrade before checking uname?

No, I don't. I will try the process again. Maybe I did something accidentally along the way.

starbasessd commented 2 years ago

I just did a full desktop Stretch image from 2017 (on a stripped current Buster desktop running on a Pi4b-8GB) and can confirm both report the current Buster kernel Linux raspi5 5.10.63-v7l+ #1457 SMP Tue Sep 28 11:26:14 BST 2021 armv7l GNU/Linux Interesting...

mikedorin commented 2 years ago

I just did a full desktop Stretch image from 2017 (on a stripped current Buster desktop running on a Pi4b-8GB) and can confirm both report the current Buster kernel Linux raspi5 5.10.63-v7l+ #1457 SMP Tue Sep 28 11:26:14 BST 2021 armv7l GNU/Linux Interesting...

I just need nearly the same exact test!

starbasessd commented 2 years ago

My process: I went and downloaded the image from 2017-09-07-raspbian-stretch. Placed the .img file in ~/vdesktop Ran the command: vdesktop ./2017-09-07-raspbian-stretch.img It booted up with no issue to the desktop. Opened the terminal window in the vdesktop and ran: uname -a got the response: Linux raspi5 5.10.63-v7l+ #1457 SMP Tue Sep 28 11:26:14 BST 2021 armv7l GNU/Linux closed the terminal, and ran shutdown Ran the uname -a command in another local terminal window, and received the response: Linux raspi5 5.10.63-v7l+ #1457 SMP Tue Sep 28 11:26:14 BST 2021 armv7l GNU/Linux I'm not sure what or why it's passing through the host kernel, instead of actually running the image kernel, other than there wasn't RPi4 support in the earlier kernels (obviously) and might get 'confused'. I will try a later (mid-last year) image and see if it also has the same issue...

starbasessd commented 2 years ago

I did the 2020-02-13 image, same thing.

starbasessd commented 2 years ago

From dmesg in the vdesktop running the 2020-02-13 Stretch [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 5.10.63-v7l+ (dom@buildbot) (arm-linux-gnueabihf-gcc-8 (Ubuntu/Linaro 8.4.0-3ubuntu1) 8.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #1457 SMP Tue Sep 28 11:26:14 BST 2021 [ 0.000000] CPU: ARMv7 Processor [410fd083] revision 3 (ARMv7), cr=30c5383d [ 0.000000] CPU: div instructions available: patching division code [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [ 0.000000] OF: fdt: Machine model: Raspberry Pi 4 Model B Rev 1.4 [ 0.000000] random: fast init done [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] Reserved memory: created CMA memory pool at 0x000000001ac00000, So it appears it doesn't use the /boot partition to boot from... Interesting...

Botspot commented 2 years ago

Simple answer: vdesktop is barely more than a chroot. It runs the guest system using the host's kernel.