Re: [yocto] Can't boot to initramfs
Hello Moritz, I need here some help from you. I'll try to reconstruct the parts of the local.conf you are using, so I (and Jupiter) can understand what should we do to also bundle kernel image with initramfs, to end up in Dracut/rescue shell. Here is what I anticipate after reading several YOCTO @ threads: IMAGE_FSTYPES_append = " cpio.gz" INITRAMFS_IMAGE = "core-image-minimal-initramfs" INITRAMFS_IMAGE_BUNDLE = "1" # debug: adds debug boot parameters like 'shell' and 'debug', see # meta/recipes-core/initrdscripts/initramfs-framework/debug for details # Could be removed in more minimal product image PACKAGE_INSTALL += "initramfs-module-debug" Could you, please, review these lines and fix, if something is not correct? I what I understood, this does the magic, but you could not stop in initramfs shell? Still, this problem is not solved? > I was following this site: https://wiki.debian.org/InitramfsDebug > Rescue shell (also known as initramfs shell) > Read man initramfs-tools to learn about the break=something kernel > parameter (where valid arguments for something are: top, modules, > premount, mount, mountroot, bottom, init), which starts a debug shell. > You can try, for example, break=premount. You can edit /boot/grub/grub.cfg > to add this to the end of the kernel line, or you can do it interactively > from the grub boot menu: "e" to edit, and "b" to boot once you've edited > the kernel line. Now, as my understanding is, you solved this problem actually adding to grub.cfg in command kernel line break=premount, and was able to stop in rescue shell?! Am I correct here? Thank you, Zoran ___ On Mon, Jul 1, 2019 at 4:33 PM Moritz Porst wrote: > > Hello, > I think I found the issue. ( see below ) > > On 01.07.19 15:57, Zoran Stojsavljevic wrote: > > Hello Moritz, > > Too hot here, in Belgrade... Where I am resting for the Time being > (actually, this message given to my invisible spying security "angels" > on this list)... :-) Projected +38C degrees today. Too hot for this > too old Siberian untouchable bobcat! > > Luckily it's a rather cold day in germany, thanks that you still take the > time to answer ! > > I started from the core-image-minimal to have a small image and > extended it with the features I need, which is e.g. a graphical system. > The console=[...] part in the kernel command line is probably a > remnant but my image boots into the GUI. Is this a problem ? > > Nope, it is not. If you need to do it correctly, you should use > bitbake -k core-image-sato build command (my best educated guess). > Then, I do not feel comfortable seeing in your kernel command line > serial interface, do you agree? > > Yes that is true. > > YOCTO maintainers, any additional > advices? > > My bootloader is currently grub, the EFI is AM. > > Nope. Ek. Wrong. Currently, your boot-loader is UEFI AMI. Your > OS (Linux probably, U name it) boot-loader is GRUB2. Let us keep it > contained, sane and sober. > > Sorry but I can't find this info in the EFI. > > Could you, please try the following command being root: dmesg | grep > MCU. or grep mcu, or grep CPUID or grep cpuid?? Please, post results > to this list (to me). > > No luck unfortunately (used grep -i) > > Could you, also, send to YOCTO list/me attached file: > /boot/microcode.cpio so I can somehow (?) inspect it? ;-) > > I send it to you directly, so I don't spam the list with a large attachment. > > 2GB, single channel. > > All Cool. E3825 by HW/silicon design could/does NOT support multiple > memory channels. ONLY single... But even YOCTO primes (INTEL ones from > this list) are not gonna tell this to you. Not 'cause they are nasty. > They are NOT aware/they are ignorant (with the purpose)! ;-)) > > No, the boot does not stop. Even if I do issue "break=premount" I > end up in my graphical interface with the rootfs mounted. This is the > last message in the log: EXT4-fs (sdb2): re-mounted. Opts: (null) > The rootfs partition is always 2, so either /dev/sda2 or /dev/sdb2 > (when booting from stick) > > Yes, from https://pastebin.com/ya7iCtq7, so it is remounted rw, not > read only. So, it seems that you have passed dracut phase. and mounted > SD or flash rootfs. So, initramfs is NOT your true problem, is it??? > > The thing is that the boot works but I want an initramfs that can be used for > updating (in case the rootfs is broken). However I need to be able to > intercept the boot process there because otherwise I can't deploy an update > mechanism, that's what I was trying. > > Zoran > ___ > > > No, the boot does not stop. Even if I do issue "break=premount" I end up > in my graphical interface with the rootfs mounted. This is the last message > in the log: EXT4-fs (sdb2): re-mounted. Opts: (null) The rootfs partition is > always 2, so either /dev/sda2 or /dev/sdb2 (when booting from stick) > > > So for the issue... > I expected yocto to put the bundled bzImage onto my rootfs. This was not the > case. My image directory contains 2x
[yocto] Image not staring after upgrade from sumo to thud
Hi all, I have several platforms and I have upgrade Yocto from sumo to thud. Most of them works fine after the upgrade, but some of them are not starting. Basically after I install the image and I have chose my OS in grub, the system reboot. But if I create the image using sumo, the image is working fine. My system is a x86 arch. I have read the guide for migrating from sumo to thud and I was using COMPATIBLE_MACHINE for kernel multiconfig. I have fix this because it's known issue. But other than that, I don't know why it's not working (also because most of the other platforms are working as with sumo). Any suggestions? Thank you. Best, Pierluigi -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Can't boot to initramfs
Hello Zoran, Jupiter and list The configuration you sent seems to be correct. As I already said initramfs seems overly complicated in yocto. the most important thing to note is that 2 kernel images are created, one is called bzImage (in my case) an the other bzImage-initramfs. However only the bzImage is written into the rootfs so you have to exchange them manually. (in /boot/bzImage). I did not find a way of including the bundled kernel right away. What you can do is to build core-image-minimal-initramfs and delete the symbolic link "bzImage", then recreate it and let it point to bzImage-initramfs. However this is rather a hack than a solution. An other mistake I made was to use IMAGE_INSTALL_append which is ignored. Use PACKAGE_INSTALL_append. Also I found that "break" does not work as a kernel parameter. Use "shell" oder "debug-shell" instead. If you want to try to boot into initramfs you can remove all parameters to the booting line so you either end up in a kernel panic (initramfs doesn't work) or in the rescue shell (initramfs works). In the end I actually managed to get a working shell, but I often ended up in initramfs telling me "dropping to shell..." but then freezing. I don't have access to my files right now but I can tell you more on my setup tomorrow. In case the solution is not included above. Best regards Moritz On 11/07/2019 09:24, Zoran Stojsavljevic wrote: Hello Moritz, I need here some help from you. I'll try to reconstruct the parts of the local.conf you are using, so I (and Jupiter) can understand what should we do to also bundle kernel image with initramfs, to end up in Dracut/rescue shell. Here is what I anticipate after reading several YOCTO @ threads: IMAGE_FSTYPES_append = " cpio.gz" INITRAMFS_IMAGE = "core-image-minimal-initramfs" INITRAMFS_IMAGE_BUNDLE = "1" # debug: adds debug boot parameters like 'shell' and 'debug', see # meta/recipes-core/initrdscripts/initramfs-framework/debug for details # Could be removed in more minimal product image PACKAGE_INSTALL += "initramfs-module-debug" Could you, please, review these lines and fix, if something is not correct? I what I understood, this does the magic, but you could not stop in initramfs shell? Still, this problem is not solved? I was following this site: https://wiki.debian.org/InitramfsDebug Rescue shell (also known as initramfs shell) Read man initramfs-tools to learn about the break=something kernel parameter (where valid arguments for something are: top, modules, premount, mount, mountroot, bottom, init), which starts a debug shell. You can try, for example, break=premount. You can edit /boot/grub/grub.cfg to add this to the end of the kernel line, or you can do it interactively from the grub boot menu: "e" to edit, and "b" to boot once you've edited the kernel line. Now, as my understanding is, you solved this problem actually adding to grub.cfg in command kernel line break=premount, and was able to stop in rescue shell?! Am I correct here? Thank you, Zoran ___ On Mon, Jul 1, 2019 at 4:33 PM Moritz Porst wrote: Hello, I think I found the issue. ( see below ) On 01.07.19 15:57, Zoran Stojsavljevic wrote: Hello Moritz, Too hot here, in Belgrade... Where I am resting for the Time being (actually, this message given to my invisible spying security "angels" on this list)... :-) Projected +38C degrees today. Too hot for this too old Siberian untouchable bobcat! Luckily it's a rather cold day in germany, thanks that you still take the time to answer ! I started from the core-image-minimal to have a small image and extended it with the features I need, which is e.g. a graphical system. The console=[...] part in the kernel command line is probably a remnant but my image boots into the GUI. Is this a problem ? Nope, it is not. If you need to do it correctly, you should use bitbake -k core-image-sato build command (my best educated guess). Then, I do not feel comfortable seeing in your kernel command line serial interface, do you agree? Yes that is true. YOCTO maintainers, any additional advices? My bootloader is currently grub, the EFI is AM. Nope. Ek. Wrong. Currently, your boot-loader is UEFI AMI. Your OS (Linux probably, U name it) boot-loader is GRUB2. Let us keep it contained, sane and sober. Sorry but I can't find this info in the EFI. Could you, please try the following command being root: dmesg | grep MCU. or grep mcu, or grep CPUID or grep cpuid?? Please, post results to this list (to me). No luck unfortunately (used grep -i) Could you, also, send to YOCTO list/me attached file: /boot/microcode.cpio so I can somehow (?) inspect it? ;-) I send it to you directly, so I don't spam the list with a large attachment. 2GB, single channel. All Cool. E3825 by HW/silicon design could/does NOT support multiple memory channels. ONLY single... But even YOCTO primes (INTEL ones from this list) are not gonna tell this to you. Not 'cause they are nasty. They are NOT aware/they are ignor
Re: [yocto] Can't boot to initramfs
Moritz, Thank you very much for this reply. It makes it very clear... What is the current State of Affairs for the topic. Let us see if there will be the improvement to this topic. I'll document this on one of my private GitHubs. And archive this email. Zoran ___ On Thu, Jul 11, 2019 at 12:39 PM Moritz Porst wrote: > > Hello Zoran, Jupiter and list > > The configuration you sent seems to be correct. > > As I already said initramfs seems overly complicated in yocto. the most > important thing to note is that 2 kernel images are created, one is > called bzImage (in my case) an the other bzImage-initramfs. However only > the bzImage is written into the rootfs so you have to exchange them > manually. (in /boot/bzImage). I did not find a way of including the > bundled kernel right away. > > What you can do is to build core-image-minimal-initramfs and delete the > symbolic link "bzImage", then recreate it and let it point to > bzImage-initramfs. However this is rather a hack than a solution. > > An other mistake I made was to use IMAGE_INSTALL_append which is > ignored. Use PACKAGE_INSTALL_append. > > Also I found that "break" does not work as a kernel parameter. Use > "shell" oder "debug-shell" instead. If you want to try to boot into > initramfs you can remove all parameters to the booting line so you > either end up in a kernel panic (initramfs doesn't work) or in the > rescue shell (initramfs works). > > In the end I actually managed to get a working shell, but I often ended > up in initramfs telling me "dropping to shell..." but then freezing. > > I don't have access to my files right now but I can tell you more on my > setup tomorrow. In case the solution is not included above. > > Best regards > Moritz > > On 11/07/2019 09:24, Zoran Stojsavljevic wrote: > > Hello Moritz, > > > > I need here some help from you. I'll try to reconstruct the parts of > > the local.conf you are using, so I (and Jupiter) can understand what > > should we do to also bundle kernel image with initramfs, to end up in > > Dracut/rescue shell. > > > > Here is what I anticipate after reading several YOCTO @ threads: > > > > IMAGE_FSTYPES_append = " cpio.gz" > > INITRAMFS_IMAGE = "core-image-minimal-initramfs" > > INITRAMFS_IMAGE_BUNDLE = "1" > > # debug: adds debug boot parameters like 'shell' and 'debug', see > > # meta/recipes-core/initrdscripts/initramfs-framework/debug for details > > # Could be removed in more minimal product image > > PACKAGE_INSTALL += "initramfs-module-debug" > > > > Could you, please, review these lines and fix, if something is not correct? > > > > I what I understood, this does the magic, but you could not stop in > > initramfs shell? Still, this problem is not solved? > > > >> I was following this site: https://wiki.debian.org/InitramfsDebug > >> Rescue shell (also known as initramfs shell) > >> Read man initramfs-tools to learn about the break=something kernel > >> parameter (where valid arguments for something are: top, modules, > >> premount, mount, mountroot, bottom, init), which starts a debug shell. > >> You can try, for example, break=premount. You can edit /boot/grub/grub.cfg > >> to add this to the end of the kernel line, or you can do it interactively > >> from the grub boot menu: "e" to edit, and "b" to boot once you've edited > >> the kernel line. > > Now, as my understanding is, you solved this problem actually adding > > to grub.cfg in command kernel line break=premount, and was able to > > stop in rescue shell?! Am I correct here? > > > > Thank you, > > Zoran > > ___ > > > > > > On Mon, Jul 1, 2019 at 4:33 PM Moritz Porst wrote: > >> Hello, > >> I think I found the issue. ( see below ) > >> > >> On 01.07.19 15:57, Zoran Stojsavljevic wrote: > >> > >> Hello Moritz, > >> > >> Too hot here, in Belgrade... Where I am resting for the Time being > >> (actually, this message given to my invisible spying security "angels" > >> on this list)... :-) Projected +38C degrees today. Too hot for this > >> too old Siberian untouchable bobcat! > >> > >> Luckily it's a rather cold day in germany, thanks that you still take the > >> time to answer ! > >> > >> I started from the core-image-minimal to have a small image and > >> extended it with the features I need, which is e.g. a graphical system. > >> The console=[...] part in the kernel command line is probably a > >> remnant but my image boots into the GUI. Is this a problem ? > >> > >> Nope, it is not. If you need to do it correctly, you should use > >> bitbake -k core-image-sato build command (my best educated guess). > >> Then, I do not feel comfortable seeing in your kernel command line > >> serial interface, do you agree? > >> > >> Yes that is true. > >> > >> YOCTO maintainers, any additional > >> advices? > >> > >> My bootloader is currently grub, the EFI is AM. > >> > >> Nope. Ek. Wrong. Currently, your boot-loader is UEFI AMI. Your > >> OS (Linux probably, U name it) boot-loader is GRUB2. Let us keep it > >> contained, sane an
Re: [yocto] Can't boot to initramfs
Hey, The only thing I can add to what I already said is my "core-image-minimal-initramfs.bbappend": PACKAGE_INSTALL += "\ busybox \ base-files \ base-passwd \ bash \ util-linux-lsblk \ vim \ " Jupiter, are you able to produce your zImage-initramfs now ? If not further do the following: bitbake -e > tempfile [wait until done, then search] grep tempfile where may be e.g.: zImage, zImage-initramfs, INITRAMFS_IMAGE, INITRAMFS_IMAGE_BUNDLE Especially check that all variables you set are not overwritten somewhere else Best regards Moritz On 12.07.19 06:36, Zoran Stojsavljevic wrote: Moritz, Thank you very much for this reply. It makes it very clear... What is the current State of Affairs for the topic. Let us see if there will be the improvement to this topic. I'll document this on one of my private GitHubs. And archive this email. Zoran ___ On Thu, Jul 11, 2019 at 12:39 PM Moritz Porst wrote: Hello Zoran, Jupiter and list The configuration you sent seems to be correct. As I already said initramfs seems overly complicated in yocto. the most important thing to note is that 2 kernel images are created, one is called bzImage (in my case) an the other bzImage-initramfs. However only the bzImage is written into the rootfs so you have to exchange them manually. (in /boot/bzImage). I did not find a way of including the bundled kernel right away. What you can do is to build core-image-minimal-initramfs and delete the symbolic link "bzImage", then recreate it and let it point to bzImage-initramfs. However this is rather a hack than a solution. An other mistake I made was to use IMAGE_INSTALL_append which is ignored. Use PACKAGE_INSTALL_append. Also I found that "break" does not work as a kernel parameter. Use "shell" oder "debug-shell" instead. If you want to try to boot into initramfs you can remove all parameters to the booting line so you either end up in a kernel panic (initramfs doesn't work) or in the rescue shell (initramfs works). In the end I actually managed to get a working shell, but I often ended up in initramfs telling me "dropping to shell..." but then freezing. I don't have access to my files right now but I can tell you more on my setup tomorrow. In case the solution is not included above. Best regards Moritz On 11/07/2019 09:24, Zoran Stojsavljevic wrote: Hello Moritz, I need here some help from you. I'll try to reconstruct the parts of the local.conf you are using, so I (and Jupiter) can understand what should we do to also bundle kernel image with initramfs, to end up in Dracut/rescue shell. Here is what I anticipate after reading several YOCTO @ threads: IMAGE_FSTYPES_append = " cpio.gz" INITRAMFS_IMAGE = "core-image-minimal-initramfs" INITRAMFS_IMAGE_BUNDLE = "1" # debug: adds debug boot parameters like 'shell' and 'debug', see # meta/recipes-core/initrdscripts/initramfs-framework/debug for details # Could be removed in more minimal product image PACKAGE_INSTALL += "initramfs-module-debug" Could you, please, review these lines and fix, if something is not correct? I what I understood, this does the magic, but you could not stop in initramfs shell? Still, this problem is not solved? I was following this site: https://wiki.debian.org/InitramfsDebug Rescue shell (also known as initramfs shell) Read man initramfs-tools to learn about the break=something kernel parameter (where valid arguments for something are: top, modules, premount, mount, mountroot, bottom, init), which starts a debug shell. You can try, for example, break=premount. You can edit /boot/grub/grub.cfg to add this to the end of the kernel line, or you can do it interactively from the grub boot menu: "e" to edit, and "b" to boot once you've edited the kernel line. Now, as my understanding is, you solved this problem actually adding to grub.cfg in command kernel line break=premount, and was able to stop in rescue shell?! Am I correct here? Thank you, Zoran ___ On Mon, Jul 1, 2019 at 4:33 PM Moritz Porst wrote: Hello, I think I found the issue. ( see below ) On 01.07.19 15:57, Zoran Stojsavljevic wrote: Hello Moritz, Too hot here, in Belgrade... Where I am resting for the Time being (actually, this message given to my invisible spying security "angels" on this list)... :-) Projected +38C degrees today. Too hot for this too old Siberian untouchable bobcat! Luckily it's a rather cold day in germany, thanks that you still take the time to answer ! I started from the core-image-minimal to have a small image and extended it with the features I need, which is e.g. a graphical system. The console=[...] part in the kernel command line is probably a remnant but my image boots into the GUI. Is this a problem ? Nope, it is not. If you need to do it correctly, you should use bitbake -k core-image-sato build command (my best educated
Re: [yocto] Can't boot to initramfs
Forgot to CC Jupiter and the most important thing: PACKAGE_INSTALL += "initramfs-module-debug" (To my understanding this enables the rescue shell) On 12.07.19 08:22, Moritz Porst wrote: Hey, The only thing I can add to what I already said is my "core-image-minimal-initramfs.bbappend": PACKAGE_INSTALL += "\ busybox \ base-files \ base-passwd \ bash \ util-linux-lsblk \ vim \ " Jupiter, are you able to produce your zImage-initramfs now ? If not further do the following: bitbake -e > tempfile [wait until done, then search] grep tempfile where may be e.g.: zImage, zImage-initramfs, INITRAMFS_IMAGE, INITRAMFS_IMAGE_BUNDLE Especially check that all variables you set are not overwritten somewhere else Best regards Moritz On 12.07.19 06:36, Zoran Stojsavljevic wrote: Moritz, Thank you very much for this reply. It makes it very clear... What is the current State of Affairs for the topic. Let us see if there will be the improvement to this topic. I'll document this on one of my private GitHubs. And archive this email. Zoran ___ On Thu, Jul 11, 2019 at 12:39 PM Moritz Porst wrote: Hello Zoran, Jupiter and list The configuration you sent seems to be correct. As I already said initramfs seems overly complicated in yocto. the most important thing to note is that 2 kernel images are created, one is called bzImage (in my case) an the other bzImage-initramfs. However only the bzImage is written into the rootfs so you have to exchange them manually. (in /boot/bzImage). I did not find a way of including the bundled kernel right away. What you can do is to build core-image-minimal-initramfs and delete the symbolic link "bzImage", then recreate it and let it point to bzImage-initramfs. However this is rather a hack than a solution. An other mistake I made was to use IMAGE_INSTALL_append which is ignored. Use PACKAGE_INSTALL_append. Also I found that "break" does not work as a kernel parameter. Use "shell" oder "debug-shell" instead. If you want to try to boot into initramfs you can remove all parameters to the booting line so you either end up in a kernel panic (initramfs doesn't work) or in the rescue shell (initramfs works). In the end I actually managed to get a working shell, but I often ended up in initramfs telling me "dropping to shell..." but then freezing. I don't have access to my files right now but I can tell you more on my setup tomorrow. In case the solution is not included above. Best regards Moritz On 11/07/2019 09:24, Zoran Stojsavljevic wrote: Hello Moritz, I need here some help from you. I'll try to reconstruct the parts of the local.conf you are using, so I (and Jupiter) can understand what should we do to also bundle kernel image with initramfs, to end up in Dracut/rescue shell. Here is what I anticipate after reading several YOCTO @ threads: IMAGE_FSTYPES_append = " cpio.gz" INITRAMFS_IMAGE = "core-image-minimal-initramfs" INITRAMFS_IMAGE_BUNDLE = "1" # debug: adds debug boot parameters like 'shell' and 'debug', see # meta/recipes-core/initrdscripts/initramfs-framework/debug for details # Could be removed in more minimal product image PACKAGE_INSTALL += "initramfs-module-debug" Could you, please, review these lines and fix, if something is not correct? I what I understood, this does the magic, but you could not stop in initramfs shell? Still, this problem is not solved? I was following this site: https://wiki.debian.org/InitramfsDebug Rescue shell (also known as initramfs shell) Read man initramfs-tools to learn about the break=something kernel parameter (where valid arguments for something are: top, modules, premount, mount, mountroot, bottom, init), which starts a debug shell. You can try, for example, break=premount. You can edit /boot/grub/grub.cfg to add this to the end of the kernel line, or you can do it interactively from the grub boot menu: "e" to edit, and "b" to boot once you've edited the kernel line. Now, as my understanding is, you solved this problem actually adding to grub.cfg in command kernel line break=premount, and was able to stop in rescue shell?! Am I correct here? Thank you, Zoran ___ On Mon, Jul 1, 2019 at 4:33 PM Moritz Porst wrote: Hello, I think I found the issue. ( see below ) On 01.07.19 15:57, Zoran Stojsavljevic wrote: Hello Moritz, Too hot here, in Belgrade... Where I am resting for the Time being (actually, this message given to my invisible spying security "angels" on this list)... :-) Projected +38C degrees today. Too hot for this too old Siberian untouchable bobcat! Luckily it's a rather cold day in germany, thanks that you still take the time to answer ! I started from the core-image-minimal to have a small image and extended it with the features I need, which is e.g. a graphical system. The console=[...] part in the kernel command line is probab
